Re: [PATCH 0/5] crypto: Speck support

2018-02-12 Thread Eric Biggers 
Hi Jeff,

On Mon, Feb 12, 2018 at 02:57:06PM -0500, Jeffrey Walton wrote:
> On Mon, Feb 12, 2018 at 2:19 PM, Eric Biggers  wrote:
> > Hi all,
> >
> > On Fri, Feb 09, 2018 at 07:07:01PM -0500, Jeffrey Walton wrote:
> >> > Hi Jeffrey,
> >> >
> >> > I see you wrote the SPECK implementation in Crypto++, and you are 
> >> > treating the
> >> > words as big endian.
> >> >
> >> > Do you have a reference for this being the "correct" order?  
> >> > Unfortunately the
> >> > authors of the cipher failed to mention the byte order in their paper.  
> >> > And they
> >> > gave the test vectors as words, so the test vectors don't clarify it 
> >> > either.
> >> >
> >> > I had assumed little endian words, but now I am having second 
> >> > thoughts...  And
> >> > to confuse things further, it seems that some implementations (including 
> >> > the
> >> > authors own implementation for the SUPERCOP benchmark toolkit [1]) even 
> >> > consider
> >> > the words themselves in the order (y, x) rather than the more intuitive 
> >> > (x, y).
> >> >
> >> > [1] 
> >> > https://github.com/iadgov/simon-speck-supercop/blob/master/crypto_stream/speck128128ctr/ref/stream.c
> >> >
> >> > In fact, even the reference code from the paper treats pt[0] as y and 
> >> > pt[1] as
> >> > x, where 'pt' is a u64 array -- although that being said, it's not shown 
> >> > how the
> >> > actual bytes should be translated to/from those u64 arrays.
> >> >
> >> > I'd really like to avoid people having to add additional versions of 
> >> > SPECK later
> >> > for the different byte and word orders...
> >>
> >> Hi Eric,
> >>
> >> Yeah, this was a point of confusion for us as well. After the sidebar
> >> conversations I am wondering about the correctness of Crypto++
> >> implementation.
> >>
> >
> > We've received another response from one of the Speck creators (Louis 
> > Wingers)
> > that (to summarize) the intended byte order is little endian, and the 
> > intended
> > word order is (y, x), i.e. 'y' is at a lower memory address than 'x'.  Or
> > equivalently: the test vectors given in the original paper need to be read 
> > as
> > byte arrays from *right-to-left*.
> >
> > (y, x) is not the intuitive order, but it's not a huge deal.  The more 
> > important
> > thing is that we don't end up with multiple implementations with different 
> > byte
> > and/or word orders.
> >
> > So, barring any additional confusion, I'll send a revised version of this
> > patchset that flips the word order.  Jeff would need to flip both the byte 
> > and
> > word orders in his implementation in Crypto++ as well.
> 
> Thanks Eric.
> 
> Yeah, the (y,x) explains a lot of the confusion, and explains the
> modification I needed in my GitHub clone of the IAD Team's SUPERCOP to
> arrive at test vector results. My clone is available at
> https://github.com/noloader/simon-speck-supercop.
> 
> So let me ask you... Given the Speck-128(128) test vector from Appendix C:
> 
> Key: 0f0e0d0c0b0a0908 0706050403020100
> Plaintext: 6c61766975716520 7469206564616d20
> Ciphertext: a65d985179783265 7860fedf5c570d18
> 
> Will the Linux implementation arrive at the published result, or will
> it arrive at a different result? I guess what I am asking, where is
> the presentation detail going to be handled?
> 
> A related question is, will the kernel be parsing just the key as
> (y,x), or will all parameters be handled as (y,x)? At this point I
> believe it only needs to apply to the key but I did not investigate
> the word swapping in detail because I was chasing the test vector.
> 

The kernel implementation has to operate on byte arrays.  But the test vectors
in the original paper are given as *words* in the order (x, y) and likewise for
the key (i.e. the rightmost word shown becomes the first round key).  But based
on the clarifications from the Speck team, the actual byte arrays that
correspond to the Speck-128/128 test vector would be:

const uint8_t key[16] = 
"\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f";
const uint8_t plaintext[16] = 
"\x20\x6d\x61\x64\x65\x20\x69\x74\x20\x65\x71\x75\x69\x76\x61\x6c";
const uint8_t ciphertext[16] = 
"\x18\x0d\x57\x5c\xdf\xfe\x60\x78\x65\x32\x78\x79\x51\x98\x5d\xa6";

So equivalently, if we consider the printed test vectors as just listing the
bytes (ignoring the whitespace between the words), then they are backwards.
That applies to all 3 parts (Key, Plaintext, and Ciphertext).

Note that my patch 1/5 adds the Speck test vectors to testmgr.h so that they are
hooked into the Linux kernel's crypto self-tests, so on appropriately-configured
kernels it will be automatically verified that the implementation matches the
test vectors.  The ones in the current version of the patchset have the "wrong"
word order though, so I will need to send out a new version with the correct
implementation and test vectors.

Thanks,

Eric

Re: [PATCH 0/5] crypto: Speck support

2018-02-12 Thread Jeffrey Walton 
On Mon, Feb 12, 2018 at 2:19 PM, Eric Biggers  wrote:
> Hi all,
>
> On Fri, Feb 09, 2018 at 07:07:01PM -0500, Jeffrey Walton wrote:
>> > Hi Jeffrey,
>> >
>> > I see you wrote the SPECK implementation in Crypto++, and you are treating 
>> > the
>> > words as big endian.
>> >
>> > Do you have a reference for this being the "correct" order?  Unfortunately 
>> > the
>> > authors of the cipher failed to mention the byte order in their paper.  
>> > And they
>> > gave the test vectors as words, so the test vectors don't clarify it 
>> > either.
>> >
>> > I had assumed little endian words, but now I am having second thoughts...  
>> > And
>> > to confuse things further, it seems that some implementations (including 
>> > the
>> > authors own implementation for the SUPERCOP benchmark toolkit [1]) even 
>> > consider
>> > the words themselves in the order (y, x) rather than the more intuitive 
>> > (x, y).
>> >
>> > [1] 
>> > https://github.com/iadgov/simon-speck-supercop/blob/master/crypto_stream/speck128128ctr/ref/stream.c
>> >
>> > In fact, even the reference code from the paper treats pt[0] as y and 
>> > pt[1] as
>> > x, where 'pt' is a u64 array -- although that being said, it's not shown 
>> > how the
>> > actual bytes should be translated to/from those u64 arrays.
>> >
>> > I'd really like to avoid people having to add additional versions of SPECK 
>> > later
>> > for the different byte and word orders...
>>
>> Hi Eric,
>>
>> Yeah, this was a point of confusion for us as well. After the sidebar
>> conversations I am wondering about the correctness of Crypto++
>> implementation.
>>
>
> We've received another response from one of the Speck creators (Louis Wingers)
> that (to summarize) the intended byte order is little endian, and the intended
> word order is (y, x), i.e. 'y' is at a lower memory address than 'x'.  Or
> equivalently: the test vectors given in the original paper need to be read as
> byte arrays from *right-to-left*.
>
> (y, x) is not the intuitive order, but it's not a huge deal.  The more 
> important
> thing is that we don't end up with multiple implementations with different 
> byte
> and/or word orders.
>
> So, barring any additional confusion, I'll send a revised version of this
> patchset that flips the word order.  Jeff would need to flip both the byte and
> word orders in his implementation in Crypto++ as well.

Thanks Eric.

Yeah, the (y,x) explains a lot of the confusion, and explains the
modification I needed in my GitHub clone of the IAD Team's SUPERCOP to
arrive at test vector results. My clone is available at
https://github.com/noloader/simon-speck-supercop.

So let me ask you... Given the Speck-128(128) test vector from Appendix C:

Key: 0f0e0d0c0b0a0908 0706050403020100
Plaintext: 6c61766975716520 7469206564616d20
Ciphertext: a65d985179783265 7860fedf5c570d18

Will the Linux implementation arrive at the published result, or will
it arrive at a different result? I guess what I am asking, where is
the presentation detail going to be handled?

A related question is, will the kernel be parsing just the key as
(y,x), or will all parameters be handled as (y,x)? At this point I
believe it only needs to apply to the key but I did not investigate
the word swapping in detail because I was chasing the test vector.

Jeff

Re: [PATCH 0/5] crypto: Speck support

2018-02-12 Thread Eric Biggers 
Hi all,

On Fri, Feb 09, 2018 at 07:07:01PM -0500, Jeffrey Walton wrote:
> > Hi Jeffrey,
> >
> > I see you wrote the SPECK implementation in Crypto++, and you are treating 
> > the
> > words as big endian.
> >
> > Do you have a reference for this being the "correct" order?  Unfortunately 
> > the
> > authors of the cipher failed to mention the byte order in their paper.  And 
> > they
> > gave the test vectors as words, so the test vectors don't clarify it either.
> >
> > I had assumed little endian words, but now I am having second thoughts...  
> > And
> > to confuse things further, it seems that some implementations (including the
> > authors own implementation for the SUPERCOP benchmark toolkit [1]) even 
> > consider
> > the words themselves in the order (y, x) rather than the more intuitive (x, 
> > y).
> >
> > [1] 
> > https://github.com/iadgov/simon-speck-supercop/blob/master/crypto_stream/speck128128ctr/ref/stream.c
> >
> > In fact, even the reference code from the paper treats pt[0] as y and pt[1] 
> > as
> > x, where 'pt' is a u64 array -- although that being said, it's not shown 
> > how the
> > actual bytes should be translated to/from those u64 arrays.
> >
> > I'd really like to avoid people having to add additional versions of SPECK 
> > later
> > for the different byte and word orders...
> 
> Hi Eric,
> 
> Yeah, this was a point of confusion for us as well. After the sidebar
> conversations I am wondering about the correctness of Crypto++
> implementation.
> 

We've received another response from one of the Speck creators (Louis Wingers)
that (to summarize) the intended byte order is little endian, and the intended
word order is (y, x), i.e. 'y' is at a lower memory address than 'x'.  Or
equivalently: the test vectors given in the original paper need to be read as
byte arrays from *right-to-left*.

(y, x) is not the intuitive order, but it's not a huge deal.  The more important
thing is that we don't end up with multiple implementations with different byte
and/or word orders.

So, barring any additional confusion, I'll send a revised version of this
patchset that flips the word order.  Jeff would need to flip both the byte and
word orders in his implementation in Crypto++ as well.

- Eric

> As a first step here is the official test vector for Speck-128(128)
> from Appendix C, p. 42 (https://eprint.iacr.org/2013/404.pdf):
> 
> Speck128/128
> Key: 0f0e0d0c0b0a0908 0706050403020100
> Plaintext: 6c61766975716520 7469206564616d20
> Ciphertext: a65d985179783265 7860fedf5c570d18
> 
> We had some confusion over the presentation. Here is what the Simon
> and Speck team sent when I asked about it, what gets plugged into the
> algorithm, and how it gets plugged in:
> 
> 
> 
> On Mon, Nov 20, 2017 at 10:50 AM,  wrote:
> > ...
> > I'll explain the problem you have been having with our test vectors.
> >
> > The key is:  0x0f0e0d0c0b0a0908 0x0706050403020100
> > The plaintext is:  6c61766975716520 7469206564616d20
> > The ciphertext is:  a65d985179783265 7860fedf5c570d18
> >
> > The problem is essentially one of what goes where and we probably could
> > have done a better job explaining things.
> >
> > For the key, with two words, K=(K[1],K[0]).  With three words 
> > K=(K[2],K[1],K[0]),
> > with four words K=(K[3],K[2],K[1],K[0]).
> >
> > So for the test vector you should have K[0]= 0x0706050403020100, K[1]= 
> > 0x0f0e0d0c0b0a0908
> > which is the opposite of what you have done.
> >
> > If we put this K into ExpandKey(K,sk) then the first few round keys
> > are:
> >
> > 0706050403020100
> > 37253b31171d0309
> > f91d89cc90c4085c
> > c6b1f07852cc7689
> > ...
> >
> > For the plaintext, P=(P[1],P[0]), i.e., P[1] goes into the left word of the 
> > block cipher
> > and P[0] goes into the right word of the block cipher.  So you should have
> > m[0]= 7469206564616d20 and m[1]= 6c61766975716520, which is again opposite 
> > of what you
> > have. If c[0]=m[0] and c[1]=m[1], then the encrypt function should be 
> > called as
> > Encrypt(c+1,c+0,sk).   The resulting ciphertext is (c+1,c+0).
> >
> > In general, everything goes in as a byte stream (not 64-bit words).  In 
> > this case,
> > if the 16 bytes of key are 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 
> > then
> > we first need to turn these into two 64-bit words.  The first word, K[0] is
> > 0706050403020100 and the second word is K[1]=0f0e0d0c0b0a0908.  On x86 
> > processors,
> > if the key bytes are in the array k[] of type uint8_t, then a simple
> > casting should get you K[1] and K[0].  That is, K[0]=((uint64_t *)k)[0] and
> > K[1]=((uint64_t *)k)[1].  The key expansion is run with ExpandKey(K,sk).
> > So that was what we had in mind.
> >
> > Similarly, if the plaintext "bytes" were:  20 6d 61 64 65 20 69 74 20 65 71 
> > 75 69 76 61 6c
> > (which is ascii for " made it equival")
> > then we first need to turn these into two 64-bit words.  The first word is
> > pt[0]=7469206564616d20 and the second word is

Re: [PATCH 0/5] crypto: Speck support

2018-02-09 Thread Jeffrey Walton 
On Thu, Feb 8, 2018 at 4:01 PM, Eric Biggers  wrote:
> On Wed, Feb 07, 2018 at 08:47:05PM -0500, Jeffrey Walton wrote:
>> On Wed, Feb 7, 2018 at 7:09 PM, Eric Biggers  wrote:
>> > Hello,
>> >
>> > This series adds Speck support to the crypto API, including the Speck128
>> > and Speck64 variants.  Speck is a lightweight block cipher that can be
>> > much faster than AES on processors that don't have AES instructions.
>> >
>> > We are planning to offer Speck-XTS (probably Speck128/256-XTS) as an
>> > option for dm-crypt and fscrypt on Android, for low-end mobile devices
>> > with older CPUs such as ARMv7 which don't have the Cryptography
>> > Extensions.  Currently, such devices are unencrypted because AES is not
>> > fast enough, even when the NEON bit-sliced implementation of AES is
>> > used.  Other AES alternatives such as Blowfish, Twofish, Camellia,
>> > Cast6, and Serpent aren't fast enough either; it seems that only a
>> > modern ARX cipher can provide sufficient performance on these devices.
>> >
>> > This is a replacement for our original proposal
>> > (https://patchwork.kernel.org/patch/10101451/) which was to offer
>> > ChaCha20 for these devices.  However, the use of a stream cipher for
>> > disk/file encryption with no space to store nonces would have been much
>> > more insecure than we thought initially, given that it would be used on
>> > top of flash storage as well as potentially on top of F2FS, neither of
>> > which is guaranteed to overwrite data in-place.
>> >
>> > ...
>> > Thus, patch 1 adds a generic implementation of Speck, and the following
>> > patches add a 32-bit ARM NEON implementation of Speck-XTS.  The
>> > NEON-accelerated implementation is much faster than the generic
>> > implementation and therefore is the implementation that would primarily
>> > be used in practice on the devices we are targeting.
>> >
>> > There is no AArch64 implementation added, since such CPUs are likely to
>> > have the Cryptography Extensions, allowing the use of AES.
>>
>> +1 on SPECK.
>> ...
>
> Hi Jeffrey,
>
> I see you wrote the SPECK implementation in Crypto++, and you are treating the
> words as big endian.
>
> Do you have a reference for this being the "correct" order?  Unfortunately the
> authors of the cipher failed to mention the byte order in their paper.  And 
> they
> gave the test vectors as words, so the test vectors don't clarify it either.
>
> I had assumed little endian words, but now I am having second thoughts...  And
> to confuse things further, it seems that some implementations (including the
> authors own implementation for the SUPERCOP benchmark toolkit [1]) even 
> consider
> the words themselves in the order (y, x) rather than the more intuitive (x, 
> y).
>
> [1] 
> https://github.com/iadgov/simon-speck-supercop/blob/master/crypto_stream/speck128128ctr/ref/stream.c
>
> In fact, even the reference code from the paper treats pt[0] as y and pt[1] as
> x, where 'pt' is a u64 array -- although that being said, it's not shown how 
> the
> actual bytes should be translated to/from those u64 arrays.
>
> I'd really like to avoid people having to add additional versions of SPECK 
> later
> for the different byte and word orders...

Hi Eric,

Yeah, this was a point of confusion for us as well. After the sidebar
conversations I am wondering about the correctness of Crypto++
implementation.

As a first step here is the official test vector for Speck-128(128)
from Appendix C, p. 42 (https://eprint.iacr.org/2013/404.pdf):

Speck128/128
Key: 0f0e0d0c0b0a0908 0706050403020100
Plaintext: 6c61766975716520 7469206564616d20
Ciphertext: a65d985179783265 7860fedf5c570d18

We had some confusion over the presentation. Here is what the Simon
and Speck team sent when I asked about it, what gets plugged into the
algorithm, and how it gets plugged in:



On Mon, Nov 20, 2017 at 10:50 AM,  wrote:
> ...
> I'll explain the problem you have been having with our test vectors.
>
> The key is:  0x0f0e0d0c0b0a0908 0x0706050403020100
> The plaintext is:  6c61766975716520 7469206564616d20
> The ciphertext is:  a65d985179783265 7860fedf5c570d18
>
> The problem is essentially one of what goes where and we probably could
> have done a better job explaining things.
>
> For the key, with two words, K=(K[1],K[0]).  With three words 
> K=(K[2],K[1],K[0]),
> with four words K=(K[3],K[2],K[1],K[0]).
>
> So for the test vector you should have K[0]= 0x0706050403020100, K[1]= 
> 0x0f0e0d0c0b0a0908
> which is the opposite of what you have done.
>
> If we put this K into ExpandKey(K,sk) then the first few round keys
> are:
>
> 0706050403020100
> 37253b31171d0309
> f91d89cc90c4085c
> c6b1f07852cc7689
> ...
>
> For the plaintext, P=(P[1],P[0]), i.e., P[1] goes into the left word of the 
> block cipher
> and P[0] goes into the right word of the block cipher.  So you should have
> m[0]= 7469206564616d20 and m[1]= 6c61766975716520, which is again

Re: [PATCH 0/5] crypto: Speck support

2018-02-08 Thread Eric Biggers 
On Wed, Feb 07, 2018 at 08:47:05PM -0500, Jeffrey Walton wrote:
> On Wed, Feb 7, 2018 at 7:09 PM, Eric Biggers  wrote:
> > Hello,
> >
> > This series adds Speck support to the crypto API, including the Speck128
> > and Speck64 variants.  Speck is a lightweight block cipher that can be
> > much faster than AES on processors that don't have AES instructions.
> >
> > We are planning to offer Speck-XTS (probably Speck128/256-XTS) as an
> > option for dm-crypt and fscrypt on Android, for low-end mobile devices
> > with older CPUs such as ARMv7 which don't have the Cryptography
> > Extensions.  Currently, such devices are unencrypted because AES is not
> > fast enough, even when the NEON bit-sliced implementation of AES is
> > used.  Other AES alternatives such as Blowfish, Twofish, Camellia,
> > Cast6, and Serpent aren't fast enough either; it seems that only a
> > modern ARX cipher can provide sufficient performance on these devices.
> >
> > This is a replacement for our original proposal
> > (https://patchwork.kernel.org/patch/10101451/) which was to offer
> > ChaCha20 for these devices.  However, the use of a stream cipher for
> > disk/file encryption with no space to store nonces would have been much
> > more insecure than we thought initially, given that it would be used on
> > top of flash storage as well as potentially on top of F2FS, neither of
> > which is guaranteed to overwrite data in-place.
> >
> > Speck has been somewhat controversial due to its origin.  Nevertheless,
> > it has a straightforward design (it's an ARX cipher), and it appears to
> > be the leading software-optimized lightweight block cipher currently,
> > with the most cryptanalysis.  It's also easy to implement without side
> > channels, unlike AES.  Moreover, we only intend Speck to be used when
> > the status quo is no encryption, due to AES not being fast enough.
> >
> > We've also considered a novel length-preserving encryption mode based on
> > ChaCha20 and Poly1305.  While theoretically attractive, such a mode
> > would be a brand new crypto construction and would be more complicated
> > and difficult to implement efficiently in comparison to Speck-XTS.
> >
> > Thus, patch 1 adds a generic implementation of Speck, and the following
> > patches add a 32-bit ARM NEON implementation of Speck-XTS.  The
> > NEON-accelerated implementation is much faster than the generic
> > implementation and therefore is the implementation that would primarily
> > be used in practice on the devices we are targeting.
> >
> > There is no AArch64 implementation added, since such CPUs are likely to
> > have the Cryptography Extensions, allowing the use of AES.
> 
> +1 on SPECK.
> 
> Its a nice cipher that runs fast. It is nice because the security
> engineering and parameter selection is well specified, and you can
> push the margins as low as you like. It does not guess at security
> parameters like some of the other ciphers used in dm-crypt.
> 
> On a modern Core-i5 6th gen I've seen numbers as low as ...
> SPECK-64/128 runs around 2.1 cpb, and SPECK-128/256 runs around 2.4
> cpb.
> 
> I've already done some work for a US contractor who wanted/needed
> SPECK for a possible NASA contract. NASA is looking at SPECK for some
> satellite comms.
> 

Hi Jeffrey,

I see you wrote the SPECK implementation in Crypto++, and you are treating the
words as big endian.

Do you have a reference for this being the "correct" order?  Unfortunately the
authors of the cipher failed to mention the byte order in their paper.  And they
gave the test vectors as words, so the test vectors don't clarify it either.

I had assumed little endian words, but now I am having second thoughts...  And
to confuse things further, it seems that some implementations (including the
authors own implementation for the SUPERCOP benchmark toolkit [1]) even consider
the words themselves in the order (y, x) rather than the more intuitive (x, y).

[1] 
https://github.com/iadgov/simon-speck-supercop/blob/master/crypto_stream/speck128128ctr/ref/stream.c

In fact, even the reference code from the paper treats pt[0] as y and pt[1] as
x, where 'pt' is a u64 array -- although that being said, it's not shown how the
actual bytes should be translated to/from those u64 arrays.

I'd really like to avoid people having to add additional versions of SPECK later
for the different byte and word orders...

- Eric

Re: [PATCH 0/5] crypto: Speck support

2018-02-07 Thread Jeffrey Walton 
On Wed, Feb 7, 2018 at 7:09 PM, Eric Biggers  wrote:
> Hello,
>
> This series adds Speck support to the crypto API, including the Speck128
> and Speck64 variants.  Speck is a lightweight block cipher that can be
> much faster than AES on processors that don't have AES instructions.
>
> We are planning to offer Speck-XTS (probably Speck128/256-XTS) as an
> option for dm-crypt and fscrypt on Android, for low-end mobile devices
> with older CPUs such as ARMv7 which don't have the Cryptography
> Extensions.  Currently, such devices are unencrypted because AES is not
> fast enough, even when the NEON bit-sliced implementation of AES is
> used.  Other AES alternatives such as Blowfish, Twofish, Camellia,
> Cast6, and Serpent aren't fast enough either; it seems that only a
> modern ARX cipher can provide sufficient performance on these devices.
>
> This is a replacement for our original proposal
> (https://patchwork.kernel.org/patch/10101451/) which was to offer
> ChaCha20 for these devices.  However, the use of a stream cipher for
> disk/file encryption with no space to store nonces would have been much
> more insecure than we thought initially, given that it would be used on
> top of flash storage as well as potentially on top of F2FS, neither of
> which is guaranteed to overwrite data in-place.
>
> Speck has been somewhat controversial due to its origin.  Nevertheless,
> it has a straightforward design (it's an ARX cipher), and it appears to
> be the leading software-optimized lightweight block cipher currently,
> with the most cryptanalysis.  It's also easy to implement without side
> channels, unlike AES.  Moreover, we only intend Speck to be used when
> the status quo is no encryption, due to AES not being fast enough.
>
> We've also considered a novel length-preserving encryption mode based on
> ChaCha20 and Poly1305.  While theoretically attractive, such a mode
> would be a brand new crypto construction and would be more complicated
> and difficult to implement efficiently in comparison to Speck-XTS.
>
> Thus, patch 1 adds a generic implementation of Speck, and the following
> patches add a 32-bit ARM NEON implementation of Speck-XTS.  The
> NEON-accelerated implementation is much faster than the generic
> implementation and therefore is the implementation that would primarily
> be used in practice on the devices we are targeting.
>
> There is no AArch64 implementation added, since such CPUs are likely to
> have the Cryptography Extensions, allowing the use of AES.

+1 on SPECK.

Its a nice cipher that runs fast. It is nice because the security
engineering and parameter selection is well specified, and you can
push the margins as low as you like. It does not guess at security
parameters like some of the other ciphers used in dm-crypt.

On a modern Core-i5 6th gen I've seen numbers as low as ...
SPECK-64/128 runs around 2.1 cpb, and SPECK-128/256 runs around 2.4
cpb.

I've already done some work for a US contractor who wanted/needed
SPECK for a possible NASA contract. NASA is looking at SPECK for some
satellite comms.

Jeff

[PATCH 0/5] crypto: Speck support

2018-02-07 Thread Eric Biggers 
Hello,

This series adds Speck support to the crypto API, including the Speck128
and Speck64 variants.  Speck is a lightweight block cipher that can be
much faster than AES on processors that don't have AES instructions.

We are planning to offer Speck-XTS (probably Speck128/256-XTS) as an
option for dm-crypt and fscrypt on Android, for low-end mobile devices
with older CPUs such as ARMv7 which don't have the Cryptography
Extensions.  Currently, such devices are unencrypted because AES is not
fast enough, even when the NEON bit-sliced implementation of AES is
used.  Other AES alternatives such as Blowfish, Twofish, Camellia,
Cast6, and Serpent aren't fast enough either; it seems that only a
modern ARX cipher can provide sufficient performance on these devices.

This is a replacement for our original proposal
(https://patchwork.kernel.org/patch/10101451/) which was to offer
ChaCha20 for these devices.  However, the use of a stream cipher for
disk/file encryption with no space to store nonces would have been much
more insecure than we thought initially, given that it would be used on
top of flash storage as well as potentially on top of F2FS, neither of
which is guaranteed to overwrite data in-place.

Speck has been somewhat controversial due to its origin.  Nevertheless,
it has a straightforward design (it's an ARX cipher), and it appears to
be the leading software-optimized lightweight block cipher currently,
with the most cryptanalysis.  It's also easy to implement without side
channels, unlike AES.  Moreover, we only intend Speck to be used when
the status quo is no encryption, due to AES not being fast enough.

We've also considered a novel length-preserving encryption mode based on
ChaCha20 and Poly1305.  While theoretically attractive, such a mode
would be a brand new crypto construction and would be more complicated
and difficult to implement efficiently in comparison to Speck-XTS.

Thus, patch 1 adds a generic implementation of Speck, and the following
patches add a 32-bit ARM NEON implementation of Speck-XTS.  The
NEON-accelerated implementation is much faster than the generic
implementation and therefore is the implementation that would primarily
be used in practice on the devices we are targeting.

There is no AArch64 implementation added, since such CPUs are likely to
have the Cryptography Extensions, allowing the use of AES.

Eric Biggers (5):
  crypto: add support for the Speck block cipher
  crypto: speck - export common helpers
  crypto: arm/speck: add NEON-accelerated implementation of Speck-XTS
  crypto: speck - add test vectors for Speck128-XTS
  crypto: speck - add test vectors for Speck64-XTS

 arch/arm/crypto/Kconfig   |6 +
 arch/arm/crypto/Makefile  |2 +
 arch/arm/crypto/speck-neon-core.S |  431 +++
 arch/arm/crypto/speck-neon-glue.c |  290 
 crypto/Kconfig|   14 +
 crypto/Makefile   |1 +
 crypto/speck.c|  302 
 crypto/testmgr.c  |   36 +
 crypto/testmgr.h  | 1478 +
 include/crypto/speck.h|   62 ++
 10 files changed, 2622 insertions(+)
 create mode 100644 arch/arm/crypto/speck-neon-core.S
 create mode 100644 arch/arm/crypto/speck-neon-glue.c
 create mode 100644 crypto/speck.c
 create mode 100644 include/crypto/speck.h

-- 
2.16.0.rc1.238.g530d649a79-goog