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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171211065535.GA8457@gondor.apana.org.au>
Date:   Mon, 11 Dec 2017 17:55:35 +1100
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     linux-crypto@...r.kernel.org, ard.biesheuvel@...aro.org,
        ebiggers@...gle.com, linux-fscrypt@...r.kernel.org, tytso@....edu,
        linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
        linux-mtd@...ts.infradead.org, linux-fsdevel@...r.kernel.org,
        jaegeuk@...nel.org, mhalcrow@...gle.com, paulcrowley@...gle.com,
        martin@...ongswan.org, david@...ma-star.at, Jason@...c4.com,
        smueller@...onox.de
Subject: Re: [RFC PATCH] crypto: chacha20 - add implementation using 96-bit
 nonce

Ard Biesheuvel <ard.biesheuvel@...aro.org> 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 block counter, which
> advances every 64 bytes. This means that the counter value that gets
> selected as IV for the next input block will collide with the ChaCha20
> block counter of the previous block, basically recreating the same
> keystream but shifted by 64 bytes.

As Eric pointed out for steram ciphers such as chacha20 our policy
is to expose the raw IV in the base algorithm, and then layer
more restrictive implementations on top that can then be used
in different scenarios such as IPsec or disk encryption.

For example, with CTR, ctr(aes) is the base algorithm and places
no restrictions on the IV, while rfc3686(ctr(aes)) is the more
restrictive version that's used by IPsec.

Within the kernel I don't really see an issue with abuse because
all users are hopefully reviewed by the community.  If you're
worried about incorrect use in user-space we could think about
restricting access to these base implementations.

For chacha20 we did not add a restrictive template because the
primary user IPsec uses it only through AEAD where the IV restriction
is in place.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt