Subject: Re: [Lwip] IoT Performance Measurements

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 1 Sep 2015 08:12:06 +0200

Hi Pablo,

thanks for the quick response.

>> What software implementation are you going to use for the
>> AES/SHA-256?
> 
> AES encryption is based on Contiki 3.x default library based on the
> AES-128 implementation by Texas Instruments, and SHA1 (not SHA-256)
> is based on TinyECC library.
> 
> I need to check it, but the mk60 accelerator should support AES128,
> AES192, AES256, DES, 3DES, MD5, SHA-1 and SHA-256. I can do a
> software-hardware performance analysis, in which ones are you
> interested?

I am interested in the AES and SHA-256 measurements.

Ciao
Hannes

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 1 Sep 2015 14:16:18 +0300

Hannes Tschofenig writes:
> On 08/28/2015 10:25 AM, Pablo Puñal Pereira wrote:
> > Hi Hannes, Malisa, all,
> > 
> > Right now I'm doing the performance analysis (in time and power
> > consumption) of IPsec, also in the context of IEEE802.15.4.
> 
> Why are you focusing your analysis on IPsec? Are you analysis IPsec
> AH/ESP or also IKEv2?
> 
> How does your test setup look like? How does IEEE 802.15.4 fit into this
> analysis? Wouldn't it be sufficient to focus on the performance of
> cryptographic algorithms?

IEEE 802.15.9 will be adding IKEv2 as one of the key management
protocols for IEEE 820.15.4, so that IKEv2 can be used to generate the
link keys for the network. In that setup it would be useful to do the
end to end security using IKEv2 + IPsec. Doing full protocol
performance analysis is more interesting than just comparing
cryptographic algorithms. For example the bit rates in the 802.15.4
are so slow, that the cryptographic performance penalty might not even
be noticiable, but on the other hand power consumption might be. 

>  The
> > configuration is: IKE negotiation: AES128-CTR, AES-XCBC, SHA1,
> > ECP192 ESP encryption: AES128-CTR, AES-XCBC
> 
> These are rather unusual choices for algorithms. Why did you pick these
> algorithms? I would have accepted to see AES-CCM or something like
> ChaCha20 there.

As the IEEE 802.15.4 uses AES128-CCM* (modified version of AES128-CCM)
for link encryption, the chipsets quite often have support for them.
Because of that I would have picked AES128-CCM for both IKEv2 and ESP.
-- 
[email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Tue, 1 Sep 2015 13:55:21 +0000

Hi, 

I agree with Tero that doing full protocol performance analysis is more interesting than just comparing cryptographic algorithms.
In our tests, compared to unprotected packets, the power consumption for encryption did not exceeded a few percents, whereas ESP has a significant network overhead depending on the size of the payload. 

BR, 
Daniel

-----Original Message-----
From: Lwip [mailto:[email-masked]] On Behalf Of Tero Kivinen
Sent: Tuesday, September 01, 2015 7:16 AM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Lwip] IoT Performance Measurements

Hannes Tschofenig writes:
> How does your test setup look like? How does IEEE 802.15.4 fit into 
> this analysis? Wouldn't it be sufficient to focus on the performance 
> of cryptographic algorithms?

IEEE 802.15.9 will be adding IKEv2 as one of the key management protocols for IEEE 820.15.4, so that IKEv2 can be used to generate the link keys for the network. In that setup it would be useful to do the end to end security using IKEv2 + IPsec. Doing full protocol performance analysis is more interesting than just comparing cryptographic algorithms. For example the bit rates in the 802.15.4 are so slow, that the cryptographic performance penalty might not even be noticiable, but on the other hand power consumption might be. 

> These are rather unusual choices for algorithms. Why did you pick 
> these algorithms? I would have accepted to see AES-CCM or something 
> like
> ChaCha20 there.

As the IEEE 802.15.4 uses AES128-CCM* (modified version of AES128-CCM) for link encryption, the chipsets quite often have support for them.
Because of that I would have picked AES128-CCM for both IKEv2 and ESP.
--
[email-masked]

_______________________________________________
Lwip mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lwip