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

[David Howells]

Andrew Zaborowski  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
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Andrew Zaborowski]

Hi David,

On 23 February 2016 at 11:55, David Howells  wrote:
> Andrew Zaborowski  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
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

Andrew Zaborowski  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
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

Tadeusz Struk  wrote:

> > Ummm...  Possibly.  Is that how it's used?
> > 
> > warthog>git grep pkcs1pad -- Documentation
> > warthog1>
> 
> Yes, no docs. Sorry.

Can I suggest you at least stick a quick usage summary in the banner comment
at the top of the file?

> > Anyway, the problem I have with this is that I want to get that knowledge
> > out of the asymmetric key in-software public key subtype.  It knows "rsa",
> > "dsa", "ecdsa", ... because that's all the OIDs tell it.
> 
> Rigth, for now the public_key would need to build the full algorithm string as
> follows:
> 
> vsprintf(name, "pkcs1pad(%s, %s)", pkey_algo_name[sig->pkey_algo],
>  hash_algo_name[sig->pkey_hash_algo]);

Does this apply to anything other than RSA?

> Do you plan to add more padding schemes later? 

No plans to, but one never knows.  I'm *assuming* that OID_rsaEncryption and
OID_sha256WithRSAEncryption, for example, must implicitly specify the padding
scheme (RFC4055 suggests I'm right in this assumption).

We might have to suppose RSASSA-SSP at some point.

> Yes, I can start woring on a subsequent patch based on your changes in
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-rsa
> Is that ok with you?

Sure.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Andrew Zaborowski]

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 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
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tadeusz Struk]

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,
>> e.g the public_key would allocate "pkcs1pad(rsa, sha1)"?
> 
> Ummm...  Possibly.  Is that how it's used?
> 
>   warthog>git grep pkcs1pad -- Documentation
>   warthog1>

Yes, no docs. Sorry.

> 
> Anyway, the problem I have with this is that I want to get that knowledge out
> of the asymmetric key in-software public key subtype.  It knows "rsa", "dsa",
> "ecdsa", ... because that's all the OIDs tell it.

Rigth, for now the public_key would need to build the full algorithm string as
follows:

vsprintf(name, "pkcs1pad(%s, %s)", pkey_algo_name[sig->pkey_algo],
 hash_algo_name[sig->pkey_hash_algo]);

Do you plan to add more padding schemes later? 

> 
> I guess if I have to, I can stoop to converting "rsa" to "pkcs1pad(rsa, 
> sha1)".
> 
> Can you do me a really quick merge?  -rc5 is already out, and I want to get it
> to James pronto - plus I have things that are pending on this change being
> made.

Yes, I can start woring on a subsequent patch based on your changes in
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-rsa
Is that ok with you?

> 
> Oh - and how does the padding template find the algorithm DER encoding string
> to use?  I have wondered whether it should be stored in with the hash
> algorithm, but it probably makes more sense to keep it with the rsa module.

We can put everything into the crypto/rsa-pkcs1pad.c
This is where all the padding logic should be, I think.
Thanks,
-- 
TS
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

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)"?

Ummm...  Possibly.  Is that how it's used?

warthog>git grep pkcs1pad -- Documentation
warthog1>

Anyway, the problem I have with this is that I want to get that knowledge out
of the asymmetric key in-software public key subtype.  It knows "rsa", "dsa",
"ecdsa", ... because that's all the OIDs tell it.

I guess if I have to, I can stoop to converting "rsa" to "pkcs1pad(rsa, sha1)".

Can you do me a really quick merge?  -rc5 is already out, and I want to get it
to James pronto - plus I have things that are pending on this change being
made.

Oh - and how does the padding template find the algorithm DER encoding string
to use?  I have wondered whether it should be stored in with the hash
algorithm, but it probably makes more sense to keep it with the rsa module.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html