On Thu, Jun 04, 2015 at 05:34:39PM +0200, Marek Vasut wrote:
Is this really a valid way to go about crypto -- introduce all kinds
of obscure nuances into the API which are driver specific at best ?
So what do you suggest?
--
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page:
On Thu, Jun 04, 2015 at 03:15:19PM -0700, Tadeusz Struk wrote:
Hi Herbert,
On 05/22/2015 01:30 AM, Herbert Xu wrote:
This patch makes use of the new AEAD interface which uses a single
SG list instead of separate lists for the AD and plain text.
The fact the src and assoc point to the same
On Tue, May 19, 2015 at 10:18:05PM +0800, Herbert Xu wrote:
On Tue, May 19, 2015 at 09:50:28AM -0400, Theodore Ts'o wrote:
Finally, this is only going to block *once*, when the system is
initially botting up. Why is it so important that we get the
asynchronous nature of this right, and
Hi Herbert,
On 06/03/2015 11:49 PM, Herbert Xu wrote:
Because the caller is going to be allocating memory for the output,
we need to provide a way for them to know how much memory to
allocate.
This presumably will depend on the key size.
So something like
int (*maxsize)(struct
Herbert,
I just realised that this doesn't quite work. The key is shared
by all users of the tfm, yet in your case you need it to be local
I agree, as Poly1305 uses a different key for each tag the current
approach doesn't work.
I think the simplest solution is to make the key the beginning
On Thursday, June 04, 2015 at 05:24:00 AM, Herbert Xu wrote:
On Wed, Jun 03, 2015 at 03:02:13PM -0500, Jay Monkman wrote:
That would be one use, but a more likely use would be to prevent
access to the keys. A system could write keys to the key slots in
the bootloader or in a TrustZone
Vinod,
On 06/02/2015 03:55 PM, Vinod Koul wrote:
On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote:
On 05/29/2015 01:18 PM, Vinod Koul wrote:
On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote:
On Fri, May 29, 2015 at 11:33 AM, Vinod Koul vinod.k...@intel.com
Hi Stephan
On 06/03/2015 05:15 PM, Stephan Mueller wrote:
May I ask that the outbuf_enc is memcmp()ed with an expected value? This
check
is required for FIPS 140-2 compliance. Without that memcmp, FIPS 140-2
validations will not be successful.
Sure, I will do that. I wasn't aware that this
On Wed, Jun 03, 2015 at 03:44:08PM -0700, Tadeusz Struk wrote:
+/**
+ * struct akcipher_alg - generic public key algorithm
+ *
+ * @sign:Function performs a sign operation as defined by public key
+ * algorithm
+ * @verify: Function performs a sign operation as defined by
On Wed, Jun 03, 2015 at 03:44:14PM -0700, Tadeusz Struk wrote:
Change the existing rsa and public key code to integrate it
with the new Public Key Encryption API.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
I'd like to see this split into multiple patches. First of all
the new
On Tue, Jun 02, 2015 at 03:22:10PM -0400, Dan Streetman wrote:
Reduce the nx-842 pSeries driver minimum buffer size from 128 to 8.
Also replace the single use of IO_BUFFER_ALIGN macro with the standard
and correct DDE_BUFFER_ALIGN.
The hw sometimes rejects buffers that contain padding past
On Thu, Jun 04, 2015 at 12:01:20AM +0900, Masanari Iida wrote:
This patch fix some spelling typo found in crypto-API.tmpl
Signed-off-by: Masanari Iida standby2...@gmail.com
Both applied.
--
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key:
On Mon, Jun 01, 2015 at 01:43:55PM +0200, Martin Willi wrote:
This is a first version of a patch series implementing the ChaCha20-Poly1305
AEAD construction defined in RFC7539. It is based on the current cryptodev
tree.
The first two patches implement the ChaCha20 cipher, the second two the
On Mon, Jun 01, 2015 at 01:43:58PM +0200, Martin Willi wrote:
+static int poly1305_setkey(struct crypto_shash *tfm,
+const u8 *key, unsigned int keylen)
+{
+ struct poly1305_ctx *ctx = crypto_shash_ctx(tfm);
+
+ if (keylen != POLY1305_KEY_SIZE) {
+
14 matches
Mail list logo
