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