Hi, In the TLS case, RFC5288 defines the following IV construction (Section 3):
```
struct {
opaque salt[4];
opaque nonce_explicit[8];
} GCMNonce;
The salt is the "implicit" part of the nonce and is not sent in the
packet. Instead, the salt is generated as part of the handshake
process: it is either the client_write_IV (when the client is
sending) or the server_write_IV (when the server is sending). The
salt length (SecurityParameters.fixed_iv_length) is 4 octets.
```
As you can see the salt is is implicitly derived from the *_write_IV. We have
no influence on this part of the IV construction, whereas the `nonce_explicit`
is generated by the implementer. I don't see a way how we could XOR some
records and compromise confidentiality, we've checked, believe me. If somebody
can come up with an attack though, that'd be nice.
On the catastrophic part: I'd like to keep it around. I don't think it deserves
a name like a hurricane, but catastrophic is pretty spot on in this regard.
w.r.t. nonce/n-nonce: either we keep the parentheses with "number used once"
around or we change it to n-once as suggested by Tony and beautifully
pronounced by Adam Langley :)
Aaron
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
