Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1340091 > unrolled thread

Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer Andrew Zaborowski <balrogg@googlemail.com> - 2016-02-23 01:10 +0100
    Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer David Howells <dhowells@redhat.com> - 2016-02-23 12:00 +0100
      Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer Andrew Zaborowski <balrogg@googlemail.com> - 2016-02-23 12:30 +0100
        Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer David Howells <dhowells@redhat.com> - 2016-02-26 12:50 +0100

#1340091 — 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@redhat.com> wrote:
> Tadeusz Struk <tadeusz.struk@intel.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

[toc] | [next] | [standalone]

#1340529

Andrew Zaborowski <balrogg@googlemail.com> wrote:

> 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.

The hash parameter is necessary for the verify operation.  From my
perspective, I want a verify operation that takes the signature, the message
hash and the hash name and gives me back an error code.

David

[toc] | [prev] | [next] | [standalone]

#1340555

Hi David,

On 23 February 2016 at 11:55, David Howells <dhowells@redhat.com> wrote:
> Andrew Zaborowski <balrogg@googlemail.com> wrote:
>
>> 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.
>
> The hash parameter is necessary for the verify operation.  From my
> perspective, I want a verify operation that takes the signature, the message
> hash and the hash name and gives me back an error code.

From the certificates point of view yes, but the akcipher API only has
the four operations each of which has one input buffer and out output
buffer.

Without overhauling akcipher you could modify pkcs1pad so that sign
takes the hash as input, adds the DER struct in front of it to build
the signature, and the verify operation could at most check that the
DER string matches the hash type and return the hash.  But I think
RFC2437 suggests that you rather compare the signatures, not the
hashes.

Cheers

[toc] | [prev] | [next] | [standalone]

#1344193

Andrew Zaborowski <balrogg@googlemail.com> wrote:

> Without overhauling akcipher you could modify pkcs1pad so that sign
> takes the hash as input, adds the DER struct in front of it to build
> the signature, and the verify operation could at most check that the
> DER string matches the hash type and return the hash.  But I think
> RFC2437 suggests that you rather compare the signatures, not the
> hashes.

Whilst that is true about what RFC2437 shows, I wonder how strict it wants to
be about that rather than it just being a convenient way of describing the
algorithm.

The advantage of doing it the way the RFC suggests is that you get to use the
EMSA-PKCS1-V1_5-ENCODE operation twice, thereby saving code and only having
one place for bugs to occur instead of two - but you can argue this either
way.

That said, I would be okay with it returning just the message hash with the
padding stripped off, providing the padding is validated in the crypto layer,
if that's necessary.

David

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web