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 (the ARMv8 Cryptography Extensions). This re
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 devices still use older CPUs such as ARMv7, which do not support
>> the
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
>>>
>>> fscrypt currently only supports AES encryption. However, many low-end
>>> mobile devices sti
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 well, so
> I propose we fix this one way (fix the current code) or the other
> (depr
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 well, so
>> I propose w
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 simi
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 addition, this patch i
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 e
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 with
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?
David
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 fix
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.
Can I put that down as a Reviewed-by?
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_
> > authentication sucks anyway in
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
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 endian counter as the
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
>>> our implementation of ChaCha20 creates a risk
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 an
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
>> >> (https://cr.yp.to/chacha/chacha-20080128.
> 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 u
19 matches
Mail list logo
