47 replies to this topic

[jgcode]

This OpenG Review is closed. See Summary Post here. Please start a new thread to discuss new changes to this VI. Please PM me if there are any issues with this thread.

Community,

This VI was in the Candidates folder for the String Package.



It has been sitting in there for a while therefore, I have just gone ahead and posted as is (so the license will be migrated on confirmation from the author etc...).

What are you thoughts on this VI?

• Would you like to see such a function in OpenG?
  
• Can you optimize the code?
  
• It may be better suited in e.g. Comparison Package?
  
• Should it be rejected?

Kind regards







Jonathon Green
OpenG Developer

 Is an MD5.vi   7.91K   136 downloads
 TEST - Is an MD5.vi   20.54K   128 downloads
Code is in LabVIEW 2009

[jgcode]

I propose that we use RegEx and clean up the BD.
Not sure of the best way to handle the error, above is an example to maintain the VI's interface.



 Is an MD5.vi   7.91K   60 downloads
Code is in LabVIEW 2009

[jcarmody]

A Regex would be slower, I would ignore the error (if using Match Regular Expression) and the \w will include non-hex characters.

[jgcode]

and the \w will include non-hex characters.

Of course! Thx!
Does it always have to be lower case hex only as per these examples?

[Phillip Brooks]

The RFC states that it must be lower case...

http://www.ietf.org/rfc/rfc2831.txt

Let HEX(n) be the representation of the 16 octet MD5 hash n as astring of 32 hex digits (with alphabetic characters always in lowercase, since MD5 is case sensitive).

Edited by Phillip Brooks, 29 August 2011 - 11:15 AM.

[jgcode]

A Regex would be slower, I would ignore the error (if using Match Regular Expression) and the \w will include non-hex characters.

Yes RegEx is slower but your code with Match Pattern does not pass the Test VI?
I don't think Match Pattern supports Quantifiers? I am not sure? (I always find myself looking up Match Pattern help as its different to RegEx)
Can anyone confirm - can we use MP for this (it is much faster).

Anyways here is the fix from using any alphanumeric to specifying a character class based on Phillip's post.
(Sorry, I cut, pasted and edit from the GUID thread - thanks for pointing that out)

I had to update the original Test VI to fail MD5's that contain [A-F] range (see new VI attached).

 Is an MD5.vi   19.5K   71 downloads
 TEST - Is an MD5.vi   20.61K   67 downloads
Code is in LabVIEW 2009

Attached Thumbnails

• 

[jcarmody]

My only comment is that the Regex doesn't need the pipe. I don't understand why Match Pattern doesn't work, but it definitely doesn't.

[jgcode]

My only comment is that the Regex doesn't need the pipe. I don't understand why Match Pattern doesn't work, but it definitely doesn't.

I can take the alternation metacharacter out if no one likes it in there - no dramas. (Unsure if it impacts performance or not).

[asbo]

Agreed, the alternation character is unnecessary. It'll work just the same, but it changes the logic of the expression (though it may have no performance impact).

The Match Pattern node does not support finite quantifiers, but dot and star work as expected. Because string length is an O(1) operation, maybe this is worth considering:



Edit: Oops, had a-z as the character range, when it should have been a-f.

[jgcode]

Agreed, the alternation character is unnecessary. It'll work just the same, but it changes the logic of the expression (though it may have no performance impact).

The Match Pattern node does not support finite quantifiers, but dot and star work as expected. Because string length is an O(1) operation, maybe this is worth considering:

That's quite clever, and would be faster than RegEx.

[Wouter]

My question... why would you ever want to test if a string looks like it is a md5 string?

Further I had much rather see VI's in OpenG which could create SHA1 and SHA2 hashes. Maybe ask Ton... https://bitbucket.or...rc/ee5c00d513e7

Edited by Wouter, 30 August 2011 - 11:38 AM.

[jgcode]

My question... why would you ever want to test if a string looks like it is a md5 string?

Most likely for data validation.
Of course the main reason for the review is verify whether this would be a useful function (and then how to implement it, if it is useful).

• Should it be rejected?

So, please continue to let us know either way.

[dannyt]

My question... why would you ever want to test if a string looks like it is a md5 string? Further I had much rather see VI's in OpenG which could create SHA1 and SHA2 hashes. Maybe ask Ton... https://bitbucket.or...rc/ee5c00d513e7

I sort of agree with the question above, what is the use case for checking a string just looks like an MD5 string, it is either a correct valid md5 string for something or it is not. Maybe I am just not seeing the obvious here.

Danny

[Phillip Brooks]

I sort of agree with the question above, what is the use case for checking a string just looks like an MD5 string, it is either a correct valid md5 string for something or it is not. Maybe I am just not seeing the obvious here.

Danny

Lets say you have a very large file that you want to verify (the LabVIEW 2011 image )

Before extracting and installing, you might want to verify the file. The time to generate the MD5 from the downloaded file may be significant. If you are going to compare the results of a time consuming operation with an invalid string, you will be wasting time (by re-downloading a file that may be good).

It is not easy to visually read or count the characters of an MD5 checksum...

[Ton Plomp]

If we are going to implement this, I wouldn't want it to be strict regarding the case, one of the reasons being that LabVIEW using %x formatter outputs uppercast hex-values.

Regarding the SHA hashes, yes my intention is to offer that code in the OpenG package, however I haven't got time to write unit tests for the SHA and HMAC hashing, though I have a complete set of unit test's for AES cyper/decypher routines.

Ton

[François Normandin]

This VI was in the Candidates folder for the String Package.

I'd find more natural to find this in the MD5 palette.

[jgcode]

In summary:

• Add this VI to OpenG
  
• Move to MD5 package
  
• Allow non-strict capitalization
  
• Implement code similar to this:

With the non-strict capitalization issue, could an optional Boolean flag called "Strict Capitalization" (default = F) be added to the interface?
Would that be a good feature to have?

[Ton Plomp]

If we are going to use this functionality, we nood to change the MD5 hash-vi with an extra output.
CUrrently the VI outputs a binary string, that should be converted to a hex-string to produce a valid MD5-hash.

[asbo]

I'm not sure I see the value in implementing a strict option. Unless you're actually evaluating whether something is following MD5 spec, the case of your hex string is irrelevant to the data it contains. There's trivial overhead in exposing the option to do this, but the execution of a mixed-case regular expression suffers ~20% performance penalty in some brief benchmarks.

I like Ton's idea RE: the hex string and would actually go as far to say that the string should be the only output - I've never had a use case where I need an MD5 in binary. It's always been for display or inclusion as a checksum (like VIPM does for package files and the like).

[jgcode]

...but the execution of a mixed-case regular expression suffers ~20% performance penalty in some brief benchmarks.

No, i was thinking that the flag would select the correct RegEx string to use in the MP primitive. So overhead should be negligible.