Jump to content
Sign in to follow this  
jgcode

MD5 Hash (MD5 Package)

Recommended Posts

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.

post-10325-0-01203200-1314576207.png

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

TEST - Is an MD5.vi

Code is in LabVIEW 2009

Share this post


Link to post
Share on other sites

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.

post-10325-0-62032400-1314606524.png

Is an MD5.vi

Code is in LabVIEW 2009

Share this post


Link to post
Share on other sites

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

post-7534-0-10196800-1314612257.png

post-7534-0-40661600-1314612644_thumb.pn

  • Like 1

Share this post


Link to post
Share on other sites

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
  • Like 1

Share this post


Link to post
Share on other sites

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

post-7534-0-10196800-1314612257.png

post-7534-0-40661600-1314612644_thumb.pn

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

TEST - Is an MD5.vi

Code is in LabVIEW 2009

post-10325-0-68391200-1314619191.png

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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:

post-13461-0-69352700-1314629366.png

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

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.org/tcplomp/labviewencryption/src/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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

In summary:

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

post-13461-0-69352700-1314629366.png

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
...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.

Share this post


Link to post
Share on other sites

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

Right, I was comparing the performance of /^[0-9a-f]$/ versus /^[0-9a-fA-F]$/. The addition of the second range of characters is where the 20% comes from.

(I should have included a snippet...)

Share this post


Link to post
Share on other sites

My only complaints are that of verbiage:

* "Strict Character Case" vs. "Strict Capitalization"

* "Is an MD5? returns TRUE if Input String represents an MD5 hash, otherwise it returns FALSE."

* "Valid characters are ..." vs. "Expected characters are ..."

Other than that, thanks for dedicating the time to this :)

Share this post


Link to post
Share on other sites

Other than that, thanks for dedicating the time to this :)

Likewise (to everyone who's posted too)

* "Is an MD5? returns TRUE if Input String represents an MD5 hash, otherwise it returns FALSE."

I changed everything else you mentioned but to be consistent I use the variable names so MD5? instead of Is an MD5?

post-10325-0-29527900-1316100425_thumb.p

post-10325-0-77081100-1316100343_thumb.p

Is an MD5.vi

TEST - Is an MD5.vi

Code is in LabVIEW 2009.

Share this post


Link to post
Share on other sites

I changed everything else you mentioned but to be consistent I use the variable names so MD5? instead of Is an MD5?

Ahh, that makes sense. Looks good!

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

  • Similar Content

    • By matteofara
      I'm trying to developed in LabView the algorithm used to generete localized key with MD5 defined in the rfc2574.
      maybe sombody already did it, is this code already available somewhere?
       
      thank you
      A.2.1. Password to Key Sample Code for MD5void password_to_key_md5( u_char *password, /* IN */ u_int passwordlen, /* IN */ u_char *engineID, /* IN - pointer to snmpEngineID */ u_int engineLength,/* IN - length of snmpEngineID */ u_char *key) /* OUT - pointer to caller 16-octet buffer */{ MD5_CTX MD; u_char *cp, password_buf[64]; u_long password_index = 0; u_long count = 0, i; MD5Init (&MD); /* initialize MD5 */ /**********************************************/ /* Use while loop until we've done 1 Megabyte */ /**********************************************/ while (count < 1048576) { cp = password_buf; for (i = 0; i < 64; i++) { /*************************************************/ /* Take the next octet of the password, wrapping */ /* to the beginning of the password as necessary.*/ /*************************************************/ *cp++ = password[password_index++ % passwordlen]; } MD5Update (&MD, password_buf, 64); count += 64; } MD5Final (key, &MD); /* tell MD5 we're done */ /*****************************************************/ /* Now localize the key with the engineID and pass */ /* through MD5 to produce final key */ /* May want to ensure that engineLength <= 32, */ /* otherwise need to use a buffer larger than 64 */ /*****************************************************/ memcpy(password_buf, key, 16); memcpy(password_buf+16, engineID, engineLength); memcpy(password_buf+16+engineLength, key, 16); MD5Init(&MD); MD5Update(&MD, password_buf, 32+engineLength); MD5Final(key, &MD); return;}
    • By drjdpowell
      This OpenG Review is closed. See Summary Post here. Please start a new thread to discuss new changes to this VI.
      Read this post for start of review.
      I’d like to suggest these three VIs (or similar) as possible LVOOP-object additions to the OpenG Toolkit:

      “Get Class Name” is a modification of “Get Name of Class of Object” posted by AQ. Here it just returns the basic class name (which I use often in custom probes and the like).
      "Get Default Object” is inspired by this discussion and uses AQ’s zero-iteration loop method. This is a very simple VI, but using it instead of the raw code is much clearer to the reader.
      “Same or child class” just uses “Preserve Runtime Class” as a tester. Again, the advantage here is code readability (or it will be, as soon as someone comes up with a good icon for it).
      Thoughts?
      — James
      OpenG Suggestions.zip
    • By Wouter
      This OpenG Review is closed. See Summary Post here. Please start a new thread to discuss new changes to this VI.
      VI Name:
      Supress error
      Total VIs:
      2
      Description:
      This VI has a integer (array), error code, as input and when the error code matches the error code on the error wire it supresses the error.
      Note:
      -
      Blockdiagram:
      Scalar:

      Array:

      Code:
      Supress Error.zip
      What are you thoughts on this VI?
      Would you like to see such a function in OpenG?
      Can you optimize the code?
      In which package should it be included?
      Should it be rejected?

    • By Phillip Brooks
      This OpenG Review is closed.
      Based on Jim's suggestion in my post Select Random Array Indices, I submit this VI: 'Random Int Number - Within range'.
      The existing OpenG Random Number VI would presumably be renamed and added to a polymorphic VI.
      I chose I32 data types for compatibility with array indexing functions. The default values of one and zero allow this to be used with 'Not Equal to Zero?' to simulate a coin toss.
      Discuss.

      Random Int Number - Within Range__ogtk.vi
      UPDATE:
      I was going to provide a link to the existing OpenG 'Random Number' documentation. A Google search found that Jim already submitted something similar to the old OpenG forums, see here. Jim mentions that the high and low are negatively biased and solves this by adding one to the high value and then rounding down.
      I think his is better. Rather than duplicate Jim's post and test code, is there a way we can import the discussion from the OpenG board to the LAVA board?
    • By jgcode
      This package will be available for download through VIPM in a few days and contains a small mod to the 4.1.0.8 release:
      [MOD] 3421698 - Message Digest Polymorphic VI should show instance icons


×
×
  • Create New...

Important Information

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