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

From: Peter Schwabe <[email-masked]>
Date: Tue, 15 Sep 2015 10:09:38 +0200

Hannes Tschofenig <[email-masked]> wrote:
> Hi all,

Hi Hannes, hi all,

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

Yesterday Michael Hutter presented joint work with Jürgen Schilling,
Wolfgang Wieser and me at CHES. The title of the paper is "NaCl's
crypto_box in hardware" and we're aiming exactly at IoT devices. This
implementation is using Salsa20+Poly1305 instead of ChaCha20+Poly1305,
but performance numbers wouldn't change drastically for ChaCha20. If
you're interested, the paper is online at
https://cryptojedi.org/papers/#naclhw; the VHDL source code is in the
public domain and online at https://cryptojedi.org/crypto/#naclhw.

Best regards,

Peter

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 15 Sep 2015 10:18:22 +0200

Thanks, Peter.

Based on the feedback we have not included a recommendation for
implementation of ChaCha20 / Poly1305 in the current version of the
DTLS/TLS for IoT profiles document.

You work is interesting nevertheless and might be relevant for future
systems.

Ciao
Hannes

---

From: Joachim Strömbergson <[email-masked]>
Date: Tue, 15 Sep 2015 14:51:24 +0200

Aloha!

Peter Schwabe wrote:
>> Hi all, 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.

Cryptech has been providing a ChaCha HW implementation for more than a
year. The cre is written in Verilog and not bound to a specific technology.

http://wiki.cryptech.is/browser/core/cipher/chacha

> crypto_box in hardware" and we're aiming exactly at IoT devices.
> This implementation is using Salsa20+Poly1305 instead of
> ChaCha20+Poly1305, but performance numbers wouldn't change
> drastically for ChaCha20. If you're interested, the paper is online
> at https://cryptojedi.org/papers/#naclhw; the VHDL source code is in
> the public domain and online at
> https://cryptojedi.org/crypto/#naclhw.

Indeed, the performance between Salsa and ChaCha is very small.

Great work and release by you btw. Very cool! If I may suggest something
is to add a simple LICENSE or similar file to the distribution to really
clarify that the code is public domain. As it is today there seems to be
no header etc stating anything at all about usage rights of the code.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================

---

From: Peter Schwabe <[email-masked]>
Date: Tue, 15 Sep 2015 16:38:04 +0200

Joachim Strömbergson <[email-masked]> wrote:

Hi all,

> no header etc stating anything at all about usage rights of the code.

Done.

Cheers,

Peter

---

From: Paul Lambert <[email-masked]>
Date: Wed, 16 Sep 2015 01:07:57 +0000

On 7/30/15, 8:18 AM, "Cfrg on behalf of Derek Atkins"
<[email-masked] on behalf of [email-masked]> wrote:

>Yoav Nir <[email-masked]> writes:
>
>> On Jul 28, 2015, at 11:15 PM, Simon Josefsson <[email-masked]>
>>wrote:
>>
>>> 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.
>>
>> 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.
>
>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.

Comparing full custom hardware implementations of CCM or GCM, the
structure of GCM allows it to considerable faster.

In link layer protocols (e.g. IEEE 802.3,.11,.15) the implementations are
moving slowing to GCM where higher performance is required (e.g. 60GHz
applications).  

Paul

>
>(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
>
>_______________________________________________
>Cfrg mailing list
>[email-masked]
>http://www.irtf.org/mailman/listinfo/cfrg