From: "kevin.z.m.zh-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" Subject: Re: Re: AW: problem with testing a CTR block cipher mode which is partially working Date: Wed, 1 Apr 2015 10:06:37 +0800 Message-ID: <2015040110063394945846@gmail.com> References: <55198F14.1090902@gmail.com>, <12EF8D94C6F8734FB2FF37B9FBEDD1735FC8AB40@EXCHANGE.collogia.de>, <551AE140.3000209@gmail.com> Reply-To: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_001_NextPart650844260004_=----" Cc: "linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org" To: "linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org" , "Markus Stockhausen" , "linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" Return-path: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , List-Id: linux-crypto.vger.kernel.org This is a multi-part message in MIME format. ------=_001_NextPart650844260004_=---- Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear All, About the SS module, there is some detail information. There is some issues on the SS hardware module, the issues make the some=20 AES/DES/3DS algorithm be not available. 1. The byte order of the counter is wrong, make the result error, so, the C= TR=20 mode is not available. 2. Hardware don't support the continuous subcontracting, make the CTS mode = is=20 not available. 3. Another issue need be taken attention is that hardware will modify the k= ey=20 register when do AES encrypt, so, it need software to restore the key regis= ter when doing every frame. These issues are presented on the A10, A13, A20, A31 and A33. The issues of SS module have been fixed on the A83T platform, so, I suggest= to=20 take more attention to the A83T platform if any interest in the SS module. If any problem, please don't hesitate to contact me(kevin-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf@public.gmane.org= ) or Shuge(shuge-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf@public.gmane.org). kevin.z.m.zh-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org =20 From: Corentin LABBE Date: 2015-04-01 02:02 To: Markus Stockhausen; linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org CC: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Subject: [linux-sunxi] Re: AW: problem with testing a CTR block cipher mode= which is partially working Le 30/03/2015 20:08, Markus Stockhausen a =C3=A9crit : >> Von: linux-crypto-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [linux-crypto-owner-u79uwXL29TasMV2rI37PzA@public.gmane.org= org]" im Auftrag von "Corentin LABBE [clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] >> Gesendet: Montag, 30. M=C3=A4rz 2015 19:59 >> An: linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org >> Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org >> Betreff: problem with testing a CTR block cipher mode which is partially= working >> >> hello >> >> I am trying to add the CTR (counter) block cipher mode for AES on my Sec= urity System driver. >> >> When testing with the tcrypt module I got the following result: >> [ 1256.986989] alg: skcipher: Test 1 failed on encryption for ctr-aes-su= nxi-ss >> [ 1256.987004] 00000000: 87 4d 61 91 b6 20 e3 26 1b ef 68 64 99 0d b6 ce >> [ 1256.987013] 00000010: 40 94 25 91 d7 b4 4f 49 ab c1 9d 33 a4 4e f6 54 >> [ 1256.987023] 00000020: ce 58 d2 f0 01 8f 92 a2 5f 2c bb 66 13 8b 9d 76 >> [ 1256.987032] 00000030: 30 fa 4a 40 b1 67 2e f3 46 b7 9a 7c ba 91 0b a2 >> >> As you can see the first ciphered block is correct (according to testmgr= .h), the subsequent blocks are bad. >> >> So Could I assume that the setting of key and IV are good (at least for = the first cipher pass. >> >> The number of inputs(register) are limited and I have tested near all th= e possibility. >> Any idea of what could be wrong. >> >=20 > had a similar challenge a few months ago. I had to take care about >=20 > - counter IV is big endian (implemented it little endian in first place) > - CTR allows to encrypt data that does not need to be amultiple of 16 byt= es. >=20 > Markus >=20 =20 Sorry but if I change endianness of anything, the first block became invali= d. =20 I have tryed ctr(des) but the same problem rise, the first block (so the fi= rst 8bytes) are correctly ciphered then everything is bad. So I suspect the hardware to not increasing counter between blocks, but why= .. =20 =20 --=20 You received this message because you are subscribed to the Google Groups "= linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. --=20 You received this message because you are subscribed to the Google Groups "= linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. ------=_001_NextPart650844260004_=---- Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear All,


About the SS module, there is some de= tail information.
There is some issues on the SS hardware module, the is= sues make the some
AES/DES/3DS algorithm be not available.
1. The by= te order of the counter is wrong, make the result error, so, the CTR
mo= de is not available.
2. Hardware don't support the continuous subcontrac= ting, make the CTS mode is
not available.
3. Another issue need be t= aken attention is that hardware will modify the key
register when do AE= S encrypt, so, it need software to restore the key register

when doing e= very frame.

These issues are presented on the A10, A13, A20, A31 and= A33.
The issues of SS module have been fixed on the A83T platform, so, = I suggest to
take more attention to the A83T platform if any interest i= n the SS module.

If any problem, please don't hesitate to contact me= (kevin-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf@public.gmane.org
)

or Shuge(shuge@allwinnertec= h.com).



kevin.z.m.zh-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
 
Date:=  2015-04-01 02:02
Subject: [linux-sunxi] Re: AW: problem w= ith testing a CTR block cipher mode which is partially working
<= /div>
Le 30/03/2015 20:08, Markus Stockhausen a =C3=A9crit :
>> Von: linux-crypto-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [linux-crypto-owner@v= ger.kernel.org]&quot; im Auftrag von &quot;Corentin LABBE [clabbe.m= ontjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
>> Gesendet: Montag, 30. M=C3=A4rz 2015 19:59
>> An: linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>> Betreff: problem with testing a CTR block cipher mode which i= s partially working
>>
>> hello
>>
>> I am trying to add the CTR (counter) block cipher mode for AE= S on my Security System driver.
>>
>> When testing with the tcrypt module I got the following resul= t:
>> [ 1256.986989] alg: skcipher: Test 1 failed on encryption for= ctr-aes-sunxi-ss
>> [ 1256.987004] 00000000: 87 4d 61 91 b6 20 e3 26 1b ef 68 64 = 99 0d b6 ce
>> [ 1256.987013] 00000010: 40 94 25 91 d7 b4 4f 49 ab c1 9d 33 = a4 4e f6 54
>> [ 1256.987023] 00000020: ce 58 d2 f0 01 8f 92 a2 5f 2c bb 66 = 13 8b 9d 76
>> [ 1256.987032] 00000030: 30 fa 4a 40 b1 67 2e f3 46 b7 9a 7c = ba 91 0b a2
>>
>> As you can see the first ciphered block is correct (according= to testmgr.h), the subsequent blocks are bad.
>>
>> So Could I assume that the setting of key and IV are good (at= least for the first cipher pass.
>>
>> The number of inputs(register) are limited and I have tested = near all the possibility.
>> Any idea of what could be wrong.
>>
>
> had a similar challenge a few months ago. I had to take care abou= t
>
> - counter IV is big endian (implemented it little endian in first= place)
> - CTR allows to encrypt data that does not need to be amultiple o= f 16 bytes.
>
> Markus
>
 
Sorry but if I change endianness of anything, the first block became i= nvalid.
 
I have tryed ctr(des) but the same problem rise, the first block (so t= he first 8bytes) are correctly ciphered then everything is bad.
So I suspect the hardware to not increasing counter between blocks, bu= t why..
 
 
--
You received this message because you are subscribed to the Google Gro= ups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send= an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups &= quot;linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to linux-s= unxi+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit http= s://groups.google.com/d/optout.
------=_001_NextPart650844260004_=------