You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Szymon Janc <sz...@codecoup.pl> on 2017/01/09 13:30:10 UTC
crypto libraries
Hi,
Currently there are 2 crypto libraries in mynewt sourcetree - TinyCrypt and
mbedTLS. TinyCrypt is used only by Bluetooth LE Secure Connections and
bootutils.
From a very brief look it seems that mbetTLS provides necessary EC and DH API.
Also TinyCrypt seems to be in quite old version 1.0 while 2.0.5 is already
available. (I'm not sure about mbetTLS version).
Having two crypto libraries being used together seems like a waste of memory.
What are the plans for this? Adding generic crypto API that would allow to
choose backend on compilation? Remove one of the libraries and rewrite code
that is using it to other crypto? Just leave both around and use them where
it seems better?
If last option is feasible IMO at least Mynewt Core should rely on single
crypto lib while applications can choose any of those if needed.
Comments?
--
pozdrawiam
Szymon Janc
Re: crypto libraries
Posted by marko kiiskila <ma...@runtime.io>.
Hi Szymon,
> On Jan 18, 2017, at 6:05 AM, Szymon Janc <sz...@codecoup.pl> wrote:
>
> Hi Marko,
>
> On 9 January 2017 at 19:25, marko kiiskila <ma...@runtime.io> wrote:
>> Hi,
>>
>>> On Jan 9, 2017, at 5:30 AM, Szymon Janc <sz...@codecoup.pl> wrote:
>>>
>>> Hi,
>>>
>>> Currently there are 2 crypto libraries in mynewt sourcetree - TinyCrypt and
>>> mbedTLS. TinyCrypt is used only by Bluetooth LE Secure Connections and
>>> bootutils.
>>>
>>> From a very brief look it seems that mbetTLS provides necessary EC and DH API.
>>>
>>> Also TinyCrypt seems to be in quite old version 1.0 while 2.0.5 is already
>>> available. (I'm not sure about mbetTLS version).
>>>
>>> Having two crypto libraries being used together seems like a waste of memory.
>>>
>>> What are the plans for this? Adding generic crypto API that would allow to
>>> choose backend on compilation? Remove one of the libraries and rewrite code
>>> that is using it to other crypto? Just leave both around and use them where
>>> it seems better?
>>>
>>> If last option is feasible IMO at least Mynewt Core should rely on single
>>> crypto lib while applications can choose any of those if needed.
>>>
>>> Comments?
>>
>> they are not quite equal. mbedTLS has wider variety of crypto algorithms available, and
>> includes SSL/TLS. Tinycrypt has significantly smaller implementation of ECC.
>>
>> My current thinking is that we’d leave both in, and then pick one depending on use case.
>
> Fair enough.
>
> That said, I've just sent a pull request making BLE SM code use only
> TinyCrypt for crypto
> operations. This yields some nice image size reduction. Details in pull request.
>
> https://github.com/apache/incubator-mynewt-core/pull/161
>
size reduction is quite significant. Thanks for doing this!
—
M
Re: crypto libraries
Posted by Szymon Janc <sz...@codecoup.pl>.
Hi Marko,
On 9 January 2017 at 19:25, marko kiiskila <ma...@runtime.io> wrote:
> Hi,
>
>> On Jan 9, 2017, at 5:30 AM, Szymon Janc <sz...@codecoup.pl> wrote:
>>
>> Hi,
>>
>> Currently there are 2 crypto libraries in mynewt sourcetree - TinyCrypt and
>> mbedTLS. TinyCrypt is used only by Bluetooth LE Secure Connections and
>> bootutils.
>>
>> From a very brief look it seems that mbetTLS provides necessary EC and DH API.
>>
>> Also TinyCrypt seems to be in quite old version 1.0 while 2.0.5 is already
>> available. (I'm not sure about mbetTLS version).
>>
>> Having two crypto libraries being used together seems like a waste of memory.
>>
>> What are the plans for this? Adding generic crypto API that would allow to
>> choose backend on compilation? Remove one of the libraries and rewrite code
>> that is using it to other crypto? Just leave both around and use them where
>> it seems better?
>>
>> If last option is feasible IMO at least Mynewt Core should rely on single
>> crypto lib while applications can choose any of those if needed.
>>
>> Comments?
>
> they are not quite equal. mbedTLS has wider variety of crypto algorithms available, and
> includes SSL/TLS. Tinycrypt has significantly smaller implementation of ECC.
>
> My current thinking is that we’d leave both in, and then pick one depending on use case.
Fair enough.
That said, I've just sent a pull request making BLE SM code use only
TinyCrypt for crypto
operations. This yields some nice image size reduction. Details in pull request.
https://github.com/apache/incubator-mynewt-core/pull/161
--
pozdrawiam
Szymon K. Janc
Re: crypto libraries
Posted by marko kiiskila <ma...@runtime.io>.
Hi,
> On Jan 9, 2017, at 5:30 AM, Szymon Janc <sz...@codecoup.pl> wrote:
>
> Hi,
>
> Currently there are 2 crypto libraries in mynewt sourcetree - TinyCrypt and
> mbedTLS. TinyCrypt is used only by Bluetooth LE Secure Connections and
> bootutils.
>
> From a very brief look it seems that mbetTLS provides necessary EC and DH API.
>
> Also TinyCrypt seems to be in quite old version 1.0 while 2.0.5 is already
> available. (I'm not sure about mbetTLS version).
>
> Having two crypto libraries being used together seems like a waste of memory.
>
> What are the plans for this? Adding generic crypto API that would allow to
> choose backend on compilation? Remove one of the libraries and rewrite code
> that is using it to other crypto? Just leave both around and use them where
> it seems better?
>
> If last option is feasible IMO at least Mynewt Core should rely on single
> crypto lib while applications can choose any of those if needed.
>
> Comments?
they are not quite equal. mbedTLS has wider variety of crypto algorithms available, and
includes SSL/TLS. Tinycrypt has significantly smaller implementation of ECC.
My current thinking is that we’d leave both in, and then pick one depending on use case.