I need to implement a couple of functions which comply with the following:
function genKey: given a string q (this may be a MD5 or SHA hash) and a seed string, the function must generate a new string p
function checkKey: this function must return true if a string p was generated from string q (using the previous function)
In seudo-code the above would be something lie this:
p=genKey(q,seed) ; // generate string p from q and seed
checkKey(p,q)==true ; // if p was generated from q, then this must return true. False otherwise.
Does anyone know about existing algorithms that do such thing??
I can implement the algorithms myself if there are no known implementations for PHP, so what I'm really asking is for the procedure to accomplish this.
It sounds like you might be trying to describe a MAC.
A message authentication code takes a message digest, a secret, and message. The secret and data are hashed together, and the result is included with the message.
A message recipient who knows the secret can perform the same digest computation, and compare his MAC to the one that accompanied the received message. If they are equal, he can trust that the message was not altered.
Given your comments, I understand now that you are working with asymmetric keys, rather than a secret key, which would be used in a MAC.
However, there's still a little confusion. Normally, a private signature key is kept secret by its owner, which in this case seems to be the client. A client can cryptographically prove that they possess a private key that corresponds to a public key without disclosing the private key.
Using digital signatures, you can do something like this:
p = genKey(pvt, seed)
checkKey(pub, p)
Here, pvt is the server's private key, pub is its public key. The seed parameter is the data that gets signed. If I understand your application (which I doubt), seed should be the client identifier. Then p is a message format that bundles seed and its signature together. Your question is confusing because q is used both generating and verifying p—like a shared secret.
However, there's nothing in this scheme (or in the MAC scheme) to stop one client from using another's value of p. All you can do with such a technique is to ensure that the message content has not been altered. For example, if the message is something like "clientID=Alice,IPAddress=192.168.1.1", you can make sure that Mallory didn't substitute his own IP address for Alice's.
But if the message is just "clientID=Alice", you can't stop Alice from giving Bob her tamper-proof message (in return for splitting the cost of a license), and you can't control whether Mallory hacks into Alice's box and steals the message.
By the way, if message integrity really is all you need, and you can easily share a secret between the sender and a receiver, MACs have some nice advantages over public-key cryptography, such as much smaller message size and faster performance.
Outline the threats you are trying to defend against. Cryptography is hard. Devising untried schemes usually ends badly.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With