On Thu, Feb 14, 2019 at 09:54:47PM -0800, Eric Biggers wrote:
>
> Sure, but the bar shouldn't be so low that new implementations of insecure
> algorithms the world is moving away from are accepted without a real use case.
> We should be moving towards removing these algorithms instead. The origina
On Fri, Feb 15, 2019 at 01:24:42PM +0800, Herbert Xu wrote:
> On Wed, Feb 13, 2019 at 10:51:36AM -0800, Eric Biggers wrote:
> >
> > You are claiming you need DES-ECB, 3DES-ECB, *and* ARC4 for that?
> >
> > Which one is it actually, if any?
>
> Since these are existing algorithms in the crypto API
On Fri, Feb 08, 2019 at 03:50:06PM +0200, Iuliana Prodan wrote:
> This patch set adds ecb mode support for aes, des, 3des and arc4 ciphers.
> skcipher implementation is reused, making sure to handle the no IV case.
>
> While here:
> -fix a DMA API issue where initial src/dst_nents are used instead
On Wed, Feb 13, 2019 at 10:51:36AM -0800, Eric Biggers wrote:
>
> You are claiming you need DES-ECB, 3DES-ECB, *and* ARC4 for that?
>
> Which one is it actually, if any?
Since these are existing algorithms in the crypto API and we're
simply adding them to the driver I think the bar of acceptance
Hi Linus:
This push fixes a crash on resume in the ccree driver.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Gilad Ben-Yossef (1):
crypto: ccree - fix resume race condition on init
drivers/crypto/ccree/cc_driver.c | 7 ---
drivers/
I've been working on wrapping various SEV kernel APIs for userspace
consumption. There does not appear to be any privilege separation for
these commands: you can run them all or none of them. This is less
than ideal because it means that a compromise of the code which
launches VMs could make perman
On 2/8/2019 3:51 PM, Iuliana Prodan wrote:
> This patch set adds ecb mode support for aes, des, 3des and arc4 ciphers.
> skcipher implementation is reused, making sure to handle the no IV case.
>
For the series:
Reviewed-by: Horia Geantă
Thanks,
Horia
On 2/14/19 10:57 AM, Nathaniel McCallum wrote:
> I'm a little concerned that this immediately disables SEV_GET_ID.
> IMHO, we should continue to support both for a period of time. One
> justification for immediate disablement would be that if keeping it
> around is likely to enabled incorrect or
From: Eric Biggers
Add 1536 and 4096-byte Adiantum test vectors so that the case where
there are multiple NH hashes is tested. This is already tested by the
nhpoly1305 test vectors, but it should be tested at the Adiantum level
too. Moreover the 4096-byte case is especially important.
As with
From: Eric Biggers
This is needed to test that the end of the message is zero-padded when
the length is not a multiple of 16 (NH_MESSAGE_UNIT). It's already
tested indirectly by the 31-byte Adiantum test vector, but it should be
tested directly at the nhpoly1305 level too.
As with the other nhp
I'm a little concerned that this immediately disables SEV_GET_ID.
IMHO, we should continue to support both for a period of time. One
justification for immediate disablement would be that if keeping it
around is likely to enabled incorrect or insecure userspace behavior
with a firmware change. Given
On Thu, Feb 14, 2019 at 09:33:51AM +0100, Ard Biesheuvel wrote:
> On Thu, 14 Feb 2019 at 09:28, Eric Biggers wrote:
> >
> > On Thu, Feb 14, 2019 at 09:14:13AM +0100, Ard Biesheuvel wrote:
> > > On Thu, 14 Feb 2019 at 09:04, Eric Biggers wrote:
> > > >
> > > > From: Eric Biggers
> > > >
> > > > M
On Thu, 14 Feb 2019 at 09:28, Eric Biggers wrote:
>
> On Thu, Feb 14, 2019 at 09:14:13AM +0100, Ard Biesheuvel wrote:
> > On Thu, 14 Feb 2019 at 09:04, Eric Biggers wrote:
> > >
> > > From: Eric Biggers
> > >
> > > Make the arm64 ctr-aes-neon and ctr-aes-ce algorithms update the IV
> > > buffer
On Thu, Feb 14, 2019 at 09:14:13AM +0100, Ard Biesheuvel wrote:
> On Thu, 14 Feb 2019 at 09:04, Eric Biggers wrote:
> >
> > From: Eric Biggers
> >
> > Make the arm64 ctr-aes-neon and ctr-aes-ce algorithms update the IV
> > buffer to contain the next counter after processing a partial final
> > bl
On Thu, 14 Feb 2019 at 09:04, Eric Biggers wrote:
>
> From: Eric Biggers
>
> Make the arm64 ctr-aes-neon and ctr-aes-ce algorithms update the IV
> buffer to contain the next counter after processing a partial final
> block, rather than leave it as the last counter. This makes these
> algorithms
From: Eric Biggers
Make the arm ctr-aes-ce algorithm update the IV buffer to contain the
next counter after processing a partial final block, rather than leave
it as the last counter. This makes ctr-aes-ce pass the updated AES-CTR
tests. This change also makes the code match the arm64 version i
From: Eric Biggers
3DES only has an 8-byte block size, but the 3DES-CTR test vectors use
16-byte IVs. Remove the unused 8 bytes from the ends of the IVs.
Signed-off-by: Eric Biggers
---
crypto/testmgr.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/crypto/testmgr.h
Hello,
This series makes the crypto self-tests test that all CBC and CTR
implementations update req->iv to contain the IV for the next block.
This apparently has been a requirement for a long time, but it wasn't
actually tested for.
With this series applied, all self-tests pass on x86_64, arm32,
From: Eric Biggers
Allow skcipher test vectors to declare the value the IV buffer should be
updated to at the end of the encryption or decryption operation.
(This check actually used to be supported in testmgr, but it was never
used and therefore got removed except for the AES-Keywrap special ca
From: Eric Biggers
Test that all CBC implementations update the IV buffer to contain the
last ciphertext block, aka the IV to continue the encryption/decryption
of a larger message. Users may rely on this for chaining.
Signed-off-by: Eric Biggers
---
crypto/testmgr.h | 48
From: Eric Biggers
Test that all CTR implementations update the IV buffer to contain the
next counter block, aka the IV to continue the encryption/decryption of
a larger message. When the length processed is a multiple of the block
size, users may rely on this for chaining.
When the length proc
From: Eric Biggers
Make the arm64 ctr-aes-neon and ctr-aes-ce algorithms update the IV
buffer to contain the next counter after processing a partial final
block, rather than leave it as the last counter. This makes these
algorithms pass the updated AES-CTR tests.
Signed-off-by: Eric Biggers
--
22 matches
Mail list logo
