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

[Ole Reinhardt]

Hi Harald,

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

>> There were lots of include errors. I tried to fix this in the current
>> trunk and further added nut/include/contrib as a standard include path
>> to the Makefiles.
> 
> The Configurator allows to define additional include paths. I think I
> added to last include dir. If I remember correctly, that didn't work
> with the Qt version, which is one of the reasons I went back to the
> wxWidget version. But I think that had been fixed recently in qnutconf.

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.

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.

>> Btw: Is the arm-crypto-library in out contrib directory the most recent
>> and up to date version? I'm currently playing arround with the TLS
>> implemenmtation of Daniel Otte and I'm facing a few problems. Just want
>> to get sure that I did not run into truble because of bugs in the used
>> crypto library.
> 
> The one that is included in the trunk had been tested, but it is not the
> recent one. Before updating I'd suggest to contact Daniel. You can reach
> him at Das Labor.

I just wrote him a private mail today :-)

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

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.

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

Best regards,

Ole

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