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


Groups > linux.kernel > #1590291 > unrolled thread

Re: Problem with RSA test from testmgr

Started byCorentin Labbe <clabbe.montjoie@gmail.com>
First post2017-03-01 13:10 +0100
Last post2017-03-02 17:30 +0100
Articles 7 — 3 participants

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: Problem with RSA test from testmgr Corentin Labbe <clabbe.montjoie@gmail.com> - 2017-03-01 13:10 +0100
    Re: Problem with RSA test from testmgr Stephan Müller <smueller@chronox.de> - 2017-03-01 16:10 +0100
      Re: Problem with RSA test from testmgr Corentin Labbe <clabbe.montjoie@gmail.com> - 2017-03-02 07:40 +0100
        Re: Problem with RSA test from testmgr Tadeusz Struk <tadeusz.struk@intel.com> - 2017-03-02 17:40 +0100
    Re: Problem with RSA test from testmgr Tadeusz Struk <tadeusz.struk@intel.com> - 2017-03-02 03:20 +0100
      Re: Problem with RSA test from testmgr Stephan Müller <smueller@chronox.de> - 2017-03-02 07:40 +0100
        Re: Problem with RSA test from testmgr Tadeusz Struk <tadeusz.struk@intel.com> - 2017-03-02 17:30 +0100

#1590291 — Re: Problem with RSA test from testmgr

FromCorentin Labbe <clabbe.montjoie@gmail.com>
Date2017-03-01 13:10 +0100
SubjectRe: Problem with RSA test from testmgr
Message-ID<tgbeW-2ST-5@gated-at.bofh.it>
On Tue, Feb 28, 2017 at 11:35:04PM +0100, Stephan Müller wrote:
> Am Dienstag, 28. Februar 2017, 17:45:53 CET schrieb Corentin Labbe:
> 
> Hi Corentin,
> 
> > On Tue, Feb 28, 2017 at 05:08:35PM +0100, Stephan Müller wrote:
> > > Am Dienstag, 28. Februar 2017, 16:59:53 CET schrieb Corentin Labbe:
> > > 
> > > Hi Corentin,
> > > 
> > > > hello
> > > > 
> > > > I work on the sun8i-ce crypto accelerator and I have some problem with
> > > > the
> > > > RSA part.
> > > > 
> > > > The RSA register fail at the first RSA test (encrypt 512bit) with this
> > > > output: [ 8480.146843] alg: akcipher: encrypt test failed. Invalid
> > > > output
> > > > [ 8480.146871] 00000000: 6e 7c 8a 75 e7 30 80 d1 5e ab 9b db a2 cf ed db
> > > > [ 8480.146897] 00000010: c9 b2 db 43 bd 9a b9 75 27 f3 73 d9 73 b7 81 8c
> > > > [ 8480.146921] 00000020: 49 e8 45 fc 43 44 f5 6d f0 f7 b8 f2 ae 6b ae 49
> > > > [ 8480.146946] 00000030: 1b 8e 50 c6 88 4e 99 09 78 14 f2 5d 99 c3 7f f9
> > > > [ 8480.146995] alg: akcipher: test 1 failed for rsa-sun8i-ce, err=-22
> > > > 
> > > > But with the same parameters (msg, n, e) openssl give me exactly this
> > > > output.
> > > > 
> > > > So what I miss for made it work ?
> > > > In which format testmgr expect the output data ?
> > > 
> > > The output should be simply the binary string from the modular
> > > exponentiation operation.
> > > 
> > > What I am wondering is: the output logged above is not found in the
> > > expected values of testmgr.h. Which input data or test vectors do you
> > > use?
> > > 
> > > Ciao
> > > Stephan
> > 
> > I use the first test from rsa_tv_template in crypto/testmgr.h
> > The test fail on the encrypt operation.
> > 
> > I have put below the openssl program that give me the same output than my
> > hardware accelerator with the same parameters.
> 
> I would think the issue is that the OpenSSL BIGNUM lib has some issues: when 
> calculating m^e mod n, m has to be equal to the key size. The kernel's MPI 
> code handles the case where m is smaller than the key size.
> 
> Note, in your code below, ptext is the 8 bytes from ptext_ex plus trailing 
> zeroes whereas the kernel uses just the 8 bytes.
> 
> It seems that your implementation has the same issue.
> 
> What about the following test: change vector->m to be 64 bytes (i.e. 
> RSA_size(key) in size in testmgr.h and check the output of crypto/rsa.c, 
> openssl's output with the app below and your RSA hardware.

I got the following:

[    1.086228] alg: akcipher: encrypt test failed. Invalid output
[    1.092196] 00000000: 6e 7c 8a 75 e7 30 80 d1 5e ab 9b db a2 cf ed db
[    1.098882] 00000010: c9 b2 db 43 bd 9a b9 75 27 f3 73 d9 73 b7 81 8c
[    1.105524] 00000020: 49 e8 45 fc 43 44 f5 6d f0 f7 b8 f2 ae 6b ae 49
[    1.112090] 00000030: 1b 8e 50 c6 88 4e 99 09 78 14 f2 5d 99 c3 7f f9
[    1.118747] alg: akcipher: test 1 failed for rsa-generic, err=-22
(Exactly the output of my hardare and openssl test)

So the problem is just that my hardware does not handle non-padded data.

Thanks
Regards
Corentin Labbe

[toc] | [next] | [standalone]


#1590395

FromStephan Müller <smueller@chronox.de>
Date2017-03-01 16:10 +0100
Message-ID<tge39-4N8-49@gated-at.bofh.it>
In reply to#1590291
Am Mittwoch, 1. März 2017, 13:04:14 CET schrieb Corentin Labbe:

Hi Corentin,

> 
> I got the following:
> 
> [    1.086228] alg: akcipher: encrypt test failed. Invalid output
> [    1.092196] 00000000: 6e 7c 8a 75 e7 30 80 d1 5e ab 9b db a2 cf ed db
> [    1.098882] 00000010: c9 b2 db 43 bd 9a b9 75 27 f3 73 d9 73 b7 81 8c
> [    1.105524] 00000020: 49 e8 45 fc 43 44 f5 6d f0 f7 b8 f2 ae 6b ae 49
> [    1.112090] 00000030: 1b 8e 50 c6 88 4e 99 09 78 14 f2 5d 99 c3 7f f9
> [    1.118747] alg: akcipher: test 1 failed for rsa-generic, err=-22
> (Exactly the output of my hardare and openssl test)
> 
> So the problem is just that my hardware does not handle non-padded data.

I guess the best course of action would be to patch the test vector to use the 
padded data.

Ciao
Stephan

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


#1590864

FromCorentin Labbe <clabbe.montjoie@gmail.com>
Date2017-03-02 07:40 +0100
Message-ID<tgsz7-6IB-5@gated-at.bofh.it>
In reply to#1590395
On Wed, Mar 01, 2017 at 04:07:17PM +0100, Stephan Müller wrote:
> Am Mittwoch, 1. März 2017, 13:04:14 CET schrieb Corentin Labbe:
> 
> Hi Corentin,
> 
> > 
> > I got the following:
> > 
> > [    1.086228] alg: akcipher: encrypt test failed. Invalid output
> > [    1.092196] 00000000: 6e 7c 8a 75 e7 30 80 d1 5e ab 9b db a2 cf ed db
> > [    1.098882] 00000010: c9 b2 db 43 bd 9a b9 75 27 f3 73 d9 73 b7 81 8c
> > [    1.105524] 00000020: 49 e8 45 fc 43 44 f5 6d f0 f7 b8 f2 ae 6b ae 49
> > [    1.112090] 00000030: 1b 8e 50 c6 88 4e 99 09 78 14 f2 5d 99 c3 7f f9
> > [    1.118747] alg: akcipher: test 1 failed for rsa-generic, err=-22
> > (Exactly the output of my hardare and openssl test)
> > 
> > So the problem is just that my hardware does not handle non-padded data.
> 
> I guess the best course of action would be to patch the test vector to use the 
> padded data.
> 
> Ciao
> Stephan

I am finishing a patch that made testmgr test both (padded and unpadded).

Regards
Corentin Labbe

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


#1591263

FromTadeusz Struk <tadeusz.struk@intel.com>
Date2017-03-02 17:40 +0100
Message-ID<tgBVM-4ZX-19@gated-at.bofh.it>
In reply to#1590864
On 03/01/2017 10:21 PM, Corentin Labbe wrote:
> I am finishing a patch that made testmgr test both (padded and unpadded).

Even if you patch the test vectors there is no guarantee that a user
of the API will always have the plain text padded.
It can be anything between 1 and the key size.
This needs to be the driver who adds padding if needed.
See how other implementations handle it.
Thanks,
-- 
Tadeusz

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


#1590804

FromTadeusz Struk <tadeusz.struk@intel.com>
Date2017-03-02 03:20 +0100
Message-ID<tgovw-3Ky-13@gated-at.bofh.it>
In reply to#1590291
Hi Corentin,
On 03/01/2017 04:04 AM, Corentin Labbe wrote:
>> I would think the issue is that the OpenSSL BIGNUM lib has some issues: when 
>> calculating m^e mod n, m has to be equal to the key size. The kernel's MPI 
>> code handles the case where m is smaller than the key size.
>>
>> Note, in your code below, ptext is the 8 bytes from ptext_ex plus trailing 
>> zeroes whereas the kernel uses just the 8 bytes.
>>
>> It seems that your implementation has the same issue.
>>
>> What about the following test: change vector->m to be 64 bytes (i.e. 
>> RSA_size(key) in size in testmgr.h and check the output of crypto/rsa.c, 
>> openssl's output with the app below and your RSA hardware.
> I got the following:
> 
> [    1.086228] alg: akcipher: encrypt test failed. Invalid output
> [    1.092196] 00000000: 6e 7c 8a 75 e7 30 80 d1 5e ab 9b db a2 cf ed db
> [    1.098882] 00000010: c9 b2 db 43 bd 9a b9 75 27 f3 73 d9 73 b7 81 8c
> [    1.105524] 00000020: 49 e8 45 fc 43 44 f5 6d f0 f7 b8 f2 ae 6b ae 49
> [    1.112090] 00000030: 1b 8e 50 c6 88 4e 99 09 78 14 f2 5d 99 c3 7f f9
> [    1.118747] alg: akcipher: test 1 failed for rsa-generic, err=-22
> (Exactly the output of my hardare and openssl test)
> 
> So the problem is just that my hardware does not handle non-padded data.

The difference between openssl's RSA_private_decrypt() and the akcipher api
is that openssl only takes only one size, flen, for both src and dst buffers,
so in your test app you need to do something like this:

	memset(ptextp, 0, 256);
	memcpy(ptextp + 64 - 8, ptext_ex, plen);

	key = RSA_new();

	key->n = BN_bin2bn(n, sizeof(n)-1, key->n);
	key->e = BN_bin2bn(e, sizeof(e)-1, key->e);

	num = RSA_public_encrypt(RSA_size(key), ptextp, ctext, key, RSA_NO_PADDING);

The akcipher API has separate sizes for both the src and dst. It is the length of the
scatterlist in the akcipher_request. If a HW can't handle different buffers lengths
then its driver needs to add the padding internally.

Thanks,
-- 
Tadeusz

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


#1590862

FromStephan Müller <smueller@chronox.de>
Date2017-03-02 07:40 +0100
Message-ID<tgsz7-6IB-7@gated-at.bofh.it>
In reply to#1590804
Am Donnerstag, 2. März 2017, 03:15:13 CET schrieb Tadeusz Struk:

Hi Tadeusz,

> 
> 	memset(ptextp, 0, 256);
> 	memcpy(ptextp + 64 - 8, ptext_ex, plen);

I actually have tested that and it did not return the data the kernel 
implementation would return

Ciao
Stephan

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


#1591258

FromTadeusz Struk <tadeusz.struk@intel.com>
Date2017-03-02 17:30 +0100
Message-ID<tgBM5-4Vc-1@gated-at.bofh.it>
In reply to#1590862
Hi Stephan,
On 03/01/2017 10:08 PM, Stephan Müller wrote:
>> 	memset(ptextp, 0, 256);
>> 	memcpy(ptextp + 64 - 8, ptext_ex, plen);
> I actually have tested that and it did not return the data the kernel 
> implementation would return

It did for me:
Result 64 plen=8
63 1c cd 7b e1 7e e4 de c9 a8 89 a1 74 cb 3c 63 7d 24 ec 83 c3 15 e4 7f 73 05 34 d1 ec 22 bb 8a 5e 32 39 6d c1 1d 7d 50 3b 9f 7a ad f0 2e 25 53 9f 6e bd 4c 55 84 0c 9b cf 1a 4b 51 1e 9e 0c 06

Are you sure you are compering this with the fist test vector?
http://lxr.free-electrons.com/source/crypto/testmgr.h#L183

Thanks,
-- 
Tadeusz

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web