Re: AES-NI: slower than aes-generic?

On Thu, May 26, 2016 at 08:49:39PM +0200, Stephan Mueller wrote: > > Using the kernel crypto API one can relieve the CPU of the crypto work, if a > hardware or assembler implementation is available. This may be of particular > interest for smaller systems. So, for smaller systems (where kernel

[PATCH] KEYS: Add placeholder for KDF usage with DH

Hi James, Could you pass this along to Linus as soon as possible, please? This alters a new keyctl function added in the current merge window to allow for a future extension planned for the next merge window. Thanks, David --- From: Stephan Mueller Date: Thu May 26

[PATCH v2] KEYS: Add placeholder KDF usage with DH

Am Donnerstag, 26. Mai 2016, 21:10:50 schrieb David Howells: Hi David, Mat asked me to step in in case his patch needed an update. ---8<--- The values computed during Diffie-Hellman key exchange are often used in combination with key derivation functions to create cryptographic keys. Add a

RE: [PATCH 2/7] crypto : async implementation for sha1-mb

> From: Dey, Megha > Sent: Thursday, May 19, 2016 5:43 PM > To: herb...@gondor.apana.org.au > Cc: tim.c.c...@linux.intel.com; da...@davemloft.net; linux- > cry...@vger.kernel.org; linux-ker...@vger.kernel.org; Dey, Megha > ; Yu, Fenghua ; Megha > Dey

[PATCH 2/5] lib/digsig: digsig_verify_rsa(): return -EINVAL if modulo length is zero

Currently, if digsig_verify_rsa() detects that the modulo's length is zero, i.e. mlen == 0, it returns -ENOMEM which doesn't really fit here. Make digsig_verify_rsa() return -EINVAL upon mlen == 0. Signed-off-by: Nicolai Stange --- lib/digsig.c | 8 +--- 1 file

[PATCH 1/5] lib/mpi: mpi_read_from_buffer(): return error code

mpi_read_from_buffer() reads a MPI from a buffer into a newly allocated MPI instance. It expects the buffer's leading two bytes to contain the number of bits, followed by the actual payload. On failure, it returns NULL and updates the in/out argument ret_nread somewhat inconsistently: - If the

[PATCH 5/5] lib/mpi: refactor mpi_read_from_buffer() in terms of mpi_read_raw_data()

mpi_read_from_buffer() and mpi_read_raw_data() do basically the same thing except that the former extracts the number of payload bits from the first two bytes of the input buffer. Besides that, the data copying logic is exactly the same. Replace the open coded buffer to MPI instance conversion

[PATCH 3/5] lib/mpi: mpi_read_from_buffer(): return -EINVAL upon too short buffer

Currently, if the input buffer is shorter than the expected length as indicated by its first two bytes, an MPI instance of this expected length will be allocated and filled with as much data as is available. The rest will remain uninitialized. Instead of leaving this condition undetected, an

[PATCH 4/5] lib/mpi: mpi_read_from_buffer(): sanitize short buffer printk

The first two bytes of the input buffer encode its expected length and mpi_read_from_buffer() prints a console message if the given buffer is too short. However, there are some oddities with how this message is printed: - It is printed at the default loglevel. This is different from the one

[PATCH 0/5] refactor mpi_read_from_buffer()

mpi_read_from_buffer() and mpi_read_raw_data() do almost the same and share a fair amount of common code. This patchset attempts to rewrite mpi_read_from_buffer() in order to implement it in terms of mpi_read_raw_data(). The patches 1 and 3, i.e. "lib/mpi: mpi_read_from_buffer(): return error

Re: [PATCH] KEYS: Add optional key derivation parameters for DH

Mat Martineau wrote: > +struct keyctl_kdf_params { > + char *name; > + __u8 reserved[32]; /* Reserved for future use, must be 0 */ > +}; > + > #endif /* _LINUX_KEYCTL_H */ > diff --git a/security/keys/compat.c b/security/keys/compat.c > index

Re: AES-NI: slower than aes-generic?

On Thu, May 26, 2016 at 2:49 PM, Stephan Mueller wrote: > Then, the use of the DRBG offers users to choose between a Hash/HMAC and CTR > implementation to suit their needs. The DRBG code is agnostic of the > underlying cipher. So, you could even use Blowfish instead of AES

Re: AES-NI: slower than aes-generic?

Am Donnerstag, 26. Mai 2016, 14:20:19 schrieb Sandy Harris: Hi Sandy, > > Why are you using AES? Granted, it is a reasonable idea, but when Ted > replaced the non-blocking pool with a DBRG, he used a different cipher > (I think chacha, not certain) and I think chose not to use the crypto >

Re: AES-NI: slower than aes-generic?

Stephan Mueller wrote: > for the DRBG and the LRNG work I am doing, I also test the speed of the DRBG. > The DRBG can be considered as a form of block chaining mode on top of a raw > cipher. > > What I am wondering is that when encrypting 256 16 byte blocks, I get a

Re: AES-NI: slower than aes-generic?

Am Donnerstag, 26. Mai 2016, 19:30:01 schrieb Stephan Mueller: Hi, > > However, the key difference to a standard speed test is that I set up a new > key schedule quite frequently. And I would suspect that something is going > on here... With tcrypt, there is some interesting hint: on smaller

Re: AES-NI: slower than aes-generic?

> What I am wondering is that when encrypting 256 16 byte blocks, I get a speed > of about 170 MB/s with the AES-NI driver. When using the aes-generic or aes- > asm, I get up to 180 MB/s with all else being equal. Note, that figure > includes a copy_to_user of the generated data. > > ...

Re: AES-NI: slower than aes-generic?

Am Donnerstag, 26. Mai 2016, 13:25:02 schrieb Jeffrey Walton: Hi Jeffrey, > > What I am wondering is that when encrypting 256 16 byte blocks, I get a > > speed of about 170 MB/s with the AES-NI driver. When using the > > aes-generic or aes- asm, I get up to 180 MB/s with all else being equal. >

Re: key retention service: DH support

On Wed, 25 May 2016, David Howells wrote: Mat Martineau wrote: Since the KDF patches are not yet merged, I'm not sure of the best way to accomodate the future feature. We could future-proof KEYCTL_DH_COMPUTE by adding a 5th arg, an optional pointer to KDF

[PATCH] KEYS: Add optional key derivation parameters for DH

The values computed during Diffie-Hellman key exchange are often used in combination with key derivation functions to create cryptographic keys. Add an interface to configure a key derivation function that will transform the Diffie-Hellman result returned by the KEYCTL_DH_COMPUTE command.

AES-NI: slower than aes-generic?

Hi, for the DRBG and the LRNG work I am doing, I also test the speed of the DRBG. The DRBG can be considered as a form of block chaining mode on top of a raw cipher. What I am wondering is that when encrypting 256 16 byte blocks, I get a speed of about 170 MB/s with the AES-NI driver. When

Re: [RFC 3/3] md: dm-crypt: Introduce the bulk mode method when sending request

Comments inlined. In general the most concerning bit is the need for memory allocation in the IO path (see comment/question below near call to sg_alloc_table). In DM targets we make heavy use of .ctr preallocated memory and/or per-bio-data to avoid memory allocations in the IO path. On Wed, May

[PATCH 2/2] lib/mpi: mpi_read_raw_data(): fix nbits calculation

The number of bits, nbits, is calculated in mpi_read_raw_data() as follows: nbits = nbytes * 8; Afterwards, the number of leading zero bits of the first byte get subtracted: nbits -= count_leading_zeros(buffer[0]); However, count_leading_zeros() takes an unsigned long and thus, the u8 gets

[PATCH 1/2] lib/mpi: mpi_read_raw_data(): purge redundant clearing of nbits

In mpi_read_raw_data(), unsigned nbits is calculated as follows: nbits = nbytes * 8; and redundantly cleared later on if nbytes == 0: if (nbytes > 0) ... else nbits = 0; Purge this redundant clearing for the sake of clarity. Signed-off-by: Nicolai Stange ---

[PATCH] lib/mpi: purge mpi_set_buffer()

mpi_set_buffer() has no in-tree users and similar functionality is provided by mpi_read_raw_data(). Remove mpi_set_buffer(). Signed-off-by: Nicolai Stange --- Applicable to linux-next-20150525. allmodconfig build on x86_64 succeeded. include/linux/mpi.h | 1 -

Re: SKB dst field is NULL when AEAD request complete() is called

The bug was: return value of my driver's encrypt() function should have been -EINPROGRESS to support asynchronous operation. Thanks. On Thu, May 26, 2016 at 12:29 PM, Herbert Xu wrote: > Denis B wrote: >> Working with kernel 3.12.14, in AEAD

Re: SKB dst field is NULL when AEAD request complete() is called

Denis B wrote: > Working with kernel 3.12.14, in AEAD mode, I register my crypto driver > and the givencrypt() method in the driver gets called when I send > IPSec traffic. I store the request, and later call its complete() > method from a work queue. There is no actual