On Mon, Aug 05, 2024 at 07:52:38PM +0200, Thorsten Blum wrote:
> struct poly_req {
> @@ -611,8 +611,8 @@ static int chachapoly_create(struct crypto_template
> *tmpl, struct rtattr **tb,
> poly->base.cra_priority) / 2;
> inst->alg.base.cra_blocksize = 1;
On Fri, May 17, 2024 at 07:48:48PM +0300, Jarkko Sakkinen wrote:
> On Fri May 17, 2024 at 7:22 PM EEST, Nícolas F. R. A. Prado wrote:
> > On Fri, May 17, 2024 at 07:25:40AM -0700, James Bottomley wrote:
> > > On Fri, 2024-05-17 at 15:43 +0200, Ard Biesheuvel wrote:
> > > > On Fri, 17 May 2024 at 15
On Mon, Apr 22, 2024 at 04:05:34PM +0800, kernel test robot wrote:
> [ 235.998172][T1] Kernel panic - not syncing: Certs selftest 0:
> pkcs7_verify() = -65
Thanks! The problem is that CONFIG_FIPS_SIGNATURE_SELFTEST is missing
dependencies on the algorithms it uses.
https://lore.kernel.org/r
On Thu, Mar 14, 2024 at 04:52:47AM -0700, James Prestwood wrote:
> IWD uses AF_ALG/keyctl for _all_ its crypto, cipher, and checksum needs.
> Anything that wifi requires as far as crypto goes IWD uses the kernel,
> except ECC is the only exception. The entire list of crypto requirements
> (for full
On Wed, Mar 13, 2024 at 04:06:11PM -0700, Eric Biggers wrote:
> On Wed, Mar 13, 2024 at 03:51:10PM -0700, Jeff Johnson wrote:
> > On 3/13/2024 3:10 PM, Eric Biggers wrote:
> > > On Wed, Mar 13, 2024 at 02:17:29PM -0700, James Prestwood wrote:
> > >> Hi,
> >
On Wed, Mar 13, 2024 at 03:51:10PM -0700, Jeff Johnson wrote:
> On 3/13/2024 3:10 PM, Eric Biggers wrote:
> > On Wed, Mar 13, 2024 at 02:17:29PM -0700, James Prestwood wrote:
> >> Hi,
> >>
> >> On 3/13/24 1:22 PM, Eric Biggers wrote:
> >>> On Wed, M
On Wed, Mar 13, 2024 at 02:17:29PM -0700, James Prestwood wrote:
> Hi,
>
> On 3/13/24 1:22 PM, Eric Biggers wrote:
> > On Wed, Mar 13, 2024 at 01:12:54PM -0700, James Prestwood wrote:
> > > Hi,
> > >
> > > On 3/13/24 12:44 PM, Eric Biggers wrote:
> &
On Wed, Mar 13, 2024 at 01:12:54PM -0700, James Prestwood wrote:
> Hi,
>
> On 3/13/24 12:44 PM, Eric Biggers wrote:
> > On Wed, Mar 13, 2024 at 10:26:06AM -0700, James Prestwood wrote:
> > > Hi,
> > >
> > > On 3/13/24 1:56 AM, Johannes Berg wrote:
&g
On Wed, Mar 13, 2024 at 10:26:06AM -0700, James Prestwood wrote:
> Hi,
>
> On 3/13/24 1:56 AM, Johannes Berg wrote:
> > Not sure why you're CC'ing the world, but I guess adding a few more
> > doesn't hurt ...
> >
> > On Wed, 2024-03-13 at 09:50 +0100, Karel Balej wrote:
> > > and I use iwd
> >
On Mon, Jan 22, 2024 at 04:27:21PM -0800, Kees Cook wrote:
> In an effort to separate intentional arithmetic wrap-around from
> unexpected wrap-around, we need to refactor places that depend on this
> kind of math. One of the most common code patterns of this is:
>
> VAR + value < VAR
>
> N
he "Fixes" line shouldn't be line-wrapped.
Otherwise this looks fine. The explanation in the commit message still isn't
great, but it's much better than it was before.
You can add:
Reviewed-by: Eric Biggers
- Eric
itted even if SHA-256 is being used.
> + imply CRYPTO_SHA256
> help
> This option enables fs-verity. fs-verity is the dm-verity
> mechanism implemented at the file level. On supported
Looks fine,
Acked-by: Eric Biggers
- Eric
On Fri, Apr 16, 2021 at 06:06:41PM +0200, Ard Biesheuvel wrote:
> Even if FS encryption has strict functional dependencies on various
> crypto algorithms and chaining modes. those dependencies could potentially
> be satisified by other implementations than the generic ones, and no link
> time depen
On Mon, Apr 19, 2021 at 04:16:13AM +, Mothershead, Hailey wrote:
> Hello,
>
> The patch quoted below causes the kernel to panic when fips is enabled with:
>
>alg: ecdh: test failed on vector 2, err=-14
>Kernel panic - not syncing: alg: self-tests for ecdh-generic (ecd
On Thu, Apr 15, 2021 at 03:46:46PM -0400, Chris von Recklinghausen wrote:
> Hibernation fails on a system in fips mode because md5 is used for the e820
> integrity check and is not available. Use crc32 instead.
>
> This patch changes the integrity check algorithm from md5 to crc32.
The second par
On Wed, Apr 14, 2021 at 11:53:51AM -0700, Nick Terrell wrote:
> On Wed, Apr 14, 2021 at 11:35 AM Eric Biggers wrote:
> >
> > On Wed, Apr 14, 2021 at 11:01:29AM -0700, Nick Terrell wrote:
> > > Hi all,
> > >
> > > I would really like to make some prog
On Wed, Apr 14, 2021 at 11:01:29AM -0700, Nick Terrell wrote:
> Hi all,
>
> I would really like to make some progress on this and get it merged.
> This patchset offsers:
> * 15-30% better decompression speed
> * 3 years of zstd bug fixes and code improvements
> * Allows us to import zstd directly
On Tue, Apr 13, 2021 at 12:13:30PM -0400, Chris von Recklinghausen wrote:
> Suspend fails on a system in fips mode because md5 is used for the e820
Suspend to disk (hibernation), or any suspend?
> struct restore_data_record {
> unsigned long jump_address;
> unsigned long jump_address
On Tue, Apr 13, 2021 at 12:13:30PM -0400, Chris von Recklinghausen wrote:
> +static inline void get_e820_crc32(struct e820_table *table, void *buf)
> {
This should just return the CRC-32 value as a u32. There's no need for the
'void *buf' argument.
Also like I said, compute_e820_crc32() would b
On Mon, Apr 12, 2021 at 03:04:58PM -0400, Chris von Recklinghausen wrote:
> On 4/12/21 1:45 PM, Eric Biggers wrote:
> > On Mon, Apr 12, 2021 at 10:09:32AM -0400, Chris von Recklinghausen wrote:
> > > Suspend fails on a system in fips mode because md5 is used for the e820
> &g
t; v2
>bump up RESTORE_MAGIC
> v2 -> v3
>move embelishment from cover letter to commit comments (no code change)
> v3 -> v4
>add note to comments that md5 isn't used for encryption here.
> v4 -> v5
>reword comment per Simo's suggestion
> v5
On Thu, Apr 08, 2021 at 11:53:59AM -0400, Chris von Recklinghausen wrote:
> On 4/8/21 11:30 AM, Eric Biggers wrote:
> > On Thu, Apr 08, 2021 at 09:15:06AM -0400, Chris von Recklinghausen wrote:
> > > Suspend fails on a system in fips mode because md5 is used for the e820
> &g
On Thu, Apr 08, 2021 at 09:15:06AM -0400, Chris von Recklinghausen wrote:
> Suspend fails on a system in fips mode because md5 is used for the e820
> integrity check and is not available. Use crc32 instead.
>
> This patch changes the integrity check algorithm from md5 to
> crc32. This integrity ch
On Thu, Apr 08, 2021 at 03:32:38PM +0200, Rafael J. Wysocki wrote:
> On Thu, Apr 8, 2021 at 3:15 PM Chris von Recklinghausen
> wrote:
> >
> > Suspend fails on a system in fips mode because md5 is used for the e820
> > integrity check and is not available. Use crc32 instead.
> >
> > This patch chan
On Thu, Apr 08, 2021 at 07:58:08PM +0800, Hangbin Liu wrote:
> On Thu, Apr 08, 2021 at 09:06:52AM +0800, Hangbin Liu wrote:
> > > Also, couldn't you just consider WireGuard to be outside your FIPS module
> > > boundary, which would remove it from the scope of the certification?
> > >
> > > And how
On Wed, Apr 07, 2021 at 07:39:20PM +0800, Hangbin Liu wrote:
> As the cryptos(BLAKE2S, Curve25519, CHACHA20POLY1305) in WireGuard are not
> FIPS certified, the WireGuard module should be disabled in FIPS mode.
>
> Signed-off-by: Hangbin Liu
I think you mean "FIPS allowed", not "FIPS certified"?
On Wed, Apr 07, 2021 at 06:04:21AM -0400, Chris von Recklinghausen wrote:
> Suspend fails on a system in fips mode because md5 is used for the e820
> integrity check and is not available. Use crc32 instead.
>
> Prior to this patch, MD5 is used only to create a digest to ensure integrity
> of
> th
On Mon, Apr 05, 2021 at 11:04:38AM -0400, Julian Braha wrote:
> Currently, when a config option selects a
> CRYPTO_LIB_* option while CRYPTO is disabled,
> Kbuild gives an unmet dependency. However,
> these config options do not actually need to
> depend on CRYPTO.
>
> Signed-off-by: Julian Braha
On Thu, Apr 01, 2021 at 06:19:57PM +0200, Rafael J. Wysocki wrote:
> On Thu, Apr 1, 2021 at 3:59 PM Ard Biesheuvel wrote:
> >
> > On Thu, 1 Apr 2021 at 15:34, Rafael J. Wysocki wrote:
> > >
> > > On Thu, Apr 1, 2021 at 2:25 PM Chris von Recklinghausen
> > > wrote:
> > > >
> > > > Suspend fails o
On Thu, Apr 01, 2021 at 09:54:21AM -0400, Chris von Recklinghausen wrote:
> On 4/1/21 9:38 AM, Rafael J. Wysocki wrote:
> > On Thu, Apr 1, 2021 at 10:47 AM Ard Biesheuvel wrote:
> > > On Tue, 30 Mar 2021 at 21:56, Simo Sorce wrote:
> > > > On Tue, 2021-03-30 at 21:45 +0200, Ard Biesheuvel wrote:
On Thu, Apr 01, 2021 at 08:50:05AM +0300, Jarkko Sakkinen wrote:
> On Thu, Apr 01, 2021 at 12:11:32PM +1100, Herbert Xu wrote:
> > On Wed, Mar 31, 2021 at 04:34:29PM -0700, Eric Biggers wrote:
> > > On Thu, Apr 01, 2021 at 02:31:46AM +0300, Jarkko Sakkinen wrote:
> > > &
On Thu, Apr 01, 2021 at 02:31:46AM +0300, Jarkko Sakkinen wrote:
>
> It's a bummer but uapi is the god in the end. Since TPM does not do it
> today, that behaviour must be supported forever. That's why a boot option
> AND a warning would be the best compromise.
>
It's not UAPI if there is no way
On Tue, Mar 30, 2021 at 09:38:55AM -0700, Randy Dunlap wrote:
> On 3/29/21 10:29 PM, Eric Biggers wrote:
> > On Mon, Mar 29, 2021 at 10:06:51PM -0700, Randy Dunlap wrote:
> >> Having just seen a report of using "fips=1" on the kernel command line,
> >> I coul
On Sun, Mar 28, 2021 at 11:37:23PM +0300, Jarkko Sakkinen wrote:
>
> Unfortunately, TPM trusted keys started this bad security practice, and
> obviously it cannot be fixed without breaking uapi backwards compatibility.
>
The whole point of a randomness source is that it is random. So userspace
-crypto@vger.kernel.org
> Cc: Eric Biggers
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> ---
> Updates/corrections welcome.
>
> v2: drop comment that "fips_enabled can cause some tests to be
On Mon, Mar 29, 2021 at 09:56:18PM +, Dexuan Cui wrote:
> Hi all,
> The v5.12.0-rc5 kernel (1e43c377a79f) panics with fips=1.
>
> Please refer to the below panic call-trace. The kernel config file and
> the full kernel messages are also attached.
>
> Is this a known issue?
>
> Thanks,
> -- D
me key".
So that's why there's a mix of 16 and 32 byte "keys".
The naming "POLY1305_KEY_SIZE" assumes the second convention, which is a bit
confusing; it really should be called something like POLY1305_ONETIME_KEY_SIZE.
I guess the idea was that the one-time key convention is the more common one.
Anyway, the patch seems to be fine, as it uses the correct length in each
location. You can add:
Reviewed-by: Eric Biggers
- Eric
On Mon, Mar 22, 2021 at 08:45:22AM +0300, Dan Carpenter wrote:
> On Sun, Mar 21, 2021 at 10:07:48PM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > crypto_stats_get() is a no-op when the kernel is compiled without
> > CONFIG_CRYPTO_STATS, so pai
From: Eric Biggers
Remove some dead code that was left over following commit 90ea1c6436d2
("random: remove the blocking pool").
Cc: linux-crypto@vger.kernel.org
Cc: Andy Lutomirski
Cc: Jann Horn
Cc: Theodore Ts'o
Reviewed-by: Andy Lutomirski
Acked-by: Ard Biesheuvel
Sign
From: Eric Biggers
On big endian CPUs, the ChaCha20-based CRNG is using the wrong
endianness for the ChaCha20 constants.
This doesn't matter cryptographically, but technically it means it's not
ChaCha20 anymore. Fix it to always use the standard constants.
Cc: linux-crypto@vger.ker
From: Eric Biggers
crypto_stats_get() is a no-op when the kernel is compiled without
CONFIG_CRYPTO_STATS, so pairing it with crypto_alg_put() unconditionally
(as crypto_rng_reset() does) is wrong.
Fix this by moving the call to crypto_stats_get() to just before the
actual algorithm operation
From: Eric Biggers
The new ARM BLAKE2s code doesn't work correctly (fails the self-tests)
in big endian kernel builds because it doesn't swap the endianness of
the message words when loading them. Fix this.
Fixes: 5172d322d34c ("crypto: arm/blake2s - add ARM scalar optimized B
t; Reviewed-by: Nicolas Pitre
> Reviewed-by: Geert Uytterhoeven
> Reviewed-by: Linus Walleij
Reviewed-by: Eric Biggers
Although likewise, shouldn't the commit title say "rev_l" instead of "rev_32"?
- Eric
Walleij
Reviewed-by: Eric Biggers
Although shouldn't the commit title say "rev_l" instead of "rev_32"?
- Eric
ash(struct crypto_ahash *tfm)
> {
You missed crypto_free_shash().
Otherwise this looks good, feel free to add:
Reviewed-by: Eric Biggers
- Eric
On Mon, Mar 01, 2021 at 09:51:56PM +0100, Christoph Böhmwalder wrote:
> > Do you have a specific use case in mind for this information? Normally,
> > users
> > should already know which algorithm they want to use (or set of algorithms
> > they
> > might want to use).
>
> I have a pretty specifi
On Mon, Mar 01, 2021 at 05:59:17PM +0100, Christoph Böhmwalder wrote:
> Currently, it is not apparent for userspace users which hash algorithms
> require a key and which don't. We have /proc/crypto, so add a field
> with this information there.
>
> Signed-off-by: Christoph Böhmwalder
>
> ---
>
On Sun, Feb 28, 2021 at 01:28:24PM +0100, Ard Biesheuvel wrote:
> Given that crypto_alloc_tfm() may return ERR pointers, and to avoid
> crashes on obscure error paths where such pointers are presented to
> crypto_destroy_tfm() (such as [0]), add an ERR_PTR check there
> before dereferencing the sec
simd)
> crypto_disable_simd_for_test();
> - err = crypto_shash_update(desc, sg_data(&tsgl->sgl[i]),
> + err = crypto_shash_update(desc, sg_virt(&tsgl->sgl[i]),
> tsgl->sgl[i].length);
> if (divs[i]->nosimd)
> crypto_reenable_simd_for_test();
> --
Looks good,
Reviewed-by: Eric Biggers
- Eric
From: Eric Biggers
Neither crypto_unregister_shashes() nor the module_exit function return
a value, so the explicit 'return' is unnecessary.
Signed-off-by: Eric Biggers
---
arch/arm/crypto/blake2b-neon-glue.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Thu, Feb 04, 2021 at 07:09:53PM -0500, Thara Gopinath wrote:
> > > @@ -260,6 +261,10 @@ static int qce_skcipher_crypt(struct
> > > skcipher_request *req, int encrypt)
> > > rctx->flags |= encrypt ? QCE_ENCRYPT : QCE_DECRYPT;
> > > keylen = IS_XTS(rctx->flags) ? ctx->enc_keyl
On Thu, Feb 04, 2021 at 04:43:54PM -0500, Thara Gopinath wrote:
> + /*
> + * ECB and CBC algorithms require message lengths to be
> + * multiples of block size.
> + * TODO: The spec says AES CBC mode for certain versions
> + * of crypto engine can handle partial blocks as we
On Thu, Feb 04, 2021 at 04:43:53PM -0500, Thara Gopinath wrote:
> Crypto engine BAM dma does not support 0 length data. Return unsupported
> if zero length messages are passed for transformation.
>
> Signed-off-by: Thara Gopinath
> ---
> drivers/crypto/qce/skcipher.c | 5 +
> 1 file changed,
crypto/testmgr.c | 6 -
> crypto/testmgr.h | 79
> crypto/twofish_generic.c | 11 +-
> 12 files changed, 90 insertions(+), 303 deletions(-)
Thanks for fixing this up! These patches all look good to me, and all the
self-tests still pass. You can add:
Reviewed-by: Eric Biggers
- Eric
On Tue, Jan 12, 2021 at 11:28:18AM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
> doesn't make sense. Reseed it from the input_pool instead.
>
> Fixes: d848e5f8e1eb ("random: add new ioc
On Tue, Jan 12, 2021 at 11:29:27AM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> On big endian CPUs, the ChaCha20-based CRNG is using the wrong
> endianness for the ChaCha20 constants.
>
> This doesn't matter cryptographically, but technically it means it's not
On Tue, Jan 12, 2021 at 11:29:38AM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> Remove some dead code that was left over following commit 90ea1c6436d2
> ("random: remove the blocking pool").
>
> Cc: linux-crypto@vger.kernel.org
> Cc: Andy Lutomirski
>
On Sun, Jan 24, 2021 at 03:04:50PM +0100, Stephan Müller wrote:
> The clearing of the OKM memory buffer in case of an error is already
> performed by the HKDF implementation crypto_hkdf_expand. Thus, the
> code clearing is not needed any more in the file system code base.
>
> Signed-off-by: Stepha
On Sun, Jan 24, 2021 at 03:04:31PM +0100, Stephan Müller wrote:
> @@ -74,16 +57,14 @@ int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, const u8
> *master_key,
> return PTR_ERR(hmac_tfm);
> }
>
> - if (WARN_ON(crypto_shash_digestsize(hmac_tfm) != sizeof(prk))) {
> + if
Please prefix the commit subject with "fscrypt: " rather than "fs: ".
On Sun, Jan 24, 2021 at 03:04:31PM +0100, Stephan Müller wrote:
> diff --git a/fs/crypto/hkdf.c b/fs/crypto/hkdf.c
> index e0ec21055505..ae236b42b1f0 100644
> --- a/fs/crypto/hkdf.c
> +++ b/fs/crypto/hkdf.c
> @@ -9,7 +9,7 @@
>
On Sun, Jan 24, 2021 at 03:03:28PM +0100, Stephan Müller wrote:
> RFC5869 specifies an extract and expand two-step key derivation
> function. The HKDF implementation is provided as a service function that
> operates on a caller-provided HMAC handle. The caller has to allocate
> the HMAC shash handl
On Thu, Jan 21, 2021 at 02:07:33PM +0100, Ard Biesheuvel wrote:
> Salsa20 is not used anywhere in the kernel, is not suitable for disk
> encryption, and widely considered to have been superseded by ChaCha20.
> So let's remove it.
>
> Signed-off-by: Ard Biesheuvel
> ---
> Documentation/admin-guid
On Fri, Jan 15, 2021 at 04:20:44PM -0800, Dave Hansen wrote:
> On 1/15/21 4:14 PM, Dey, Megha wrote:
> > Also, I do not know of any cores that implement PCLMULQDQ and not AES-NI.
>
> That's true, bit it's also possible that a hypervisor could enumerate
> support for PCLMULQDQ and not AES-NI. In g
On Sat, Jan 16, 2021 at 08:59:50AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> master
> head: b3a3cbdec55b090d22a09f75efb7c7d34cb97f25
> commit: 28dcca4cc0c01e2467549a36b1b0eacfdb01236c [952/3956] crypto: blake2b -
> sync with
On Fri, Jan 15, 2021 at 04:14:40PM -0800, Dey, Megha wrote:
> > Hello Megha,
> >
> > What is the purpose of this separate GHASH module? GHASH is only used
> > in combination with AES-CTR to produce GCM, and this series already
> > contains a GCM driver.
> >
> > Do cores exist that implement PCLMU
On Fri, Jan 15, 2021 at 06:17:43PM +0100, Jason A. Donenfeld wrote:
> users are unable to load the module after use.
It should say "unload".
- Eric
From: Eric Biggers
Remove some dead code that was left over following commit 90ea1c6436d2
("random: remove the blocking pool").
Cc: linux-crypto@vger.kernel.org
Cc: Andy Lutomirski
Cc: Jann Horn
Cc: Theodore Ts'o
Reviewed-by: Andy Lutomirski
Signed-off-by: Eric Biggers
---
From: Eric Biggers
The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
doesn't make sense. Reseed it from the input_pool instead.
Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
Cc: sta...@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: Andy
From: Eric Biggers
On big endian CPUs, the ChaCha20-based CRNG is using the wrong
endianness for the ChaCha20 constants.
This doesn't matter cryptographically, but technically it means it's not
ChaCha20 anymore. Fix it to always use the standard constants.
Cc: linux-crypto@vger.ker
particular,
> whether synchronize_rcu_tasks() is sufficient to ensure that a module
> providing the target of a static call can be unloaded safely.
>
> Cc: "Martin K. Petersen"
> Cc: Eric Biggers
> Cc: Peter Zijlstra
>
> Ard Biesheuvel (7):
> crypto: crc-t1
+Jason, since this looks WireGuard-related.
On Sat, Jan 09, 2021 at 05:05:24AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:73d62e81 kmsan: random: prevent boot-time reports in _mix_..
> git tree: https://github.com/google/kmsan.git master
> co
On Fri, Jan 08, 2021 at 06:17:06PM +0100, Ard Biesheuvel wrote:
> diff --git a/include/crypto/skcipher.h b/include/crypto/skcipher.h
> index 6a733b171a5d..aa133dc3bf39 100644
> --- a/include/crypto/skcipher.h
> +++ b/include/crypto/skcipher.h
> @@ -128,7 +128,7 @@ struct skcipher_alg {
>
On Thu, Jan 07, 2021 at 01:41:28PM +0100, Ard Biesheuvel wrote:
> Unlike many other structure types defined in the crypto API, the
> 'shash_desc' structure is permitted to live on the stack, which
> implies its contents may not be accessed by DMA masters. (This is
> due to the fact that the stack m
On Thu, Jan 07, 2021 at 08:53:15AM +0100, Stephan Mueller wrote:
> >
> > > RFC5869
> > > allows two optional parameters to be provided to the extract operation:
> > > the salt and additional information. Both are to be provided with the
> > > seed parameter where the salt is the first entry of the
On Thu, Jan 07, 2021 at 08:49:52AM +0100, Stephan Mueller wrote:
> > > -int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, const u8 *master_key,
> > > +int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, u8 *master_key,
> > > unsigned int master_key_size);
> >
> > It shouldn't be
On Mon, Jan 04, 2021 at 10:49:13PM +0100, Stephan Müller wrote:
> RFC5869 specifies an extract and expand two-step key derivation
> function. The HKDF implementation is provided as a service function that
> operates on a caller-provided HMAC cipher handle.
HMAC isn't a "cipher".
> The extract fun
On Mon, Jan 04, 2021 at 10:50:49PM +0100, Stephan Müller wrote:
> As the kernel crypto API implements HKDF, replace the
> file-system-specific HKDF implementation with the generic HKDF
> implementation.
>
> Signed-off-by: Stephan Mueller
> ---
> fs/crypto/Kconfig | 2 +-
> fs/crypto/
On Wed, Jan 06, 2021 at 10:59:24PM -0800, Eric Biggers wrote:
> On Thu, Jan 07, 2021 at 07:37:05AM +0100, Stephan Mueller wrote:
> > Am Montag, dem 04.01.2021 um 14:20 -0800 schrieb Eric Biggers:
> > > On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote:
> >
On Thu, Jan 07, 2021 at 07:37:05AM +0100, Stephan Mueller wrote:
> Am Montag, dem 04.01.2021 um 14:20 -0800 schrieb Eric Biggers:
> > On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote:
> > > The HKDF addition is used to replace the implementation in the files
On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote:
> The HKDF addition is used to replace the implementation in the filesystem
> crypto extension. This code was tested by using an EXT4 encrypted file
> system that was created and contains files written to by the current
> implementatio
On Fri, Nov 20, 2020 at 10:52:54AM -0800, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 09:33:54AM -0700, Eric Biggers wrote:
> > On Tue, Oct 06, 2020 at 08:51:45PM -0700, Eric Biggers wrote:
> > > On Fri, Sep 18, 2020 at 02:57:05PM -0700, Eric Biggers wrote:
> > > >
On Fri, Nov 20, 2020 at 10:52:35AM -0800, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 09:34:03AM -0700, Eric Biggers wrote:
> > On Tue, Oct 06, 2020 at 08:50:58PM -0700, Eric Biggers wrote:
> > > On Tue, Sep 15, 2020 at 09:36:52PM -0700, Eric Biggers wrote:
> >
On Fri, Nov 20, 2020 at 10:52:14AM -0800, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 09:33:43AM -0700, Eric Biggers wrote:
> > On Tue, Oct 06, 2020 at 08:50:21PM -0700, Eric Biggers wrote:
> > > On Tue, Sep 15, 2020 at 09:19:08PM -0700, Eric Biggers wrote:
> >
| 2 +-
> 12 files changed, 8 insertions(+), 8 deletions(-)
Acked-by: Eric Biggers
| 6 -
> include/crypto/internal/skcipher.h| 1 -
> 6 files changed, 243 deletions(-)
Acked-by: Eric Biggers
h_avx_glue.c | 73 +-
> arch/x86/crypto/twofish_glue_3way.c | 80 ++--
> crypto/Kconfig | 2 -
> 3 files changed, 44 insertions(+), 111 deletions(-)
Acked-by: Eric Biggers
t6_avx_glue.c | 61 ++--
> crypto/Kconfig | 1 -
> 2 files changed, 17 insertions(+), 45 deletions(-)
Acked-by: Eric Biggers
5_avx_glue.c | 184 ++--
> 1 file changed, 17 insertions(+), 167 deletions(-)
Acked-by: Eric Biggers
t_avx2_glue.c | 73 +-
> arch/x86/crypto/serpent_avx_glue.c | 61 ---
> arch/x86/crypto/serpent_sse2_glue.c | 81 ++--
> crypto/Kconfig | 3 -
> 4 files changed, 61 insertions(+), 157 deletions(-)
Acked-by: Eric Biggers
core of the ECB and CBC processing, so we can wire
> them up for existing users of the glue helper module, i.e., Camellia,
> Serpent, Twofish and CAST6.
>
> Signed-off-by: Ard Biesheuvel
> ---
> arch/x86/crypto/ecb_cbc_helpers.h | 71
> 1 file changed, 71 insertions(+)
Acked-by: Eric Biggers
_aesni_avx2_glue.c | 85 ++--
> arch/x86/crypto/camellia_aesni_avx_glue.c | 73 +
> arch/x86/crypto/camellia_glue.c| 61 --
> crypto/Kconfig | 2 -
> 4 files changed, 60 insertions(+), 161 deletions(-)
Acked-by: Eric Biggers
3_ede_glue.c | 104
> crypto/Kconfig | 1 +
> 2 files changed, 1 insertion(+), 104 deletions(-)
Acked-by: Eric Biggers
> template and the bare cipher.
>
> Signed-off-by: Ard Biesheuvel
> ---
> arch/x86/crypto/cast5_avx_glue.c | 103
> crypto/Kconfig | 1 +
> 2 files changed, 1 insertion(+), 103 deletions(-)
Acked-by: Eric Biggers
wfish_glue.c | 107
> crypto/Kconfig | 1 +
> 2 files changed, 1 insertion(+), 107 deletions(-)
Acked-by: Eric Biggers
C mode implementations
> to get rid of the indirect calls. Or perhaps we could drop [some of] these
> algorithms entirely ...
>
> * tcrypt results for various XTS implementations below, captured on a
> Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
>
> Cc: Megha Dey
> Cc: Eric
hmarked using tcrypt using 1420 byte blocks - full results below)
>
> It also allows us to enable the same driver for i386.
>
> Cc: Megha Dey
> Cc: Eric Biggers
> Cc: Herbert Xu
>
> Ard Biesheuvel (2):
> crypto: x86/aes-ni-xts - use direct calls to and 4-way stri
From: Eric Biggers
Add a NEON-accelerated implementation of BLAKE2b.
On Cortex-A7 (which these days is the most common ARM processor that
doesn't have the ARMv8 Crypto Extensions), this is over twice as fast as
SHA-256, and slightly faster than SHA-1. It is also almost three times
as fa
From: Eric Biggers
Add helper functions for shash implementations of BLAKE2s to
include/crypto/internal/blake2s.h, taking advantage of
__blake2s_update() and __blake2s_final() that were added by the previous
patch to share more code between the library and shash implementations
From: Eric Biggers
Add an ARM scalar optimized implementation of BLAKE2s.
NEON isn't very useful for BLAKE2s because the BLAKE2s block size is too
small for NEON to help. Each NEON instruction would depend on the
previous one, resulting in poor performance.
With scalar instructions, o
From: Eric Biggers
The file comment for blake2b_generic.c makes it sound like it's the
reference implementation of BLAKE2b with only minor changes. But it's
actually been changed a lot. Update the comment to make this clearer.
Reviewed-by: David Sterba
Acked-by: Ard Biesheuvel
Sig
1 - 100 of 1649 matches
Mail list logo
