Hi Herbert,
On Mon, Dec 11, 2017 at 06:29:46PM +1100, Herbert Xu wrote:
> On Tue, Nov 28, 2017 at 10:05:17AM +0100, Antoine Tenart wrote:
> >
> > if (sreq->finish)
> > result_sz = crypto_ahash_digestsize(ahash);
> > - memcpy(sreq->state, areq->result, result_sz);
> > +
> > +
Hi,
> Anyway, I actually thought it was intentional that the ChaCha
> implementations in the Linux kernel allowed specifying the block
> counter, and therefore allowed seeking to any point in the keystream,
> exposing the full functionality of the cipher.
If I remember correctly, it was indeed in
On Tue, Nov 28, 2017 at 10:05:17AM +0100, Antoine Tenart wrote:
> The patch fixes the ahash support by only updating the result buffer
> when provided. Otherwise the driver could crash with NULL pointer
> exceptions, because the ahash caller isn't required to supply a result
> buffer on all calls.
Hi Linus:
This push fixes the following issues:
- Buffer overread in RSA.
- Potential use after free in algif_aead.
- Error path null pointer dereference in af_alg.
- Forbid combinations such as hmac(hmac(sha3)) which may crash.
- Crash in salsa20 due to incorrect API usage.
Please pull from
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 the counter get mapped onto the ChaCha20
On Fri, Dec 08, 2017 at 07:48:54PM -0500, Jeffrey Walton wrote:
> > 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
