On 21 October 2018 at 11:00, James Bottomley
<james.bottom...@hansenpartnership.com> wrote:
> On October 21, 2018 9:58:04 AM GMT, Ard Biesheuvel
> <ard.biesheu...@linaro.org> wrote:
>>On 21 October 2018 at 10:07, James Bottomley
>><james.bottom...@hansenpartnership.com> wrote:
>>> On Sun, 2018-10-21 at 09:05 +0200, Ard Biesheuvel wrote:
>>>> (+ James)
>>>
>>> Thanks!
>>>
>>>> On 20 October 2018 at 01:01, Dmitry Eremin-Solenikov
>>>> <dbarysh...@gmail.com> wrote:
>>>> > crypto_cfb_decrypt_segment() incorrectly XOR'ed generated
>>keystream
>>>> > with
>>>> > IV, rather than with data stream, resulting in incorrect
>>>> > decryption.
>>>> > Test vectors will be added in the next patch.
>>>> >
>>>> > Signed-off-by: Dmitry Eremin-Solenikov <dbarysh...@gmail.com>
>>>> > Cc: sta...@vger.kernel.org
>>>> > ---
>>>> > crypto/cfb.c | 2 +-
>>>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>>>> >
>>>> > diff --git a/crypto/cfb.c b/crypto/cfb.c
>>>> > index a0d68c09e1b9..fd4e8500e121 100644
>>>> > --- a/crypto/cfb.c
>>>> > +++ b/crypto/cfb.c
>>>> > @@ -144,7 +144,7 @@ static int crypto_cfb_decrypt_segment(struct
>>>> > skcipher_walk *walk,
>>>> >
>>>> > do {
>>>> > crypto_cfb_encrypt_one(tfm, iv, dst);
>>>> > - crypto_xor(dst, iv, bsize);
>>>> > + crypto_xor(dst, src, bsize);
>>>
>>> This does look right. I think the reason the TPM code works is that
>>it
>>> always does encrypt/decrypt in-place, which is a separate piece of
>>the
>>> code which appears to be correct.
>>>
>>
>>Yeah I figured that.
>>
>>So where is the TPM code that actually uses this code?
>
> It was posted to the integrity list a while ago. I'm planning a repost
> shortly.
>
OK, found it. Mind cc'ing me on that repost?
