On 13/06/16 06:00, Yoav Nir wrote:
On 10 Jun 2016, at 5:39 PM, Yaron Sheffer <[email protected]
<mailto:[email protected]>> wrote:
Hi,
The document takes care to not define Implicit IV for AES-CBC, and I
believe the underlying reason is malleability of the encryption. The
same would apply to AES-CTR. So I would suggest to:
* Exclude AES-CTR from this draft, or...
* Better yet, restrict the draft to AEAD algorithms.
BTW, the reference for AES-GCM is incorrect. Should be 4106.
Speaking of which, AES-GCM in ESP has a "salt" derived from IKE key
material. Is that kept intact by the current proposal?
Hi, Yaron
AES-CTR is pretty similar to AES-GCM and AES-CCM, except for the
confusing terminology:
* The 32-bit per-SA value derived from IKE is called “nonce” in RFC
3686 and “salt” in RFC 4106 (thanks for the corrected reference).
* The concatenation of 32-bit per-SA value and IV is called “nonce” in
RFC 4106 and doesn’t have a name in RFC 3686.
* The concatenation of 32-bit per-SA value, IV, and block counter is
called “counter block” in RFC 3686, but isn’t explicitly mentioned
in RFC 4106. The GCM spec also calls it “counter block”.
AFAICT it is not malleable like CBC. In CBC the issue was that an
attacker knowing the next IV would be able to generate the first block
of the next message such that IV xor Block0 would be whatever the
attacker wanted. That block would be the input to the encryption
function and thus the attacker could force the encryptor to encrypt
whatever block it wanted. With counter mode (or GCM or CCM) the attacker
has no control on the inputs to the encryption function. That is why RFC
3686 has text similar to the other documents:
The same
IV and key combination MUST NOT be used more than once. The
encryptor can generate the IV in any manner that ensures uniqueness.
Common approaches to IV generation include *incrementing a counter* for
each packet and linear feedback shift registers (LFSRs).
So I think CTR belongs in this draft as much as the others.
And yes, the GCM salt or the CTR nonce are derived in the same way and
used in the same way.
Yoav
AES-CTR is potentially malleable by a MITM who can change counter values
into ones she'd observed before. However since RFC 3686 is very emphatic
about the need for integrity protection (Sec. 3.3), we should be fine.
Thanks,
Yaron
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
