[En-Nut-Discussion] Anyone ever compiled contrib/arm-crypto-library?

Harald Kipp harald.kipp at egnite.de
Tue Oct 29 09:43:09 CET 2013

Hi Ole,

On 28.10.2013 23:25, Ole Reinhardt wrote:
>>> does anyone ever compiled the arm-crypto-library provided in the contrib
>>> directory?
>> Yes, me, several times for different boards.
> Cool. Have you compiled it seperately or directly with the configurator?

I rarely use the Configurator for compiling, but almost always for

> Ok. That explains a lot. I just thought that each part of NutOS which is
> selected in the configurator should compile without further manual
> interaction.

Definitely the best way. TLS is a special case, though. It's contributed
under a different license and actually not part of Nut/OS.

Daniel is still working on it. The reason for adding it to the Ethernut
distribution was to make sure, that we have a verified and tested
release. To simplify merges with later versions, I decided not to modify
his include statements. Well, patching them is not a bit deal.

> Anyway, could you perhaps have a short look to my latest changes there?
> I modified the include pathes that way that it now compiles without
> further configuration. These changes should not harm any existing
> applications.

It shouldn't and I'll test it within the next days. I anyway wanted to
do a test with pre-computed keys on an ARM7.

> Btw: Have you planned to merge the TLS app into the trunk?

No and I'd prefer to keep it separate. One reason, of course, is the
license of the required crypto library. The other reason is, that it
requires more CPU power than most Nut/OS targets are able to provide.

An alternative would be to create a separate project.

> I tried it out on the M-BED board last weekend and it just looks quite
> promising. It's still a little bit like a rough diamond and still needs
> some polish at several places, but perhaps we will use it for one
> project. However we won't need the server implementation but the client
> side. Daniels code is a very good starting point to continue the
> implementation.

Yeah, his coding style is a bit random. :-)

His mayor work is probably the implementation of all these crypto
algorithms. He really is an expert in this field.

> From the perfomance point of view: On the M-BED (LPC1768 @100 Mhz) the
> session key decryption took around 4 seconds. I think for long running
> connections this is totally acceptable.

Really? 4 seconds only? That didn't coincide with my experience. I
didn't test the Cortex, but the ARM7TDMI took about 1 minute @ 50MHz.

I'd even accept 10 to 20 seconds, because once established, the browser
rarely starts a new negotiation.



More information about the En-Nut-Discussion mailing list