[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOq732LxkcSbk93ofENxL-53SFRQEtK7PcLF9LDLYmctX9W7cA@mail.gmail.com>
Date: Tue, 23 Feb 2016 01:01:50 +0100
From: Andrew Zaborowski <balrogg@...glemail.com>
To: David Howells <dhowells@...hat.com>
Cc: Tadeusz Struk <tadeusz.struk@...el.com>, keyrings@...r.kernel.org,
linux-security-module@...r.kernel.org, zohar@...ux.vnet.ibm.com,
linux-kernel@...r.kernel.org,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer
Hi,
On 22 February 2016 at 23:28, David Howells <dhowells@...hat.com> wrote:
> Tadeusz Struk <tadeusz.struk@...el.com> 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 pass the hash param as a separate template param,
>> e.g the public_key would allocate "pkcs1pad(rsa, sha1)"?
>
> Ummm... Possibly. Is that how it's used?
Currently it only does the padding and doesn't care about the hash.
The input is expected to be the entire DigestInfo struct.
AIUI Tadeusz is proposing adding the hashing as a new feature. Note
though that the hash paremeter won't make sense for the encrypt,
decrypt or verify operations.
Also note that TLS 1.0 uses the padding to sign data that is not a
DigestInfo structure and even for 1.2 there are situations where
you'll be hashing the data yourself over some time and then you'll
want the algorithm to only do the padding and RSA signing.
Cheers
Powered by blists - more mailing lists