* libkcapi tests are failing on kernels 5.5+
@ 2020-04-21 8:08 Ondrej Mosnáček
2020-04-21 9:19 ` Stephan Mueller
2020-05-05 7:58 ` Herbert Xu
0 siblings, 2 replies; 6+ messages in thread
From: Ondrej Mosnáček @ 2020-04-21 8:08 UTC (permalink / raw)
To: linux-crypto, Herbert Xu, Stephan Mueller
Cc: Sahana Prasad, Tomas Mraz, Ard Biesheuvel
Hi all,
the libkcapi [1] tests are failing on kernels 5.5-rc1 and above [2].
All encryption/decryption tests that use 'ctr(aes)' and a message size
that is not a multiple of 16 fail due to kcapi-enc returning different
output than expected.
It seems that it started with:
commit 5b0fe9552336338acb52756daf65dd7a4eeca73f
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue Sep 10 11:42:05 2019 +1000
crypto: algif_skcipher - Use chunksize instead of blocksize
Reverting the above commit makes the tests pass again.
Here is a one-line reproducer:
head -c 257 /dev/zero | kcapi-enc -vvv --pbkdfiter 1 -p "passwd" -s
"123" -e -c "ctr(aes)" --iv "0123456789abcdef0123456789abcdef"
>/dev/null
Output without revert:
[...]
libkcapi - Debug: AF_ALG: recvmsg syscall returned 256
kcapi-enc - Verbose: Removal of padding disabled
kcapi-enc - Verbose: 256 bytes of ciphertext created
Output with the revert and on older kernels:
[...]
libkcapi - Debug: AF_ALG: recvmsg syscall returned 257
kcapi-enc - Verbose: Removal of padding disabled
kcapi-enc - Verbose: 257 bytes of ciphertext created
I'm not familiar with the code in question, so I'm not sure if this is
a kernel bug or whether the change just exposed a bug in libkcapi.
Stephan, Herbert, can you please have a look?
Thanks,
Ondrej
[1] https://github.com/smuellerDD/libkcapi
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1826022
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libkcapi tests are failing on kernels 5.5+
2020-04-21 8:08 libkcapi tests are failing on kernels 5.5+ Ondrej Mosnáček
@ 2020-04-21 9:19 ` Stephan Mueller
2020-04-28 8:19 ` Stephan Mueller
2020-05-05 7:58 ` Herbert Xu
1 sibling, 1 reply; 6+ messages in thread
From: Stephan Mueller @ 2020-04-21 9:19 UTC (permalink / raw)
To: Ondrej Mosnáček
Cc: linux-crypto, Herbert Xu, Sahana Prasad, Tomas Mraz, Ard Biesheuvel
Am Dienstag, 21. April 2020, 10:08:14 CEST schrieb Ondrej Mosnáček:
Hi Ondrej,
> Hi all,
>
> the libkcapi [1] tests are failing on kernels 5.5-rc1 and above [2].
> All encryption/decryption tests that use 'ctr(aes)' and a message size
> that is not a multiple of 16 fail due to kcapi-enc returning different
> output than expected.
Confirmed.
On the recent kernels, the data generated by kcapi-enc contains trailing zero
bytes for data that is a fraction of the block size.
I think the issue is in the following kernel code in _skcipher_recvmsg:
unsigned int bs = crypto_skcipher_chunksize(tfm);
/*
* If more buffers are to be expected to be processed, process only
* full block size buffers.
*/
if (ctx->more || len < ctx->used)
len -= len % bs;
The kernel truncates the size to be processed to the chunk size. As the
chunksize returns the block size of the underlying cipher (e.g. AES -> 16),
the kernel code will not process non-aligned data.
Herbert, could you help me identifying what exactly was the root cause for the
patch 5b0fe9552336338acb52756daf65dd7a4eeca73f ? I.e. it seems that stream
ciphers made out of a block cipher would not generate the data part that is a
fraction of the block size (e.g. CTR, CTS).
Ciao
Stephan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libkcapi tests are failing on kernels 5.5+
2020-04-21 9:19 ` Stephan Mueller
@ 2020-04-28 8:19 ` Stephan Mueller
0 siblings, 0 replies; 6+ messages in thread
From: Stephan Mueller @ 2020-04-28 8:19 UTC (permalink / raw)
To: Herbert Xu
Cc: Ondrej Mosnáček, linux-crypto, Sahana Prasad,
Tomas Mraz, Ard Biesheuvel
Am Dienstag, 21. April 2020, 11:19:36 CEST schrieb Stephan Mueller:
Hi Herbert,
could you please help us with the answer to the question below?
> Am Dienstag, 21. April 2020, 10:08:14 CEST schrieb Ondrej Mosnáček:
>
> Hi Ondrej,
>
> > Hi all,
> >
> > the libkcapi [1] tests are failing on kernels 5.5-rc1 and above [2].
> > All encryption/decryption tests that use 'ctr(aes)' and a message size
> > that is not a multiple of 16 fail due to kcapi-enc returning different
> > output than expected.
>
> Confirmed.
>
> On the recent kernels, the data generated by kcapi-enc contains trailing
> zero bytes for data that is a fraction of the block size.
>
> I think the issue is in the following kernel code in _skcipher_recvmsg:
>
> unsigned int bs = crypto_skcipher_chunksize(tfm);
>
> /*
> * If more buffers are to be expected to be processed, process only
> * full block size buffers.
> */
> if (ctx->more || len < ctx->used)
> len -= len % bs;
>
>
> The kernel truncates the size to be processed to the chunk size. As the
> chunksize returns the block size of the underlying cipher (e.g. AES -> 16),
> the kernel code will not process non-aligned data.
>
> Herbert, could you help me identifying what exactly was the root cause for
> the patch 5b0fe9552336338acb52756daf65dd7a4eeca73f ? I.e. it seems that
> stream ciphers made out of a block cipher would not generate the data part
> that is a fraction of the block size (e.g. CTR, CTS).
>
> Ciao
> Stephan
Ciao
Stephan
--
atsec information security GmbH, Steinstraße 70, 81667 München, Germany
Phone: +49 89 442 49 830 - Fax: +49 89 442 49 831
Mobile DE: +49 172 216 55 78 - Mobile US: +1 737 346 1613
HRB: 129439 (Amtsgericht München)
GF: Salvatore la Pietra, Staffan Persson, Manuela Gambarotto
atsec it security news blog - atsec-information-security.blogspot.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libkcapi tests are failing on kernels 5.5+
2020-04-21 8:08 libkcapi tests are failing on kernels 5.5+ Ondrej Mosnáček
2020-04-21 9:19 ` Stephan Mueller
@ 2020-05-05 7:58 ` Herbert Xu
2020-05-05 8:05 ` Stephan Mueller
2020-05-05 22:04 ` Stephan Müller
1 sibling, 2 replies; 6+ messages in thread
From: Herbert Xu @ 2020-05-05 7:58 UTC (permalink / raw)
To: Ondrej Mosnáček
Cc: linux-crypto, Stephan Mueller, Sahana Prasad, Tomas Mraz, Ard Biesheuvel
On Tue, Apr 21, 2020 at 10:08:14AM +0200, Ondrej Mosnáček wrote:
> Hi all,
>
> the libkcapi [1] tests are failing on kernels 5.5-rc1 and above [2].
> All encryption/decryption tests that use 'ctr(aes)' and a message size
> that is not a multiple of 16 fail due to kcapi-enc returning different
> output than expected.
>
> It seems that it started with:
> commit 5b0fe9552336338acb52756daf65dd7a4eeca73f
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Tue Sep 10 11:42:05 2019 +1000
>
> crypto: algif_skcipher - Use chunksize instead of blocksize
>
> Reverting the above commit makes the tests pass again.
>
> Here is a one-line reproducer:
> head -c 257 /dev/zero | kcapi-enc -vvv --pbkdfiter 1 -p "passwd" -s
> "123" -e -c "ctr(aes)" --iv "0123456789abcdef0123456789abcdef"
> >/dev/null
>
> Output without revert:
> [...]
> libkcapi - Debug: AF_ALG: recvmsg syscall returned 256
> kcapi-enc - Verbose: Removal of padding disabled
> kcapi-enc - Verbose: 256 bytes of ciphertext created
OK, I tried it here and the problem is that kcapi-enc is setting
the flag SPLICE_F_MORE:
splice(4, NULL, 6, NULL, 257, SPLICE_F_MORE) = 257
write(2, "libkcapi - Debug: AF_ALG: splice"..., 54libkcapi - Debug: AF_ALG: splice syscall returned 257
) = 54
write(2, "kcapi-enc - Debug: Data size exp"..., 59kcapi-enc - Debug: Data size expected to be generated: 257
) = 59
recvmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\363\212\340S\r\231\371+\234\320\"\360}%\244\242.\365iJ\304\257\210\f\366\20\257'F\5EP"..., iov_len=257}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 256
That flag means that the request is not finished and because of
the way CTR works we must wait for more input before returning
the next block (or partial block).
So kcapi-enc needs to unset the SPLICE_F_MORE to finish a request.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libkcapi tests are failing on kernels 5.5+
2020-05-05 7:58 ` Herbert Xu
@ 2020-05-05 8:05 ` Stephan Mueller
2020-05-05 22:04 ` Stephan Müller
1 sibling, 0 replies; 6+ messages in thread
From: Stephan Mueller @ 2020-05-05 8:05 UTC (permalink / raw)
To: Herbert Xu
Cc: Ondrej Mosnáček, linux-crypto, Sahana Prasad,
Tomas Mraz, Ard Biesheuvel
Am Dienstag, 5. Mai 2020, 09:58:35 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Apr 21, 2020 at 10:08:14AM +0200, Ondrej Mosnáček wrote:
> > Hi all,
> >
> > the libkcapi [1] tests are failing on kernels 5.5-rc1 and above [2].
> > All encryption/decryption tests that use 'ctr(aes)' and a message size
> > that is not a multiple of 16 fail due to kcapi-enc returning different
> > output than expected.
> >
> > It seems that it started with:
> > commit 5b0fe9552336338acb52756daf65dd7a4eeca73f
> > Author: Herbert Xu <herbert@gondor.apana.org.au>
> > Date: Tue Sep 10 11:42:05 2019 +1000
> >
> > crypto: algif_skcipher - Use chunksize instead of blocksize
> >
> > Reverting the above commit makes the tests pass again.
> >
> > Here is a one-line reproducer:
> > head -c 257 /dev/zero | kcapi-enc -vvv --pbkdfiter 1 -p "passwd" -s
> > "123" -e -c "ctr(aes)" --iv "0123456789abcdef0123456789abcdef"
> >
> > >/dev/null
> >
> > Output without revert:
> > [...]
> > libkcapi - Debug: AF_ALG: recvmsg syscall returned 256
> > kcapi-enc - Verbose: Removal of padding disabled
> > kcapi-enc - Verbose: 256 bytes of ciphertext created
>
> OK, I tried it here and the problem is that kcapi-enc is setting
> the flag SPLICE_F_MORE:
>
> splice(4, NULL, 6, NULL, 257, SPLICE_F_MORE) = 257
> write(2, "libkcapi - Debug: AF_ALG: splice"..., 54libkcapi - Debug: AF_ALG:
> splice syscall returned 257 ) = 54
> write(2, "kcapi-enc - Debug: Data size exp"..., 59kcapi-enc - Debug: Data
> size expected to be generated: 257 ) = 59
> recvmsg(6, {msg_name=NULL, msg_namelen=0,
> msg_iov=[{iov_base="\363\212\340S\r\231\371+\234\320\"\360}%\244\242.\365iJ
> \304\257\210\f\366\20\257'F\5EP"..., iov_len=257}], msg_iovlen=1,
> msg_controllen=0, msg_flags=0}, 0) = 256
>
> That flag means that the request is not finished and because of
> the way CTR works we must wait for more input before returning
> the next block (or partial block).
>
> So kcapi-enc needs to unset the SPLICE_F_MORE to finish a request.
Thanks a lot, let me work on that.
>
> Cheers,
Ciao
Stephan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libkcapi tests are failing on kernels 5.5+
2020-05-05 7:58 ` Herbert Xu
2020-05-05 8:05 ` Stephan Mueller
@ 2020-05-05 22:04 ` Stephan Müller
1 sibling, 0 replies; 6+ messages in thread
From: Stephan Müller @ 2020-05-05 22:04 UTC (permalink / raw)
To: Ondrej Mosnáček, Herbert Xu
Cc: linux-crypto, Sahana Prasad, Tomas Mraz, Ard Biesheuvel
Am Dienstag, 5. Mai 2020, 09:58:35 CEST schrieb Herbert Xu:
Hi Herbert,
Issue is fixed in libkcapi with https://github.com/smuellerDD/libkcapi/commit/
2fdd3738c77b0db825b4bb94eef9a932aa5077de
Thanks.
Ciao
Stephan
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-05-05 22:04 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-21 8:08 libkcapi tests are failing on kernels 5.5+ Ondrej Mosnáček
2020-04-21 9:19 ` Stephan Mueller
2020-04-28 8:19 ` Stephan Mueller
2020-05-05 7:58 ` Herbert Xu
2020-05-05 8:05 ` Stephan Mueller
2020-05-05 22:04 ` Stephan Müller
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.