I'm hoping we can get iwd fixed to use a userspace crypto library, as well. This is something that people could help with.

iwd also runs as root, so it would be okay with a CAP_SYS_ADMIN permission check if one were introduced, I think.

The fact that the first link recommends using keyctl() for RSA private keys is also "interesting", given that the kernel's implementation of RSA isn't hardened against timing attacks (but userspace implementations of RSA typically are).

To be clear, general-purpose Linux distros generally can't disable these kconfig options yet, due to these cases. But there are many Linux systems that simply don't need this functionality.

A good project for someone to work on would be to fix iwd and cryptsetup to always use userspace crypto, as they should.

I think cryptsetup / LUKS also requires it with some non-default options. With the default options, it works fine with the kconfigs disabled.

There's not much else, as far as I know. Normally programs just use a userspace library instead, such as OpenSSL.

The algorithm being used in this exploit, "authencesn", is even an IPsec implementation detail, which never should have been exposed to userspace as a general-purpose en/decryption API.

If you're in charge of the configuration for a Linux kernel, I strongly recommend disabling all CONFIG_CRYPTO_USER_API_* kconfig options. This would have made this bug, and also every past and future AF_ALG bug, unexploitable. In the unlikely event that you find that it breaks any userspace programs on your system, please help migrate them to userspace crypto code! For some it's already been done. But in general, AF_ALG has actually never been used much in the first place, other than in exploits.

I don't think there's much other option. This sort of userspace API might have been sort of okay many years ago. But it just doesn't stand up in a world with syzbot, LLM-assisted bug discovery, etc.

IMO, what the maintainer did (taking authorship and crediting the original author/reporter via Reported-by, after rewriting the entire patch including the commit message) was in line with kernel conventions. The lines are a bit blurry, and I think keeping the original author/reporter as at least a Co-developer would also have been acceptable. Still, people sometimes complain if they are kept as the author or co-developer if their patch is rewritten, as they don't want to "own" that rewritten patch and take blame for any issues in it. So pick your poison.

Ideally, more time would have been taken to work with the original author/reporter to get their patch in shape. Unfortunately, there isn't always time for that. In this case, the bug was reported to security@kernel.org as a security vulnerability, so that throws much of the usual process out the window; it needed to be fixed quickly. The maintainer went out of their way to get it fixed quickly, in a better way, and even added unit tests for it later. The original author/reporter was credited in both the fix commit and the pull request merge commit. Also note that the maintainer's commit is dated June 7 and was merged into mainline on June 9. So AFAICS, it predated the original author/reporter sending a revised patch; it postdated only the first patch.

This isn't unusual. This is actually the usual case.

The unusual thing here is actually that someone downstream noticed they were missing a fix (probably because its LTP regression test was failing, which is also unusual because most kernel fixes don't have an LTP regression test).

More commonly, no one notices and these bugs never get fixed in downstream kernels that aren't staying up to-date with LTS; and there is never a CVE, an oss-security post, a Hacker News thread, etc. But these bugs are still there.

- https://syzkaller.appspot.com/linux-4.14 - https://syzkaller.appspot.com/linux-4.19

As far as I know, no one is doing anything with the syzbot bugs against stable kernels directly, since no company using Linux is paying anyone to do it as their job. But some are getting fixed; e.g., some get reported against mainline too, then fixed and backported.

Also, note that there may not actually be a proof-of-concept exploit yet, beyond a reproducer causing a KASAN splat. When people request a CVE for a use-after-free bug they usually just assume that code execution may be possible. (Exploits can be very creative.)

We considered it, of course, along with many other block ciphers. However, heavily optimized Threefish-256 is 22.6 cycles per byte on Cortex-A7 (by far the most common CPU this is needed on) which is over twice as slow as Adiantum. Threefish-512 and Threefish-1024 would be much slower still. We're already at the borderline of the performance needed to actually get all Android devices encrypted, so over 2x worse performance is a no-go.

Threefish also wasn't published as a standalone block cipher but rather was part of Skein, which lost the SHA-3 competition. Therefore it hasn't received as much cryptanalysis as ChaCha and AES, and probably won't get much more in the future.

Finally, note that unlike Adiantum, Threefish isn't a wide-block cipher, where flipping one bit in the sector scrambles all other bits. So comparing its complexity directly to Adiantum's is somewhat unfair. Other wide-block modes such as HCH and HCTR are also more complex than narrow-block modes.

Some have argued this problem will go away with new CPUs that can do AES faster. This is probably the "right" solution. But in practice this will require ARM CE (AES instructions). Unfortunately, this is an optional processor extension and it will be _at least_ several years before all relevant processors have it, if they ever all do. Note that this requires moving the whole industry, including not just device vendors but also the SoC and processor vendors they rely on; and devices are usually planned years in advance, with price, performance, and power efficiency being the main concerns, rather than encryption. So, it is tough and very slow, and a software solution could be in place much sooner. Plus, in any case it would be valuable to have an efficient cipher in software, in case a weakness is found in AES.

Why Speck128-XTS? Well, after extensive research it actually seems to be the best option from a technical perspective, considering many security and performance aspects; see e.g. https://www.spinics.net/lists/linux-crypto/msg33000.html for details. Again, this is specifically for the disk/file encryption use case on processors without AES instructions. The fact that there isn't a less controversial option is really a consequence of the current state of the art, and not (as far as I can tell) just because we haven't done our homework. Most critically, in the disk/file encryption use case there is no space to store a nonce; thus, stream ciphers such as ChaCha20 are inappropriate, as IVs are reused when data is overwritten, and with flash storage and/or f2fs an attacker may even be able to recover from the "disk" multiple versions of data written to a particular logical block offset, even after only a single point-in-time offline compromise. Stream ciphers fail much more catastrophically than XTS here. (It's unfortunate how many "crypto people" seem to be unfamiliar with the problems and constraints of practical disk encryption.)

Of course, even with kernel support available, no Android device will actually use Speck until it is actually added to the CDD. That may or may not actually happen, and isn't my call. Given the increased level of controversy, it may very well be punted on for this year's Android release. Still, the alternative of no encryption is not okay, so in parallel we've also designed a new length-preserving encryption construction ("HPolyC") based on XChaCha and Poly1305, which will be published soon. Hopefully the wider crypto community will also step up to help review this construction and even publish other new software-optimized disk encryption algorithms, which are greatly needed. (And separately, perhaps the Speck team can better rise to the occasion of the, arguably disproportional but perhaps well-deserved, level of scrutity they are receiving and really set the gold standard for crypto proposals. Although I still find their latest paper to be of higher quality than you find from other designers, it evidently still has room for improvement; and crypto needs to be held to exceptionally high standards in any case.)