> On 10 Jun 2016, at 5:39 PM, Yaron Sheffer <[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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
