[openssl-dev] Speck Cipher Integration with OpenSSL

Tue Jan 9 07:46:13 UTC 2018

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 <levitte at 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 at default> on Mon, 8 Jan 2018 13:58:59 -0800 (PST), Paul Dale <paul.dale at 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:wbathurs at gmail.com] 
> paul.dale> Sent: Tuesday, 9 January 2018 7:10 AM
> paul.dale> To: openssl-dev at openssl.org
> paul.dale> Cc: Llamoureux at 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 <wbathurs at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5801 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180109/114d9fc0/attachment.bin>