Speck Cipher Integration with OpenSSL

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Speck Cipher Integration with OpenSSL

William Bathurst
Hello All,

We have open sourced our work in regards to integrating the Speck Cipher
with OpenSSL. Basic information about this cipher can be found here.

https://en.wikipedia.org/wiki/Speck_(cipher)
<https://en.wikipedia.org/wiki/Speck_%28cipher%29>

SPECK is a lightweight block ciphers each of which comes in a variety of
widths and key sizes and is targeted towards resource constrained
devices and environments. This implementation is currently implemented
using the 128 and 256 block sizes.

We are currently modifying the source from Apache to OpenSSL open source
licensing for the Speck/OpenSSL integration. Related repositories such
as the cipher itself will remain under the Apache license. We would love
input on the following items:

1) Community interest in such a lightweight cipher.
2) Committers willing to help on the code for improvements.
3) Information on how to make this available as a patch.

We have currently integrated Speck with OpenSSL 1.1. We also have an
Speck Client software available for people who wish to test this
software. Future ports will be to mbedTLS.

We have listed making it available as an issue:

https://github.com/openssl/openssl/issues

OpenSSL/Speck Integration open source repositories:

https://github.com/m2mi/openssl_speck
https://github.com/m2mi/open_speck

Feel free to contact to to discuss the cipher and uses.

With Regards,
Bill

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

Daniel Kahn Gillmor
Hi Bill--

On Fri 2018-01-05 10:52:01 -0800, William Bathurst wrote:

> We have open sourced our work in regards to integrating the Speck Cipher
> with OpenSSL. Basic information about this cipher can be found here.
>
> https://en.wikipedia.org/wiki/Speck_(cipher)
> <https://en.wikipedia.org/wiki/Speck_%28cipher%29>
>
> SPECK is a lightweight block ciphers each of which comes in a variety of
> widths and key sizes and is targeted towards resource constrained
> devices and environments. This implementation is currently implemented
> using the 128 and 256 block sizes.
Thanks for your work on this, and for reporting on it here.  Out of
curiosity, who is the "We" involved here?  The changeset history
appears to be a bit ambivalent about the authorship, based on edits to
the README itself:

  https://github.com/m2mi/openssl_speck/commit/4a67a5644ff5c56956063d858033585f57686d1e
  https://github.com/m2mi/openssl_speck/commit/8d619beffa3bd1c221fc6a7946b9aa7a00774019

> 1) Community interest in such a lightweight cipher.

I'm not convinced that the OpenSSL project should encourage the adoption
of SPECK, given the general level of distrust around the algorithm:

  https://www.schneier.com/blog/archives/2017/09/iso_rejects_nsa.html

My understanding is that the algorithm designers and primary advocates
have not been particularly forthcoming with their design goals, and
their reputation is mixed, at best.

Regards,

      --dkg

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

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

Hanno Böck-4
In reply to this post by William Bathurst
On Fri, 5 Jan 2018 10:52:01 -0800
William Bathurst <[hidden email]> 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.

--
Hanno Böck
https://hboeck.de/

mail/jabber: [hidden email]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

William Bathurst
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.

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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

OpenSSL - Dev mailing list
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

Paul Dale
In reply to this post by William Bathurst
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.

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.

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.


Pauli
--
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia

-----Original Message-----
From: William Bathurst [mailto:[hidden email]]
Sent: Tuesday, 9 January 2018 7:10 AM
To: [hidden email]
Cc: [hidden email]
Subject: Re: [openssl-dev] Speck Cipher Integration with OpenSSL

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.

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 <[hidden email]> 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
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

Richard Levitte - VMS Whacker-2
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 <[hidden email]> 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:[hidden email]]
paul.dale> Sent: Tuesday, 9 January 2018 7:10 AM
paul.dale> To: [hidden email]
paul.dale> Cc: [hidden email]
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

Blumenthal, Uri - 0553 - MITLL
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 <[hidden email]> 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 <[hidden email]> 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:[hidden email]]
> paul.dale> Sent: Tuesday, 9 January 2018 7:10 AM
> paul.dale> To: [hidden email]
> paul.dale> Cc: [hidden email]
> 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 <[hidden email]> 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

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

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

Dmitry Belyavsky-3
In reply to this post by William Bathurst
Dear William,

Does SPECK implementation need to be a part of the OpenSSL bundle itself? 
It can be added as engine, similar to Russian GOST support, with minimal patches providing OIDs/NIDs if necessary.

On Fri, Jan 5, 2018 at 9:52 PM, William Bathurst <[hidden email]> wrote:
Hello All,

We have open sourced our work in regards to integrating the Speck Cipher with OpenSSL. Basic information about this cipher can be found here.

https://en.wikipedia.org/wiki/Speck_(cipher) <https://en.wikipedia.org/wiki/Speck_%28cipher%29>

SPECK is a lightweight block ciphers each of which comes in a variety of widths and key sizes and is targeted towards resource constrained devices and environments. This implementation is currently implemented using the 128 and 256 block sizes.

We are currently modifying the source from Apache to OpenSSL open source licensing for the Speck/OpenSSL integration. Related repositories such as the cipher itself will remain under the Apache license. We would love input on the following items:

1) Community interest in such a lightweight cipher.
2) Committers willing to help on the code for improvements.
3) Information on how to make this available as a patch.

We have currently integrated Speck with OpenSSL 1.1. We also have an Speck Client software available for people who wish to test this software. Future ports will be to mbedTLS.

We have listed making it available as an issue:

https://github.com/openssl/openssl/issues

OpenSSL/Speck Integration open source repositories:

https://github.com/m2mi/openssl_speck
https://github.com/m2mi/open_speck

Feel free to contact to to discuss the cipher and uses.

With Regards,
Bill

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



--
SY, Dmitry Belyavsky

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

Hanno Böck-4
In reply to this post by William Bathurst
Hi,

I'm not particularly convinced.

On Mon, 8 Jan 2018 13:10:07 -0800
William Bathurst <[hidden email]> wrote:

> 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.

Why would someone want a 256 bit cipher in a constrained device? This
sounds more like crypto numerology to me where people think "larger
keys are better just because". I'd take a well researched algorithm
like aes128 over a hardly researcherd 256 bit one every time.

> 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.

Ok, so we're talking about Speck in TLS here.
I feel this raises the bar even more and doesn't really belong here any
time soon.
Is there any effort in standardizing this? I haven't seen it on the TLS
WG mailing list and I tried to google speck tls draft and haven't found
anything.

For the record: I feel such a move - adding a new cipher to TLS -
requires much more than "we want a lightweight cipher and NSA gave us
one".
If there is serious demand for more lightweight ciphers in TLS I'd
expect some kind of open and transparent competition like it happened
with AES or SHA3 - or at least some open discussion in CFRG. However I'm
not convinced this demand even exists.


--
Hanno Böck
https://hboeck.de/

mail/jabber: [hidden email]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

OpenSSL - Dev mailing list
In reply to this post by William Bathurst

➢  We are currently modifying the source from Apache to OpenSSL open source
    licensing for the Speck/OpenSSL integration. Related repositories such
    as the cipher itself will remain under the Apache license. We would love
    input on the following items:

Don’t bother changing the license.  The future direction of OpenSSL is moving to Apache, anda it’s unlikely this work would show up in OpenSSL before we change the license.

We’ll soon have a blog post about our current thoughts on a crypto policy.  Watch this space.

For discussion, the future-compatible thing to do :) is open a GitHub issue.  Then, make a pull request after the issue discussion seems to have died down.

Hope this helps.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

Randall S. Becker
On January 9, 2018 8:41 AM, Rich Salz

> ➢  We are currently modifying the source from Apache to OpenSSL open
> source
>     licensing for the Speck/OpenSSL integration. Related repositories such
>     as the cipher itself will remain under the Apache license. We would love
>     input on the following items:
>
> Don’t bother changing the license.  The future direction of OpenSSL is moving
> to Apache, anda it’s unlikely this work would show up in OpenSSL before we
> change the license.
>
> We’ll soon have a blog post about our current thoughts on a crypto policy.
> Watch this space.
>
> For discussion, the future-compatible thing to do :) is open a GitHub issue.
> Then, make a pull request after the issue discussion seems to have died
> down.

A request, maybe OT. The NonStop platform does broadly deploy Apache but do use OpenSSL. I understand that OpenSSL does not officially support the HPE NonStop NSE/NSX platforms - but it is used on the platform through my team's port, which I currently support, and through other ports as well. Added a dependency to Apache is likely to dead-end the project for us depending on the depth of the dependency, if I understand where this is going (hoping I am wrong).

With respect,
Randall

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

OpenSSL - Dev mailing list
On 01/09/2018 08:32 AM, Randall S. Becker wrote:

> On January 9, 2018 8:41 AM, Rich Salz
>> ➢  We are currently modifying the source from Apache to OpenSSL open
>> source
>>     licensing for the Speck/OpenSSL integration. Related repositories such
>>     as the cipher itself will remain under the Apache license. We would love
>>     input on the following items:
>>
>> Don’t bother changing the license.  The future direction of OpenSSL is moving
>> to Apache, anda it’s unlikely this work would show up in OpenSSL before we
>> change the license.
>>
>> We’ll soon have a blog post about our current thoughts on a crypto policy.
>> Watch this space.
>>
>> For discussion, the future-compatible thing to do :) is open a GitHub issue.
>> Then, make a pull request after the issue discussion seems to have died
>> down.
> A request, maybe OT. The NonStop platform does broadly deploy Apache but do use OpenSSL. I understand that OpenSSL does not officially support the HPE NonStop NSE/NSX platforms - but it is used on the platform through my team's port, which I currently support, and through other ports as well. Added a dependency to Apache is likely to dead-end the project for us depending on the depth of the dependency, if I understand where this is going (hoping I am wrong).
>

Apache license, not Apache software.   

-Ben
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

Randall S. Becker
On January 9, 2018 9:46 AM Benjamin Kaduk wrote:

> To: [hidden email]; Randall S. Becker <[hidden email]>
> On 01/09/2018 08:32 AM, Randall S. Becker wrote:
> > On January 9, 2018 8:41 AM, Rich Salz
> >> ➢  We are currently modifying the source from Apache to OpenSSL open
> >> source
> >>     licensing for the Speck/OpenSSL integration. Related repositories such
> >>     as the cipher itself will remain under the Apache license. We would love
> >>     input on the following items:
> >>
> >> Don’t bother changing the license.  The future direction of OpenSSL
> >> is moving to Apache, anda it’s unlikely this work would show up in
> >> OpenSSL before we change the license.
> >>
> >> We’ll soon have a blog post about our current thoughts on a crypto policy.
> >> Watch this space.
> >>
> >> For discussion, the future-compatible thing to do :) is open a GitHub issue.
> >> Then, make a pull request after the issue discussion seems to have
> >> died down.
> > A request, maybe OT. The NonStop platform does broadly deploy Apache
> but do use OpenSSL. I understand that OpenSSL does not officially support
> the HPE NonStop NSE/NSX platforms - but it is used on the platform through
> my team's port, which I currently support, and through other ports as well.
> Added a dependency to Apache is likely to dead-end the project for us
> depending on the depth of the dependency, if I understand where this is
> going (hoping I am wrong).
> >
>
> Apache license, not Apache software.

Thank you thank you thank you 😊, but sorry about adding noise to the conversation.
Cheers,
Randall

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

OpenSSL - Dev mailing list
In reply to this post by Randall S. Becker
I don’t think anyone is talking about OpenSSL depending on or requiring Apache; that’s a non-starter.

It would be interesting to see how many changes you need to support your platform.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

Randall S. Becker
On January 9, 2018 10:05 AM, Rich Salz wrote:
> It would be interesting to see how many changes you need to support your
> platform.

Surprisingly not many at all. The platform has been significantly modernized since early ports. Most of the differences are the addition of a FLOSS layer (though #includes) and one byte swap issue on bn_mul_add_words that I'm not sure is relevant anymore. Some of the tracked files that generated (tests/Makefile) have spacing difference due to tooling differences. The code, however, is very close to vanilla as of 1.0.2n.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

Hubert Kario
In reply to this post by William Bathurst
On Monday, 8 January 2018 22:10:07 CET 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-20
> 15/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.
so security is afterthought, but they got out of their way to use "more
secure" (debatable) option?

sorry, that does not hold water
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

William Bathurst
In reply to this post by Daniel Kahn Gillmor
Hi dkg,

You stated the following:

My understanding is that the algorithm designers and primary advocates
have not been particularly forthcoming with their design goals, and
their reputation is mixed, at best.

Simon and Speck has been in the public domain for a number of years and
there are quite a few white papers and articles on the Ciphers. Allowing
public scrutiny and crypto-analysis is one way to put a cipher through
the grinder to make sure there are no back doors or weaknesses.

Regards,
Bill


On 1/5/2018 11:33 AM, Daniel Kahn Gillmor wrote:

> Hi Bill--
>
> On Fri 2018-01-05 10:52:01 -0800, William Bathurst wrote:
>
>> We have open sourced our work in regards to integrating the Speck Cipher
>> with OpenSSL. Basic information about this cipher can be found here.
>>
>> https://en.wikipedia.org/wiki/Speck_(cipher)
>> <https://en.wikipedia.org/wiki/Speck_%28cipher%29>
>>
>> SPECK is a lightweight block ciphers each of which comes in a variety of
>> widths and key sizes and is targeted towards resource constrained
>> devices and environments. This implementation is currently implemented
>> using the 128 and 256 block sizes.
> Thanks for your work on this, and for reporting on it here.  Out of
> curiosity, who is the "We" involved here?  The changeset history
> appears to be a bit ambivalent about the authorship, based on edits to
> the README itself:
>
>    https://github.com/m2mi/openssl_speck/commit/4a67a5644ff5c56956063d858033585f57686d1e
>    https://github.com/m2mi/openssl_speck/commit/8d619beffa3bd1c221fc6a7946b9aa7a00774019
>
>> 1) Community interest in such a lightweight cipher.
> I'm not convinced that the OpenSSL project should encourage the adoption
> of SPECK, given the general level of distrust around the algorithm:
>
>    https://www.schneier.com/blog/archives/2017/09/iso_rejects_nsa.html
>
> My understanding is that the algorithm designers and primary advocates
> have not been particularly forthcoming with their design goals, and
> their reputation is mixed, at best.
>
> Regards,
>
>        --dkg

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

William Bathurst
In reply to this post by Dmitry Belyavsky-3

Hi Dmitry,

We implemented it using the same means as we saw the other ciphers. It was using the EVP functions. This way it could be included or excluded via makefile.

Regards,
Bill


On 1/9/2018 12:23 AM, Dmitry Belyavsky wrote:
Dear William,

Does SPECK implementation need to be a part of the OpenSSL bundle itself? 
It can be added as engine, similar to Russian GOST support, with minimal patches providing OIDs/NIDs if necessary.

On Fri, Jan 5, 2018 at 9:52 PM, William Bathurst <[hidden email]> wrote:
Hello All,

We have open sourced our work in regards to integrating the Speck Cipher with OpenSSL. Basic information about this cipher can be found here.

https://en.wikipedia.org/wiki/Speck_(cipher) <https://en.wikipedia.org/wiki/Speck_%28cipher%29>

SPECK is a lightweight block ciphers each of which comes in a variety of widths and key sizes and is targeted towards resource constrained devices and environments. This implementation is currently implemented using the 128 and 256 block sizes.

We are currently modifying the source from Apache to OpenSSL open source licensing for the Speck/OpenSSL integration. Related repositories such as the cipher itself will remain under the Apache license. We would love input on the following items:

1) Community interest in such a lightweight cipher.
2) Committers willing to help on the code for improvements.
3) Information on how to make this available as a patch.

We have currently integrated Speck with OpenSSL 1.1. We also have an Speck Client software available for people who wish to test this software. Future ports will be to mbedTLS.

We have listed making it available as an issue:

https://github.com/openssl/openssl/issues

OpenSSL/Speck Integration open source repositories:

https://github.com/m2mi/openssl_speck
https://github.com/m2mi/open_speck

Feel free to contact to to discuss the cipher and uses.

With Regards,
Bill

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



--
SY, Dmitry Belyavsky




--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speck Cipher Integration with OpenSSL

Wim Lewis-3
In reply to this post by Randall S. Becker

On 9. jan. 2018, at 7:40 f.h., Randall S. Becker <[hidden email]> wrote:
> On January 9, 2018 10:05 AM, Rich Salz wrote:
>> It would be interesting to see how many changes you need to support your
>> platform.
>
> Surprisingly not many at all. The platform has been significantly modernized since early ports. Most of the differences are the addition of a FLOSS layer (though #includes) and one byte swap issue on bn_mul_add_words that I'm not sure is relevant anymore. Some of the tracked files that generated (tests/Makefile) have spacing difference due to tooling differences. The code, however, is very close to vanilla as of 1.0.2n.

In this case, I think Dmitry Belyavsky's suggestion makes the most sense. SPECK can be built as an ENGINE, the same way that GOST, CAPI, etc. are. (see [1].) This may require small changes to OpenSSL proper (to add OIDs, say), but they should be small enough not to add any complexity or maintenance burden to OpenSSL. If/when SPECK gains more use, or is considered for standardization in TLS, etc., then this codebase can be moved into OpenSSL's. In the meantime, people can build the SPECK engine to use it in an OpenSSL-based program.

[1] https://github.com/gost-engine/engine

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