[CR] Encryption

[Ton Plomp]

Name: Encryption

Submitter: Ton Plomp

Submitted: 07 Sep 2011

Category: *Uncertified*

LabVIEW Version: 2010

License Type: BSD (Most common)

This package consist of a series of tools in native LabVIEW 2010 code.

For encryption/decription the AES (Rijndael) routine is used with key sizes of 128, 192 and 256 bytes.

The encryption supports the following block modes:

• EBC
  
• CBC
  
• CFB128
  
• OFB
  

For signing of string/packages it performs the SHA-1 and SHA-2 hashing, for MD5 hashing the OpenG functionality is used.

The hash functions return a binary string and a hex-formatted string with the hash.

The following hashes are supported:

• MD5 (via OpenG library)
  
• SHA1
  
• SHA-2 224 bit
  
• SHA-2 256 bit
  
• SHA-2 384 bit
  
• SHA-2 512 bit
  

For Hashed key authentication the HMAC functionality is provided based on the supported hash functions.

The used functions are tested against NIST public test vectors.

The use of these functions is not: secure the code does not try to protect it's memory nor the used keys.

© Ton Plomp 2011 - No warranty implied.

Click here to download this file

[Jon Kokott]

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

[Ton Plomp]

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.

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

[Jon Kokott]

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

[Val Brown]

Do you an AES key generator in native LV?

[Ton Plomp]

No, I don't the rules for an AES key are something I need to study first.

Ton

[Val Brown]

Ah so what do you use then to generate them?

[Ton Plomp]

Hello MrMike,

sorry to hear that it's confusing you. I can understand how that happenend. Currently I am resaving the library for LV2009, and I'll look at your comments and incorporate them in the code.

Ton

[JodyK]

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

[JodyK]

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

[ShaunR]

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.

[Phillip Brooks]

I found this (https://decibel.ni.com/content/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?

[Mr Mike]

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

[Darin]

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

[ShaunR]

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

Indeed. He has been a busy ;little squirrel.

This drives info is taken from my windows API (windows_api_Drives.llb).

[Phillip Brooks]

His icons are nicer than yours ;P

[ShaunR]

His icons are nicer than yours ;P

Well. in my defence. They were originally written in about 1997 before all the new fangled icon bitmap editing. When a customer complains about icons rather than bugs; maybe then I'll change them

[Ton Plomp]

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

[ShaunR]

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 December 20, 2012 by ShaunR

[Rob Calhoun]

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

 

 

[JamesMc86]

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