Jump to content

[CR] Encryption


Recommended Posts

  • 2 weeks later...

I like this a lot.

One thing, for AES encryption the input text is immediately converted to ASCII hex. I think this might be a mistake. This results in putting plaintext in, cyfering it, then invcyfer does not result in the original text, it results in the ASCII hex representation of the original text. This is data bloat, and would require an additional converter to return the original text.

I would also support some kind of a primitive method of padding the key and initialization vector for ease of use.

~Jon

Link to comment

One thing, for AES encryption the input text is immediately converted to ASCII hex.

Jon, I don't see where this happens.

... then invcyfer does not result in the original text, it results in the ASCII hex representation of the original text. This is data bloat, and would require an additional converter to return the original text.

Inverse cypher returns the data just as the input of the cypher, however the control is set to HEX-display (very usefull during debuggin), if you drop a control based on that you definitly get something different than you expect, but you shouldn't need to use an additional conversion.

altrJ.png

I would also support some kind of a primitive method of padding the key and initialization vector for ease of use.

Yes/No, it would be nice if there is some standard of padding... I've looked throught several NIST documents and they only mention padding with 'nulls', not defining an official accepted form of padding. Note that padding depends on the type of block mode you use.

Ton

  • Like 1
Link to comment

Ack I didn't look closely enough. The output and input match. I saw that the Initialization vector/Cipher key were converted to bin from ASCII text, and I assumed that the message was also exhibiting this behavior. I suppose converting the cipher key from ascii is fine, it just through me off as I put in the correct sized key/vector and the function still output an error on cipher size until i found that it was converting from ASCII.

So the only change I would realistically like to see is that the default display for "message in" on encryption and "plaintext out" on inverse cipher be of the same display style so I don't fool myself again.

Again I really like this, I will use it on my config files so no one will try to mess with any binaries without me knowing again.

~Jon

Link to comment
  • 3 months later...
  • 2 months later...

Could you maybe code a quick example of the AES in action? I need some guidance in terms of the key size and text size. From my initial poking it looks like I'm going to need to pad the cipher text and that keys need to be a multiple of 16? I'm not intimately familiar with AES, so a little guidance or some notes would be nice.

Thanks, and I'm really happy to find a native implementation of AES in LV.

-Jody

Link to comment

Alright, I think I figured things out with regard to the VIs. I wrote two quick VIs to Pad/De-Pad the message input so that it can be divided into 16 byte blocks. I followed the PKCS7 standard (http://en.wikipedia....raphy)#CBC_mode). They're attached to this post.

I've also been trying to workout an implementation of PBKDF2 (http://en.wikipedia.org/wiki/PBKDF2) in LV native code, but it's probably overkill for my application - there are much easier attack vectors...

Hope these VIs help. Feel free to add them to the rest of the library.

-Jody

De-Pad Message String.vi

Pad Message String.vi

Link to comment

Alright, I think I figured things out with regard to the VIs. I wrote two quick VIs to Pad/De-Pad the message input so that it can be divided into 16 byte blocks. I followed the PKCS7 standard (http://en.wikipedia....raphy)#CBC_mode). They're attached to this post.

I've also been trying to workout an implementation of PBKDF2 (http://en.wikipedia.org/wiki/PBKDF2) in LV native code, but it's probably overkill for my application - there are much easier attack vectors...

Hope these VIs help. Feel free to add them to the rest of the library.

-Jody

Sweet.

The padding length (in most cases) is dependant on the size of the block (16=128 bit block) so it really needs to be configurable.

I've modified your padding VI (to account for the block length) and added the ANSI, ISO and PKCS5 (Ver 2.0) methods.

Link to comment
  • 9 months later...

I found this (https://decibel.ni.c.../docs/DOC-25034) on the NI forums today.

I think this is simply Ton's package posted on the NI forums.

If there is no difference, is this an appropriate thing for the person who posted this on NI to be doing?

It looks pretty much the same. Same filenames (mostly) and a few front panels are exactly the same. I reported the problem and it should be resolved shortly. Or at least that's what the 'report abuse' page told me.

- Mike

Link to comment

It looks pretty much the same. Same filenames (mostly) and a few front panels are exactly the same. I reported the problem and it should be resolved shortly. Or at least that's what the 'report abuse' page told me.

- Mike

From the VI description of the first random file I opened.

© Ton Plomp, 2011

THIS SOFTWARE IS PROVIDED AS IS, AND ANY WARRANTY IS REJECTED

Link to comment

I don't really have an issue on this (however some direct attribution/link would be nice).

However it brings up a strange angle in the whole NI.COM license discussion:

The code is licensed under the BSD (while I don't specify it, attribution should be given).

The ni.com license says 'Upload it and it belongs to us' (Shaun will love that wording)

So uploading / sharing the code under the BSD license on the internet is OK, UNLESS you post it to ni.com. (other sites might be banned as well).

Concluding the user is not breaking the BSD license, (if he attributes), but is breaking the ni.com EULA.

Ton

Link to comment

I don't really have an issue on this (however some direct attribution/link would be nice).

However it brings up a strange angle in the whole NI.COM license discussion:

The code is licensed under the BSD (while I don't specify it, attribution should be given).

The ni.com license says 'Upload it and it belongs to us' (Shaun will love that wording)

So uploading / sharing the code under the BSD license on the internet is OK, UNLESS you post it to ni.com. (other sites might be banned as well).

Concluding the user is not breaking the BSD license, (if he attributes), but is breaking the ni.com EULA.

Ton

I could argue many aspects of that. The windows API is a much stricter license however (Creative Commons Non-Commercial Share-Alike).

More importantly. In the case of the code that's taken from the windows API, an attempt has obviously been made to pass it off as original work (plagiarism in academic circles) otherwise, why change the icons, the distribution format, remove the attribution notices in the revision info and license file. That's just "not cricket" and should annoy you in terms of your code as much as it does me. I'm not saying that the person that posted it on NI.com did this (although they have opened themselves to the issue). They could have innocently picked it up from somewhere else. It does however highlight the importance of licensing and the validation. if not commercial gain, that some seek from the efforts of others.

Maybe a MOD can move these comments to the licensing thread so as not to gum up this support thread?

Edited by ShaunR
Link to comment
  • 2 years later...

Hi Ton,

 

You did a nice job with this! The code is both easy to read and easy to use.

Was your library ever incorporated into OpenG? I did not see it there, so I downloaded it from the link above. It would definitely be a useful addition to the OpenG libraries.

 

Thanks for sharing your work.

 

-Rob

 

 

  • Like 1
Link to comment
  • 2 years later...

Hi Ton,

I'm interested in getting an scrypt implementation in LabVIEW and so looking at using your library as a base. It requires the addition of PBKDF2. Are you interested in contributions to this library rather than forking it? If so it would be great to have a version with your test vectors as well and what version you would want to keep it in. Ideal would be a github repo.

If not we will crack on and just depend on what you have already.

Cheers,

James

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.