Re: [PATCH] crypto: remove speck

[Eric Biggers]

Hi Jeffrey,

On Mon, Aug 06, 2018 at 09:03:27PM -0400, Jeffrey Walton wrote:
> On Mon, Aug 6, 2018 at 7:04 PM, Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
> > These are unused, undesired, and have never actually been used by
> > anybody. The original authors of this code have changed their mind about
> > its inclusion. Therefore, this patch removes it.
> 
> I think it may be unwise to completely discard Speck for several
> reasons. The two biggest pain points for me are:
> 
>   - political concerns addressed by other ciphers
>   - high quality lightweight block cipher implementation
>   - some regulated industries will need it for their problem domains
> 
> It seems to me the political concerns were addressed by not using
> Speck for Android. I don't believe HPolyC and Speck are orthogonal.
> Instead they provide the user with a choice which is usually a good
> thing.
> 
> I also think allowing politics a heavy hand endangers other ciphers
> like SM3 and SM4. I would advise against removing them just because
> they are Chinese ciphers. I suppose the same could be argued for North
> Korea and Jipsam and Pilsung (if North Korea ever offers their
> ciphers).
> 
> I think Eric, Ard and other contributions lead to a high quality
> implementation of Speck. High quality implementations that "just
> works" everywhere on multiple platforms are rather hard to come by.
> The kernel's unified implementation ensures lots of folks don't go
> making lots of mistakes when rolling their own.
> 
> There are verticals that will need a choice or alternative like Speck.
> US Aerospace, US Automotive and US Hoteliers come to mind. US
> Financial my use them too (they having some trading platforms with
> absurd requirements that make Simon and Speck appear bloated and
> overweight).  Some of the verticals are going to need an alternative
> that meets technical and security goals and pass the audits.
> 
> Choice is a good thing. Users need choices for technical, regulatory
> and legal reasons.
> 

This is about the Linux kernel, though.  The purpose of the Linux kernel's
crypto API is to allow kernel code to do crypto, and also sometimes to allow
access to crypto accelerator hardware.  It's *not* to provide a comprehensive
collection of algorithms for userspace programs to use, or to provide reference
implementations for crypto algorithms.  Before our change in plans, we needed
Speck-XTS in the kernel so that it could be used in dm-crypt and fscrypt, which
are kernel features and therefore require in-kernel implementations.  And of
course, our proposed new solution, HPolyC, will need to be supported in the
kernel too for the same reason.  It's just the way transparent disk and file
encryption works; the crypto needs to be done in the kernel.  But do your other
mentioned use cases actually need Speck to be in the Linux kernel?

I doubt it, in general.  Userspace applications of Speck seem likely to use
their own implementation.  Remember, Speck is extraordinarily simple, and the
original paper has example C code.  So if someone really wanted to use Speck in
a userspace application, they're likely to just add an implementation directly
to their application, rather than coding up a Linux-specific thing using AF_ALG.
Or they'd use a Speck implementation from a library like Crypto++.

And while I think it's clear that the reasons why a significant number of people
don't want to *use* Speck (even in legitimate use cases) are heavily political,
that doesn't necessarily mean that the reason for removing Speck from Linux
needs to be as political.  If there's code in the kernel with no known users
anymore, whether it's a crypto algorithm or something like an obsolete CPU
architecture, then it's eligible to be removed so that it doesn't need to be
maintained -- potentially even if it breaks the userspace ABI (since it's not
really broken if no one cares)...  Note that Skein is another example of a
crypto algorithm that was recently removed from the kernel because no one was
using it, though to be fair it was in the staging directory too.  It's still a
bit of a double standard as there are likely other ciphers in the kernel that
actually no one is using either, but it's a valid argument...

Thanks,

- Eric