Subject: [IPsec] ChaCha20 & Poly1305, AEAD and other modes

From: Yoav Nir <[email-masked]>
Date: Sun, 9 Mar 2014 17:03:07 +0200

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'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.

Thanks

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 10 Mar 2014 08:00:40 +0200

Hi Yoav,

Can you explain why we need Poly1305 at all? We have SHA-2 and will 
probably adopt Keccak (SHA-3), so it's not like we don't have a backup.

Let me suggest that we adopt *only* ChaCha20, which can be combined with 
any integrity protection algorithm in the normal ESP way. Is there any 
extra value (maybe code sharing?) in predefining an AEAD?

Thanks,
	Yaron

On 03/09/2014 05:03 PM, Yoav Nir wrote:
> 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.
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 10 Mar 2014 10:15:17 +0200

> probably adopt Keccak (SHA-3), so it's not like we don't have a backup.

Sure.  Poly1305 is fast.Faster than SHA-1, SHA-2, and Keccak. I haven't
compared it to GMAC on Intel, but that is fast only becuase it has special
Intel instructions like PCLMULQD. Both ChaCha and Poly1305 can be fast in a
plain C implementation, so they're fast on any platform.  Poly1305 needs
another algorithm to generate the per-message keys. That could be AES as in
DJB's original paper, or it can be ChaCha as in this draft (with or without
the AEAD).

> extra value (maybe code sharing?) in predefining an AEAD?

The AEAD version is already in at least one crypto library (NSS as used in
Chrome) and there's a patch that AGL donated to OpenSSL (not in there yet).
So in addition to AEADs being fashionable, this combination makes sense for
performance, especially on non-Intel platforms.

Yoav

---

From: Daniel Migault <[email-masked]>
Date: Mon, 10 Mar 2014 09:43:05 +0100

Hi,

My understanding is that Poly1305 and chacha20 are provided as
"alternatives" to SHA* or AES*. Specific devices with AES
accelerations may be willing, for performance optimization, to use
Poly1305 instead of SHA with AES. For this reason it might be better
to have:
    - chacha20 as a stand-alone cipher
    - Poly1305 as a stand-alone MAC

On the other hand, providing the AEAD chacha20-poly1305 may be helpful
for end users or admins. Especially if security consideration
recommends AEAD. Would it bring too much complexity to also define
AEAD chacha20-poly1305?

BR
Daniel

On Mon, Mar 10, 2014 at 9:15 AM, Yoav Nir <[email-masked]> wrote:
>> any integrity protection algorithm in the normal ESP way. Is there any extra
>> value (maybe code sharing?) in predefining an AEAD?
>
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Yoav Nir <[email-masked]>
Date: Mon, 10 Mar 2014 10:51:01 +0200

The draft currently has all three: standalone ChaCha, standalone Poly1305,
and AEAD.

Standalone Poly1305 has the issue that it requires a one-time key or a
nonce to generate it, but ESP only allows an IV for the cipher, not for the
MAC. The draft deals with it by using the replay counter as a nonce, but
then changes APIs. That is one reason why some people are opposed to
standalone Poly1305.

Yoav

On Mon, Mar 10, 2014 at 10:43 AM, Daniel Migault <[email-masked]>wrote:

> extra

---

From: Paul Wouters <[email-masked]>
Date: Mon, 10 Mar 2014 10:33:04 -0400 (EDT)

On Sun, 9 Mar 2014, Yoav Nir wrote:

> 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'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.

Yes. We have too many algorithms in IKE already. If we believe that
combined mode algorithms are better than classic ENCR+INTEG algorithms,
and I think we do, than we should not be adding more old style ENCR+INTEG
algorithms.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 10 Mar 2014 17:36:06 +0200

> 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.
-- 
[email-masked]