I think being able to interoperate with IoT devices using SPECK is a good idea.
I'd like to know what kind of key exchange is likely to be used there. Regards, Uri Sent from my iPhone > On Jan 9, 2018, at 04:58, Richard Levitte <levi...@openssl.org> wrote: > > I'm not terribly savvy regarding IoT, but I imagine that they do talk > to something bigger. A server end, perhaps? What do we expect to run > on that end? What happens, in that case, if SPECK makes its way into > the TLS cipher suites? Would it be interesting to have OpenSSL > interop with such devices? > > Note: I'm not terribly partial either way, just thought that we need > to look at it from a broader perspective... > > Cheers, > Richard > > In message <a37c4b30-0f9d-4894-ad63-35b971ffe368@default> on Mon, 8 Jan 2018 > 13:58:59 -0800 (PST), Paul Dale <paul.d...@oracle.com> said: > > paul.dale> I'm wondering if one of the more specialised embedded > cryptographic toolkits mightn't be a better option for your lightweight IoT > TLS stack. There is a wide choice available: CycloneSSL, ECT, Fusion, > MatrixSSL, mbedTLS, NanoSSL, SharkSSL, WolfSSL, uC/SSL and many others. All > of them claim to be the smallest, fastest and most feature laden :) To sell > to the US government, your first selection criteria should be "does the > toolkit have a current FIPS validation?" From memory this means: ECT, > nanoSSL or WolfSSL. > paul.dale> > paul.dale> The more comprehensive toolkits (OpenSSL, NSS, GNU TLS) are less > suitable for embedded applications, especially tightly resource constrained > ones. It is possible to cut OpenSSL down in size but it will never compete > with the designed for embedded toolkits. Plus, the FIPS module is fixed and > cannot be shrunk. > paul.dale> > paul.dale> The current OpenSSL FIPS validation only applies to 1.0.2 builds > currently. FIPS is on the project plan for 1.1 but it isn't available at the > moment. The US government is forbidden to purchase any product that contains > cryptographic operations unless the product has a FIPS validation. No FIPS, > no sale. > paul.dale> > paul.dale> > paul.dale> Pauli > paul.dale> -- > paul.dale> Oracle > paul.dale> Dr Paul Dale | Cryptographer | Network Security & Encryption > paul.dale> Phone +61 7 3031 7217 > paul.dale> Oracle Australia > paul.dale> > paul.dale> -----Original Message----- > paul.dale> From: William Bathurst [mailto:wbath...@gmail.com] > paul.dale> Sent: Tuesday, 9 January 2018 7:10 AM > paul.dale> To: openssl-dev@openssl.org > paul.dale> Cc: llamour...@gmail.com > paul.dale> Subject: Re: [openssl-dev] Speck Cipher Integration with OpenSSL > paul.dale> > paul.dale> Hi Hanno/all, > paul.dale> > paul.dale> 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: > paul.dale> > paul.dale> > https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf > paul.dale> > paul.dale> 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 > paul.dale> 256 would be an option because it has better performance and > provides sufficient security. > paul.dale> > paul.dale> 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. > paul.dale> > paul.dale> [IoT Device] -----TLS/Speck---->[IoT Gateway]-----TLS----> > [Services] > paul.dale> > paul.dale> 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. > paul.dale> > paul.dale> 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. > paul.dale> > paul.dale> It is my hope to accomplish the following: > paul.dale> > paul.dale> [1] Make Speck available via Open Source, this could be as an > option or as a patch in OpenSSL. > paul.dale> [2] If we make it available as a patch, is there a place where we > would announce/make it known that it is available? > paul.dale> > paul.dale> 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. > paul.dale> > paul.dale> Thanks for your input! > paul.dale> > paul.dale> Bill > paul.dale> > paul.dale> On 1/5/2018 11:40 AM, Hanno Böck wrote: > paul.dale> > On Fri, 5 Jan 2018 10:52:01 -0800 > paul.dale> > William Bathurst <wbath...@gmail.com> wrote: > paul.dale> > > paul.dale> >> 1) Community interest in such a lightweight cipher. > paul.dale> > I think there's a shifting view that "more is not always good" > in > paul.dale> > crypto. OpenSSL has added features in the past "just because" > and it > paul.dale> > was often a bad decision. > paul.dale> > > paul.dale> > Therefore I'd generally oppose adding ciphers without a clear > usecase, > paul.dale> > as increased code complexity has a cost. > paul.dale> > So I think questions that should be answered: > paul.dale> > What's the usecase for speck in OpenSSL? Are there plans to use > it in > paul.dale> > TLS? If yes why? By whom? What advantages does it have over > existing > paul.dale> > ciphers? (Yeah, it's "lightweight", but that's a pretty vague > thing.) > paul.dale> > > paul.dale> > > paul.dale> > Also just for completeness, as some may not be aware: There are > some > paul.dale> > concerns about Speck due to its origin (aka the NSA). I don't > think > paul.dale> > that is a reason to dismiss a cipher right away, what I'd find > more > paul.dale> > concerning is that from what I observed there hasn't been a lot > of > paul.dale> > research about speck. > paul.dale> > > paul.dale> > paul.dale> -- > paul.dale> openssl-dev mailing list > paul.dale> To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-dev > paul.dale> -- > paul.dale> openssl-dev mailing list > paul.dale> To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-dev > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
