Hi Rick,
Minor comment below.
On 18 May 2017 at 03:59, Rick Altherr wrote:
> When a hw_random device's quality is non-zero, it will automatically be
> used to fill the kernel's entropy pool. Since timeriomem_rng is used by
> many different devices, the quality needs to be
On Fri, Apr 28, 2017 at 06:11:55PM +0200, Sabrina Dubroca wrote:
> The current aesni AES-GCM implementation only offers support for
> rfc4106(gcm(aes)). This makes some things a little bit simpler
> (handling of associated data and authentication tag), but it means
> that non-IPsec users of
On Wed, Apr 26, 2017 at 05:11:32PM +0100, Ard Biesheuvel wrote:
> Replace the inline asm which exports struct offsets as ELF symbols
> with proper const variables exposing the same values. This works
> around an issue with Clang which does not interpret the "i" (or "I")
> constraints in the same
On Tue, Apr 25, 2017 at 04:26:34PM +0300, Horia Geantă wrote:
> This patch set adds support for the second and third RSA private key
> representations and extends caampkc to use the fastest key when all related
> components are present in the private key.
>
> Additionally a rsa tcrypt test has
On Tue, Apr 25, 2017 at 08:59:44AM -0500, Gary R Hook wrote:
> CC: # 4.9.x+
>
> Signed-off-by: Gary R Hook
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key:
On Tue, Apr 25, 2017 at 12:18:54PM +0300, Dan Carpenter wrote:
> We recently added some new locking but missed the unlocks on these
> error paths in sha512_ctx_mgr_submit().
>
> Fixes: c459bd7beda0 ("crypto: sha512-mb - Protect sha512 mb ctx mgr access")
> Signed-off-by: Dan Carpenter
On Tue, Apr 25, 2017 at 11:25:40AM +0300, Gilad Ben-Yossef wrote:
> The tcrypt AEAD cycles speed tests disables irqs during the test, which is
> broken at the very least since commit
> '1425d2d17f7309c6 ("crypto: tcrypt - Fix AEAD speed tests")'
> adds a wait for completion as part of the test and
On Thu, May 11, 2017 at 02:53:43PM +0300, Gilad Ben-Yossef wrote:
> drbg_kcapi_sym_ctr() was using wait_for_completion_interruptible() to
> wait for completion of async crypto op but if a signal occurs it
> may return before DMA ops of HW crypto provider finish, thus
> corrupting the output
On Mon, Apr 24, 2017 at 04:16:21PM +0200, Corentin Labbe wrote:
> Many HMAC users directly use directly 0x36/0x5c values.
> It's better with crypto to use a name instead of directly some crypto
> constant.
>
> This patch simply add HMAC_IPAD_VALUE/HMAC_OPAD_VALUE defines.
>
> Signed-off-by:
From: Logan Gunthorpe
Date: Wed, 17 May 2017 21:33:22 -0600
>
>
> On 17/05/17 09:26 PM, Herbert Xu wrote:
>> On Thu, May 18, 2017 at 11:25:06AM +0800, Herbert Xu wrote:
>>> On Fri, Apr 28, 2017 at 11:02:40AM -0600, Logan Gunthorpe wrote:
* Cleaned up the formatting of
On Tue, Apr 25, 2017 at 04:26:35PM +0300, Horia Geantă wrote:
> From: Radu Alexe
>
> Signed-off-by: Radu Alexe
> Signed-off-by: Tudor Ambarus
> Signed-off-by: Horia Geantă
I think it's time to stop
On Thu, May 18, 2017 at 11:25:06AM +0800, Herbert Xu wrote:
> On Fri, Apr 28, 2017 at 11:02:40AM -0600, Logan Gunthorpe wrote:
> > * Cleaned up the formatting of ablkcipher_get arguments so it complies
> > with kernel style
> > * The offset in ablkcipher_get sould be added to the source, not the
On Fri, Apr 28, 2017 at 11:02:40AM -0600, Logan Gunthorpe wrote:
> * Cleaned up the formatting of ablkcipher_get arguments so it complies
> with kernel style
> * The offset in ablkcipher_get sould be added to the source, not the
> destination. We rename it to soffset for clarity.
> * dst++
When a hw_random device's quality is non-zero, it will automatically be
used to fill the kernel's entropy pool. Since timeriomem_rng is used by
many different devices, the quality needs to be provided by platform
data or device tree.
Signed-off-by: Rick Altherr
---
Signed-off-by: Rick Altherr
---
Documentation/devicetree/bindings/rng/timeriomem_rng.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/rng/timeriomem_rng.txt
b/Documentation/devicetree/bindings/rng/timeriomem_rng.txt
index
On Wed, May 17, 2017 at 03:44:27PM -0500, Josh Poimboeuf wrote:
> On Tue, May 16, 2017 at 09:03:08PM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > When using the "aes-asm" implementation of AES (*not* the AES-NI
> > implementation) on an x86_64, v4.12-rc1 kernel
On Thu, Apr 27, 2017 at 8:24 AM, Antoine Tenart
wrote:
> The Inside Secure Safexcel cryptographic engine is found on some Marvell
> SoCs (7k/8k). Document the bindings used by its driver.
>
> Signed-off-by: Antoine Tenart
>
On Tue, May 16, 2017 at 09:03:08PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> When using the "aes-asm" implementation of AES (*not* the AES-NI
> implementation) on an x86_64, v4.12-rc1 kernel with lockdep enabled, the
> following warning was reported, along with a
El Wed, Apr 26, 2017 at 05:11:32PM +0100 Ard Biesheuvel ha dit:
> Replace the inline asm which exports struct offsets as ELF symbols
> with proper const variables exposing the same values. This works
> around an issue with Clang which does not interpret the "i" (or "I")
> constraints in the same
If the user provides a NULL private key, the kernel will
generate it and further use it for dh.
Signed-off-by: Tudor Ambarus
---
crypto/dh.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/crypto/dh.c b/crypto/dh.c
index 87e3542..7b4ac5b
The test considers a party that already has a private-public
key pair and a party that provides a NULL key. The kernel will
generate the private-public key pair for the latter, computes
the shared secret on both ends and verifies it it's the same.
The explicit private-public key pairs were copied
If the user provides a NULL ecc private key, the kernel will
generate it and further use it for ecdh.
Signed-off-by: Tudor Ambarus
---
crypto/ecdh.c | 4
1 file changed, 4 insertions(+)
diff --git a/crypto/ecdh.c b/crypto/ecdh.c
index 63ca337..f28f5b5 100644
Add support for generating ecc private keys.
Generation of ecc private keys is helpful in a user-space to kernel
ecdh offload because the keys are not revealed to user-space. Private
key generation is also helpful to implement forward secrecy.
Signed-off-by: Tudor Ambarus
Hi,
This is an RFC to discuss how to support private key generation for dh and ecdh.
This is helpful in a user-space to kernel (ec)dh offload because the keys are
generated in kernel and never revealed to user-space.
Private key generation is also helpful to implement forward secrecy.
A
crypto_kpp_maxsize() returns minimum length for output buffer
or error code if key hasn't been set.
Signed-off-by: Tudor Ambarus
---
crypto/testmgr.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 87a4abd..0bf9a00
Signed-off-by: Tudor Ambarus
---
crypto/rsa.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/crypto/rsa.c b/crypto/rsa.c
index 4c280b6..a80f76d 100644
--- a/crypto/rsa.c
+++ b/crypto/rsa.c
@@ -279,6 +279,9 @@ static int
crypto_akcipher_maxsize() returns minimum length for output buffer
or error code if key hasn't been set.
Signed-off-by: Tudor Ambarus
---
crypto/asymmetric_keys/public_key.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/crypto/asymmetric_keys/public_key.c
setkey can be called multiple times during the existence
of the transformation object. Free the old MPI key if any.
Signed-off-by: Tudor Ambarus
---
crypto/dh.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/crypto/dh.c b/crypto/dh.c
index 325a5dd..b55b03d
crypto_akcipher_maxsize() returns minimum length for output buffer
or error code if key hasn't been set.
Signed-off-by: Tudor Ambarus
---
crypto/testmgr.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index
Signed-off-by: Tudor Ambarus
---
crypto/ecc.c | 8 +++-
crypto/ecc.h | 13 +++--
crypto/ecdh.c | 11 +--
3 files changed, 11 insertions(+), 21 deletions(-)
diff --git a/crypto/ecc.c b/crypto/ecc.c
index 414c78a..69b4cc4 100644
---
The function should return minimum size for output buffer
or error code if key hasn't been set.
Signed-off-by: Tudor Ambarus
---
crypto/ecdh.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/crypto/ecdh.c b/crypto/ecdh.c
index
Rename ecdh_make_pub_key() to ecc_make_pub_key().
This function might as well be used by ecdsa.
Signed-off-by: Tudor Ambarus
---
crypto/ecc.c | 4 ++--
crypto/ecc.h | 4 ++--
crypto/ecdh.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git
The function should return minimum size for output buffer
or error code if key hasn't been set.
Signed-off-by: Tudor Ambarus
---
crypto/dh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/dh.c b/crypto/dh.c
index 7cec0498..325a5dd 100644
Hi,
These are various fixes that I made while reading kpp and akcipher
implementations.
For KEYS there is only one patch. It checks the return value of
crypto_akcipher_maxsize().
Changes in v2:
- squash the patches that removed the unnecessary casts
- add the last five patches
v1 can be
While here, add missing argument description (ndigits).
Signed-off-by: Tudor Ambarus
---
crypto/dh.c | 4 ++--
crypto/dh_helper.c| 4 ++--
crypto/ecc.h | 8 +---
crypto/ecdh.c | 4 ++--
crypto/ecdh_helper.c | 4 ++--
ecc software implementation works with chunks of u64 data. There were some
unnecessary casts to u8 and then back to u64 for the ecc keys. This patch
removes the unnecessary casts.
Signed-off-by: Tudor Ambarus
---
crypto/ecc.c | 28 +---
The test considers a party that already has a private-public
key pair and a party that provides a NULL key. The kernel will
generate the private-public key pair for the latter, computes
the shared secret on both ends and verifies it it's the same.
The explicit private-public key pairs were copied
If the user provides a NULL ecc private key, the kernel will
generate it and further use it for ecdh.
Signed-off-by: Tudor Ambarus
---
crypto/ecdh.c | 4
1 file changed, 4 insertions(+)
diff --git a/crypto/ecdh.c b/crypto/ecdh.c
index 63ca337..f28f5b5 100644
If the user provides a NULL private key, the kernel will
generate it and further use it for dh.
Signed-off-by: Tudor Ambarus
---
crypto/dh.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/crypto/dh.c b/crypto/dh.c
index 87e3542..33df165
Hi,
This is an RFC to discuss how to support private key generation for dh and
ecdh.
This is helpful in a user-space to kernel (ec)dh offload because the keys
are generated in kernel and never revealed to user-space.
Private key generation is also helpful to implement forward secrecy.
A
Add support for generating ecc private keys.
Generation of ecc private keys is helpful in a user-space to kernel
ecdh offload because the keys are not revealed to user-space. Private
key generation is also helpful to implement forward secrecy.
Signed-off-by: Tudor Ambarus
41 matches
Mail list logo