Hi,
ctr(aes) is broken in current kernel (v5.1+). It may have been broken
for longer, but the crypto tests now check for a correct output IV. The
testmgr answers with:
alg: skcipher: ctr-aes-caam encryption test failed (wrong output IV) on test vector 0, cfg="in-place"
output IV is this, which is the last 16 bytes of the encrypted message:
00000000: 1e 03 1d da 2f be 03 d1 79 21 70 a0 f3 00 9c ee
It should look like this instead, which is input IV + 4:
00000000: f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd ff 03
I have no idea how to fix this as I don't know how to get the output IV
back from the CAAM. Any ideas?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Hi Sascha,
On Wed, May 15, 2019 at 10:09 AM Sascha Hauer <[email protected]> wrote:
>
> Hi,
>
> ctr(aes) is broken in current kernel (v5.1+). It may have been broken
> for longer, but the crypto tests now check for a correct output IV. The
> testmgr answers with:
>
> alg: skcipher: ctr-aes-caam encryption test failed (wrong output IV) on test vector 0, cfg="in-place"
>
> output IV is this, which is the last 16 bytes of the encrypted message:
> 00000000: 1e 03 1d da 2f be 03 d1 79 21 70 a0 f3 00 9c ee
>
> It should look like this instead, which is input IV + 4:
> 00000000: f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd ff 03
>
> I have no idea how to fix this as I don't know how to get the output IV
> back from the CAAM. Any ideas?
Is this problem similar to this one?
https://www.mail-archive.com/[email protected]/msg37512.html
Hi Fabio,
On Wed, May 15, 2019 at 10:17:19AM -0300, Fabio Estevam wrote:
> Hi Sascha,
>
> On Wed, May 15, 2019 at 10:09 AM Sascha Hauer <[email protected]> wrote:
> >
> > Hi,
> >
> > ctr(aes) is broken in current kernel (v5.1+). It may have been broken
> > for longer, but the crypto tests now check for a correct output IV. The
> > testmgr answers with:
> >
> > alg: skcipher: ctr-aes-caam encryption test failed (wrong output IV) on test vector 0, cfg="in-place"
> >
> > output IV is this, which is the last 16 bytes of the encrypted message:
> > 00000000: 1e 03 1d da 2f be 03 d1 79 21 70 a0 f3 00 9c ee
> >
> > It should look like this instead, which is input IV + 4:
> > 00000000: f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd ff 03
> >
> > I have no idea how to fix this as I don't know how to get the output IV
> > back from the CAAM. Any ideas?
>
> Is this problem similar to this one?
> https://www.mail-archive.com/[email protected]/msg37512.html
Different algo, different hardware, but yes, it seems to be the same
type of failure.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On 5/15/2019 4:22 PM, Sascha Hauer wrote:
> Hi Fabio,
>
> On Wed, May 15, 2019 at 10:17:19AM -0300, Fabio Estevam wrote:
>> Hi Sascha,
>>
>> On Wed, May 15, 2019 at 10:09 AM Sascha Hauer <[email protected]> wrote:
>>>
>>> Hi,
>>>
>>> ctr(aes) is broken in current kernel (v5.1+). It may have been broken
>>> for longer, but the crypto tests now check for a correct output IV. The
>>> testmgr answers with:
>>>
>>> alg: skcipher: ctr-aes-caam encryption test failed (wrong output IV) on test vector 0, cfg="in-place"
>>>
>>> output IV is this, which is the last 16 bytes of the encrypted message:
>>> 00000000: 1e 03 1d da 2f be 03 d1 79 21 70 a0 f3 00 9c ee
>>>
>>> It should look like this instead, which is input IV + 4:
>>> 00000000: f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd ff 03
>>>
>>> I have no idea how to fix this as I don't know how to get the output IV
>>> back from the CAAM. Any ideas?
>>
>> Is this problem similar to this one?
>> https://www.mail-archive.com/[email protected]/msg37512.html
>
> Different algo, different hardware, but yes, it seems to be the same
> type of failure.
>
For talitos, the problem is the lack of IV update.
For caam, the problem is incorrect IV update (output IV is equal to last
ciphertext block, which is correect for cbc, but not for ctr mode).
I am working at a fix, but it takes longer since I would like to program the
accelerator to the save the IV (and not do counter increment in SW, which
created problems for many other implementations).
Regards,
Horia
On Wed, May 15, 2019 at 01:35:16PM +0000, Horia Geanta wrote:
> On 5/15/2019 4:22 PM, Sascha Hauer wrote:
> > Hi Fabio,
> >
> > On Wed, May 15, 2019 at 10:17:19AM -0300, Fabio Estevam wrote:
> >> Hi Sascha,
> >>
> >> On Wed, May 15, 2019 at 10:09 AM Sascha Hauer <[email protected]> wrote:
> >>>
> >>> Hi,
> >>>
> >>> ctr(aes) is broken in current kernel (v5.1+). It may have been broken
> >>> for longer, but the crypto tests now check for a correct output IV. The
> >>> testmgr answers with:
> >>>
> >>> alg: skcipher: ctr-aes-caam encryption test failed (wrong output IV) on test vector 0, cfg="in-place"
> >>>
> >>> output IV is this, which is the last 16 bytes of the encrypted message:
> >>> 00000000: 1e 03 1d da 2f be 03 d1 79 21 70 a0 f3 00 9c ee
> >>>
> >>> It should look like this instead, which is input IV + 4:
> >>> 00000000: f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd ff 03
> >>>
> >>> I have no idea how to fix this as I don't know how to get the output IV
> >>> back from the CAAM. Any ideas?
> >>
> >> Is this problem similar to this one?
> >> https://www.mail-archive.com/[email protected]/msg37512.html
> >
> > Different algo, different hardware, but yes, it seems to be the same
> > type of failure.
> >
> For talitos, the problem is the lack of IV update.
>
> For caam, the problem is incorrect IV update (output IV is equal to last
> ciphertext block, which is correect for cbc, but not for ctr mode).
>
> I am working at a fix, but it takes longer since I would like to program the
> accelerator to the save the IV (and not do counter increment in SW, which
> created problems for many other implementations).
Thanks for working on it. I'd be glad to test it once you have
something.
Thanks
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Hi Horia,
On Wed, May 15, 2019 at 01:35:16PM +0000, Horia Geanta wrote:
> For talitos, the problem is the lack of IV update.
>
> For caam, the problem is incorrect IV update (output IV is equal to last
> ciphertext block, which is correect for cbc, but not for ctr mode).
>
> I am working at a fix, but it takes longer since I would like to program the
> accelerator to the save the IV (and not do counter increment in SW, which
> created problems for many other implementations).
Any news here? With the fix Ard provided gcm(aes) now works again, but
only as long as the crypto self tests are disabled.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On 6/12/2019 12:40 PM, Sascha Hauer wrote:
> Hi Horia,
>
> On Wed, May 15, 2019 at 01:35:16PM +0000, Horia Geanta wrote:
>> For talitos, the problem is the lack of IV update.
>>
>> For caam, the problem is incorrect IV update (output IV is equal to last
>> ciphertext block, which is correect for cbc, but not for ctr mode).
>>
>> I am working at a fix, but it takes longer since I would like to program the
>> accelerator to the save the IV (and not do counter increment in SW, which
>> created problems for many other implementations).
>
> Any news here? With the fix Ard provided gcm(aes) now works again, but
> only as long as the crypto self tests are disabled.
>
I've recently submitted support for IV update done in HW (caam engine),
which fixes this issue:
https://patchwork.kernel.org/cover/10984927/
Unfortunately it's probably too big to be sent to -stable.
We'll have to rely on Ard's workaround on previous kernels.
Horia
On Wed, Jun 12, 2019 at 10:33:56AM +0000, Horia Geanta wrote:
> On 6/12/2019 12:40 PM, Sascha Hauer wrote:
> > Hi Horia,
> >
> > On Wed, May 15, 2019 at 01:35:16PM +0000, Horia Geanta wrote:
> >> For talitos, the problem is the lack of IV update.
> >>
> >> For caam, the problem is incorrect IV update (output IV is equal to last
> >> ciphertext block, which is correect for cbc, but not for ctr mode).
> >>
> >> I am working at a fix, but it takes longer since I would like to program the
> >> accelerator to the save the IV (and not do counter increment in SW, which
> >> created problems for many other implementations).
> >
> > Any news here? With the fix Ard provided gcm(aes) now works again, but
> > only as long as the crypto self tests are disabled.
> >
> I've recently submitted support for IV update done in HW (caam engine),
> which fixes this issue:
> https://patchwork.kernel.org/cover/10984927/
Thanks, I haven't seen this. I'll give it a try.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Wed, Jun 12, 2019 at 01:35:36PM +0200, Sascha Hauer wrote:
> On Wed, Jun 12, 2019 at 10:33:56AM +0000, Horia Geanta wrote:
> > On 6/12/2019 12:40 PM, Sascha Hauer wrote:
> > > Hi Horia,
> > >
> > > On Wed, May 15, 2019 at 01:35:16PM +0000, Horia Geanta wrote:
> > >> For talitos, the problem is the lack of IV update.
> > >>
> > >> For caam, the problem is incorrect IV update (output IV is equal to last
> > >> ciphertext block, which is correect for cbc, but not for ctr mode).
> > >>
> > >> I am working at a fix, but it takes longer since I would like to program the
> > >> accelerator to the save the IV (and not do counter increment in SW, which
> > >> created problems for many other implementations).
> > >
> > > Any news here? With the fix Ard provided gcm(aes) now works again, but
> > > only as long as the crypto self tests are disabled.
> > >
> > I've recently submitted support for IV update done in HW (caam engine),
> > which fixes this issue:
> > https://patchwork.kernel.org/cover/10984927/
>
> Thanks, I haven't seen this. I'll give it a try.
This works here, thanks
I don't have the original patch mails, so I'm adding it here:
Tested-by: Sascha Hauer <[email protected]>
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |