[PATCH] crypto: ccp: remove duplicate module version and author entry

commit 720419f01832 ("crypto: ccp - Introduce the AMD Secure Processor device") moved the module registeration from ccp-dev.c to sp-dev.c but patch missed removing the module version and author entry from ccp-dev.c. It causes the below warning during boot when CONFIG_CRYPTO_DEV_SP_CCP=y and

Re: [RFC 20/22] x86/relocs: Add option to generate 64-bit relocations

,"Paul E . McKenney" ,Andrew Morton ,Christopher Li ,Dou Liyang ,Masahiro Yamada ,Daniel Borkmann ,Markus

Re: [RFC 06/22] kvm: Adapt assembly for PIE support

,Chris Metcalf ,"Paul E . McKenney" ,Andrew Morton ,Christopher Li ,Dou Liyang ,Masahiro Yamada ,Daniel

[PATCH] crypto: ixp4xx - Fix error handling path in 'aead_perform()'

In commit 0f987e25cb8a, the source processing has been moved in front of the destination processing, but the error handling path has not been modified accordingly. Free resources in the correct order to avoid some leaks. Fixes: 0f987e25cb8a ("crypto: ixp4xx - Fix false lastlen uninitialised

Re: [PATCH 3/3] hwrng: mxc-fsl - add support for Freescale RNGC

Hi PrasannaKumar, thanks for taking the time to review my submission. Thus wrote PrasannaKumar Muralidharan (prasannatsmku...@gmail.com): > Please combine above 2 comments. ok, I'll do this. > > + > > +/* > > + * Hardware driver for the Intel/AMD/VIA Random Number Generators (RNG) > > [...]

Re: [PATCH v1] crypto: caam - set hwrng quality level

On Wed, Jul 19, 2017 at 04:53:21PM +, Horia Geantă wrote: > On 7/19/2017 7:32 PM, Oleksij Rempel wrote: > > On Wed, Jul 19, 2017 at 12:49:47PM +, Horia Geantă wrote: > >> On 7/19/2017 10:45 AM, Oleksij Rempel wrote: > >>> According documentation, it is NIST certified TRNG. > >>> So, set

Re: [PATCH 5/6] fscrypt: cache the HMAC transform for each master key

On Mon, Jul 17, 2017 at 10:45:51AM -0700, Michael Halcrow wrote: > > +/* > > + * Get the fscrypt_master_key identified by the specified v2+ encryption > > + * context, or create it if not found. > > + * > > + * Returns the fscrypt_master_key with a reference taken, or an ERR_PTR(). > > + */ > >

Re: [PATCH 3/6] fscrypt: use HKDF-SHA512 to derive the per-inode encryption keys

On Fri, Jul 14, 2017 at 09:24:40AM -0700, Michael Halcrow wrote: > > +static int hkdf_expand(struct crypto_shash *hmac, u8 context, > > + const u8 *info, unsigned int infolen, > > + u8 *okm, unsigned int okmlen) > > +{ > > + SHASH_DESC_ON_STACK(desc, hmac); > >

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Wed, Jul 19, 2017 at 08:22:18AM +0200, Stephan Müller wrote: > In the email [1] I have expressed the core concerns I see -- none of them > address the need to keep the Jitter RNG as one noise source. To address > those, > a very deep dive into random.c needs to be made. That's simply not

Re: [PATCH v1] crypto: caam - set hwrng quality level

On 7/19/2017 7:32 PM, Oleksij Rempel wrote: > On Wed, Jul 19, 2017 at 12:49:47PM +, Horia Geantă wrote: >> On 7/19/2017 10:45 AM, Oleksij Rempel wrote: >>> According documentation, it is NIST certified TRNG. >>> So, set high quality to let the HWRNG framework automatically use it. >>> >>>

[PATCH] crypto: tcrypt - remove AES-XTS-192 speed tests

Remove xts(aes) speed tests with 2 x 192-bit keys, since implementations adhering strictly to IEEE 1619-2007 standard cannot cope with key sizes other than 2 x 128, 2 x 256 bits - i.e. AES-XTS-{128,256}: [...] tcrypt: test 5 (384 bit key, 16 byte blocks): caam_jr 802.jr: key size mismatch

Re: [PATCH v1] crypto: caam - set hwrng quality level

On Wed, Jul 19, 2017 at 12:49:47PM +, Horia Geantă wrote: > On 7/19/2017 10:45 AM, Oleksij Rempel wrote: > > According documentation, it is NIST certified TRNG. > > So, set high quality to let the HWRNG framework automatically use it. > > > > Signed-off-by: Oleksij Rempel

Re: [PATCH v4 1/5] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

On 18/07/17 11:57 PM, Michael Ellerman wrote: > Seems fair enough, have you tested it at all? It's only been compile tested and the kbuild robot has beat up on it a bit. Thanks, Logan

[PATCH 013/102] crypto: rockchip: explicitly request exclusive reset control

Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or shared reset control behavior. Convert all drivers requesting exclusive resets to the explicit

[PATCH 014/102] crypto: sun4i-ss - request exclusive reset control

Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or shared reset control behavior. Convert all drivers requesting exclusive resets to the explicit

Re: [PATCH v1] crypto: caam - set hwrng quality level

On 7/19/2017 10:45 AM, Oleksij Rempel wrote: > According documentation, it is NIST certified TRNG. > So, set high quality to let the HWRNG framework automatically use it. > > Signed-off-by: Oleksij Rempel > --- > drivers/crypto/caam/caamrng.c | 6 ++ > 1 file

[PATCH] Crypto: atmel-ecc: Make a couple of local functions static

From: Colin Ian King Functions atmel_ecc_i2c_client_alloc and atmel_ecc_i2c_client_free are local to the source and no not need to be in the global scope. Make them static. Cleans up sparse warnings: symbol 'atmel_ecc_i2c_client_alloc' was not declared. Should it be

Re: AES-XTS key size

Am Mittwoch, 19. Juli 2017, 10:20:07 CEST schrieb Horia Geantă: Hi Horia, > Hi, > > AFAICS, IEEE 1619-2007 standard mentions only XTS-AES-128 and > XTS-AES-256, meaning that the keys should be either 256 or 512 bits. > > Further, NIST SP800-38E mentions that an implementation may restrict >

[PATCH v2 2/2] crypto: inside-secure - fix the sha state length in hmac_sha1_setkey

A check is performed on the ipad/opad in the safexcel_hmac_sha1_setkey function, but the index used by the loop doing it is wrong. It is currently the size of the state array while it should be the size of a sha1 state. This patch fixes it. Fixes: 1b44c5a60c13 ("crypto: inside-secure - add

[PATCH v2 1/2] crypto: inside-secure - fix invalidation check in hmac_sha1_setkey

The safexcel_hmac_sha1_setkey function checks if an invalidation command should be issued, i.e. when the context ipad/opad change. This checks is done after filling the ipad/opad which and it can't be true. The patch fixes this by moving the check before the ipad/opad memcpy operations. Fixes:

AES-XTS key size

Hi, AFAICS, IEEE 1619-2007 standard mentions only XTS-AES-128 and XTS-AES-256, meaning that the keys should be either 256 or 512 bits. Further, NIST SP800-38E mentions that an implementation may restrict support to only one of XTS-AES-{128,256}, but does not explicitly allow other cipher suites.

[PATCH v1] crypto: caam - set hwrng quality level

According documentation, it is NIST certified TRNG. So, set high quality to let the HWRNG framework automatically use it. Signed-off-by: Oleksij Rempel --- drivers/crypto/caam/caamrng.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

Re: [v3 RFC PATCH 1/2] crypto: ecdh: fix concurrency on ecdh_ctx

On Tue, Jul 18, 2017 at 03:52:19PM +0300, Tudor Ambarus wrote: > > I'm replacing a per-tfm shared secret with a per-request dynamically > allocated shared secret. The same for the public key, I'm replacing > a per-tfm public key with a per-request dynamically allocated public > key. No shared

Re: [PATCH V6 5/7] crypto: AES CBC multi-buffer glue code

On Tue, Jul 18, 2017 at 06:18:59PM -0700, Megha Dey wrote: > > > >> +/* > > >> + * CRYPTO_ALG_ASYNC flag is passed to indicate we have an ablk > > >> + * scatter-gather walk. > > >> + */ > > >> +static struct skcipher_alg aes_cbc_mb_alg = { > > >> +.base = { > > >> +

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Wed, Jul 19, 2017 at 08:22:18AM +0200, Stephan Müller wrote: > Am Dienstag, 18. Juli 2017, 23:08:16 CEST schrieb Theodore Ts'o: > > Hi Theodore, > > > > I've been trying to take the best features and suggestions from your > > proposal and integrating them into /dev/random already. Things

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Am Mittwoch, 19. Juli 2017, 03:51:33 CEST schrieb Theodore Ts'o: Hi Theodore, > If the real unpredictability is really coming from the interrupts > changing the state of the CPU microarchitecture, the real question is > how many interrupts do you need before you consider things > "unpredictable"

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Am Dienstag, 18. Juli 2017, 23:08:16 CEST schrieb Theodore Ts'o: Hi Theodore, > > I've been trying to take the best features and suggestions from your > proposal and integrating them into /dev/random already. Things that > I've chosen not take is basically because I disbelieve that the Jitter >