# Tag Info

1

This question both describes the SRP-Z variant and mentions that the patent should expire in three years. I think the patent in question is this one, but I'm not sure: US 6539479.

0

What you are looking for is so called white-box cryptography. That said, you should definitely check if you can't get away with digital signatures. The reason is that white box cryptography is a special case of program obfuscation that is quite hard to achieve. Existing, practical schemes do not rely on hard problems but rather on not being broken so far. So ...

1

Your idea seems secure, but it is more complicated than it needs to be. If you only need to know if the "secure information" in the document matches some public information (stored on an insecure computer), it is enough to calculate a preimage resistant hash of the document (e.g. SHA-256). The document needs only to be unguessable, like a 256-bit random ...

2

But if Server’s certificate is checked sucessfully by Client, how is it possible to consider that Server has been authenticated by Client, while at this time none message signed with Server’s private key has been sent to the Client and verified by it ? If only consider the key exchange to be what the RFC says it is, then yes this key-exchange can ...

1

The authentication tag in GCM is generated by XORing a block cipher output with the Galois field hash (and truncating it for shorter lengths). It is thus assumed to look PRF. So it is effectively just a random nonce that should not collide until a birthday bound of $2^{t/2}$. With a tag length of 96 or more bits, it should be secure. Shorter random IV ...

0

You mention OpenSSH format, so may I assume you can use OpenSSH as part of your solution? If so, how about just using RSA key pairs with an authorized_key file? Example The server only ever has a public key for each user stored on it (nothing to lose to a server compromise) and the client just does RSA authentication (no passwords ever sent - client keeps ...

2

I can see some weaknesses in your protocol. For example, it allows any attacker to request the encrypted private key and thus mount an offline dictionary or brute force attack on the password. (An incorrect password doesn't give you a properly formatted OpenSSH key.) Thus this is a good idea: I'd rather use something proven. As mentioned in the ...

0

I would also mention that there are many required properties that you want a authenticated key exchange (AKE) protocol to satisfy, e.g. authentication, key confirmation, forward secrecy, key freshness, secrecy on the session key. What you want is allow Alice and Bob to stablish "session keys" for each session of communication. These session keys are ...

1

TL;DR: use (D)TLS. This is exactly the kind of problem it was meant to solve. If possible, use cert pinning too (if you get to deploy the code on both ends of the channel, this should be possible). The general rule is: don't design your own crypto protocol unless both of the following apply. You have done a detailed review of what exists already and ...

-2

But for a split moment, the server knows the secret ... and so is the wireless bug in the cable of the keyboard, the web-cam of your laptop and iPhone, the microwave microphone of the satellite eavesdropping the sound of your keystrokes, etc. If you are afraid of the server don't go in Internet (it is not the server, BTW -it is the screen memory ...

3

Some background on formal key-exchange models The goal of a key-exchange (KE) is to establish a session key between two parties. Naively, we could say that a KE is secure if no adversary will be able to figure out the session key (in full) established between two honest parties. However, in formal security models we take this a bit further and insist that ...

Top 50 recent answers are included