Subject: [Cfrg] Can ChaCha20 be recommended for deployments?

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 22 Jul 2015 12:20:30 +0200

Hi all,

Stephen provided review review comments* to the 'TLS/DTLS Profiles for
the Internet of Things (IoT)' draft <draft-ietf-dice-profile> and
suggested that ChaCha20 and Poly1305 are included as a SHOULD or even a
MUST.

Currently, IoT devices often use AES in hardware. If this AES
implementation is not part of a separate crypto chip then it is part the
chip that implements the link layer protocol stack of a radio
technology. For example, Bluetooth Smart chips often have AES etc. in
hardware as part of their overall link layer stack implementation.

Unfortunately, due to the differences in nonce lengths used in AES
implementations for link layers (such as Bluetooth Smart) and nonce
lengths in TLS ciphersuites prevent easy re-use. Furthermore, chip
manufacturers are not always providing the APIs to access these crypto
functions for use with applications, i.e., only the link layer stack
uses the hardware crypto functions.

I believe that these points might give the impression that AES should
better be replaced with something else or enhanced with something else.
There may also be the desire to have a second algorithm in place in case
something goes wrong with AES, particularly considering that certain
types of IoT devices will have a very long lifetime.

On the other hand, AES has received a lot of review and ChaCha20 is
definitely not at that level. Furthermore, ChaCha20 seems to be designed
for software implementations and could therefore be added later to IoT
systems as part of a software update.

Today, there are very few software-based ChaCha20 implementations
available for IoT devices (such as the Apple Homekit) and I haven't seen
any hardware implementations yet.

Overall, I am not sure whether ChaCha20 and Poly1305 are useful
recommendations for IoT systems.

Does anyone in the CFRG have an opinion about this topic? What should we
recommend in the DTLS/TLS profile document?

Ciao
Hannes

*: http://trac.tools.ietf.org/wg/dice/trac/ticket/34

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 28 Jul 2015 22:15:30 +0200

> recommend in the DTLS/TLS profile document?

I believe ChaCha20-Poly1305 is well suited for many IoT applications,
because of its speed especially on hardware without instructions for
AES-GCM.  Given its already significant adoption in the HTTPS world, I
believe ChaCha20-Poly1305 will receive further cryptoanalytical efforts,
which over time can inspire trust.

Counter-question: what alternative to AES-GCM would be better suited?
Or even nearly as well suited as ChaCha20-Poly1305?  I can only think of
AES in some other AEAD mode, or more slower/exotic/older alternatives
like Camellia, but none rank as high in the trust/speed matrix as
ChaCha20-Poly1305 to me.

/Simon

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Jul 2015 23:47:42 +0300

> like Camellia, but none rank as high in the trust/speed matrix as

Hi, Simon

In IoT applications the go-to cipher has been AES-CCM. It’s slower than AES-GCM, but it has the advantage that you only need the AES encrypt function.

Sp that’s the baseline.  Of course chacha and poly have very small code, smaller I think than a software implementation of AES and faster.

Ypav

---

From: Mike Hamburg <[email-masked]>
Date: Tue, 28 Jul 2015 22:46:34 -0700

> like Camellia, but none rank as high in the trust/speed matrix as

Not much these days, but a possible option at some point could be sponge constructions based on either Keccak-F[1600] or Keccak-F[800], in particular the Keyak submission to CAESAR.  Keccak-F got analyzed pretty thoroughly in the SHA-3 competition, so while it may be behind ChaCha+Poly it's pretty trusted.

The neat thing about using a sponge for this is that you can also use it as a hash function, or as a general duplex object.  Then you only need one symmetric primitive.

[wanders off to refill kool-aid]

-- Mike

---

From: Derek Atkins <[email-masked]>
Date: Thu, 30 Jul 2015 11:18:55 -0400

Yoav Nir <[email-masked]> writes:

> In IoT applications the go-to cipher has been AES-CCM. It’s slower
> than AES-GCM, but it has the advantage that you only need the AES
> encrypt function.

Actually, in our implementation and testing (where we have AES-ECB in
hardware for assistance), GCM is orders of magnitude slower than CCM
because we can't easily implement the GF field math in our environment.
So I would not agree with your characterization that CCM is slower than
GCM.

(Technically we've implemented CTR+CMAC, not CCM, but I think my
argument remains the same and is still correct)

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant