On 12/28/2015 10:09 PM, Salz, Rich wrote: >> When the key is changed, the change procedure should involve new randomness. > > I don't think this is necessary, and I don't think the common crypto > expertise agrees with you, either. But I am not a cryptographer, maybe one of > the ones on this list can chime in. > > "Crank the KDF" suffices.
The attacks against GCM are at the stage where even “periodically increment the key by one“ would thwart them, right? The risk is that without real re-key (introducing additional randomness), someone might come up with a better attack that reduces the security level below the design target, and which requires similar effort as the existing GCM attack (four years of traffic at terabit speed, it seems). Real re-key is difficult to introduce as an afterthought (see my recent response to Hubert), and I'd rather see such issues fixed at the cipher level if at all possible. The current update-key mechanism doesn't have the complexity issue of real re-key, but it's ambiguous if it's a design goal to paper over cipher deficiencies in the rest of the protocol. Florian _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
