Making a hash of things



  •  As I've previously mentioned in the sidebar, I'm working on trying to clean up an existing Java codebase that my employer purchased from a third party.

    Part of the application pulls data from an external system and digests it into a local database. For one of the entities pulled across, a hash is computed for the database ID, though not just any hash:

    • multiple important data items from the object are concatenated together with System.currentTimeMillis() and Math.random()
    • this is run through MD5
    • some of the non-alphanumeric characters ('+', '/') are replaced by others
    • the whole thing is truncated to a length of 16

    When the original developer was asked why hashes are used instead of auto-increment integers, it was because the integers "could get large".

     

     



  • I was going to reply along the lines of "Well, looks like he certainly made a hash of it." But you did that one already in the thread title.

    Myabe you could suggest that if auto-incrementing integers aren't going to have the required range, he could use auto-incrementing floating point numbers?



  • Don't start on floating point numbers. This same codebase uses floating point values for currency.

    Just my $0.0200000001, anyway.



  • @Thuktun said:

  • multiple important data items from the object are concatenated together with System.currentTimeMillis() and Math.random()
  • this is run through MD5
  • Wow.  A solution for which the set of problems it solves is the null set.  Awesome.

     


  • ♿ (Parody)

    @hoodaticus said:

    Wow.  A solution for which the set of problems it solves is the null set. Awesome.

    That's true, but in these tough economic times, we should be happy that this solution creates many new problems, thereby stimulating the solution industries of the future. Truly, Winning The Future.



  • @Thuktun said:

    When the original developer was asked why hashes are used instead of auto-increment integers, it was because the integers "could get large".
     

    Large enough to cause a collision in the however many bits of entropy are left at the end? (I presume that the stuff about '+' and '/' means that there's a base-64 encoding step which was missed from the description, in which case it would be up to 96 bits of entropy).



  • @pjt33 said:

    I presume that the stuff about '+' and '/' means that there's a base-64 encoding step which was missed from the description, in which case it would be up to 96 bits of entropy
     

    Yup, forgot to include that in my description of the process.

     



  • Maybe I'm being cynical here, and I admit I don't know much about hashing, entropy, encryption, databases, and the like...  But couldn't all of that shit have a chance of collision?  currentTimeMillis wraps around and repeats vaules, Random has a limited number of unique values it produces and can certainly produce the same number twice, and the data that is taken form the objects to seed this shit could be the same.  Sounds like a very small chance for a collision as opposed to a GUID or incrimented integers.  WTFery indeed.



  • Integers could get very large.  Hashes are guaranteed to be very large.

    Yep, I see the improvement here.



  • Man, the original developer was a real hash-hole and apparently didn't know the difference between his hash and his elbow...



  • @C-Octothorpe said:

    Man, the original developer was a real hash-hole and apparently didn't know the difference between his hash and his elbow...

     

    Wow, seriously? You tried to make exactly the same forced substitution TWICE? You've always been obnoxious and irritating, but man... now you're just being lame.

     



  • @Zylon said:

    @C-Octothorpe said:

    Man, the original developer was a real hash-hole and apparently didn't know the difference between his hash and his elbow...

     

    Wow, seriously? You tried to make exactly the same forced substitution TWICE? You've always been obnoxious and irritating, but man... now you're just being lame.

    I'm happy to hear you were so annoyed by my obviously lame joke (I'm guessing you didn't notice the tag).  Good thing I didn't make the same forced lame substitution THRICE?!?!11!@



  • @C-Octothorpe said:

    I'm happy to hear you were so annoyed by my obviously lame joke (I'm guessing you didn't notice the tag).

    Pointing out it's a bad joke doesn't make the joke less bad. It does make you an asshole, because it reveals you knew it was terrible and subjected it to us anyway.


  • ♿ (Parody)

    @blakeyrat said:

    @C-Octothorpe said:
    I'm happy to hear you were so annoyed by my obviously lame joke (I'm guessing you didn't notice the tag).

    Pointing out it's a bad joke doesn't make the joke less bad. It does make you an asshole, because it reveals you knew it was terrible and subjected it to us anyway.

    All the more reason to share!


Log in to reply