This patch adds the function scatterwalk_sg_copychunks which writes
a chunk of data from a scatterwalk to another scatterwalk.
It will be used by caam driver to remove the leading zeros of RSA's
algorithm output.
Signed-off-by: Tudor Ambarus
---
crypto/scatterwalk.c | 26
Used in caam driver. Export the symbol since the caam driver
can be built as a module.
Signed-off-by: Tudor Ambarus
---
crypto/scatterwalk.c | 5 +++--
include/crypto/scatterwalk.h | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/crypto/scatterwalk.c b/crypto/scatte
Add RSA support to caam driver.
Coauthored-by: Yashpal Dutta
Signed-off-by: Tudor Ambarus
---
drivers/crypto/caam/Kconfig | 13 +
drivers/crypto/caam/Makefile | 13 +
drivers/crypto/caam/caam_rsaprivkey.asn1 | 11 +
drivers/crypto/caam/caam_rsapubkey.asn1 | 4 +
Am Montag, 22. Februar 2016, 11:16:17 schrieb Tudor Ambarus:
Hi Tudor,
>Add RSA support to caam driver.
>
>Coauthored-by: Yashpal Dutta
>
>Signed-off-by: Tudor Ambarus
>---
> drivers/crypto/caam/Kconfig | 13 +
> drivers/crypto/caam/Makefile | 13 +
> drivers/crypto/caa
Hi Stephan,
> -Original Message-
> >+++ b/drivers/crypto/caam/caam_rsaprivkey.asn1
> >@@ -0,0 +1,11 @@
> >+RsaPrivKey ::= SEQUENCE {
> >+version INTEGER,
> >+n INTEGER ({ caam_rsa_get_n }),
> >+e INTEGER ({ caam_rsa_get_e }),
> >+d
On 02/19/2016 09:18 AM, David Howells wrote:
> Move the RSA EMSA-PKCS1-v1_5 encoding from the asymmetric-key public_key
> subtype to the rsa crypto module. This means that the public_key subtype
> no longer has any dependencies on public key type.
>
> To make this work, I've made the following ch
On 02/19/2016 09:18 AM, David Howells wrote:
>
> Here's a set of patches that cleans up the public key handling in the
> asymmetric key functions:
>
> (1) - (3) These are Tadeusz's RSA akcipher conversion.
Thanks for taking this David.
>
> (4) This removes all knowledge of RSA from the softw
Tadeusz Struk wrote:
> I wonder if this should be merged with the crypto/rsa-pkcs1pad.c template
> that we already have. Looks like the two do the same padding now.
> Should we merge then and pass the hash param as a separate template param,
> e.g the public_key would allocate "pkcs1pad(rsa, sha1
On 02/22/2016 02:28 PM, David Howells wrote:
> Tadeusz Struk wrote:
>
>> I wonder if this should be merged with the crypto/rsa-pkcs1pad.c template
>> that we already have. Looks like the two do the same padding now.
>> Should we merge then and pass the hash param as a separate template param,
>>
Hi,
On 22 February 2016 at 23:28, David Howells wrote:
> Tadeusz Struk wrote:
>
>> I wonder if this should be merged with the crypto/rsa-pkcs1pad.c template
>> that we already have. Looks like the two do the same padding now.
I think that'd be a good thing to do.
>> Should we merge then and pa
Hey all,
I just upgraded from 3.14.60 to 3.14.61, and when I try to mount my
luks-encrypted disk drives, I get an error saying the mapping couldn't be
created and to check whether aes-xts-plain64 is compiled into the kernel;
it is:
[preed@underworld linux-3.14.61]$ grep CRYPTO_AES .config
CONFIG
Am Montag, 22. Februar 2016, 22:17:55 schrieb J. Paul Reed:
Hi J,
> Hey all,
>
> I just upgraded from 3.14.60 to 3.14.61, and when I try to mount my
> luks-encrypted disk drives, I get an error saying the mapping couldn't be
> created and to check whether aes-xts-plain64 is compiled into the ker
12 matches
Mail list logo
