Greetings From Miss Pamela Render Please I Need Your Urgent Reply!
I'm Pamela Render, from USA. I am a highly motivated and willing to learn, I'm
also hard working lady, very relaible. I really want to establish mutual
friendship with you, I will introduce myself better as soon as i receive y
Thanks for this series. I like the general idea. I think it might make
sense, though, to separate things out into sha1.h and sha256.h. That
will be nice preparation work for when we eventually move obsolete
primitives into some subdirectory.
Hi Eric,
On 02/05/2020 20:24, Eric Biggers wrote:
From: Eric Biggers
In preparation for naming the SHA-1 stuff in
properly and moving it to a more appropriate header, fix the HMAC-SHA256
code in mptcp_crypto_hmac_sha() to use SHA256_BLOCK_SIZE instead of
"SHA_MESSAGE_BYTES" which is actually
On Sat, 2 May 2020 at 20:44, Eric Biggers wrote:
>
> From: Eric Biggers
>
> The AES library code (which originally came from crypto/aes_ti.c) is
> supposed to be constant-time, to the extent possible for a C
> implementation. But the hardening measure of disabling interrupts while
> the S-box is
From: Eric Biggers
The AES library code (which originally came from crypto/aes_ti.c) is
supposed to be constant-time, to the extent possible for a C
implementation. But the hardening measure of disabling interrupts while
the S-box is loaded into cache was not included in the library version;
it
From: Eric Biggers
In preparation for naming the SHA-1 stuff in
properly and moving it to a more appropriate header, fix the HMAC-SHA256
code in mptcp_crypto_hmac_sha() to use SHA256_BLOCK_SIZE instead of
"SHA_MESSAGE_BYTES" which is actually the SHA-1 block size.
(Fortunately these are both 64
From: Eric Biggers
Prefix the PowerPC SHA-1 functions with "powerpc_sha1_" rather than
"sha1_". This allows us to rename the library function sha_init() to
sha1_init() without causing a naming collision.
Cc: linuxppc-...@lists.ozlabs.org
Cc: Benjamin Herrenschmidt
Cc: Michael Ellerman
Cc: Pau
From: Eric Biggers
Prefix the s390 SHA-1 functions with "s390_sha1_" rather than "sha1_".
This allows us to rename the library function sha_init() to sha1_init()
without causing a naming collision.
Cc: linux-s...@vger.kernel.org
Signed-off-by: Eric Biggers
---
arch/s390/crypto/sha1_s390.c | 12
From: Eric Biggers
sounds very generic and important, like it's the
header to include if you're doing cryptographic hashing in the kernel.
But actually it only includes the library implementation of the SHA-1
compression function (not even the full SHA-1). This should basically
never be used an
sounds very generic and important, like it's the
header to include if you're doing cryptographic hashing in the kernel.
But actually it only includes the library implementation of the SHA-1
compression function (not even the full SHA-1). This should basically
never be used anymore; SHA-1 is no lo
From: Eric Biggers
The PowerPC implementation of SHA-1 doesn't actually use the 16-word
temporary array that's passed to the assembly code. This was probably
meant to correspond to the 'W' array that lib/sha1.c uses. However, in
sha1-powerpc-asm.S these values are actually stored in GPRs 16-31.
From: Eric Biggers
sounds very generic and important, like it's the
header to include if you're doing cryptographic hashing in the kernel.
But actually it only includes the library implementation of the SHA-1
compression function (not even the full SHA-1). This should basically
never be used an
From: Eric Biggers
The library implementation of the SHA-1 compression function is
confusingly called just "sha_transform()". Alongside it are some "SHA_"
constants and "sha_init()". Presumably these are left over from a time
when SHA just meant SHA-1. But now there are also SHA-2 and SHA-3, a
On Sat, May 02, 2020 at 11:01:35AM +0300, Nikolay Borisov wrote:
> > +void xxh32_update(struct xxh32_state *state, const void *input,
> > + const size_t len)
> > {
> > const uint8_t *p = (const uint8_t *)input;
> > const uint8_t *const b_end = p + len;
> >
> > - if (input =
On 2.05.20 г. 9:34 ч., Eric Biggers wrote:
> From: Eric Biggers
>
> The return value of xxh64_update() is pointless and confusing, since an
> error is only returned for input==NULL. But the callers must ignore
> this error because they might pass input=NULL, length=0.
>
> Likewise for xxh32_
15 matches
Mail list logo
