Yoav Nir writes:
> Hi
> 
> draft-nir-ipsecme-chacha20-poly1305 currently specifies three transforms:
> 
>  1. chacha20 as a stand-alone cipher
>  2. Poly1305 as a stand-alone MAC
>  3. ChaCha20-Poly1305 as an AEAD.
> 
> Some people in the room said that we should only do the AEAD and skip the
> stand-alone algorithms. This would prevent SAs with combinations such as
> ChaCha20 + HMAC-SHA1 or AES-128-CBC + Poly1305.

I would suggest only keeping the AEED.

For example AES-128-CBC + Poly1305 does not make any sense, especially
if the Poly1305 is still defined to use ChaCha20 to generate keying
material for the Poly1305, i.e. AES-128-CBC + Poly1305 will need to
implement ChaCha20 too...

We also already have multiple quite ok MACs and I assume we will have
more when SHA3 stuff goes through, so there is no need for standalone
Poly1305. There might be some uses for standalone ChaCha20, but I
think it would be more important to keep things simple, and just
define one thing and that would be AEAD mode.

> I'm not saying whether we need or don't need these combinations. I
> don't see much use for them personally. My question to the list now
> is whether everyone agrees that it's fine to drop them and leave
> only the combined mode algorithm in the draft.

BTW, One the questions I had there that as the Poly1305 requires
separate key for each invocation and the draft uses ChaCha20 to
generate key, but if I have understood correct the way it generates
the key only gives out random unpredictable keys, but it does not
generate unique keys.

If I understood correctly the original Poly1305 document used AES in a
way which did generate unique keys for each poly1305 invocation.

The draft-nir-cfrg-chacha20-poly1305 says the "The pair (r,s) should
be unique, and MUST be unpredictable...". Should we add some text
there explaining why the way in draft-nir-ipsecme-chacha20-poly1305 is
ok, i.e. that even when we truncate the 512 bit output and only take
256 bits of it, the propability of using same key twice is negligible.
-- 
kivi...@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to