IV generation

Hi, A quick question: am I correct in my understanding that there is now no automatic IV generation support for either skcipher nor aead? And if I'm wrong, can someone point to an example of a driver that implements either, as all the ones I see are the deprecated ablkcipher interface. BTW, I'm

Re: [PATCH] crypto: chtls - fix a missing-check bug

Hi Wenwen, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on cryptodev/master] [also build test WARNING on v4.17-rc3 next-20180504] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: IV generation

On Mon, May 7, 2018 at 2:02 PM, Stephan Mueller wrote: > Am Montag, 7. Mai 2018, 08:26:08 CEST schrieb Gilad Ben-Yossef: > > Hi Gilad, > >> Hi, >> >> A quick question: am I correct in my understanding that there is now >> no automatic IV generation support for either skcipher

[PATCH 11/18] docs: crypto_engine.rst: Fix two parse warnings

./Documentation/crypto/crypto_engine.rst:13: WARNING: Unexpected indentation. ./Documentation/crypto/crypto_engine.rst:15: WARNING: Block quote ends without a blank line; unexpected unindent. Signed-off-by: Mauro Carvalho Chehab ---

Re: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support

On Tue, May 01, 2018 at 10:39:15PM +, Dey, Megha wrote: > > crypto/simd.c provides a simd_skcipher_create_compat. I have used the same > template to introduce simd_ahash_create_compat > which would wrap around the inner hash algorithm. > > Hence we would still register 2 algs, outer and

[PATCH 00/18] Fix some build warnings/errors with Sphinx

I decided to give a try with Sphinx last stable version (1.17.4), and noticed several issues. The worse one was with the networking book: a non-standard footnote there with [*] instead of a number causes it to break PDF building. So, I took some spare time to address some warnings all over the

[PATCH 03/18] docs: */index.rst: Add newer documents to their respective index.rst

A number of new docs were added, but they're currently not on the index.rst from the session they're supposed to be, causing Sphinx warnings. Add them. Signed-off-by: Mauro Carvalho Chehab --- Documentation/crypto/index.rst | 1 +

Re: IV generation

Am Montag, 7. Mai 2018, 08:26:08 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > Hi, > > A quick question: am I correct in my understanding that there is now > no automatic IV generation support for either skcipher nor aead? > And if I'm wrong, can someone point to an example of a driver that >

Re: IV generation

Am Montag, 7. Mai 2018, 13:19:47 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > ah... so if I have hardware that can implement say, seqiv, I can > register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are > right, it will be used? That is the question I cannot fully answer. Seqiv is a

Re: IV generation

On Mon, May 7, 2018 at 2:29 PM, Stephan Mueller wrote: > Am Montag, 7. Mai 2018, 13:19:47 CEST schrieb Gilad Ben-Yossef: > > Hi Gilad, > >> ah... so if I have hardware that can implement say, seqiv, I can >> register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are >>

[PATCH v17 6/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64 functions in non-64bit cases in favour of the new common io-64-nonatomic-lo-hi header. To be consistent with CAAM engine HW spec: in case of 64-bit registers, irrespective of device endianness, the lower address should be read from

[PATCH v17 3/7] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

In order to provide non-atomic functions for io{read|write}64 that will use readq and writeq when appropriate. We define a number of variants of these functions in the generic iomap that will do non-atomic operations on pio but atomic operations on mmio. These functions are only defined if readq

[PATCH v17 0/7] Add io{read|write}64 to io-64-atomic headers

This is a resend of my cleanup series to push a number of instances of people defining their own io{read|write}64 functions into common headers seing they don't exist in non-64bit systems. This series adds inline functions to the io-64-nonatomic headers and then cleans up the drivers that defined

[PATCH v17 5/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko Acked-by: Dave Jiang

[PATCH v17 2/7] parisc: iomap: introduce io{read|write}64

Add support for io{read|write}64() functions in parisc architecture. These are pretty straightforward copies of similar functions which make use of readq and writeq. Also, indicate that the lo_hi and hi_lo variants of these functions are not provided by this architecture. Signed-off-by: Logan

[PATCH v17 4/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if they are not already defined by the architecture. (As they are provided by the generic iomap library). The patch also points io{read|write}64[be] to the variant specified by the header name. This is because new drivers are

Re: [PATCH v2 0/5] crypto: Speck support

Hi Samuel, On Thu, Apr 26, 2018 at 03:05:44AM +0100, Samuel Neves wrote: > On Wed, Apr 25, 2018 at 8:49 PM, Eric Biggers wrote: > > I agree that my explanation should have been better, and should have > > considered > > more crypto algorithms. The main difficulty is that

[PATCH v17 7/7] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

Clean up the ifdefs which conditionally defined the io{read|write}64 functions in favour of the new common io-64-nonatomic-lo-hi header. Per a nit from Andy Shevchenko, the include list is also made alphabetical. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko

[PATCH v17 1/7] iomap: Use non-raw io functions for io{read|write}XXbe

Fix an asymmetry in the io{read|write}XXbe functions in that the big-endian variants make use of the raw io accessors while the little-endian variants use the regular accessors. Some architectures implement barriers to order against both spinlocks and DMA accesses and for these case, the

[PATCH v2] fscrypt: add Speck128/256 support

fscrypt currently only supports AES encryption. However, many low-end mobile devices have older CPUs that don't have AES instructions, e.g. the ARMv8 Cryptography Extensions. Currently, user data on such devices is not encrypted at rest because AES is too slow, even when the NEON bit-sliced

Re: [PATCH 03/18] docs: */index.rst: Add newer documents to their respective index.rst

On Mon, May 07, 2018 at 06:35:39AM -0300, Mauro Carvalho Chehab wrote: > A number of new docs were added, but they're currently not on > the index.rst from the session they're supposed to be, causing > Sphinx warnings. > > Add them. > > Signed-off-by: Mauro Carvalho Chehab