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

Ole Reinhardt ole.reinhardt at embedded-it.de
Wed Oct 30 09:59:47 CET 2013


Hi Harald,

Am 29.10.2013 09:43, schrieb Harald Kipp:

>> Cool. Have you compiled it seperately or directly with the configurator?
> 
> I rarely use the Configurator for compiling, but almost always for
> configuration.

Me too. But for sure I used the generated Makefiles and re-configure the
tree from time to time if the trunk has changed a lot to be sure that
everything is still in it's place.

>> 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.

Ack.

> 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.

Ok. As soon as we have a git repository pathing becomes even more easy :)

>> 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.

Ok! What about addind it to the contribs as well? Just to keep the code
close to eachother? I suppose more peaople would get aware of it, if it
is _not_ seperated as a completly different project (with different
project repository and website).

>> 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.

Yes, big kudos to him :)

>> 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 used:

gnutls-cli --insecure 192.168.2.200

I connected to the board in 4 seconds and I could manually do a "GET /
HTTP", which immediatly returned the contents.

Does the --insecure parameter speeds up things here?

Without it, gnutls always canceled the connection, as the hostname of
the board and the one configured in the certificate did not match.

With either google-chrome and firefox I did not manage to establish a
connection at all.

Bye,

Ole

-- 
kernel concepts GmbH            Tel: +49-271-771091-14
Sieghuetter Hauptweg 48         Mob: +49-177-7420433
D-57072 Siegen
http://www.embedded-it.de
http://www.kernelconcepts.de


More information about the En-Nut-Discussion mailing list