- linux-crypto@kernelnewbies.org - Kernelnewbies Mailing Lists

regression in 6.17-RC7 AF_ALG
by Daniel Pouzzner Sept. 26, 2025

Sept. 26, 2025

Our nightly tests just detected a breaking change in RC7, not present in RC6. We discovered it via the libkcapi test harness, affecting a somewhat random (but consistent) subset of the skcipher tests. I've bisected it to 1b34cbbf4f0. There doesn't seem to be anything wrong with the fix in that commit, but the refactor of the bools in struct af_alg_ctx as a bitfield is unexpectedly breaking AF_ALG calls. Target/toolchain/config details are listed below. This patch restores correct behavior for us: --- ./include/crypto/if_alg.h.dist 2025-09-25 17:14:59.821789747 +0000 +++ ./include/crypto/if_alg.h 2025-09-26 18:59:46.813132909 +0000 @@ -152,11 +152,11 @@ struct af_alg_ctx { size_t used; atomic_t rcvused; - u32 more:1, - merge:1, - enc:1, - write:1, - init:1; + bool more; + bool merge; + bool enc; + bool write; + bool init; unsigned int len; Final success/failure count from the libkcapi test harness without the patch: libkcapi test.sh results: 794 passed, 27 skipped, 61 failed. Below is a snippet from that run. The logged kcapi commands reproduce the problem directly -- I tested this separately, outside the libkcapi test script. [PASSED: 64-bit - 6.17.0-rc7] AEAD gcm(aes) synchronous one shot non-aligned test 16 [PASSED: 64-bit - 6.17.0-rc7] AEAD gcm(aes) synchronous one shot non-aligned test 17 [FAILED: 64-bit - 6.17.0-rc7] AEAD gcm(aes) synchronous stream non-aligned test 1 (/usr/local/libexec/libkcapi/kcapi -x 2 -s -c "gcm(aes)" -i aac774c39e399e7d6371ec1d -k 38bd9eb2cb29cc42ac38d6cdbe116760 -a "5dbb2884f3fe93664613e863c3bd2572855cf808765880ef1fa5787ceef8c793" -t "34a21cc3562f0ba141d73242e5a3b666" -q "d127b39d365d16246d2866b2ebabd201") Exp 8f9ec088580c23fc[...] Got Sending update buffer failed Failed to invoke testing [FAILED: 64-bit - 6.17.0-rc7] AEAD gcm(aes) synchronous stream non-aligned test 2 (/usr/local/libexec/libkcapi/kcapi -x 2 -s -c "gcm(aes)" -i 7815d4b06ae50c9c56e87bd7 -k ea38ac0c9b9998c80e28fb496a2b88d9 -a "853f98a750098bec1aa7497e979e78098155c877879556bb51ddeb6374cbaefc" -t "c4ce58985b7203094be1d134c1b8ab0b" -q "b03692f86d1b8b39baf2abb255197c98") Exp EBADMSG[...] Got Sending update buffer failed Failed to invoke testing Target arch is amd64 (7960X). Compiler is gcc (Gentoo 14.3.1_p20250801 p4) 14.3.1 20250801. Tested with binutils 2.44 and 2.45 with identical results. .config is at https://drive.google.com/file/d/1T9Iyqv_Ql4FsbMf975BPCQR9fNqmriAm/view?usp=… Note that this problem was discovered as part of the WolfSSL kernel crypto testing program, but is present in the kernel native crypto, which we test alongside our own crypto module in our nightlies.

1 0

cryptography
by Andre Coelho April 26, 2021

April 26, 2021

Greeting I think ive found a way to break AES, through brute force. The method is like starting at 0 and keep adding one's and trying the decryptition for each number. An int was used, and it took about <= 9 hours..so int is 4 bytes, to make 32bytes would need 9*8 hours. What i need are some assembly or c or whatever is the most fast language to use the cipher. There is a problem with IV, and salt that i didint consider...But sometimes i see pages saying that the IV is given, so dont know. The same thing that can crack AES can crack hashes, but it must find a function that does the same the the repeating function, but is fast to compute Later andre

1 0

(no subject)
by Theresa Avila April 5, 2020

April 5, 2020

1 0

omap-aes-gcm: fix corrupt output buffers
by Francis Le Bourse Jan. 19, 2018

Jan. 19, 2018

Hi, The output of the AES-GCM encryption or decryption is corrupted if the buffer crosses a page boundary. The culprit appears to be omap_crypto_cleanup(), scatterwalk_map_and_copy should only be called in the OMAP_CRYPTO_DATA_COPIED case. Currently the copy is also done in the OMAP_CRYPTO_BAD_DATA_LENGTH, resulting in random kernel data in the user output buffer. With the patch below, the operations are fine. diff --git a/drivers/crypto/omap-crypto.c b/drivers/crypto/omap-crypto.c index 2c42e4b..cde56ea 100644 --- a/drivers/crypto/omap-crypto.c +++ b/drivers/crypto/omap-crypto.c @@ -173,7 +173,7 @@ void omap_crypto_cleanup(struct scatterlist *sg, struct scatterlist *orig, buf = sg_virt(sg); pages = get_order(len); - if (orig && (flags & OMAP_CRYPTO_COPY_MASK)) + if (orig && (flags & OMAP_CRYPTO_DATA_COPIED)) scatterwalk_map_and_copy(buf, orig, offset, len, 1); if (flags & OMAP_CRYPTO_DATA_COPIED)

1 0

omap-aes: IV not updated after encrypt/decrypt operation
by Francis Le Bourse Jan. 19, 2018

Jan. 19, 2018

Hi, AES_REG_IV() registers should be read back at the end of encryption or decryption operations and the values returned to the caller. Add the code and helper to do just that. diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c index 49bd56f..744885b 100644 --- a/drivers/crypto/omap-aes.c +++ b/drivers/crypto/omap-aes.c @@ -97,6 +97,13 @@ static void omap_aes_write_n(struct omap_aes_dev *dd, u32 offset, omap_aes_write(dd, offset, *value); } +static void omap_aes_read_n(struct omap_aes_dev *dd, u32 offset, + u32 *value, int count) +{ + for (; count--; value++, offset += 4) + *value = omap_aes_read(dd, offset); +} + static int omap_aes_hw_init(struct omap_aes_dev *dd) { int err; @@ -389,6 +396,9 @@ static void omap_aes_finish_req(struct omap_aes_dev *dd, int err) pr_debug("err: %d\n", err); + if ((dd->flags & (FLAGS_CBC | FLAGS_CTR)) && dd->req->info) + omap_aes_read_n(dd, AES_REG_IV(dd, 0), dd->req->info, 4); + crypto_finalize_cipher_request(dd->engine, req, err);

1 0

wrong digest value using scatterlist crypto API
by aymen irt April 10, 2014

April 10, 2014

Hi all, In order to test kernel crypto API, I tried different methods for computing a SHA1 digest. First, I tried sockets with AF_ALG. Then, I tried ioctl with /dev/crypto after loading cryptodev.ko module. These two methods returned the same hash value as the one computed by OpenSSL over the same input buffer. My input is simply a 5 bytes table where each byte is equal to 0x0a. The SHA1 output is the following: 31 78 9a ce 8f db 0f ae 29 76 e8 30 3b 61 4c 51 d0 a1 39 a9. Then, I tried scatterlist crypto API. So, I tested the following module: int init_module(void) { uint8_t i=0, buf[20]={0}, m[5]={0x0a,0x0a,0x0a,0x0a,0x0a}; struct scatterlist sg; struct hash_desc desc; MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("sha1 test with crypto API"); MODULE_AUTHOR("aymen<aymen.irt(a)gmail.com>"); MODULE_ALIAS("cryptoapi test"); printk(KERN_INFO "\nScatterlist crypto API test\n"); desc.flags = 0; desc.tfm = crypto_alloc_hash("sha1", 0, CRYPTO_ALG_ASYNC); if(!desc.tfm){ printk(KERN_INFO "Error\n"); } sg_init_one(&sg, m, 5); crypto_hash_init(&desc); crypto_hash_update(&desc, &sg, 1); crypto_hash_final(&desc, buf); crypto_free_hash(desc.tfm); printk("\n"); for (i=0; i<20; i++) printk("%02x ", buf[i]); printk("\n"); return 0; } void cleanup_module(void) { printk(KERN_INFO "\nScatterlist crypto API test end...\n"); } My problem is when I insmod my test_cryptoapi.ko, i get a wrong SHA1 output. In fact, I get the following SHA1 digest: ad c8 3b 19 e7 93 49 1b 1c 6e a0 fd 8b 46 cd 9f 32 e5 92 fc. I would be grateful for any hint about this problem. Best regards, Aymen

1 0

loop-AES-v3.6a terrible slow!
by Gabriel VLASIU Feb. 13, 2011

Feb. 13, 2011

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! loop-AES-v3.6a is terrible, terrible slow. Tested on kernel 2.6.35.11. *** Using loopAES v3.6a # /usr/bin/time tar xjf xulrunner-2.0b11.source.tar.bz2 21.96user 20.86system 23:22.61elapsed 3%CPU (0avgtext+0avgdata 15664maxresident)k 132224inputs+940776outputs (3major+1511minor)pagefaults 0swaps # /usr/bin/time rm -rf mozilla-central/ 0.19user 24.34system 20:36.99elapsed 1%CPU (0avgtext+0avgdata 4832maxresident)k 0inputs+8outputs (0major+437minor)pagefaults 0swaps *** Using loopAES v3.5b - - does not compile clean. I had to apply this patch: - --- loop.c-2.6a.patched.ORIG 2010-11-09 16:32:02.000000000 +0200 +++ loop.c-2.6a.patched 2011-02-13 20:28:30.000000000 +0200 @@ -1520,7 +1520,11 @@ #endif blk_queue_max_sectors(lo->lo_queue, MAX_SECTORS); #endif +#if defined(QUEUE_FLAG_CLUSTER) lo->lo_queue->queue_flags &= ~(1 << QUEUE_FLAG_CLUSTER); +#else + lo->lo_queue->limits.cluster = 0; +#endif #if (LINUX_VERSION_CODE >= 0x20609) || defined(QUEUE_FLAG_ORDERED) loop_blk_queue_ordered(lo->lo_queue, QUEUE_ORDERED_NONE); #endif # /usr/bin/time tar xjf xulrunner-2.0b11.source.tar.bz2 20.83user 9.08system 4:50.09elapsed 10%CPU (0avgtext+0avgdata 15664maxresident)k 132056inputs+940776outputs (3major+1513minor)pagefaults 0swaps # /usr/bin/time rm -rf mozilla-central/ 0.11user 5.79system 3:02.13elapsed 3%CPU (0avgtext+0avgdata 4832maxresident)k 0inputs+0outputs (0major+437minor)pagefaults 0swaps Why is SO slow? Sincerely, Gabriel - -- // Gabriel VLASIU // // OpenGPG-KeyID : 0xE684206E // OpenGPG-Fingerprint: 0C3D 9F8B 725D E243 CB3C 8428 796A DB1F E684 206E // OpenGPG-URL : http://www.vlasiu.net/public.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFNWCsbeWrbH+aEIG4RAry9AJ0bIVv6ySnasmLT+KlLUPIrqCMkjwCfbfLe AdymT+WvU/abgM44cLWRIWs= =MJ2w -----END PGP SIGNATURE-----

1 0

loop-aes-modules on Debian Squeeze
by Tobias Walkowiak Feb. 7, 2011

Feb. 7, 2011

Does anybody know when there will be a package in the Debian squeeze repositories for the new default kernel 2.6.32? Until now there is still loop-aes-modules-2.6.26-2-amd64 available. Tobias -- count0(a)count0.net

1 0

Problem with losetup
by Felix Blanke Jan. 25, 2011

Jan. 25, 2011

Hi, I've a problem with the losetup when it is patched with loop-aes. If I'm using the unpatched losetup (from util-linux-ng) and looping a device like /dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part3 it is using readlink to track down the link to e.g. /dev/sda3. But if I'm using the patched losetup I don't see any readlink in the strace. Because no readlink is used there is a problem with device names which have more then 64 characters (the field "lo_name" is an array of 64 char). It is truncated like /dev/loop0: [0010]:6229 (/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par) encryption=AES128 That does make trouble with e.g. btrfs, because mkfs.btrfs uses the devicename provided by losetup to check if a device is mounted. That can't work with an incomplete devicename. Any thought on this problem? Regards, Felix

1 0

unsubcribe
by Sheldon Chen Jan. 10, 2011

Jan. 10, 2011

1 0