When too much plaintext has been encrypted with the same key, the key needs to be changed. When the key is changed, the change procedure should involve new randomness.
What's the confusion here??? Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. From: Eric Rescorla Sent: Monday, December 28, 2015 15:47 To: Blumenthal, Uri - 0553 - MITLL Cc: Florian Weimer; [email protected] Subject: Re: [TLS] Data volume limits To be clear, the concern that we are trying to alleviate is encrypting too much plaintext with the same key (see the discussion by Watson at the beginning of this thread). For that purpose, I'm not following why we need to introduce new randomness (draft-11 doesn't do so, but just cranks the KDF forward). It's possible I've misunderstood something, though, so happy to be corrected. -Ekr On Mon, Dec 28, 2015 at 3:40 PM, Blumenthal, Uri - 0553 - MITLL <[email protected]> wrote: Off-hand, key update or re-key without new/fresh randomness sounds weird. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. From: Eric Rescorla Sent: Monday, December 28, 2015 15:37 To: Florian Weimer Cc: [email protected] Subject: Re: [TLS] Data volume limits On Mon, Dec 28, 2015 at 3:33 PM, Florian Weimer <[email protected]> wrote: On 12/28/2015 09:11 PM, Eric Rescorla wrote: >> You still have the added complexity that during rekey, you need to >> temporarily switch from mere sending or receiving to at least >> half-duplex interaction. >> > > That's not intended. Indeed, you need to be able to handle the old key > in order to send/receive the KeyUpdate. Can you elaborate on your concern? Ah, so you want to keep the current mechanism and not inject fresh randomness? Isn't this fairly risky? Can you explain the risk you are concerned about in more detail? -Ekr
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
