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 <wbath...@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. >> > -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev