Hi Corentin,
On Mon, Nov 05, 2018 at 12:51:14PM +, Corentin Labbe wrote:
> All crypto_stats functions use the struct xxx_request for feeding stats,
> but in some case this structure could already be freed.
>
> For fixing this, the needed parameters (len and alg) will be stored
> before the re
Hi Corentin,
On Mon, Nov 05, 2018 at 12:51:12PM +, Corentin Labbe wrote:
> It is cleaner to have each stat in their own structures.
>
> Signed-off-by: Corentin Labbe
> ---
> crypto/crypto_user_stat.c | 20 +++
> include/uapi/linux/cryptouser.h | 101 --
Hi Corentin,
On Mon, Nov 05, 2018 at 12:51:11PM +, Corentin Labbe wrote:
> All the 32-bit fields need to be 64-bit. In some cases, UINT32_MAX crypto
> operations can be done in seconds.
>
> Reported-by: Eric Biggers
> Signed-off-by: Corentin Labbe
> ---
> crypto/algapi.c |
Hi Corentin,
On Mon, Nov 05, 2018 at 12:51:10PM +, Corentin Labbe wrote:
> Even if CRYPTO_STATS is set to n, some part of CRYPTO_STATS are
> compiled.
> This patch made all part of crypto_user_stat uncompiled in that case.
>
> Signed-off-by: Corentin Labbe
> ---
> crypto/Makefile
From: Eric Biggers
chacha20-generic doesn't use SIMD instructions or otherwise disable
preemption, so passing atomic=true to skcipher_walk_virt() is
unnecessary.
Suggested-by: Ard Biesheuvel
Signed-off-by: Eric Biggers
---
crypto/chacha20_generic.c | 2 +-
1 file changed, 1 insertion(+), 1 de
Hello,
We've been working to find a way to bring storage encryption to
entry-level Android devices like the inexpensive "Android Go" devices
sold in developing countries, and some smartwatches. Unfortunately,
often these devices still ship with no encryption, since for cost
reasons they have to u
From: Eric Biggers
In preparation for adding XChaCha12 support, rename/refactor the NEON
implementation of ChaCha20 to support different numbers of rounds.
Signed-off-by: Eric Biggers
---
arch/arm/crypto/Makefile | 4 +-
...hacha20-neon-core.S => chacha-neon-core.S} | 44
From: Eric Biggers
Add support for the XChaCha20 stream cipher. XChaCha20 is the
application of the XSalsa20 construction
(https://cr.yp.to/snuffle/xsalsa-20081128.pdf) to ChaCha20 rather than
to Salsa20. XChaCha20 extends ChaCha20's nonce length from 64 bits (or
96 bits, depending on conventio
From: Eric Biggers
In preparation for adding XChaCha12 support, rename/refactor
chacha20-generic to support different numbers of rounds. The
justification for needing XChaCha12 support is explained in more detail
in the patch "crypto: chacha - add XChaCha12 support".
The only difference between
From: Eric Biggers
Refactor the unkeyed permutation part of chacha20_block() into its own
function, then add hchacha20_block() which is the ChaCha equivalent of
HSalsa20 and is an intermediate step towards XChaCha20 (see
https://cr.yp.to/snuffle/xsalsa-20081128.pdf). HChaCha20 skips the
final ad
From: Eric Biggers
To improve responsivesess, disable preemption for each step of the walk
(which is at most PAGE_SIZE) rather than for the entire
encryption/decryption operation.
Suggested-by: Ard Biesheuvel
Signed-off-by: Eric Biggers
---
arch/arm/crypto/chacha20-neon-glue.c | 6 +++---
1 f
From: Eric Biggers
Add an ARM NEON implementation of NHPoly1305, an ε-almost-∆-universal
hash function used in the Adiantum encryption mode. For now, only the
NH portion is actually NEON-accelerated; the Poly1305 part is less
performance-critical so is just implemented in C.
Signed-off-by: Eric
From: Eric Biggers
In preparation for exposing a low-level Poly1305 API which implements
the ε-almost-∆-universal (εA∆U) hash function underlying the Poly1305
MAC and supports block-aligned inputs only, create structures
poly1305_key and poly1305_state which hold the limbs of the Poly1305
"r" key
From: Eric Biggers
Now that the generic implementation of ChaCha20 has been refactored to
allow varying the number of rounds, add support for XChaCha12, which is
the XSalsa construction applied to ChaCha12. ChaCha12 is one of the
three ciphers specified by the original ChaCha paper
(https://cr.y
From: Eric Biggers
Add an XChaCha20 implementation that is hooked up to the ARM NEON
implementation of ChaCha20. This is needed for use in the Adiantum
encryption mode; see the generic code patch,
"crypto: chacha20-generic - add XChaCha20 support", for more details.
We also update the NEON code
From: Eric Biggers
Now that the 32-bit ARM NEON implementation of ChaCha20 and XChaCha20
has been refactored to support varying the number of rounds, add support
for XChaCha12. This is identical to XChaCha20 except for the number of
rounds, which is 12 instead of 20.
XChaCha12 is faster than XC
From: Eric Biggers
Expose a low-level Poly1305 API which implements the
ε-almost-∆-universal (εA∆U) hash function underlying the Poly1305 MAC
and supports block-aligned inputs only.
This is needed for Adiantum hashing, which builds an εA∆U hash function
from NH and a polynomial evaluation in GF(
From: Eric Biggers
Add a generic implementation of NHPoly1305, an ε-almost-∆-universal hash
function used in the Adiantum encryption mode.
CONFIG_NHPOLY1305 is not selectable by itself since there won't be any
real reason to enable it without also enabling Adiantum support.
Signed-off-by: Eric
From: Eric Biggers
Add support for the Adiantum encryption mode. Adiantum was designed by
Paul Crowley and is specified by our paper:
Adiantum: length-preserving encryption for entry-level processors
(https://eprint.iacr.org/2018/720.pdf)
See our paper for full details; this patch only
From: Eric Biggers
Add support for the Adiantum encryption mode to fscrypt. Adiantum is a
tweakable, length-preserving encryption mode with security provably
reducible to that of XChaCha12 and AES-256, subject to a security bound.
It's also a true wide-block mode, unlike XTS. See the paper
"Adi
On 5 November 2018 at 19:23, Vitaly Chikunov wrote:
> Ard,
>
> On Mon, Nov 05, 2018 at 02:22:21PM +0100, Ard Biesheuvel wrote:
>>
>> > +static const struct streebog_uint512 buffer512 = { {
>> > + cpu_to_le64(0x200ULL),
>>
>> Can we keep the memory representation in native endianness, and onl
Ard,
On Mon, Nov 05, 2018 at 02:22:21PM +0100, Ard Biesheuvel wrote:
>
> > +static const struct streebog_uint512 buffer512 = { {
> > + cpu_to_le64(0x200ULL),
>
> Can we keep the memory representation in native endianness, and only
> swab the in/output [where needed]?
I hope you do not ins
Ard,
I will address your suggestions in v4. And below is my comments for a
few of them.
On Mon, Nov 05, 2018 at 02:22:21PM +0100, Ard Biesheuvel wrote:
> > +static const struct streebog_uint512 buffer512 = { {
> > + cpu_to_le64(0x200ULL),
>
> Can we keep the memory representation in native
On 24 October 2018 at 05:23, Vitaly Chikunov wrote:
> Add testmgr and tcrypt tests and vectors for Streebog hash function
> from RFC 6986 and GOST R 34.11-2012, for HMAC-Streebog vectors are
> from R 50.1.113-2016.
>
> Signed-off-by: Vitaly Chikunov
> ---
> crypto/tcrypt.c | 35 +++
On 24 October 2018 at 05:23, Vitaly Chikunov wrote:
> Register Streebog hash function in Hash Info arrays to let IMA use
> it for its purposes.
>
> Signed-off-by: Vitaly Chikunov
> ---
> crypto/hash_info.c | 4
> include/crypto/hash_info.h | 1 +
> include/uapi/linux/hash_in
Hi Vitaly,
On 24 October 2018 at 05:23, Vitaly Chikunov wrote:
> Add GOST/IETF Streebog hash function (GOST R 34.11-2012, RFC 6986)
> generic hash transformation.
>
> Signed-off-by: Vitaly Chikunov
> ---
> crypto/Kconfig| 12 +
> crypto/Makefile |1 +
> crypto/streeb
On 26. 9. 2018 18:04, Jason A. Donenfeld wrote:
> Hi Ivan,
>
> On Wed, Sep 26, 2018 at 6:00 PM Ivan Labáth wrote:
>>
>> On 25.09.2018 16:56, Jason A. Donenfeld wrote:
>>> Extensive documentation and description of the protocol and
>>> considerations, along with formal proofs of the cryptography,
On Mon, 2018-11-05 at 15:55 +0300, Vitaly Chikunov wrote:
> Mimi,
>
> On Mon, Nov 05, 2018 at 07:48:33AM -0500, Mimi Zohar wrote:
> > On Sat, 2018-11-03 at 08:51 +0300, Vitaly Chikunov wrote:
> > > On Wed, Oct 17, 2018 at 02:08:51PM +0800, Herbert Xu wrote:
> > > > On Fri, Oct 12, 2018 at 09:41:05
Mimi,
On Mon, Nov 05, 2018 at 07:48:33AM -0500, Mimi Zohar wrote:
> On Sat, 2018-11-03 at 08:51 +0300, Vitaly Chikunov wrote:
> > On Wed, Oct 17, 2018 at 02:08:51PM +0800, Herbert Xu wrote:
> > > On Fri, Oct 12, 2018 at 09:41:05AM +0300, Vitaly Chikunov wrote:
> > > >
> > > > It is the first part
Hello
This patchset fixes all reported problem by Eric biggers.
This patchset should be applied on top of Eric biggers patchset "crypto:
crypto_user reporting fixes and cleanups"
Regards
Corentin Labbe (5):
crypto: crypto_user_stat: made crypto_user_stat optional
crypto: crypto_user_stat: c
It is cleaner to have each stat in their own structures.
Signed-off-by: Corentin Labbe
---
crypto/crypto_user_stat.c | 20 +++
include/uapi/linux/cryptouser.h | 101
2 files changed, 73 insertions(+), 48 deletions(-)
diff --git a/crypto/crypto_user_st
Even if CRYPTO_STATS is set to n, some part of CRYPTO_STATS are
compiled.
This patch made all part of crypto_user_stat uncompiled in that case.
Signed-off-by: Corentin Labbe
---
crypto/Makefile | 3 ++-
crypto/algapi.c | 2 ++
include/crypto/internal/c
All the 32-bit fields need to be 64-bit. In some cases, UINT32_MAX crypto
operations can be done in seconds.
Reported-by: Eric Biggers
Signed-off-by: Corentin Labbe
---
crypto/algapi.c | 10 +--
crypto/crypto_user_stat.c | 114 +++-
include/cr
All crypto_stats functions use the struct xxx_request for feeding stats,
but in some case this structure could already be freed.
For fixing this, the needed parameters (len and alg) will be stored
before the request being executed.
Fixes: cac5818c25d0 ("crypto: user - Implement a generic crypto st
This patch converts the getstat example tool to the recent changes done in
crypto_user_stat
- changed all stats to u64
- separated struct stats for each crypto alg
Signed-off-by: Corentin Labbe
---
tools/crypto/getstat.c | 54 +-
1 file changed, 27 insert
On Sat, 2018-11-03 at 08:51 +0300, Vitaly Chikunov wrote:
> Herbert,
>
> On Wed, Oct 17, 2018 at 02:08:51PM +0800, Herbert Xu wrote:
> > On Fri, Oct 12, 2018 at 09:41:05AM +0300, Vitaly Chikunov wrote:
> > >
> > > It is the first part of attempts to add to the Integrity subsystem
> > > ability of
When the source and destination addresses for the cipher are the same, we
will get a NULL dereference from accessing the split destination
scatterlist memories, as shown:
[ 56.565719] tcrypt:
[ 56.565719] testing speed of async ecb(aes) (hisi_sec_aes_ecb) encryption
[ 56.574683] tcrypt: test
coccicheck currently warns of the following issues in the driver:
drivers/crypto/hisilicon/sec/sec_algs.c:864:51-66: ERROR: reference preceded by
free on line 812
drivers/crypto/hisilicon/sec/sec_algs.c:864:40-49: ERROR: reference preceded by
free on line 813
drivers/crypto/hisilicon/sec/sec_algs
This patchset fixes a couple of issues I discovered while attempting to
bringup the driver.
John Garry (2):
crypto: hisilicon - Fix NULL dereference for same dst and src
crypto: hisilicon - Fix reference after free of memories on error
path
drivers/crypto/hisilicon/sec/sec_algs.c | 31 +++
On 5 November 2018 at 13:05, Gilad Ben-Yossef wrote:
> cts(cbc(aes)) as used in the kernel has been added to NIST
> standard as CBC-CS3. Document it as such.
>
> Signed-off-by: Gilad Ben-Yossef
> Suggested-by: Stephan Mueller
Acked-by: Ard Biesheuvel
> ---
> crypto/Kconfig | 7 +--
> 1 f
cts(cbc(aes)) as used in the kernel has been added to NIST
standard as CBC-CS3. Document it as such.
Signed-off-by: Gilad Ben-Yossef
Suggested-by: Stephan Mueller
---
crypto/Kconfig | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index
Am Montag, 5. November 2018, 11:20:28 CET schrieb Ard Biesheuvel:
Hi Ard, Gilad,
> On 5 November 2018 at 10:18, Gilad Ben-Yossef wrote:
> > Hi Stephan,
> >
> > On Mon, Nov 5, 2018 at 10:50 AM Stephan Mueller
wrote:
> >> Am Sonntag, 4. November 2018, 11:05:24 CET schrieb Gilad Ben-Yossef:
> >>
On 5 November 2018 at 10:18, Gilad Ben-Yossef wrote:
> Hi Stephan,
>
> On Mon, Nov 5, 2018 at 10:50 AM Stephan Mueller wrote:
>>
>> Am Sonntag, 4. November 2018, 11:05:24 CET schrieb Gilad Ben-Yossef:
>>
>> Hi Gilad,
>>
>> > As per Sp800-38A addendum from Oct 2010[1], cts(cbc(aes)) is
>> > allowe
Hi Stephan,
On Mon, Nov 5, 2018 at 10:50 AM Stephan Mueller wrote:
>
> Am Sonntag, 4. November 2018, 11:05:24 CET schrieb Gilad Ben-Yossef:
>
> Hi Gilad,
>
> > As per Sp800-38A addendum from Oct 2010[1], cts(cbc(aes)) is
> > allowed as a FIPS mode algorithm. Mark it as such.
> >
> > [1] https://c
Am Sonntag, 4. November 2018, 11:05:24 CET schrieb Gilad Ben-Yossef:
Hi Gilad,
> As per Sp800-38A addendum from Oct 2010[1], cts(cbc(aes)) is
> allowed as a FIPS mode algorithm. Mark it as such.
>
> [1] https://csrc.nist.gov/publications/detail/sp/800-38a/addendum/final
There are several types
Currently used scalar multiplication algorithm (Matthieu Rivain, 2011)
have invalid values for scalar == 1, n-1, and for regularized version
n-2, which was previously not checked. Verify that they are not used as
private keys.
Signed-off-by: Vitaly Chikunov
---
crypto/ecc.c | 42
46 matches
Mail list logo
