Re: [Lwip] [SPAM?] Re: Notes on draft-tschofenig-lwig-tls-minimal-03

[Sye Loong Keoh <[e-mail]>]

Are you using the TinyECC library?

-----Original Message-----
From: Hauke Mehrtens [mailto:[e-mail]] 
Sent: Thursday, 10 October, 2013 10:25 PM
To: Sye Loong Keoh
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [SPAM?] Re: [Lwip] Notes on draft-tschofenig-lwig-tls-minimal-03

Hi Sye,

I am working on getting some numbers. ;-) The code is there, I also added reordering, and I started writing the stuff down for my master's thesis, so I plan to do some measurements soon.

My current problem is that the ECC code is very slow, a handshake with client authentication takes 5 - 10 minutes in cooja on a simulated MSP430X, with a psk cipher it just takes 5 - 10 seconds, the problem are the ECC operations, mostly ecc multiply on the secp256r1 curve.

Does someone know a fast and small ECC implementation supporting the
secp256r1 curve?

Hauke

On 10/08/2013 08:53 AM, Sye Loong Keoh wrote:
> Hi Hauke,
> 
> Just to follow up on your previous discussion, how's your progress on the TinyDTLS implementation on the TI MSP430?
> Do you have already have performance results that can be shared with us, by incorporating them into the Hitchhiker's guide LWIG document (http://www.ietf.org/internet-drafts/draft-ietf-lwig-tls-minimal-00.txt)?
> 
> Cheers
> Sye Loong
> 
> -----Original Message-----
> From: Hauke Mehrtens [mailto:[e-mail]]
> Sent: Wednesday, 28 August, 2013 6:53 AM
> To: Sye Loong Keoh
> Cc: [e-mail]; [e-mail]; 
> [e-mail]
> Subject: [SPAM?] Re: [SPAM?] Re: [Lwip] Notes on 
> draft-tschofenig-lwig-tls-minimal-03
> 
> Hi Sye Loong,
> 
> I am using a simulated sensor node in cooja. wismote is a simulated wireless sensor node which simulates a TI MSP430 with 16kB RAM and 128 kB Rom, so this suites in the class 1 category.
> Currently I am still in the state of getting tinydtls working on the TI MSP430.
> 
> Hauke
> 
> On 08/27/2013 03:32 AM, Keoh, Sye Loong wrote:
>> Hi Hauke,
>>
>> What is a wismote? Do you have a use case for your work? and what are 
>> the assumptions of the nodes in your network? Are they class 1 
>> devices as defined in the Terminology draft?
>>
>> Great that you are willing to contribute!
>>
>> cheers
>> Sye Loong
>>
>> -----Original Message----- From: Hauke Mehrtens
>> Sent: Monday, August 26, 2013 10:42 PM
>> To: Sye Loong Keoh
>> Cc: [e-mail] ; [e-mail] ; 
>> [e-mail]
>> Subject: [SPAM?] Re: [Lwip] Notes on
>> draft-tschofenig-lwig-tls-minimal-03
>>
>> Hi Sye Loong,
>>
>> I am currently at implementing reordering, it seams to work, but it 
>> is not committed to github yet.
>>
>> I am also sending only one message at a time, so a flight contains 
>> many UDP packages.
>>
>> I am currently trying to get it to work in cooja on a simulated 
>> wismote, the psk handshake already works, but I still have problems 
>> with the ECDH_ECDSA handshake, something is probably wrong in the ecc 
>> code, on
>> x86 it works. Cooja also has a nice tool which shows the stack usage 
>> of the application running.
>>
>> Too bad you can not give me access to your modified tinydtls version.
>>
>> Most of my code is at github, it misses some of the things that I am 
>> currently working on and that are not cleaned up right now.
>>
>> I want to do some measurements similar to the ones, you did for the 
>> psk case with ECDH_ECDSA for my master's thesis and I would like to 
>> get them integrated into the draft.
>>
>> Hauke
>>
>> On 08/26/2013 12:04 PM, Keoh, Sye Loong wrote:
>>> Hi Hauke,
>>>
>>> Thank you for your interest in our draft. It is great to hear that 
>>> you are extending TinyDTLS with raw public key support, and this is 
>>> indeed the contribution that we needed in this document, as we only 
>>> had performance and implementation details of PSK in TinyDTLS.
>>>
>>> At least in your implementation, we needed the re-ordering because 
>>> messages were not sent using message flights. Each message is sent 
>>> individually.
>>>
>>> I am sorry that the the modified TinyDTLS code cannot be made 
>>> available due to some constraints that we have. But, we can discuss 
>>> specific needs that you have.
>>> When you compile and flash the application to the hardware, you can 
>>> get the RAM size measurement.
>>>
>>> Would be great if you could share your implementation details and 
>>> measurements with us, so that they can be incorporated into our 
>>> Internet Draft.
>>>
>>> cheers
>>> Sye Loong
>>>
>>>>>>
>>> Hi Hannes,
>>>
>>> I have some notes on
>>> https://tools.ietf.org/html/draft-tschofenig-lwig-tls-minimal-03
>>>
>>> I am working on tinyDTLS and came across some problems. I extended 
>>> it to support raw public keys with 
>>> TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 on the
>>> SECP256R1 curve. The ECC code just supports this specific curve.
>>>
>>> The ClientHello without a cookie is now 99 Bytes big (value in UDP
>>> header) and on ieee802.15.4 it has to be fragmented somewhere. But 
>>> to do fragmentation we have to store a state somewhere.
>>>
>>> For retransmission, instead of storing the whole message you could 
>>> store the data which is needed to recreate the message. Data like 
>>> the server certificate already has to be stored somewhere. I am 
>>> planing to implement this.
>>>
>>> We have a high memory consumption in the handshake process, you 
>>> could make it possible to be able to just do one handshake at a 
>>> time, but have more than one DTLS session open at a time. All these 
>>> DTLS session will then share a common memory space to store their 
>>> temporary handshake data. I am planing to implement this.
>>>
>>> If you have a pretty reliable medium you could leave out 
>>> implementation of reordering, the other peer will resend the 
>>> messages if a message will be lost and then the client could start 
>>> at the position where the package was lost again. This could save some ram to store the messages.
>>>
>>> Is the code of the modified tinyDTLS version and a more detailed 
>>> description of the setup available somewhere? I am planing to so 
>>> some measurements with tinyDTLS and raw public keys. How was the RAM 
>>> size measurement done?
>>>
>>> As already discussed in the meeting the sizes for the tls 
>>> implementation are pretty big. I haven't implemented a generic ASN.1 
>>> parser, I am just supporting one type of raw public key, so I am 
>>> doing a memcmp() to ensure it is the one I excepted, then there is 
>>> the public key at a constant offset.
>>>
>>> My tinyDTLS implementation with raw public keys and
>>> TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 on the SECP256R1 curve is about 
>>> 30% bigger then the version just supporting PSK cipher. This 
>>> measurement was done on a AMD64 system without any compiler 
>>> optimization for size. I am planing to do a better measurement.
>>>
>>> Hauke
>>>
>>> [0]: https://github.com/hauke/tinydtls/tree/ecdh-merge
>>
> 


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3408 / Virus Database: 3222/6738 - Release Date: 10/10/13