On 2011-02-16 10:04 AM, David-Sarah Hopwood wrote: > Note that a disadvantage of such protocols relative to > multi-round ones is that, as far as I know, they cannot > achieve forward secrecy.
In that if either party to the protocol described loses control of his secret key, all messages can be retroactively decrypted. I was unaware that any half round protocols had been described, though you proceed to describe one blow. > This kind of protocol is called a "public key > authenticator". For this purpose Dan Bernstein suggests > using static Diffie-Hellman to agree a key for a symmetric > authenticated- encryption scheme. For example the > 'crypto_box' scheme in his NaCl library uses static > Diffie-Hellman in an elliptic-curve > group:<http://nacl.cace-project.eu/box.html> I don't know > whether it has had any published analysis. > > Here's another way to achieve this generically using any > signature and (IND-CCA2-secure) public key encryption > schemes: > > Generate a key for a symmetric authenticated-encryption > scheme (such as encrypt-then-MAC). Encrypt this key to > the recipient's public encryption key. Sign the result > and an identifier for the recipient with the sender's > private signing key. This accomplishes the same result (no round trips) with the minor disadvantage that one cannot deny sending *a* message (which is a very minor disadvantage since traffic is generally traceable), and the considerable advantage that it uses only long established cryptographic primitives. > Note that this protocol must use encrypt-then-sign in that > order. If it were sign-then-encrypt, the recipient could > strip off the encryption and reuse a signature to forge a > message appearing to be from the original sender. With > encrypt-then-sign, this attack does not work: because the > encryption scheme is IND-CCA2-secure, the message will only > be accepted by someone who can decrypt it using the correct > private decryption key (subject to the caveat below). > > Most such schemes, including crypto_box and the generic > scheme above, have a potential vulnerability that needs to > be prevented at a higher protocol level. Suppose that an > attacker, Carol, claims her public key to be the same as > that of another user Bob (depending on the protocol, it may > be possible to modify this attack to work with a key that > is different but related to Bob's key). Now Alice sends > Carol a message, which Carol relays to Bob. Carol cannot > change the message since she does not know the symmetric > key, but Bob will believe that Alice intended to send him > that message, when actually Alice intended to send it only > to Carol. > > This attack can be countered by including an identifier for > the *intended* recipient in the message. This should be > checked automatically by the recipient's software, and the > message not presented as genuine unless it matches the > recipient's expected ID. > > Alternatively, each party that claims a public key can be > required to prove knowledge of the corresponding private > key. (Most multi-round protocols essentially do that in a > key confirmation step.) It would seem that forward secrecy inherently requires at least one and a half round trips, since the recipient of the message has to have a transient secret. This problem can be somewhat mitigated by caching shared secrets for a moderate period. _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
