crypto: af_alg - Allow additional ciphers for cryptsetup
PATCH 1/1 crypto: af_alg - Allow additional ciphers for cryptsetup
Add "xts(camellia)", "xts(serpent)", and "xts(twofish)" to the allowlist for af_alg_restrict=1. These niche AES alternatives have continued to see rare but persistent use via cryptsetup, which has historically relied on the AF_ALG support for these ciphers in XTS mode for performing the keyslot encryption. (cryptsetup v2.8.7 and later fall back to a temporary dm-crypt mapping, but that requires root.)
--- crypto/algif_skcipher.c | 3 +++ 1 file changed, 3 insertions(+)
crypto/algif_skcipher.c +3 -0
@@ -45,6 +45,9 @@ static const struct af_alg_allowlist_entry skcipher_allowlist[] = { { "ecb(des)", true }, /* iwd */ { "hctr2(aes)", false }, /* cryptsetup */ { "xts(aes)", false }, /* cryptsetup benchmark */ + { "xts(camellia)", false }, /* cryptsetup */ + { "xts(serpent)", false }, /* cryptsetup */ + { "xts(twofish)", false }, /* cryptsetup */ {}, };
base-commit: e264401ce4776a288524e5b87593d4d864147115
Signature · 1 line
2.54.0
Quoted 17 lines · Eric Biggers
Add "xts(camellia)", "xts(serpent)", and "xts(twofish)" to the allowlist for af_alg_restrict=1. These niche AES alternatives have continued to see rare but persistent use via cryptsetup, which has historically relied on the
AF_ALGsupport for these ciphers in XTS mode for performing the keyslot encryption. (cryptsetup v2.8.7 and later fall back to a temporary dm-crypt mapping, but that requires root.)Signed-off-by Eric Biggers <[email protected]>--- crypto/algif_skcipher.c | 3 +++ 1 file changed, 3 insertions(+)crypto/algif_skcipher.c +0
-0
crypto/algif_skcipher.c static const struct af_alg_allowlist_entry skcipher_allowlist[] = { · line 51
Quoted 7 lines
crypto/algif_skcipher.c +3
-0@@ -45,6 +45,9 @@ static const struct af_alg_allowlist_entry skcipher_allowlist[] = { { "ecb(des)", true }, /* iwd */ { "hctr2(aes)", false }, /* cryptsetup */ { "xts(aes)", false }, /* cryptsetup benchmark */ + { "xts(camellia)", false }, /* cryptsetup */ + { "xts(serpent)", false }, /* cryptsetup */ + { "xts(twofish)", false }, /* cryptsetup */ {},
Well, if we are going this way, I would also add Aria and SM4 (currently usable only in cryptsetup main branch).
Milan
p.s.
There is another user of AF_ALG hash, hardlink in util-linux, see
https://github.com/util-linux/util-linux/blob/master/lib/fileeq.c
Quoted 13 lines · Milan Broz
Quoted 12 lines · Eric Biggers
Add "xts(camellia)", "xts(serpent)", and "xts(twofish)" to the allowlist for af_alg_restrict=1. These niche AES alternatives have continued to see rare but persistent use via cryptsetup, which has historically relied on the
AF_ALGsupport for these ciphers in XTS mode for performing the keyslot encryption. (cryptsetup v2.8.7 and later fall back to a temporary dm-crypt mapping, but that requires root.)Signed-off-by Eric Biggers <[email protected]>--- crypto/algif_skcipher.c | 3 +++ 1 file changed, 3 insertions(+)
Quoted 15 lines
crypto/algif_skcipher.c static const struct af_alg_allowlist_entry skcipher_allowlist[] = { · line 51
Quoted 12 lines
crypto/algif_skcipher.c +3
-0@@ -45,6 +45,9 @@ static const struct af_alg_allowlist_entry skcipher_allowlist[] = { { "ecb(des)", true }, /* iwd */ { "hctr2(aes)", false }, /* cryptsetup */ { "xts(aes)", false }, /* cryptsetup benchmark */ + { "xts(camellia)", false }, /* cryptsetup */ + { "xts(serpent)", false }, /* cryptsetup */ + { "xts(twofish)", false }, /* cryptsetup */ {},Well, if we are going this way, I would also add Aria and SM4 (currently usable only in cryptsetup main branch).
I'm adding these three because they seem to have a history of occasional use, as can be seen by web search results including their mentions in various forums, documentation, etc. So I worry about breaking users of them who upgrade their kernel and still have cryptsetup < 2.8.7.
It doesn't seem like the same as true of aria-xts or sm4-xts. And as you said they are usable only on the cryptsetup main branch -- which I understand now consistently uses the fallback to a temporary dm-crypt mapping (at least when run as root). So perhaps we don't actually need to allow "xts(aria)" and "xts(sm4)" as well?
The point isn't to add things that could theoretically be used, but rather add the minimum set that's needed to keep actual existing users working.
Quoted 2 lines
There is another user of
AF_ALGhash, hardlink in util-linux, see
https://github.com/util-linux/util-linux/blob/master/lib/fileeq.c
The AF_ALG use in 'hardlink' is unnecessary and has just been causing problems
(https://sporks.space/2026/05/19/chasing-down-why-installing-the-kernel-segfaulted/).
Fortunately, it's not a hard dependency, as it already has a working runtime fallback. This was discussed on the util-linux issue tracker as well, and I understand the AF_ALG use is planned to be removed.
- Eric
Quoted 41 lines · Eric Biggers
Quoted 13 lines · Milan Broz
Quoted 12 lines · Eric Biggers
Add "xts(camellia)", "xts(serpent)", and "xts(twofish)" to the allowlist for af_alg_restrict=1. These niche AES alternatives have continued to see rare but persistent use via cryptsetup, which has historically relied on the
AF_ALGsupport for these ciphers in XTS mode for performing the keyslot encryption. (cryptsetup v2.8.7 and later fall back to a temporary dm-crypt mapping, but that requires root.)Signed-off-by Eric Biggers <[email protected]>--- crypto/algif_skcipher.c | 3 +++ 1 file changed, 3 insertions(+)Quoted 15 lines
crypto/algif_skcipher.c static const struct af_alg_allowlist_entry skcipher_allowlist[] = { · line 51
Quoted 12 lines
crypto/algif_skcipher.c +3
-0@@ -45,6 +45,9 @@ static const struct af_alg_allowlist_entry skcipher_allowlist[] = { { "ecb(des)", true }, /* iwd */ { "hctr2(aes)", false }, /* cryptsetup */ { "xts(aes)", false }, /* cryptsetup benchmark */ + { "xts(camellia)", false }, /* cryptsetup */ + { "xts(serpent)", false }, /* cryptsetup */ + { "xts(twofish)", false }, /* cryptsetup */ {},Well, if we are going this way, I would also add Aria and SM4 (currently usable only in cryptsetup main branch).
I'm adding these three because they seem to have a history of occasional use, as can be seen by web search results including their mentions in various forums, documentation, etc. So I worry about breaking users of them who upgrade their kernel and still have cryptsetup < 2.8.7.
It doesn't seem like the same as true of aria-xts or sm4-xts. And as you said they are usable only on the cryptsetup main branch -- which I understand now consistently uses the fallback to a temporary dm-crypt mapping (at least when run as root). So perhaps we don't actually need to allow "xts(aria)" and "xts(sm4)" as well?
Quoted 3 lines
The point isn't to add things that could theoretically be used, but rather add the minimum set that's needed to keep actual existing users working.
Do we need to add cbc(...) for these algorithms as well?
- Eric
Herbert Xu
maintainerQuoted 11 lines · Eric Biggers
Add "xts(camellia)", "xts(serpent)", and "xts(twofish)" to the allowlist for af_alg_restrict=1. These niche AES alternatives have continued to see rare but persistent use via cryptsetup, which has historically relied on the
AF_ALGsupport for these ciphers in XTS mode for performing the keyslot encryption. (cryptsetup v2.8.7 and later fall back to a temporary dm-crypt mapping, but that requires root.)Signed-off-by Eric Biggers <[email protected]>--- crypto/algif_skcipher.c | 3 +++ 1 file changed, 3 insertions(+)
Patch applied. Thanks.
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt