Jump to content

Encode a string into a hex triplet


AParson

Recommended Posts

Hi,

 

I am working on a project, and my customer is demanding some sort of "non-standard" hashing to encode field values on a database. This customer wants something exclusive, difficult to be decoded, and would accept no argument proving that the existing hash algorithms are good enough for the job.

 

What makes it even more challenging for me is that I don't have much experience in PHP.

 

The output should be something similar to a hex triplet (web color), so... this basically means I cannot use MD5, SHA, etc.

 

This also means that PHP hash() function is useless in this case, unless there is a hash algorithm I don't know about, and that gives me the output I need.

 

What I need is something like:

$output = functionthatdoesntexist("string to be encoded");

 

The "$output" var should contain something like: 19f7b4 (this is just a random value I am using to illustrate the format required for the output.)

 

Now here are my questions:

 

1) Is there a PHP function that encodes a string/number, and gives me back a "hex triplet"?

2) If such function doesn't exist, is there a way to create one from scratch? How should I start?

 

I just can't figure out how to solve this problem, so any help is appreciated.

 

 

Thanks in advance,

 

 

AP

Link to comment
Share on other sites

First up, hashing is one way. You cannot "un-"hash md5, sha1, etc. Encryption is what you're after. Though it'll be impossible to accurately encrypt/decrypt something with as few characters as that at as there'd be too many possible collisions; how would you know which is the right decrypted value if multiple values evaluate to the same string?

Link to comment
Share on other sites

I missed the part about the "difficult to decode."  In that case, add a salt to your string, serialize it, THEN use bin2hex.. easy enough.

 

The salt is what keeps it all different.  It's pretty much a password.

 

Say you have the string "bubble" and you want to encode it..

 

You could add a salt to it like "yutmgjtutyhdk583474" giving you "bubbleyutmgjtutyhdk583474", which you'd then serialize (which isn't too hard to decode) and then bin2hex.

 

$salt = "yutmgjtutyhdk583474";
$string = "bubble";
$encodeIt = bin2hex(serialize($string.$salt));

Link to comment
Share on other sites

Encryption is what you're after.

Aha! I think you may be right. I only have to ask the customer, if the data will have to be decripted at some point. Either way, anything that can give the customer the expected result will do (either hash/encryption function).

 

What kind of input are you expecting? do the strings have to be the same length like with md5 and sha1 or can it be just be something where A = Z and B = Y (in it's most simple form) making the string length depending on the input.

Basically it's a (15-character maximum) password, and a UNIX timestamp. The encrypted (or hashed) output should be in a "hex triplet" (web color) format... something like "000000" or "fa37d1". Those are gonna be recorded in two separate, extra fields.

 

I asked the customer why does it have to be that way... he then went red, sighed and asked "Can you do it or not?". He's a very old-fashioned and stubborn person, I have to say.

 

I missed the part about the "difficult to decode."  In that case, add a salt to your string, serialize it, THEN use bin2hex.. easy enough.

The salt is what keeps it all different.  It's pretty much a password.

Say you have the string "bubble" and you want to encode it..

That might help, depending on whether or not the customer will need that data decrypted at some point.

 

If not, in the end I might just use "md5()" and get the 6 first characters, which should give him what he wants, but I have a felling it's not gonna be that simple...

 

Thanks everyone for your inputs, I'll let you know how it panned out.

Link to comment
Share on other sites

There's are reason that the md5 is a 128bit (16 byte/32 hex character) checksum, to provide uniqueness.

 

Using a smaller number of digits (your proposed hex triplet) would be down-right insecure because of the significantly fewer combinations that would need to be tested to find a source value that matches the same hex triplet.

 

This is simply a bad idea.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.