Re: [PATCH] fscrypt: add support for ChaCha20 contents encryption

> Still, a stream cipher is sufficient to protect data confidentiality in > the event of a single point-in-time permanent offline compromise of the > disk, which currently is the primary threat model for fscrypt. Thus, > when the alternative is quite literally *no encryption*, we might as > well

Re: [RFC PATCH] crypto: chacha20 - add implementation using 96-bit nonce

On 8 December 2017 at 23:11, Eric Biggers wrote: > On Fri, Dec 08, 2017 at 10:54:24PM +, Ard Biesheuvel wrote: >> >> Note that there are two conflicting conventions for what inputs ChaCha >> >> takes. >> >> The original paper by Daniel Bernstein >> >>

Re: [RFC PATCH] crypto: chacha20 - add implementation using 96-bit nonce

On Fri, Dec 08, 2017 at 10:54:24PM +, Ard Biesheuvel wrote: > >> Note that there are two conflicting conventions for what inputs ChaCha > >> takes. > >> The original paper by Daniel Bernstein > >> (https://cr.yp.to/chacha/chacha-20080128.pdf) says that the block counter > >> is > >> 64-bit

Re: [RFC PATCH] crypto: chacha20 - add implementation using 96-bit nonce

On 8 December 2017 at 22:42, Ard Biesheuvel wrote: > On 8 December 2017 at 22:17, Eric Biggers wrote: >> On Fri, Dec 08, 2017 at 11:55:02AM +, Ard Biesheuvel wrote: >>> As pointed out by Eric [0], the way RFC7539 was interpreted when creating

Re: [RFC PATCH] crypto: chacha20 - add implementation using 96-bit nonce

On 8 December 2017 at 22:17, Eric Biggers wrote: > On Fri, Dec 08, 2017 at 11:55:02AM +, Ard Biesheuvel wrote: >> As pointed out by Eric [0], the way RFC7539 was interpreted when creating >> our implementation of ChaCha20 creates a risk of IV reuse when using a >> little

Re: [RFC PATCH] crypto: chacha20 - add implementation using 96-bit nonce

On Fri, Dec 08, 2017 at 11:55:02AM +, Ard Biesheuvel wrote: > As pointed out by Eric [0], the way RFC7539 was interpreted when creating > our implementation of ChaCha20 creates a risk of IV reuse when using a > little endian counter as the IV generator. The reason is that the low end > bits of

Re: [PATCH] fscrypt: add support for ChaCha20 contents encryption

On Fri, Dec 08, 2017 at 07:20:43AM +, Ard Biesheuvel wrote: > On 8 December 2017 at 02:51, Jason A. Donenfeld wrote: > > Hi Eric, > > > > Nice to see more use of ChaCha20. However... > > > > Can we skip over the "sort of worse than XTS, but not having _real_ > >

Re: [PATCH] KEYS: reject NULL restriction string when type is specified

On Fri, 8 Dec 2017, David Howells wrote: Mat Martineau wrote: Since this fixes the bug for the asymmetric key type and ensures that other key types won't make the same mistake, I agree this is the way to fix it. I did not find any issues in the patch.

Re: [PATCH 00/18] crypto: talitos - fixes and performance improvement

On 10/12/2017 6:20 PM, Herbert Xu wrote: > On Fri, Oct 06, 2017 at 03:04:31PM +0200, Christophe Leroy wrote: >> This serie fixes and improves the talitos crypto driver. >> >> First 6 patchs are fixes of failures reported by the new tests in the >> kernel crypto test manager. >> Looks like these

Re: [PATCH] KEYS: reject NULL restriction string when type is specified

Mat Martineau wrote: > Since this fixes the bug for the asymmetric key type and ensures that other > key types won't make the same mistake, I agree this is the way to fix it. I > did not find any issues in the patch. Can I put that down as a Reviewed-by?

AF_ALG: skb limits

Am Freitag, 8. Dezember 2017, 12:39:06 CET schrieb Jonathan Cameron: Hi Jonathan, > > As a heads up, the other nasties we've found so far are around hitting > limits on the various socket buffers. When you run into those you can end > up with parts of the data to be encrypted going through

[RFC PATCH] crypto: chacha20 - add implementation using 96-bit nonce

As pointed out by Eric [0], the way RFC7539 was interpreted when creating our implementation of ChaCha20 creates a risk of IV reuse when using a little endian counter as the IV generator. The reason is that the low end bits of the counter get mapped onto the ChaCha20 block counter, which advances

Re: [PATCH] crypto: AF_ALG - fix race accessing cipher request

On Fri, 8 Dec 2017 11:50:37 +0100 Stephan Müller wrote: > Hi Herbert, > > This patch would go on top of 7d2c3f54e6f646887d019faa45f35d6fe9fe82ce > "crypto: af_alg - remove locking in async callback" found in Linus' tree > which is not yet in the cryptodev-2.6 tree. > > In

[PATCH] crypto: AF_ALG - fix race accessing cipher request

Hi Herbert, This patch would go on top of 7d2c3f54e6f646887d019faa45f35d6fe9fe82ce "crypto: af_alg - remove locking in async callback" found in Linus' tree which is not yet in the cryptodev-2.6 tree. In addition, this patch is already on top of the other patches discussed on this list fixing

Re: [PATCH] fscrypt: add support for ChaCha20 contents encryption

On 8 December 2017 at 10:14, Stephan Mueller wrote: > Am Freitag, 8. Dezember 2017, 11:06:31 CET schrieb Ard Biesheuvel: > > Hi Ard, > >> >> Given how it is not uncommon for counters to be used as IV, this is a >> fundamental flaw that could rear its head in other places as

Re: [PATCH] fscrypt: add support for ChaCha20 contents encryption

On 8 December 2017 at 09:11, Ard Biesheuvel wrote: > On 8 December 2017 at 09:11, Ard Biesheuvel wrote: >> Hi Eric, >> >> On 8 December 2017 at 01:38, Eric Biggers wrote: >>> From: Eric Biggers >>>

Re: [PATCH] fscrypt: add support for ChaCha20 contents encryption

On 8 December 2017 at 09:11, Ard Biesheuvel wrote: > Hi Eric, > > On 8 December 2017 at 01:38, Eric Biggers wrote: >> From: Eric Biggers >> >> fscrypt currently only supports AES encryption. However, many low-end >> mobile

Re: [PATCH] fscrypt: add support for ChaCha20 contents encryption

Hi Eric, On 8 December 2017 at 01:38, Eric Biggers wrote: > From: Eric Biggers > > fscrypt currently only supports AES encryption. However, many low-end > mobile devices still use older CPUs such as ARMv7, which do not support > the AES instructions