30 Aug, 2019
1 commit
-
Add a test vector for the ESSIV mode that is the most widely used,
i.e., using cbc(aes) and sha256, in both skcipher and AEAD modes
(the latter is used by tcrypt to encapsulate the authenc template
or h/w instantiations of the same)Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
26 Jul, 2019
1 commit
-
Reviewed-by: Ondrej Mosnacek
Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
31 May, 2019
1 commit
-
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later versionextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 3029 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman
18 Apr, 2019
1 commit
-
Use subsys_initcall for registration of all templates and generic
algorithm implementations, rather than module_init. Then change
cryptomgr to use arch_initcall, to place it before the subsys_initcalls.This is needed so that when both a generic and optimized implementation
of an algorithm are built into the kernel (not loadable modules), the
generic implementation is registered before the optimized one.
Otherwise, the self-tests for the optimized implementation are unable to
allocate the generic implementation for the new comparison fuzz tests.Note that on arm, a side effect of this change is that self-tests for
generic implementations may run before the unaligned access handler has
been installed. So, unaligned accesses will crash the kernel. This is
arguably a good thing as it makes it easier to detect that type of bug.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
08 Mar, 2019
1 commit
-
To prevent any issues with persistent data, separate lzo-rle from lzo so
that it is treated as a separate algorithm, and lzo is still available.Link: http://lkml.kernel.org/r/20190205155944.16007-3-dave.rodgman@arm.com
Signed-off-by: Dave Rodgman
Cc: David S. Miller
Cc: Greg Kroah-Hartman
Cc: Herbert Xu
Cc: Markus F.X.J. Oberhumer
Cc: Matt Sealey
Cc: Minchan Kim
Cc: Nitin Gupta
Cc: Richard Purdie
Cc: Sergey Senozhatsky
Cc: Sonny Rao
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Dec, 2018
1 commit
-
In order to have better coverage of algorithms operating on block
sizes that are in the ballpark of a VPN packet, add 1472 to the
block_sizes array.Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
20 Nov, 2018
1 commit
-
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 provides an overview.
Adiantum is a tweakable, length-preserving encryption mode designed for
fast and secure disk encryption, especially on CPUs without dedicated
crypto instructions. Adiantum encrypts each sector using the XChaCha12
stream cipher, two passes of an ε-almost-∆-universal (εA∆U) hash
function, and an invocation of the AES-256 block cipher on a single
16-byte block. On CPUs without AES instructions, Adiantum is much
faster than AES-XTS; for example, on ARM Cortex-A7, on 4096-byte sectors
Adiantum encryption is about 4 times faster than AES-256-XTS encryption,
and decryption about 5 times faster.Adiantum is a specialization of the more general HBSH construction. Our
earlier proposal, HPolyC, was also a HBSH specialization, but it used a
different εA∆U hash function, one based on Poly1305 only. Adiantum's
εA∆U hash function, which is based primarily on the "NH" hash function
like that used in UMAC (RFC4418), is about twice as fast as HPolyC's;
consequently, Adiantum is about 20% faster than HPolyC.This speed comes with no loss of security: Adiantum is provably just as
secure as HPolyC, in fact slightly *more* secure. Like HPolyC,
Adiantum's security is reducible to that of XChaCha12 and AES-256,
subject to a security bound. XChaCha12 itself has a security reduction
to ChaCha12. Therefore, one need not "trust" Adiantum; one need only
trust ChaCha12 and AES-256. Note that the εA∆U hash function is only
used for its proven combinatorical properties so cannot be "broken".Adiantum is also a true wide-block encryption mode, so flipping any
plaintext bit in the sector scrambles the entire ciphertext, and vice
versa. No other such mode is available in the kernel currently; doing
the same with XTS scrambles only 16 bytes. Adiantum also supports
arbitrary-length tweaks and naturally supports any length input >= 16
bytes without needing "ciphertext stealing".For the stream cipher, Adiantum uses XChaCha12 rather than XChaCha20 in
order to make encryption feasible on the widest range of devices.
Although the 20-round variant is quite popular, the best known attacks
on ChaCha are on only 7 rounds, so ChaCha12 still has a substantial
security margin; in fact, larger than AES-256's. 12-round Salsa20 is
also the eSTREAM recommendation. For the block cipher, Adiantum uses
AES-256, despite it having a lower security margin than XChaCha12 and
needing table lookups, due to AES's extensive adoption and analysis
making it the obvious first choice. Nevertheless, for flexibility this
patch also permits the "adiantum" template to be instantiated with
XChaCha20 and/or with an alternate block cipher.We need Adiantum support in the kernel for use in dm-crypt and fscrypt,
where currently the only other suitable options are block cipher modes
such as AES-XTS. A big problem with this is that many low-end mobile
devices (e.g. Android Go phones sold primarily in developing countries,
as well as some smartwatches) still have CPUs that lack AES
instructions, e.g. ARM Cortex-A7. Sadly, AES-XTS encryption is much too
slow to be viable on these devices. We did find that some "lightweight"
block ciphers are fast enough, but these suffer from problems such as
not having much cryptanalysis or being too controversial.The ChaCha stream cipher has excellent performance but is insecure to
use directly for disk encryption, since each sector's IV is reused each
time it is overwritten. Even restricting the threat model to offline
attacks only isn't enough, since modern flash storage devices don't
guarantee that "overwrites" are really overwrites, due to wear-leveling.
Adiantum avoids this problem by constructing a
"tweakable super-pseudorandom permutation"; this is the strongest
possible security model for length-preserving encryption.Of course, storing random nonces along with the ciphertext would be the
ideal solution. But doing that with existing hardware and filesystems
runs into major practical problems; in most cases it would require data
journaling (like dm-integrity) which severely degrades performance.
Thus, for now length-preserving encryption is still needed.Signed-off-by: Eric Biggers
Reviewed-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
16 Nov, 2018
1 commit
-
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 RFC 7836 and R 50.1.113-2016.Cc: linux-integrity@vger.kernel.org
Signed-off-by: Vitaly Chikunov
Acked-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
09 Nov, 2018
1 commit
-
Add AES128/192/256-CFB testvectors from NIST SP800-38A.
Signed-off-by: Dmitry Eremin-Solenikov
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Eremin-Solenikov
Signed-off-by: Herbert Xu
28 Sep, 2018
3 commits
-
We already have OFB test vectors and tcrypt OFB speed tests.
Add OFB functional tests to tcrypt as well.Signed-off-by: Gilad Ben-Yossef
Signed-off-by: Herbert Xu -
Add additional test vectors from "The SM4 Blockcipher Algorithm And Its
Modes Of Operations" draft-ribose-cfrg-sm4-10 and register cipher speed
tests for sm4.Signed-off-by: Gilad Ben-Yossef
Signed-off-by: Herbert Xu -
Commit 110492183c4b ("crypto: compress - remove unused pcomp interface")
removed pcomp interface but missed cleaning up tcrypt.Signed-off-by: Horia Geantă
Signed-off-by: Herbert Xu
21 Sep, 2018
1 commit
-
ghash is a keyed hash algorithm, thus setkey needs to be called.
Otherwise the following error occurs:
$ modprobe tcrypt mode=318 sec=1
testing speed of async ghash-generic (ghash-generic)
tcrypt: test 0 ( 16 byte blocks, 16 bytes per update, 1 updates):
tcrypt: hashing failed ret=-126Cc: # 4.6+
Fixes: 0660511c0bee ("crypto: tcrypt - Use ahash")
Tested-by: Franck Lenormand
Signed-off-by: Horia Geantă
Acked-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
03 Aug, 2018
1 commit
-
Avoid RCU stalls in the case of non-preemptible kernel and lengthy
speed tests by rescheduling when advancing from one block size
to another.Signed-off-by: Horia Geantă
Signed-off-by: Herbert Xu
01 Jul, 2018
1 commit
-
Remove the original version of the VMAC template that had the nonce
hardcoded to 0 and produced a digest with the wrong endianness. I'm
unsure whether this had users or not (there are no explicit in-kernel
references to it), but given that the hardcoded nonce made it wildly
insecure unless a unique key was used for each message, let's try
removing it and see if anyone complains.Leave the new "vmac64" template that requires the nonce to be explicitly
specified as the first 16 bytes of data and uses the correct endianness
for the digest.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
27 May, 2018
1 commit
-
The Blackfin CRC driver was removed by commit 9678a8dc53c1 ("crypto:
bfin_crc - remove blackfin CRC driver"), but it was forgotten to remove
the corresponding "hmac(crc32)" test vectors. I see no point in keeping
them since nothing else appears to implement or use "hmac(crc32)", which
isn't an algorithm that makes sense anyway because HMAC is meant to be
used with a cryptographically secure hash function, which CRC's are not.Thus, remove the unneeded test vectors.
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
05 May, 2018
1 commit
-
In the quest to remove all stack VLA usage from the kernel[1], this
allocates the return code buffers before starting jiffie timers, rather
than using stack space for the array. Additionally cleans up some exit
paths and make sure that the num_mb module_param() is used only once
per execution to avoid possible races in the value changing.[1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
Signed-off-by: Kees Cook
Signed-off-by: Herbert Xu
16 Mar, 2018
1 commit
-
Add testmgr tests for the newly introduced SM4 ECB symmetric cipher.
Signed-off-by: Gilad Ben-Yossef
Signed-off-by: Herbert Xu
12 Jan, 2018
2 commits
-
There seems to be a cut-n-paste bug with the name of the buffer being
free'd, xoutbuf should be used instead of axbuf.Detected by CoverityScan, CID#1463420 ("Copy-paste error")
Fixes: 427988d981c4 ("crypto: tcrypt - add multibuf aead speed test")
Signed-off-by: Colin Ian King
Signed-off-by: Herbert Xu -
Trivial fix to spelling mistakes in pr_err error message text.
Signed-off-by: Colin Ian King
Signed-off-by: Herbert Xu
28 Dec, 2017
6 commits
-
The performance of some aead tfm providers is affected by
the amount of parallelism possible with the processing.Introduce an async aead concurrent multiple buffer
processing speed test to be able to test performance of such
tfm providers.Signed-off-by: Gilad Ben-Yossef
Signed-off-by: Herbert Xu -
The performance of some skcipher tfm providers is affected by
the amount of parallelism possible with the processing.Introduce an async skcipher concurrent multiple buffer
processing speed test to be able to test performance of such
tfm providers.Signed-off-by: Gilad Ben-Yossef
Signed-off-by: Herbert Xu -
The multi buffer concurrent requests ahash speed test only
supported the cycles mode. Add support for the so called
jiffies mode that test performance of bytes/sec.We only add support for digest mode at the moment.
Signed-off-by: Gilad Ben-Yossef
Signed-off-by: Herbert Xu -
For multiple buffers speed tests, the number of buffers, or
requests, used actually sets the level of parallelism a tfm
provider may utilize to hide latency. The existing number
(of 8) is good for some software based providers but not
enough for many HW providers with deep FIFOs.Add a module parameter that allows setting the number of
multiple buffers/requests used, leaving the default at 8.Signed-off-by: Gilad Ben-Yossef
Signed-off-by: Herbert Xu -
The AEAD speed test pretended to support decryption, however that support
was broken as decryption requires a valid auth field which the test did
not provide.Fix this by running the encryption path once with inout/output sgls
switched to calculate the auth field prior to performing decryption
speed tests.Signed-off-by: Gilad Ben-Yossef
Signed-off-by: Herbert Xu -
The multi buffer ahash speed test was allocating multiple
buffers for use with the multiple outstanding requests
it was starting but never actually using them (except
to free them), instead using a different single statically
allocated buffer for all requests.Fix this by actually using the allocated buffers for the test.
It is noted that it may seem tempting to instead remove the
allocation and free of the multiple buffers and leave things as
they are since this is a hash test where the input is read
only. However, after consideration I believe that multiple
buffers better reflect real life scenario with regard
to data cache and TLB behaviours etc.Signed-off-by: Gilad Ben-Yossef
Signed-off-by: Herbert Xu
29 Nov, 2017
2 commits
-
Results better code readability.
Signed-off-by: Tudor Ambarus
Reviewed-by: Horia Geantă
Signed-off-by: Herbert Xu -
In case buffer length is a multiple of PAGE_SIZE,
the S/G table is incorrectly generated.
Fix this by handling buflen = k * PAGE_SIZE separately.Signed-off-by: Robert Baronescu
Signed-off-by: Herbert Xu
03 Nov, 2017
3 commits
-
tcrypt starts several async crypto ops and waits for their completions.
Move it over to generic code doing the same.Signed-off-by: Gilad Ben-Yossef
Signed-off-by: Herbert Xu -
Fix the way the length of the buffers used for
encryption / decryption are computed.
For e.g. in case of encryption, input buffer does not contain
an authentication tag.Signed-off-by: Robert Baronescu
Signed-off-by: Herbert Xu -
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva
Signed-off-by: Herbert Xu
22 Sep, 2017
2 commits
-
Fix checkpatch.pl warnings:
WARNING: void function return statements are not generally useful
FILE: crypto/rmd128.c:218:
FILE: crypto/rmd160.c:261:
FILE: crypto/rmd256.c:233:
FILE: crypto/rmd320.c:280:
FILE: crypto/tcrypt.c:385:
FILE: drivers/crypto/ixp4xx_crypto.c:538:
FILE: drivers/crypto/marvell/cesa.c:81:
FILE: drivers/crypto/ux500/cryp/cryp_core.c:1755:Signed-off-by: Geliang Tang
Signed-off-by: Herbert Xu -
Add testmgr and tcrypt tests and vectors for SM3 secure hash.
Signed-off-by: Gilad Ben-Yossef
Signed-off-by: Herbert Xu
03 Aug, 2017
1 commit
-
Remove xts(aes) speed tests with 2 x 192-bit keys, since implementations
adhering strictly to IEEE 1619-2007 standard cannot cope with key sizes
other than 2 x 128, 2 x 256 bits - i.e. AES-XTS-{128,256}:
[...]
tcrypt: test 5 (384 bit key, 16 byte blocks):
caam_jr 8020000.jr: key size mismatch
tcrypt: setkey() failed flags=200000
[...]Signed-off-by: Horia Geantă
Signed-off-by: Herbert Xu
18 May, 2017
1 commit
-
The tcrypt AEAD cycles speed tests disables irqs during the test, which is
broken at the very least since commit
'1425d2d17f7309c6 ("crypto: tcrypt - Fix AEAD speed tests")'
adds a wait for completion as part of the test and probably since
switching to the new AEAD API.While the result of taking a cycle count diff may not mean much on SMP
systems if the task migrates, it's good enough for tcrypt being the quick
& dirty dev tool it is. It's also what all the other (i.e. hash) cycle
speed tests do.Signed-off-by: Gilad Ben-Yossef
Reported-by: Ofir Drang
Reviewed-by: Horia Geantă
Signed-off-by: Herbert Xu
23 Jan, 2017
1 commit
-
tcrypt is very tight-lipped when it succeeds, but a bit more feedback
would be useful when developing or debugging crypto drivers, especially
since even a successful run ends with the module failing to insert. Add
a couple of debug prints, which can be enabled with dynamic debug:Before:
# insmod tcrypt.ko mode=10
insmod: can't insert 'tcrypt.ko': Resource temporarily unavailableAfter:
# insmod tcrypt.ko mode=10 dyndbg
tcrypt: testing ecb(aes)
tcrypt: testing cbc(aes)
tcrypt: testing lrw(aes)
tcrypt: testing xts(aes)
tcrypt: testing ctr(aes)
tcrypt: testing rfc3686(ctr(aes))
tcrypt: all tests passed
insmod: can't insert 'tcrypt.ko': Resource temporarily unavailableSigned-off-by: Rabin Vincent
Signed-off-by: Herbert Xu
01 Jul, 2016
4 commits
-
This patch adds HMAC-SHA3 test modes in tcrypt module
and related test vectors.Signed-off-by: Raveendra Padasalagi
Signed-off-by: Herbert Xu -
The multibuffer hash speed test is incorrectly bailing because
of an EINPROGRESS return value. This patch fixes it by setting
ret to zero if it is equal to -EINPROGRESS.Reported-by: Megha Dey
Signed-off-by: Herbert Xu -
This patch adds speed tests for cts(cbc(aes)).
Signed-off-by: Herbert Xu
-
This patch converts tcrypt to use the new skcipher interface as
opposed to ablkcipher/blkcipher.Signed-off-by: Herbert Xu