Subject: [Lwip] draft-aks-lwig-crypto-sensors-00 & Crypto Performance

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Jul 2016 13:23:01 +0200

I have a question regarding draft-aks-lwig-crypto-sensors-00.

Table 2 shows ECDSA signature performance with TinyECC. The execution
time in the first row says 1,858 msec. A different writing style for
numbers and use the comma (either '.', or ',') is used throughout the
world. Hence, I guess you mean almost 2 seconds here rather than almost
2 msecs. Right?

When I read the performance figures then my impression is that the used
hardware isn't really fit to do any practical crypto for IoT devices.
What is the message you want to convey to the reader? I fear that such a
write-up could easily be misunderstood. You may want to provide a bit
more info about why you have chosen this hardware platform particularly
since it is not able to fit most of the stuff we have developed in other
working groups due to the low RAM and flash.

The currently recommended key size for IoT devices is (based on various
other IETF documents) 112 bit symmetric keys ~ 233 bit ECC keys ~ 2048
DH/RSA keys.

Hence, publishing performance results for very low, impractical key
sizes is misleading since we do not recommend them to be used at all.
Hence, I would delete any data below 192r1 (for ECC) and maybe even
192r1 as well. You include, for example, the RSA algorithm with a key
size of 64 bits.

Ciao
Hannes

---

From: Mohit Sethi <[email-masked]>
Date: Tue, 26 Jul 2016 11:07:03 -0400

Hi Hannes

Please see  the responses inline.

> world. Hence, I guess you mean almost 2 seconds here rather than almost
Agree. The numbers can be made more readable and less ambiguous. We will 
do so in the next submitted version.
> working groups due to the low RAM and flash.
If you have a look at section 11 on feasibility, we have text describing 
why we picked this platform: "It could even be argued that our chosen 
prototype platform was unnecessarily restrictive in the amount of code 
space it allows: we chose this platform on purpose to demonstrate 
something that is as small and difficult as possible."
This platform (Arduino Mega) has also been chosen by many other 
researcher/cryptographers to show feasibility of public-key crypto on 
small devices for example:
http://link.springer.com/article/10.1007/s10623-015-0087-1/fulltext.html

http://link.springer.com/chapter/10.1007/978-3-642-38553-7_9

And if you read the document (section 9: Example Application), we not 
only implement CoAP on the same platform, but a complete application 
that reads temperature measurement, performs crypto, and sends messages 
over CoAP + UDP etc. All this in about 5000 bytes of RAM. So we disagree 
that it is not able to fit most of the stuff developed at the IETF.
> 192r1 as well. You include, for example, the RSA algorithm with a key
According to some, all the public key crypto will soon be broken (so we 
should remove all the numbers from the draft) and we should move to 
Quantum resistant crypto (note that this is not my opinion). I agree 
that some of the curves are not secure anymore and perhaps we can point 
it out even more explicitly. But the reason for providing performance 
numbers on all the curves and key sizes is to provide a perspective. The 
text currently does say that " At the time of performing these 
measurements and study, it was unclear which exact elliptic curve(s) 
would be selected by the IETF community for use with 
resource-constrained devices." We will make it even more explicit in the 
next version.

Do you have any other concerns which think we should address for working 
group adoption?

Thanks
/--Mohit
>
> Ciao
> Hannes
>
>
>
>
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip