-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/09/13 12:36, ianG wrote: >> On Thu, Sep 19, 2013 at 09:20:04PM +0100, Michael Rogers wrote: >>> >>> The key reuse issue isn't related to the choice between >>> time-based and message-based updates. It's caused by keys and >>> IVs in the current design being derived deterministically from >>> the shared secret and the sequence number. If an endpoint >>> crashes and restarts, it may reuse a key and IV with new >>> plaintext. Not good. > > > Either the whole session has to be renegotiated then, or you need a > way to inject fresh randomness post-crash. It's not good to rely > on counters or RNGs in those circumstances. Time ?
I'm assuming that if a crash occurs, we can get fresh randomness (e.g. from the OS) after restarting. Is that not a safe assumption? I'd prefer not to rely on time, as the rotation periods for high-latency transports are necessarily long (we don't want to rotate keys while a message is in transit), so after crashing and restarting we may have to wait a long time until the next rotation period starts. > I'm assuming the IV is shared in the enciphered message, as > otherwise it is unknowable to the recipient if it has 1. in it. Yes - the format is (random IV || ciphertext || MAC), where the MAC is calculated over the IV and ciphertext. (If using an authenticated encryption mode instead of a separate MAC, the IV is included in the additional authenticated data.) > It seems we're getting closer to MAC-then-Encrypt. That is, take a > HMAC of the plaintext (uses 1, 2). Use that as (part of?) the IV. > Encrypt. Deliver the IV + ciphertext. To be honest I don't see a reason to use any function of the plaintext as an IV - I'd prefer the IV to simply be a fresh random value, unrelated to the plaintext, unless there's a reason to doubt that we can generate such a value. > I guess I would go back to first principles and ask why we're doing > this. Yes, great idea. Here are the requirements as I see them: 1. Protocol obfuscation: Nobody except the intended recipient should be able to distinguish any part of an encrypted message from random bits 2. Unlinkability: Nobody except the intended recipient should be able to tell whether two encrypted messages have the same sender or recipient (except by observing who sends and receives them, of course) 3. Asynchrony: Messages should be deliverable via high-latency transports such as migrating geese 4. Forward secrecy: Encrypted messages should eventually become undecipherable by their senders and recipients 5. Error tolerance: None of the above properties should be lost if messages are lost or reordered in transit And of course the standard requirements of confidentiality, integrity and authenticity. Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSSFO4AAoJEBEET9GfxSfMWOwIAMUXpoCPePO8pwrt4OhEsruS WNXw3DZGzTfEf+Rfe7tYulpxwEgz4BHUUjhTHiNe7jEwyYzq47vA5cglgJQAnvMf fOyeIk4FWhnpgC9MJcBeasBwr9lCxHBm/w2jBfYI5/z9F9fZa8CW7MDhVSrJMdrK rdVwb5hbyfr9UNPrzGfZ0zw6I9uk7e+1x+L7q+ia4ADGIZ3AuJK9JoYz/FGCQbbB 5HWAGoMvGMKqVMvSItN1Aj25oEyOkaPTb6B5ldrFqa97xsQClh1gQZyHJVcC+FTD EvyN06Fl1f9KKjLoDr21hSalqsrV9H3F3iim6y/eXYLbr6PCLNupnmWGdnUWvJw= =3kLK -----END PGP SIGNATURE----- _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
