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.


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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to