the comment to make this clearer.
After your changes I agree it appropriate to reword it.
> Signed-off-by: Eric Biggers
Reviewed-by: David Sterba
e these structs.
>
> Signed-off-by: Eric Biggers
Reviewed-by: David Sterba
> +static struct shash_alg blake2b_algs[] = {
> + BLAKE2B_ALG("blake2b-160", "blake2b-160-generic",
> + BLAKE2B_160_HASH_SIZE),
Spelling out the algo names as string i
ve to provide an
> implementation of blake2b_compress_blocks_t. (This is modeled on how
> the nhpoly1305 implementations work. Also, the prototype of
> blake2b_compress_blocks_t is meant to be similar to that of
> blake2s_compress_arch().)
>
> Signed-off-by: Eric Biggers
Reviewed-by: David Sterba
; BLAKE2B_*_HASH_SIZE
> BLAKE2B_BLOCKBYTES => BLAKE2B_BLOCK_SIZE
> BLAKE2B_KEYBYTES => BLAKE2B_KEY_SIZE
>
> Signed-off-by: Eric Biggers
Reviewed-by: David Sterba
On Wed, Dec 16, 2020 at 11:58:07AM +1100, Herbert Xu wrote:
> On Wed, Dec 16, 2020 at 12:48:51AM +, Nick Terrell wrote:
> >
> > Thanks for the advice! The first zstd patches went through Herbert’s tree,
> > which is
> > why I’ve sent them this way.
>
> Sorry, but I'm not touch these patches a
On Thu, Dec 03, 2020 at 07:58:16AM +0800, kernel test robot wrote:
> All warnings (new ones prefixed by >>):
>
>lib/zstd/compress/zstd_double_fast.c: In function
> 'ZSTD_compressBlock_doubleFast_extDict_generic':
> >> lib/zstd/compress/zstd_double_fast.c:501:1: warning: the frame size of
> >
On Mon, Nov 09, 2020 at 02:01:41PM -0500, Chris Mason wrote:
> On 6 Nov 2020, at 13:38, Christoph Hellwig wrote:
> > You just keep resedning this crap, don't you? Haven't you been told
> > multiple times to provide a proper kernel API by now?
>
> You do consistently ask for a shim layer, but you
On Wed, Sep 30, 2020 at 08:49:49PM +, Nick Terrell wrote:
> > On Sep 29, 2020, at 11:53 PM, Nick Terrell wrote:
> >
> > From: Nick Terrell
>
> It has been brought to my attention that patch 3 hasn’t made it to patchwork,
> likely because it is too large. I’ll include a pull request in the n
On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote:
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > v4:
> > - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > so that it can be backported to stable.
> > - Drop the "crypto: Remove unnecessary me
On Mon, Jun 15, 2020 at 09:57:18PM -0400, Waiman Long wrote:
> In btrfs_ioctl_get_subvol_info(), there is a classic case where kzalloc()
> was incorrectly paired with kzfree(). According to David Sterba, there
> isn't any sensitive information in the subvol_info that needs to be
&g
On Wed, Oct 23, 2019 at 11:01:25AM +0200, Ard Biesheuvel wrote:
> On Wed, 23 Oct 2019 at 02:12, David Sterba wrote:
> > Tested on x86_64 with KASAN and SLUB_DEBUG.
>
> Tested-by: Ard Biesheuvel # arm64 big-endian
Thanks!
> > crypto/Kconfig | 17 ++
removed sanity checks of key length or output size,
these values are verified in the crypto API callbacks or are hardcoded
in shash_alg and not exposed to users.
Signed-off-by: David Sterba
---
crypto/Kconfig | 17 ++
crypto/Makefile | 1 +
crypto/blake2b_g
-crypto/cover.1571043883.git.dste...@suse.com/
David Sterba (2):
crypto: add blake2b generic implementation
crypto: add test vectors for blake2b
crypto/Kconfig | 17 ++
crypto/Makefile | 1 +
crypto/blake2b_generic.c | 413 +++
crypto
CC: Eric Biggers
Signed-off-by: David Sterba
---
crypto/testmgr.c | 28 +
crypto/testmgr.h | 307 +++
2 files changed, 335 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index c39e39e55dc2..0f956780a673 100644
--- a/crypto/testm
On Thu, Oct 17, 2019 at 12:22:57PM +0200, Ard Biesheuvel wrote:
> On Mon, 14 Oct 2019 at 11:17, David Sterba wrote:
> >
> > Test vectors for blake2b with various digest sizes. As the algorithm is
> > the same up to the digest calculation, the key and input data length is
>
CC: Eric Biggers
Signed-off-by: David Sterba
---
crypto/testmgr.c | 28 ++
crypto/testmgr.h | 719 +++
2 files changed, 747 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index c39e39e55dc2..0f956780a673 100644
--- a/crypto/testmgr.c
++
...@suse.com/
David Sterba (2):
crypto: add blake2b generic implementation
crypto: add test vectors for blake2b
crypto/Kconfig | 17 +
crypto/Makefile | 1 +
crypto/blake2b_generic.c | 413 ++
crypto/testmgr.c | 28 ++
crypto/testmgr.h
removed sanity checks of key length or output size,
these values are verified in the crypto API callbacks or hardcoded in
shash_alg and not exposed to users.
Signed-off-by: David Sterba
---
crypto/Kconfig | 17 ++
crypto/Makefile | 1 +
crypto/blake2b_g
On Fri, Oct 11, 2019 at 10:57:40AM -0700, Eric Biggers wrote:
> The choice of data lengths seems a bit unusual, as they include every length
> in
> two ranges but nothing in between. Also, none of the lengths except 0 is a
> multiple of the blake2b block size. Instead, maybe use something like
>
On Fri, Oct 11, 2019 at 11:04:40AM -0700, Eric Biggers wrote:
> > +struct blake2b_param
> > +{
>
> It should be 'struct blake2b_param {'
>
> checkpatch.pl should warn about this. Can you fix the checkpatch warnings
> that
> make sense to fix?
I fixed all the { at the end of line of struct defi
On Fri, Oct 11, 2019 at 06:52:03PM +0200, David Sterba wrote:
> Testing performed:
>
> - compiled with SLUB_DEBUG and KASAN, plus crypto selftests
> CONFIG_CRYPTO_MANAGER2=y
> CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=n
> CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y
> - module loade
Add test vectors for blake2b, with 384 bit digest size. The tested
variants are with the following:
- empty key
- 1 byte key
- first 32 bytes of the default key
- default key (64 bytes)
Tested plain text are sequences of bytes of lengths 0..15 and 247..255.
Signed-off-by: David Sterba
Add test vectors for blake2b, with 256 bit digest size. The tested
variants are with the following:
- empty key
- 1 byte key
- first 32 bytes of the default key
- default key (64 bytes)
Tested plain text are sequences of bytes of lengths 0..15 and 247..255.
Signed-off-by: David Sterba
and 247..255.
Signed-off-by: David Sterba
---
crypto/testmgr.c |7 +
crypto/testmgr.h | 2915 ++
2 files changed, 2922 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index f0e6d5f7982a..8a879226afcc 100644
--- a/crypto/testmgr.c
removed sanity checks of key length or output size,
these values are verified in the crypto API callbacks or hardcoded in
shash_alg and not exposed to users.
Signed-off-by: David Sterba
---
crypto/Kconfig | 17 ++
crypto/Makefile | 1 +
crypto/blake2b_g
Add test vectors for blake2b, with 160 bit digest size. The tested
variants are with the following:
- empty key
- 1 byte key
- first 32 bytes of the default key
- default key (64 bytes)
Tested plain text are sequences of bytes of lengths 0..15 and 247..255.
Signed-off-by: David Sterba
.git.dste...@suse.com/
V3:
https://lore.kernel.org/linux-crypto/e7f46def436c2c705c0b2cac3324f817efa4717d.1570715842.git.dste...@suse.com/
David Sterba (5):
crypto: add blake2b generic implementation
crypto: add test vectors for blake2b-160
crypto: add test vectors for blake2b-256
crypto: add tes
On Thu, Oct 10, 2019 at 03:12:02PM -0700, Eric Biggers wrote:
> > I'm going to do the selftests next so the above can't happen again.
>
> The test vectors should be included in this patch.
>
> > +
> > + - blake2b - the default 512b digest
> > + - blake2b-160
> > + - blake2b-256
>
+ .base.cra_init = blake2b_cra_init,
+ }
+};
+
+static int __init blake2b_mod_init(void)
+{
+ BUILD_BUG_ON(sizeof(struct blake2b_param) != BLAKE2B_OUTBYTES);
+
+ return crypto_register_shashes(blake2b_algs, ARRAY_SIZE(blake2b_algs));
+}
+
+static void __exit blake
Hi,
On Wed, Oct 09, 2019 at 03:47:09PM +0200, Ard Biesheuvel wrote:
> I have a couple more comments - apologies for not spotting these the
> first time around.
No problem, there was a lot of churn since v1.
> > +enum {
> > + BLAKE2_DUMMY_2 = 1 / (sizeof(struct blake2b_param) ==
> > BLAKE2
oding style (whitespace, comments,
uintXX_t -> uXX types, removed unused prototypes and #ifdefs, removed
testing code, changed secure_zero_memory -> memzero_explicit, used own
helpers for unaligned reads/writes and rotations).
Signed-off-by: David Sterba
---
V2:
File changes:
- delete blake2
Hi,
thanks for the review.
On Thu, Oct 03, 2019 at 02:18:55PM +0200, Ard Biesheuvel wrote:
> On Mon, 30 Sep 2019 at 15:12, David Sterba wrote:
> > The patch brings support of several BLAKE2 algorithms (2b, 2s, various
> > digest lengths). The in-tree user will be btrfs (f
hat I read
elsewhere in crypto/, but please let me know about things to fix up or update
or if it's preferred to split the patch.
d.
David Sterba (1):
crypto: blake2s reference implementation
crypto/Kconfig | 35 +++
crypto/Makefile | 2 +
crypto/bla
= digest_update,
+ .final = digest_final,
+ .finup = digest_finup,
+ .descsize = sizeof(struct digest_desc_ctx),
+ .base = {
+ .cra_name = "blake2b-512",
+
On Tue, May 14, 2019 at 02:34:10PM -0700, Eric Biggers wrote:
> On Tue, May 14, 2019 at 06:33:48PM +0200, David Sterba wrote:
> > Hi,
> >
> > Q: is there a way to query the crypto layer whether a given algorithm
> > (digest, crypto) is accelerated by the driver?
>
Hi,
Q: is there a way to query the crypto layer whether a given algorithm
(digest, crypto) is accelerated by the driver?
This information can be used to decide if eg. a checksum should can be
calculated right away or offloaded to a thread. This is done in btrfs,
(fs/btrfs/disk-io.c:check_async_wr
double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann
> ---
> fs/btrfs/super.c | 2 +-
Acked-by: David Sterba
Adding linux-crypto@vger.kernel.org to CC
Link to the 2/2 patch https://patchwork.kernel.org/patch/10149203/
On Mon, Jan 08, 2018 at 11:45:04AM +0200, Nikolay Borisov wrote:
> This function returns a string with the currently in-use implementation
> of the crc32c algorithm, i.e crc32c-generic (fo
is Mason
> Cc: Josef Bacik
> Cc: David Sterba
> Cc: linux-bt...@vger.kernel.org
Acked-by: David Sterba
On Wed, Sep 13, 2017 at 01:02:19PM +0530, Allen Pais wrote:
> Signed-off-by: Allen Pais
> ---
> fs/btrfs/check-integrity.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
> index 7d5a9b5..efa4c23 100644
> --- a/fs/b
On Wed, Jul 26, 2017 at 12:19:29AM +0100, Giovanni Cabiddu wrote:
> Hi Nick,
>
> On Thu, Jul 20, 2017 at 10:27:42PM +0100, Nick Terrell wrote:
> > Add zstd compression and decompression support to BtrFS. zstd at its
> > fastest level compresses almost as well as zlib, while offering much
> > faste
On Fri, Aug 11, 2017 at 09:20:10AM -0400, Chris Mason wrote:
>
>
> On 08/10/2017 03:25 PM, Hugo Mills wrote:
> > On Thu, Aug 10, 2017 at 01:41:21PM -0400, Chris Mason wrote:
> >> On 08/10/2017 04:30 AM, Eric Biggers wrote:
> >>>
> >>> Theses benchmarks are misleading because they compress the who
memset(&iv, 0xff, iv_len);
crypto/tcrypt.c:test_cipher_speed()
- unsigned char *key, iv[128];
+ const char *key, iv[128];
...
memset(&iv, 0xff, iv_len);
CC: Herbert Xu
Signed-off-by: David Sterba
---
crypto/tcrypt.c |3 ++-
1 files changed,
43 matches
Mail list logo
