Hi,
I am trying to update the old ifxdeu driver to pass the crypto mgr tests.
However, I continously fail to pass the split tests and I wonder what to do.
For example, I successfully pass the test vector 0 here:
https://elixir.bootlin.com/linux/latest/source/crypto/testmgr.h#L16654
if there is no split.
But if the text "Single block msg" is split into two 8 byte blocks
(single even aligned splits), which end up as separate skcipher walks
in the driver, the second block is wrong and does not compare
correctly, to what is hardcoded in testmgr.h. Same if I try it with
online aes-ctr encoders in the web.
I have tried doing the xor manually with the aes encoded iv, but I get
the same result as the hardware and if I use the next last iv, I still
do not get the second 8 bytes that are hardcoded in cryptomgr.h.
Can someone shed a light on it?
Is it valid to compare a crypto result that was done on a single walk
with 16byte with two separate walks on the 8 byte splits (of the
original 16)? Is the cryptomgr test on the split tests expecting that
I concat the two walks into a single one?
If yes, how to do that on the uneven splits with separations like 15
16 5 byte sequences, etc., fill up the walk up to full block size and
spill over into the next walk?
Thanks in advance.
On Mon, May 03, 2021 at 09:56:40AM +0200, Kestrel seventyfour wrote:
> Hi,
>
> I am trying to update the old ifxdeu driver to pass the crypto mgr tests.
> However, I continously fail to pass the split tests and I wonder what to do.
>
> For example, I successfully pass the test vector 0 here:
> https://elixir.bootlin.com/linux/latest/source/crypto/testmgr.h#L16654
> if there is no split.
>
> But if the text "Single block msg" is split into two 8 byte blocks
> (single even aligned splits), which end up as separate skcipher walks
> in the driver, the second block is wrong and does not compare
> correctly, to what is hardcoded in testmgr.h. Same if I try it with
> online aes-ctr encoders in the web.
> I have tried doing the xor manually with the aes encoded iv, but I get
> the same result as the hardware and if I use the next last iv, I still
> do not get the second 8 bytes that are hardcoded in cryptomgr.h.
>
> Can someone shed a light on it?
> Is it valid to compare a crypto result that was done on a single walk
> with 16byte with two separate walks on the 8 byte splits (of the
> original 16)? Is the cryptomgr test on the split tests expecting that
> I concat the two walks into a single one?
> If yes, how to do that on the uneven splits with separations like 15
> 16 5 byte sequences, etc., fill up the walk up to full block size and
> spill over into the next walk?
>
The split test cases expect the same output (same sequence of bytes) as the
non-split test cases. The only difference is how the data is split up into
scatterlist elements. Yes, that means that a single 16-byte block of the
keystream may need to be XOR'ed with data from multiple scatterlist elements.
Take a look at how other drivers handle this.
- Eric
Hi Eric,
thanks for the info. Walksize did the trick returning the chunks.
D. Kestrel
Am Di., 4. Mai 2021 um 18:52 Uhr schrieb Eric Biggers <[email protected]>:
>
> On Mon, May 03, 2021 at 09:56:40AM +0200, Kestrel seventyfour wrote:
> > Hi,
> >
> > I am trying to update the old ifxdeu driver to pass the crypto mgr tests.
> > However, I continously fail to pass the split tests and I wonder what to do.
> >
> > For example, I successfully pass the test vector 0 here:
> > https://elixir.bootlin.com/linux/latest/source/crypto/testmgr.h#L16654
> > if there is no split.
> >
> > But if the text "Single block msg" is split into two 8 byte blocks
> > (single even aligned splits), which end up as separate skcipher walks
> > in the driver, the second block is wrong and does not compare
> > correctly, to what is hardcoded in testmgr.h. Same if I try it with
> > online aes-ctr encoders in the web.
> > I have tried doing the xor manually with the aes encoded iv, but I get
> > the same result as the hardware and if I use the next last iv, I still
> > do not get the second 8 bytes that are hardcoded in cryptomgr.h.
> >
> > Can someone shed a light on it?
> > Is it valid to compare a crypto result that was done on a single walk
> > with 16byte with two separate walks on the 8 byte splits (of the
> > original 16)? Is the cryptomgr test on the split tests expecting that
> > I concat the two walks into a single one?
> > If yes, how to do that on the uneven splits with separations like 15
> > 16 5 byte sequences, etc., fill up the walk up to full block size and
> > spill over into the next walk?
> >
>
> The split test cases expect the same output (same sequence of bytes) as the
> non-split test cases. The only difference is how the data is split up into
> scatterlist elements. Yes, that means that a single 16-byte block of the
> keystream may need to be XOR'ed with data from multiple scatterlist elements.
> Take a look at how other drivers handle this.
>
> - Eric