# Tag Info

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

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

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

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.

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

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

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

Only top voted, non community-wiki answers of a minimum length are eligible