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