Re: [RFC 0/5] add integrity and security to TPM2 transactions

On Sat, 2018-03-10 at 10:29 -0800, James Bottomley wrote: > OK, you might want to wait for v3 then. I've got it working with > sealed (trusted) keys, well except for a problem with the trusted keys > API that means we can't protect the password for policy based keys. I > think the API is finally

Re: [PATCH v3 1/6] tpm-buf: create new functions for handling TPM buffers

On Mon, 2018-03-12 at 09:00 -0700, J Freyensee wrote: > > > > +int tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal) > > +{ > > + int rc; > > + > > + rc = __tpm_buf_init(buf); > > > Assuming that functions like tpm_buf_init() are the top-level API > being defined in this patch,

Re: [tpmdd-devel] in-kernel user of ecdsa

On Mon, 2018-03-12 at 19:07 +0200, Tudor Ambarus wrote: > Hi, > > Would you consider using ECDSA in the kernel module signing facility? > When compared with RSA, ECDSA has shorter keys, the key generation > process is faster, the sign operation is faster, but the verify > operation is slower than

Re: [PATCH 2/2] crypto: talitos: Delete an error message for a failed memory allocation in talitos_edesc_alloc()

Le 12/03/2018 à 14:32, SF Markus Elfring a écrit : From: Markus Elfring Date: Mon, 12 Mar 2018 14:18:23 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by:

Re: [PATCH v10 crypto 07/11] chtls: Program the TLS Key

On Sat, 10 Mar 2018 00:40:12 +0530 Atul Gupta wrote: > Initialize the space reserved for storing the TLS keys > get and free the location where key is stored for the TLS > connection > Program the tx and rx key as received from user in > struct

Re: what is a replacement for private_AES_set_encrypt_key and AES_encrypt functions

On 12 March 2018 at 14:38, Vitaly Andrianov wrote: > Hello, > > The Texas Instruments keystone2 out-of-tree kernel uses the > private_AES_set_encrypt_key() and > the AES_encrypt() at the crypto HW acceleration driver. > > The "crypto: arm/aes - replace bit-sliced OpenSSL NEON

Re: [PATCH v10 crypto 09/11] chtls: Inline TLS request Tx/Rx

On Sat, 10 Mar 2018 00:40:14 +0530 Atul Gupta wrote: > TLS handler for record transmit and receive. > Create Inline TLS work request and post to FW. > Create Inline TLS record CPLs for hardware > > Signed-off-by: Atul Gupta > --- >

Re: [PATCH 1/2] crypto: talitos: Use common error handling code in talitos_edesc_alloc()

Le 12/03/2018 à 14:31, SF Markus Elfring a écrit : From: Markus Elfring Date: Mon, 12 Mar 2018 14:08:55 +0100 Add jump targets so that an error message and the setting of a specific error code is stored only once at the end of this function. Signed-off-by:

what is a replacement for private_AES_set_encrypt_key and AES_encrypt functions

Hello, The Texas Instruments keystone2 out-of-tree kernel uses the private_AES_set_encrypt_key() and the AES_encrypt() at the crypto HW acceleration driver. The "crypto: arm/aes - replace bit-sliced OpenSSL NEON code" commit removed those functions. Here is a code, which calls the removed

[PATCH 1/2] crypto: talitos: Use common error handling code in talitos_edesc_alloc()

From: Markus Elfring Date: Mon, 12 Mar 2018 14:08:55 +0100 Add jump targets so that an error message and the setting of a specific error code is stored only once at the end of this function. Signed-off-by: Markus Elfring ---

[PATCH 2/2] crypto: talitos: Delete an error message for a failed memory allocation in talitos_edesc_alloc()

From: Markus Elfring Date: Mon, 12 Mar 2018 14:18:23 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

Re: [PATCH v3 0/6] add integrity and security to TPM2 transactions

On Mon, 2018-03-12 at 12:58 +0200, Jarkko Sakkinen wrote: > On Sat, 2018-03-10 at 14:13 -0800, James Bottomley wrote: > > > > By now, everybody knows we have a problem with the TPM2_RS_PW easy > > button on TPM2 in that transactions on the TPM bus can be > > intercepted > > and altered.  The way

Re: [PATCH v3 1/6] tpm-buf: create new functions for handling TPM buffers

+int tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal) +{ + int rc; + + rc = __tpm_buf_init(buf); Assuming that functions like tpm_buf_init() are the top-level API being defined in this patch, shouldn't it check if buf is valid before passing into the internal functions

Re: [PATCH v3 0/6] add integrity and security to TPM2 transactions

On Sat, 2018-03-10 at 14:13 -0800, James Bottomley wrote: > By now, everybody knows we have a problem with the TPM2_RS_PW easy > button on TPM2 in that transactions on the TPM bus can be intercepted > and altered. The way to fix this is to use real sessions for HMAC > capabilities to ensure

Re: [tpmdd-devel] in-kernel user of ecdsa

Am Montag, 12. März 2018, 19:09:18 CET schrieb James Bottomley: Hi James, > On Mon, 2018-03-12 at 19:07 +0200, Tudor Ambarus wrote: > > Hi, > > > > Would you consider using ECDSA in the kernel module signing facility? > > When compared with RSA, ECDSA has shorter keys, the key generation > >

in-kernel user of ecdsa

Hi, Would you consider using ECDSA in the kernel module signing facility? When compared with RSA, ECDSA has shorter keys, the key generation process is faster, the sign operation is faster, but the verify operation is slower than with RSA. Smaller key sizes imply reduced memory footprint and

Re: [tpmdd-devel] in-kernel user of ecdsa

Am Montag, 12. März 2018, 22:55:35 CET schrieb James Bottomley: Hi James, > > ECDSA is not implemented currently in the kernel crypto API. > > an ECDSA signature is produced as a ECDH operation using the DSA > algorithm instead of KDFe, so it's trivial with what we have; signature >

Re: [tpmdd-devel] in-kernel user of ecdsa

On Mon, 2018-03-12 at 20:56 +0100, Stephan Mueller wrote: > Am Montag, 12. März 2018, 19:09:18 CET schrieb James Bottomley: > > Hi James, > > > > > On Mon, 2018-03-12 at 19:07 +0200, Tudor Ambarus wrote: > > > > > > Hi, > > > > > > Would you consider using ECDSA in the kernel module signing >