Jump to content
News about the LabVIEW Wiki! Read more... ×
Ton Plomp

[CR] Encryption

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Ton

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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).

  • Like 1

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

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