[openssl-dev] Speck Cipher Integration with OpenSSL

[Benjamin Kaduk]

On 01/08/2018 03:10 PM, William Bathurst wrote:
> Hi Hanno/all,
>
> I can understand your view that "more is not always good" in crypto.
> The reasoning behind the offering can be found in the following
> whitepaper:
>
> https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf
>
>
> I will summarize in a different way though. We wish to offer an
> optimized lightweight TLS for IoT. A majority of devices found in IoT
> are resource constrained, for example a device CPU may only have 32K
> of RAM. Therefore security is an afterthought by developers. For some
> only AES 128 is available and they wish to use 256 bit encryption.
> Then Speck 256 would be an option because it has better performance
> and provides sufficient security.
>
> Based on the above scenario you can likely see why we are interested
> in OpenSSL. First, OpenSSL can be used for terminating lightweight TLS
> connections near the edge, and then forwarding using commonly used
> ciphers.
>
> [IoT Device] -----TLS/Speck---->[IoT Gateway]-----TLS----> [Services]
>
> Also, we are interested in using OpenSSL libraries at the edge for
> client creation. One thing we would like to do is provide instructions
> for an highly optimized build of OpenSSL that can be used for
> contrained devices.
>
> I think demand will eventually grow because there is an initiative by
> the US government to improve IoT Security and Speck is being developed
> and proposed as a standard within the government. Therefore, I see
> users who wish to play in this space would be interested in a version
> where Speck could be used in OpenSSL.
>
> It is my hope to accomplish the following:
>
> [1] Make Speck available via Open Source, this could be as an option
> or as a patch in OpenSSL.
> [2] If we make it available as a patch, is there a place where we
> would announce/make it known that it is available?
>
> We are also looking at open-sourcing the client side code. This would
> be used to create light-weight clients that use Speck and currently we
> also build basic OAuth capability on top of it.
>

Interestingly, the IETF ACE (Authentication and Authorization in
Constrained Environments) is chartered to look at this space (crypto for
constrained systems/IoT), and is aiming towards something roughly
OAuth-shaped, but there has not really been any interest in Speck
expressed that I've seen.  So, is this work happening someplace else, or
is there not actually demand for it?

-Ben

> Thanks for your input!
>
> Bill
>
> On 1/5/2018 11:40 AM, Hanno Böck wrote:
>> On Fri, 5 Jan 2018 10:52:01 -0800
>> William Bathurst <wbathurs at gmail.com> wrote:
>>
>>> 1) Community interest in such a lightweight cipher.
>> I think there's a shifting view that "more is not always good" in
>> crypto. OpenSSL has added features in the past "just because" and it
>> was often a bad decision.
>>
>> Therefore I'd generally oppose adding ciphers without a clear usecase,
>> as increased code complexity has a cost.
>> So I think questions that should be answered:
>> What's the usecase for speck in OpenSSL? Are there plans to use it in
>> TLS? If yes why? By whom? What advantages does it have over existing
>> ciphers? (Yeah, it's "lightweight", but that's a pretty vague thing.)
>>
>>
>> Also just for completeness, as some may not be aware: There are some
>> concerns about Speck due to its origin (aka the NSA). I don't think
>> that is a reason to dismiss a cipher right away, what I'd find more
>> concerning is that from what I observed there hasn't been a lot of
>> research about speck.
>>
>