Comments (9)
smuellerDD
commented on July 21, 2024
I am unable to reproduce the issue with the current code.
Note, I have removed the sleep(1) that you rightfully pointed out. Could you test it again on your system whether you see that bug?
Thanks.
from libkcapi.
WOnder93
commented on July 21, 2024
Strange, I can't reproduce it either now, even when I revert to 2da4a5a and remove the sleep. I upgraded to kernel 5.6.8 in the meantime, so let me try again with the 5.5 kernel...
from libkcapi.
WOnder93
commented on July 21, 2024
Yes, it does reproduce on 5.5.10, so it must have been fixed by a kernel change somewhere between 5.5 and 5.6. I'll try to bisect it.
from libkcapi.
WOnder93
commented on July 21, 2024
OK, never mind, it turns out I just didn't wait long enough... Now I'm getting the bug also on 5.6.8-200.fc31.x86_64 and 5.7.0-0.rc4.1.fc33.x86_64 kernels (with current master and removed sleep). It usually takes a couple hundred to thousand invocations to trigger.
BTW, you reverted the sleep removal, but the commit lacks any explanation...
from libkcapi.
smuellerDD
commented on July 21, 2024
Am Mittwoch, 6. Mai 2020, 17:15:35 CEST schrieb Ondrej Mosnáček:
Hi Ondrej,
OK, never mind, it turns out I just didn't wait long enough... Now I'm
getting the bug also on `5.6.8-200.fc31.x86_64` and
`5.7.0-0.rc4.1.fc33.x86_64` kernels (with current master and removed
sleep). It usually takes a couple hundred to thousand invocations to
trigger.
BTW, you reverted the sleep removal, but the commit lacks any explanation...
Hm, yes. It was midnight and I just wanted to get the testing to pass again.
Leaving a broken archive is not good.
Then I overlooked the description part...
Ciao
Stephan
from libkcapi.
WOnder93
commented on July 21, 2024
Wait... isn't the problem that we are testing the stream mode with xts(aes), which is not a stream cipher? I mean "stream" in the sense that it updates the IV so that the encryption can continue with in a seprate operation with the returned IV. IIUC, in stream mode the socket input can be internally split into parts, which are processed in separate skcipher operations, which would produce a different output for XTS, since it would process each part with the same IV... Am I right?
from libkcapi.
smuellerDD
commented on July 21, 2024
Am Mittwoch, 6. Mai 2020, 18:58:52 CEST schrieb Ondrej Mosnáček:
Hi Ondrej,
Wait... isn't the problem that we are testing the stream mode with
`xts(aes)`, which is not a stream cipher? I mean "stream" in the sense that
it updates the IV so that the encryption can continue with in a seprate
operation with the returned IV. IIUC, in stream mode the socket input can
be internally split into parts, which are processed in separate skcipher
operations, which would produce a different output for XTS, since it would
process each part with the same IV... Am I right?
A stream operation is intended to follow an init/update/final approach where
the update can be performed multiple times. Think of it as the traditional
crypto libs:
cipher_handle = alloc_init_cipher(key, IV);
encrypt(cipher_handle, somedata);
destroy(cipher_handle);
The stream API just implements that concept.
The key/IV is set with the init part. Thus, the multiple updates operate on
the existing cipher handle whose IV is internally updated as defined by the
chaining mode.
So, the stream API is unrealated to a stream cipher, it is just a reference
that you can stream data into the open cipher handle. Thus, it works with any
type of symmetric cipher.
I think the issue is some form of race because I see the issue regularly when
I run the kernel within a QEMU environment.
If I would recollect why I added the sleep(1) to the test code... I usually
comment my code heavily to just avoid such head-scratch...
Ciao
Stephan
from libkcapi.
WOnder93
commented on July 21, 2024
The key/IV is set with the init part. Thus, the multiple updates operate on
the existing cipher handle whose IV is internally updated as defined by the
chaining mode.
Right, I probably mixed up the terminology, but my point was that xts(aes) doesn't support chaining requests like that (at least as implemented in the kernel Crypto API). You can see it in crypto/testmgr.h - the ciphers that are expected to return IVs usable for chaining have the .iv_out entries filled in in their test vectors (and those that don't support it do not). You can see that only CTR and CBC test vectors have them, not XTS.
Looking again at how XTS is defined, it seems one could implement transparent chaining by simply decrypting the final tweak using the tweak key and return it as the output IV... but I believe this has never been mandated nor implemented in the Crypto API (likely because of the overhead of the final tweak decryption, which would be pointless if you're not going to use the output IV - and there is currently no way to signal to the driver that you are going to need it).
I could remember this wrong, so you should probably double-check with Herbert, but AFAIK this is how it is (and always has been).
from libkcapi.
smuellerDD
commented on July 21, 2024
You are quite right. I slightly reformatted the patches. Thanks for your help.
from libkcapi.
Related Issues (20)
- Questions about dividing data into chunks HOT 5
- key size fixed at 32 bytes (need 52 for CAAM related "black" keys) HOT 3
- AEAD gcm(aes) decrypt failure HOT 15
- AF_ALG bind error HOT 1
- Kernel API patches Status HOT 3
- Specify key length for kcapi-enc HOT 2
- How to configure the cross compiler toolchain？ HOT 1
- Where does the function `kcapi_md_final` implement ? HOT 1
- 1.4.0: test suite failis with `error: clang frontend command failed with exit code 139` HOT 19
- Is `kcapi_handle` thread-safe? HOT 4
- Does LibkcAPI support CFB1/CFB8? HOT 2
- vmsplice() with SPLICE_F_GIFT should not be used on memory allocated from the heap (ie. calloc) HOT 2
- Hang on read call in _kcapi_common_read_data
- Can't get `kcapi_akcipher_init` with `rsa` working locally HOT 6
- Why SHA2-256 is the only hash crypto primitive for KDF in linux kernel crypto? HOT 7
- speed-tests: Bench of Asymmetric Cryptographic Algorithms HOT 3
- coreutils, etc. symlinks created in $PREFIX/libexec/libkcapi HOT 3
- 1.4.0: sha*hmac binaries has been removed? 🤔 HOT 9
- DRBG CAVP Issue HOT 2
- Unable to build on busy box HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libkcapi.