All of lore.kernel.org
 help / color / mirror / Atom feed
* pkcs1pad_verify_complete: decoding missing?
@ 2016-05-09 10:24 Stephan Mueller
  2016-05-09 18:15 ` Tadeusz Struk
  0 siblings, 1 reply; 8+ messages in thread
From: Stephan Mueller @ 2016-05-09 10:24 UTC (permalink / raw)
  To: linux-crypto

Hi,

I am experimenting with pkcs1pad(rsa-generic) signature verify. The following 
numbers shall serve as examples -- using other valid signatures, similar 
results are visible.

All signatures are correct.

The result of the signature verify operation is the following byte stream:

3021300906052b0e03021a05000414ba3bc9c6fb57dfa3103e5991e8992d4387afa6f2d93e4f478d3cb74138b28cc5d1601f2bc549c2297e5bf76578fbaf5defe617748ac29f825aa974a56b7fdffe21f8d5c6abd7d9050525c60d94a36b3ce7a763af66b1ed501ebd0edd4b686a6bb8afd903c9ab97a60853fa7345fdd28fcc

The hash of the message is:

ba3bc9c6fb57dfa3103e5991e8992d4387afa6f2


The hash of the message is embedded in the data stream returned by the 
signature verify operation.

Looking at the first bytes of the data stream from the signature verify, it 
looks like an ASN.1 sequence.

Looking into the function pkcs1pad_verify_complete, that suspicion is 
confirmed: the padding is removed, but the decoding is not implemented. Shall 
a caller implement the decoding?

If so, what is the purpose of the pkcs1pad implementation when only a part of 
the sig ver is implemented?

Looking into pkcs1pad_sign, I also do not see the BER encoding. Again, shall 
the caller do that?


Ciao
Stephan

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: pkcs1pad_verify_complete: decoding missing?
  2016-05-09 10:24 pkcs1pad_verify_complete: decoding missing? Stephan Mueller
@ 2016-05-09 18:15 ` Tadeusz Struk
  2016-05-09 18:50   ` Stephan Mueller
  0 siblings, 1 reply; 8+ messages in thread
From: Tadeusz Struk @ 2016-05-09 18:15 UTC (permalink / raw)
  To: Stephan Mueller, linux-crypto

Hi Strphan,
On 05/09/2016 03:24 AM, Stephan Mueller wrote:
> Hi,
> 
> I am experimenting with pkcs1pad(rsa-generic) signature verify. The following 
> numbers shall serve as examples -- using other valid signatures, similar 
> results are visible.
> 
> All signatures are correct.
> 
> The result of the signature verify operation is the following byte stream:
> 
> 3021300906052b0e03021a05000414ba3bc9c6fb57dfa3103e5991e8992d4387afa6f2d93e4f478d3cb74138b28cc5d1601f2bc549c2297e5bf76578fbaf5defe617748ac29f825aa974a56b7fdffe21f8d5c6abd7d9050525c60d94a36b3ce7a763af66b1ed501ebd0edd4b686a6bb8afd903c9ab97a60853fa7345fdd28fcc
> 
> The hash of the message is:
> 
> ba3bc9c6fb57dfa3103e5991e8992d4387afa6f2
> 
> 
> The hash of the message is embedded in the data stream returned by the 
> signature verify operation.
> 
> Looking at the first bytes of the data stream from the signature verify, it 
> looks like an ASN.1 sequence.
> 
> Looking into the function pkcs1pad_verify_complete, that suspicion is 
> confirmed: the padding is removed, but the decoding is not implemented. Shall 
> a caller implement the decoding?
> 
> If so, what is the purpose of the pkcs1pad implementation when only a part of 
> the sig ver is implemented?

Verify operation decrypts data provided in src, verifies, if the result has valid
padding and DER wrappings, strips the padding and wrapping and copies
the decrypted message to the dst. If padding or wrappings are not as expected
it returns -EBADMSG.
It is done in
https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/tree/crypto/rsa-pkcs1pad.c#n517
see up to line #550

An example of how it is used can be found here:
https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/tree/crypto/asymmetric_keys/public_key.c#n71

> 
> Looking into pkcs1pad_sign, I also do not see the BER encoding. Again, shall 
> the caller do that?

No, the sign operation prepends the padding and hash wrappings to the message
provided in src, encrypts the whole thing and returns the cipher text in the dst,
which is the opposite to what is done in verify.
Thanks,
-- 
TS

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: pkcs1pad_verify_complete: decoding missing?
  2016-05-09 18:15 ` Tadeusz Struk
@ 2016-05-09 18:50   ` Stephan Mueller
  2016-05-09 18:55     ` Tadeusz Struk
  0 siblings, 1 reply; 8+ messages in thread
From: Stephan Mueller @ 2016-05-09 18:50 UTC (permalink / raw)
  To: Tadeusz Struk; +Cc: linux-crypto

Am Montag, 9. Mai 2016, 11:15:04 schrieb Tadeusz Struk:

Hi Tadeusz,

> Hi Strphan,
> 
> On 05/09/2016 03:24 AM, Stephan Mueller wrote:
> > Hi,
> > 
> > I am experimenting with pkcs1pad(rsa-generic) signature verify. The
> > following numbers shall serve as examples -- using other valid
> > signatures, similar results are visible.
> > 
> > All signatures are correct.
> > 
> > The result of the signature verify operation is the following byte stream:
> > 
> > 3021300906052b0e03021a05000414ba3bc9c6fb57dfa3103e5991e8992d4387afa6f2d93e
> > 4f478d3cb74138b28cc5d1601f2bc549c2297e5bf76578fbaf5defe617748ac29f825aa974
> > a56b7fdffe21f8d5c6abd7d9050525c60d94a36b3ce7a763af66b1ed501ebd0edd4b686a6b
> > b8afd903c9ab97a60853fa7345fdd28fcc
> > 
> > The hash of the message is:
> > 
> > ba3bc9c6fb57dfa3103e5991e8992d4387afa6f2
> > 
> > 
> > The hash of the message is embedded in the data stream returned by the
> > signature verify operation.
> > 
> > Looking at the first bytes of the data stream from the signature verify,
> > it
> > looks like an ASN.1 sequence.
> > 
> > Looking into the function pkcs1pad_verify_complete, that suspicion is
> > confirmed: the padding is removed, but the decoding is not implemented.
> > Shall a caller implement the decoding?
> > 
> > If so, what is the purpose of the pkcs1pad implementation when only a part
> > of the sig ver is implemented?
> 
> Verify operation decrypts data provided in src, verifies, if the result has
> valid padding and DER wrappings, strips the padding and wrapping and copies
> the decrypted message to the dst. If padding or wrappings are not as
> expected it returns -EBADMSG.
> It is done in
> https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/tree/
> crypto/rsa-pkcs1pad.c#n517 see up to line #550

I think I see my error: pkcs1pad(rsa,HASH) -- I missed the hash part that 
activates the decoding. Thank you for the pointer.

Once I completed my testing, I think I need to beef up the documentation a 
bit.
> 
> An example of how it is used can be found here:
> https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/tree/
> crypto/asymmetric_keys/public_key.c#n71
> > Looking into pkcs1pad_sign, I also do not see the BER encoding. Again,
> > shall the caller do that?
> 
> No, the sign operation prepends the padding and hash wrappings to the
> message provided in src, encrypts the whole thing and returns the cipher
> text in the dst, which is the opposite to what is done in verify.
> Thanks,


Ciao
Stephan

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: pkcs1pad_verify_complete: decoding missing?
  2016-05-09 18:50   ` Stephan Mueller
@ 2016-05-09 18:55     ` Tadeusz Struk
  2016-05-09 19:02       ` Stephan Mueller
  0 siblings, 1 reply; 8+ messages in thread
From: Tadeusz Struk @ 2016-05-09 18:55 UTC (permalink / raw)
  To: Stephan Mueller; +Cc: linux-crypto

On 05/09/2016 11:50 AM, Stephan Mueller wrote:
> I think I see my error: pkcs1pad(rsa,HASH) -- I missed the hash part that 
> activates the decoding. Thank you for the pointer.
> 
> Once I completed my testing, I think I need to beef up the documentation a 
> bit.

Right, this can work in two modes. The pkcs1pad(rsa) only strips the padding.
Thanks,
-- 
TS

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: pkcs1pad_verify_complete: decoding missing?
  2016-05-09 18:55     ` Tadeusz Struk
@ 2016-05-09 19:02       ` Stephan Mueller
  2016-05-09 19:17         ` Tadeusz Struk
  0 siblings, 1 reply; 8+ messages in thread
From: Stephan Mueller @ 2016-05-09 19:02 UTC (permalink / raw)
  To: Tadeusz Struk; +Cc: linux-crypto

Am Montag, 9. Mai 2016, 11:55:58 schrieb Tadeusz Struk:

Hi Tadeusz,

> On 05/09/2016 11:50 AM, Stephan Mueller wrote:
> > I think I see my error: pkcs1pad(rsa,HASH) -- I missed the hash part that
> > activates the decoding. Thank you for the pointer.
> > 
> > Once I completed my testing, I think I need to beef up the documentation a
> > bit.
> 
> Right, this can work in two modes. The pkcs1pad(rsa) only strips the
> padding. Thanks,

One followup: is the final memcmp() between the decrypted hash and the hash of 
the message implemented in the RSA verify code path? At least I do not see it 
right away.


Ciao
Stephan

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: pkcs1pad_verify_complete: decoding missing?
  2016-05-09 19:02       ` Stephan Mueller
@ 2016-05-09 19:17         ` Tadeusz Struk
  2016-05-09 19:24           ` Stephan Mueller
  0 siblings, 1 reply; 8+ messages in thread
From: Tadeusz Struk @ 2016-05-09 19:17 UTC (permalink / raw)
  To: Stephan Mueller; +Cc: linux-crypto

On 05/09/2016 12:02 PM, Stephan Mueller wrote:
> One followup: is the final memcmp() between the decrypted hash and the hash of 
> the message implemented in the RSA verify code path? At least I do not see it 
> right away.

It's in line #549
-- 
TS

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: pkcs1pad_verify_complete: decoding missing?
  2016-05-09 19:17         ` Tadeusz Struk
@ 2016-05-09 19:24           ` Stephan Mueller
  2016-05-09 19:31             ` Tadeusz Struk
  0 siblings, 1 reply; 8+ messages in thread
From: Stephan Mueller @ 2016-05-09 19:24 UTC (permalink / raw)
  To: Tadeusz Struk; +Cc: linux-crypto

Am Montag, 9. Mai 2016, 12:17:21 schrieb Tadeusz Struk:

Hi Tadeusz,

> On 05/09/2016 12:02 PM, Stephan Mueller wrote:
> > One followup: is the final memcmp() between the decrypted hash and the
> > hash of the message implemented in the RSA verify code path? At least I
> > do not see it right away.
> 
> It's in line #549

Do you rather mean line 535? If yes, how would I provide the message digest to 
the verify function?

Please note that at the main driver of my question is 
https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/tree/crypto/asymmetric_keys/public_key.c#n143
where the caller implements the memcmp().

Thank you.


Ciao
Stephan

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: pkcs1pad_verify_complete: decoding missing?
  2016-05-09 19:24           ` Stephan Mueller
@ 2016-05-09 19:31             ` Tadeusz Struk
  0 siblings, 0 replies; 8+ messages in thread
From: Tadeusz Struk @ 2016-05-09 19:31 UTC (permalink / raw)
  To: Stephan Mueller; +Cc: linux-crypto

On 05/09/2016 12:24 PM, Stephan Mueller wrote:
> Am Montag, 9. Mai 2016, 12:17:21 schrieb Tadeusz Struk:
> 
> Hi Tadeusz,
> 
>> On 05/09/2016 12:02 PM, Stephan Mueller wrote:
>>> One followup: is the final memcmp() between the decrypted hash and the
>>> hash of the message implemented in the RSA verify code path? At least I
>>> do not see it right away.
>>
>> It's in line #549
> 
> Do you rather mean line 535? If yes, how would I provide the message digest to 
> the verify function?
> 
> Please note that at the main driver of my question is 
> https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/tree/crypto/asymmetric_keys/public_key.c#n143
> where the caller implements the memcmp().
> 

Sorry, I misread your question. Yes, the final data comparison needs to be done by the user.
We don't have the original msg (or its digest) in the context of the verify operation.
The only thing we are given is the encrypted message (and the key to decrypt it).
And you are right, in this case it is done in:
https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/tree/crypto/asymmetric_keys/public_key.c#n143 
Thanks,
-- 
TS

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2016-05-09 19:32 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-09 10:24 pkcs1pad_verify_complete: decoding missing? Stephan Mueller
2016-05-09 18:15 ` Tadeusz Struk
2016-05-09 18:50   ` Stephan Mueller
2016-05-09 18:55     ` Tadeusz Struk
2016-05-09 19:02       ` Stephan Mueller
2016-05-09 19:17         ` Tadeusz Struk
2016-05-09 19:24           ` Stephan Mueller
2016-05-09 19:31             ` Tadeusz Struk

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.