Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Daniel Kahn Gillmor]

On Tue 2018-01-09 18:41:25 -0800, William Bathurst wrote:
> [ dkg wrote: ]
>> 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.

It sounds like we agree that adversarial cryptanalysis is a necessary
component of evaluating cryptographic algorithms today. :)

And yes, Simon and Speck have indeed been published for a while now.  My
understanding is that there has been a steady stream of cryptanalysis
against them, which has made some non-negligible progress in whittling
down their initially-claimed security levels.

Meanwhile (as i said above), the designers have not been particularly
forthcoming with producing their design goals and their own
cryptanalysis, despite requests for those documents.  Shouldn't the
designers of algorithms intended to be used by the public also be
transparent about their design goals and their own understanding of the
strengths and weaknesses of the algorithms they're proposing?  This
seems particularly relevant when the designers have been plausibly
accused of trying to pass off sub-standard cryptographic algorithms as
acceptable for public consumption (e.g. "we got punked" as one NIST
representative described the Dual EC DRBG fiasco).

I'd personally like to see documentation of the internal design goals
and cryptanalysis from the authors of Simon and Speck before considering
it for wider adoption, especially given that reasonably efficient strong
ciphers are already available.  Or do you think that knowing the
designers' goals and internal analysis should not a relevant criterion
for consideration?

Regards,

   --dkg


signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Wim Lewis]

On 9. jan. 2018, at 7:40 f.h., Randall S. Becker  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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[William Bathurst]

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

>

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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[William Bathurst]

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)


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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Hubert Kario]

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

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Salz, Rich via openssl-dev]

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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Randall S. Becker]

On January 9, 2018 9:46 AM Benjamin Kaduk wrote:
> To: openssl-dev@openssl.org; Randall S. Becker 
> 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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Benjamin Kaduk via openssl-dev]

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

Re: [openssl-dev] 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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Salz, Rich via openssl-dev]

➢  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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Hanno Böck]

Hi,

I'm not particularly convinced.

On Mon, 8 Jan 2018 13:10:07 -0800
William Bathurst  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: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Dmitry Belyavsky]

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

Re: [openssl-dev] 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 <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 followi

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Richard Levitte]

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 B

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

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

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:wbath...@gmail.com] 
Sent: Tuesday, 9 January 2018 7:10 AM
To: openssl-dev@openssl.org
Cc: llamour...@gmail.com
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 <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
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Benjamin Kaduk via openssl-dev]

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

Re: [openssl-dev] 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  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

Re: [openssl-dev] 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) 
> 
>
> 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


signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Hanno Böck]

On Fri, 5 Jan 2018 10:52:01 -0800
William Bathurst  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: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev