Hi Hannes
Please see the responses inline.
On 07/25/2016 07:23 AM, Hannes Tschofenig wrote:
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?
Agree. The numbers can be made more readable and less ambiguous. We will
do so in the next submitted version.
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.
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.
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.
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 protected]
https://www.ietf.org/mailman/listinfo/lwip
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
