can someone explain why the guy who posted 45 patches to "rewrite the kernel in c++" in 2018 is posting completely insane modifications to crypto/ in his linux-fs tree (edit: this is all on master and i assume it's going in the 7.0 rc) https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=keys-pqc&id=f3eccecd782dbaf33d5ad0d1fd22ea277300acdb

pkcs7: Allow the signing algo to do whatever digestion it wants itself

Allow the data to be verified in a PKCS#7 or CMS message to be passed
directly to an asymmetric cipher algorithm (e.g. ML-DSA) if it wants to do
whatever passes for hashing/digestion itself. The normal digestion of the
data is then skipped as that would be ignored unless another signed info in
the message has some other algorithm that needs it.

so already this is framing ML-DSA as like doing something extra but the NIST publication indicates that's the job of HashML-DSA

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf

this exact fucking guy has an entirely separate "keyutils" repo (he apparently has a patent in this space?) https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/keyutils.git/ no activity for 3 years

Rename ->digest and ->digest_len to ->m and ->m_size to represent the input
to the signature verification algorithm, reflecting that ->digest may no
longer actually *be* a digest.

https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=keys-pqc&id=f728074f1f577565c97e465652c3d4afb0964013

diff --git a/crypto/asymmetric_keys/asymmetric_type.c b/crypto/asymmetric_keys/asymmetric_type.c
index 348966ea2175c9..2326743310b1ee 100644
--- a/crypto/asymmetric_keys/asymmetric_type.c
+++ b/crypto/asymmetric_keys/asymmetric_type.c
@@ -593,10 +593,10 @@ static int asymmetric_key_verify_signature(struct kernel_pkey_params *params,
{
struct public_key_signature sig = {
.s_size = params->in2_len,
- .digest_size = params->in_len,
+ .m_size = params->in_len,
.encoding = params->encoding,
.hash_algo = params->hash_algo,
- .digest = (void *)in,
+ .m = (void *)in,
.s = (void *)in2,
};
pkcs7: Allow the signing algo to do whatever digestion it wants itself - kernel/git/dhowells/linux-fs.git - VFS and Filesystem bits

i'm gonna have to send an email. this is accepted in 7.0 rc and on my laptop because i pulled master
reading the nist doc first. you will never guess that it says "strongly unforgeable" without citation and with no glossary entry. looking it up and "strongly unforgeable" appears to be strictly a thing for module-learning with errors lattice

https://eprint.iacr.org/2010/070.pdf

Our construction offers the same efficiency as the “bonsai tree” scheme but supports the stronger notion of strong unforgeability.

hmmmmm sounds fascist

bonsai tree definitely sounds tougher. you know they don't choose specially cultured trees for those? that's a real tree and it was made tough and beautiful

Over the past several years, there has been steady progress toward building quantum computers. The
security of many commonly used public-key cryptosystems will be at risk if large-scale quantum computers
are ever realized. This would include key-establishment schemes and digital signatures that are based on
integer factorization and discrete logarithms (both over finite fields and elliptic curves).

with you

As a result, in 2016, NIST

you've lost me there

choose a normal fucking name what's wrong with you

ML-DSA is derived from one of the selected schemes, CRYSTALS-DILITHIUM [5, 6]

well into the foreseeable future, including after the advent of cryptographically relevant quantum computers.

"cryptographically relevant" makes no fucking sense. 25. cmon. a horse can be trained to factor 25

destroy:
An action applied to a key or a piece of secret data. After a key or a piece of
secret data is destroyed, no information about its value can be recovered.

the definition of digital signature is complete word salad

The result of a cryptographic transformation of data that, when properly implemented, provides a mechanism to verify origin authenticity and data integrity and to enforce signatory non-repudiation.

"when properly implemented". psh yeah you can do cryptographic transformation of data, but can you provide a mechanism to verify origin authenticity and data integrity and to enforce signatory non-repudiation?????

🚨 fedi entities: NIST has a glossary entry for you

An individual person, organization, device, or process. Used interchangeably with party.

🥳

oh my god yes this definition of equivalence

Two processes are equivalent if the same output is produced when the same values are input to each process

ok, cool

(either as input parameters, as values made
available during the process, or both).

literally what the fuck

A function on bit strings in which the output can be extended to any desired length.

any length. ok

as long as the specified output length is
sufficiently long to prevent trivial attacks

wouldn't really say any

oh lmao and they're like "it's one-way", a definition that can only be disproven. collision-resistant: yes it has a meaning. but we're past the c entries. you're too late honey!
is a hash value a message digest?
a hash value is much broader than a message digest
only glossary entry that's a redirect
bro they have shall and should in bold. it's so over

oh my GOD

trusted third party (TTP)
An entity other than the key pair owner and the verifier that is trusted by the owner, the verifier, or both. Sometimes shortened to “trusted party.”

is it? is it sometimes shortened to that?

signature validation
The mathematical verification of the digital signature along with obtaining the appropriate assurances (e.g., public-key validity, private-key possession, etc.).

LMAO literally "the math part plus the government surveillance"

tagging the astral engineer who wrote this because pgp keys were not susceptible to his little wehow tutorial on cryptographic surveillance https://blog.yossarian.net/2023/05/21/PGP-signatures-on-PyPI-worse-than-useless
PGP signatures on PyPI: worse than useless

PyPI has done everything right, including purposely removing frontend support for PGP years ago.

literally intended to make you think an Event had happened. nope!

Type casting. The variable 𝑥 is assigned a value in a set 𝑆 that is constructed from
the value of an expression 𝑦 in a possibly different set 𝑇. The set 𝑇 and the mapping
from 𝑇 to 𝑆 are not explicitly specified, but they should be obvious from the context
in which this statement appears.

this is like. a math notation? "should be obvious from the context" honey no you need to tell me about this hash scheme and shut up

The Number Theoretic Transform (NTT) is a specific isomorphism between the rings 𝑅𝑞 and 𝑇𝑞.

that is nippon telephone and teletype

The motivation for using NTT is that multiplication is considerably faster in the ring 𝑇𝑞

that's good. i was worried there was any history of ulterior motives for NIST choosing a specific set of parameters to construct a ring

they mention things that make absolutely no sense and next line oh yeah this symbol means composition of matrix multiplication
i still hate the capital R_m used for the ring of single-variable polynomials. hated it when dan jackoff bernstein used it too
oh great the pdf links mysteriously fail at hashml-dsa.sign yesssssss and for the verify phase
algorithms "4" and "5"
YOU CAN'T BE FUCKING SERIOUS

In the HashML-DSA version, the message input to ML-DSA.Sign_internal is the result of applying either a hash function or a XOF to the content to be signed.

so the red-hat guy making insane crypto changes is also just saying insane shit about the crypto that people can't call him out on. ml-dsa does not "do its own hashing"

For some cryptographic modules that generate ML-DSA signatures, hashing the message in step 6 of ML-DSA.Sign_internal may result in unacceptable performance if the message 𝑀 is large.

this fucking high school science project is safe against quantum computers which not only will exist, but could even exist RIGHT NOW!

which is why we are doing this in the open together

come on man don't do this

For some use cases, this may be addressed by signing a digest of the message along with some domain separation information rather than signing the message directly. This version of ML-DSA is known as “pre-hash” ML-DSA or HashML-DSA . In general, the “pure” ML-DSA version is preferred.

CRYPTOGRAPHICALLY RELEVANT

These algorithms are used to support the key compression optimization of ML-DSA.

"compression"

if you could "compress" it, it wouldn't be "encrypted"

OPTIMIZATION!!!!!!!

They involve dropping the 𝑑 low-order bits of each coefficient of the polynomial vector 𝐭 from the public key using the function Power2Round.

sure that's fine they're lower order right that's fine right

However, in order to make this optimization work,

that's what i wanna hear

additional information called a “hint” needs to be provided in the signature

i dare you to use a single normal name

to allow the verifier to reconstruct enough of the information in the dropped public-key bits to verify the signature.

hm is that what the verifier is doing? reconstructing information? tbh don't care

This standard makes use of the functions SHAKE256 and SHAKE128, as defined in FIPS 202 [7]. While FIPS 202 specifies these functions as inputting and outputting bit strings, most implementations treat inputs and outputs as byte strings.

honey fips 202 is not the part you need to cite

literally

Using this approach, security strength is not described by a single number, such as “128 bits of security.”

this is gonna be good

Instead, each ML-DSA parameter set is claimed to be at least as secure as a generic block cipher with a prescribed key size or a generic hash function with a prescribed output length.

you fucking prick that's the same thing fuck you

YES!!!! YES!!!!

More precisely, it is claimed that the computational resources needed to break ML-DSA are greater than or equal to the computational resources needed to break the block cipher or hash function when these computational resources are estimated using any realistic model of computation.

yeah see it's the quantum factor

oh they set themselves up so hard

Different models of computation can be more or less realistic and, accordingly, lead to more or less accurate estimates of security strength.

nodding yes jack nicholson gif

zero normal names

For the default “hedged” version of ML-DSA signing

shut the fuck up you're not cute

for the optional deterministic variant,

that's definitely a line to only write out in the pseudocode of algorithm 2 and nowhere else. bet you wish you could do that to my code huh

hey just so it's clear all of linux-crypto and some guy from cloudflare signed off the c++ rewrite guy modifying the entire cryptographic implementation because of shit he made up

bro oh my god
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=keys-pqc&id=2c62068ac86bdd917a12eef49ba82ec8b091208b

It may be that this is inadvisable.

you can't say that man. your code is on my laptop and you are actively obfuscating it in linux-fs

x509: Separately calculate sha256 for blacklist - kernel/git/dhowells/linux-fs.git - VFS and Filesystem bits

Note that whilst ML-DSA does allow for an "external mu", CMS doesn't yet have that standardised.

hey is it good when the IETF refers to the CMS and doesn't link it

Errata Exist

oh thanks

This is because in most situations, CMS signatures are computed over a set of signed attributes that contain a hash of the content, rather than being computed over the message content itself.

see the thing about the IETF? they never let me down

ML-DSA signature generation and verification is significantly faster than SLH-DSA.

no clue what SLH is but it must be a new form of quantum

ML-DSA depends on high-quality random numbers that are suitable for use in cryptography.

yeah the problem was your low-quality commoner randoms

The use of inadequate pseudo-random number generators (PRNGs) to generate such values can
significantly undermine the security properties offered by a cryptographic algorithm.

if i know the IETF the next line "don't worry buddy, [whispers] we all do it like this!"

oh DAMN i forgot their trick move

For instance, an attacker may find it much easier to reproduce the PRNG environment that produced
any private keys, searching the resulting small set of possibilities, rather than brute-force
searching the whole key space.

when they tell you an extremely specific and nonobvious attack strategy

do you think vint cerf will ever fully mask off darth vader or has he already done that

who the hell is this guy https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=keys-next&id=965e9a2cf23b066d8bdeb690dff9cd7089c5f667

Only display the "PKCS7: Waived invalid module sig (has authattrs)" once.

it's not just him

Suggested-by: Lenny Szubowicz <[email protected]>
Signed-off-by: David Howells <[email protected]>
Tested-by: Lenny Szubowicz <[email protected]>
cc: Lukas Wunner <[email protected]>
cc: Ignat Korchagin <[email protected]>
cc: Jarkko Sakkinen <[email protected]>
cc: Stephan Mueller <[email protected]>
cc: Eric Biggers <[email protected]>
cc: Herbert Xu <[email protected]>
cc: [email protected]
cc: [email protected]
pkcs7: Change a pr_warn() to pr_warn_once() - kernel/git/dhowells/linux-fs.git - VFS and Filesystem bits

omg choose your fighter

git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
https://kernel.googlesource.com/pub/scm/linux/kernel/git/dhowells/linux-fs.git

which domain+protocol is least likely to pwn me from orbit for cloning it

i'm doing kernel.org https

didn't post this earlier but this is what it looks like if you happened to pull master randomly this week like i did (keyword ML-DSA)

*
* Public-key cryptography
*
RSA (Rivest-Shamir-Adleman) (CRYPTO_RSA) [Y/?] y
DH (Diffie-Hellman) (CRYPTO_DH) [Y/?] y
RFC 7919 FFDHE groups (CRYPTO_DH_RFC7919_GROUPS) [Y/n/?] y
ECDH (Elliptic Curve Diffie-Hellman) (CRYPTO_ECDH) [Y/?] y
ECDSA (Elliptic Curve Digital Signature Algorithm) (CRYPTO_ECDSA) [Y/?] y
EC-RDSA (Elliptic Curve Russian Digital Signature Algorithm) (CRYPTO_ECRDSA) [M/n/y/?] m
ML-DSA (Module-Lattice-Based Digital Signature Algorithm) (CRYPTO_MLDSA) [N/m/y/?] (NEW) y
*
* Asymmetric (public-key cryptographic) key type
*
Asymmetric (public-key cryptographic) key type (ASYMMETRIC_KEY_TYPE) [Y/?] y
Asymmetric public-key crypto algorithm subtype (ASYMMETRIC_PUBLIC_KEY_SUBTYPE) [Y/?] y
X.509 certificate parser (X509_CERTIFICATE_PARSER) [Y/?] y
PKCS#8 private key parser (PKCS8_PRIVATE_KEY_PARSER) [M/n/y/?] m
PKCS#7 message parser (PKCS7_MESSAGE_PARSER) [Y/?] y
Waive rejection of authenticatedAttributes for ML-DSA (PKCS7_WAIVE_AUTHATTRS_REJECTION_FOR_MLDSA) [N/y/?] (NEW) n
PKCS#7 testing key type (PKCS7_TEST_KEY) [N/m/y/?] n
Support for PE file signature verification (SIGNED_PE_FILE_VERIFICATION) [Y/n/?] y
Run FIPS selftests on the X.509+PKCS7 signature verification (FIPS_SIGNATURE_SELFTEST) [N/m/y/?] n
*
* Certificates for signature checking
*
File name or PKCS#11 URI of module signing key (MODULE_SIG_KEY) [certs/signing_key.pem] certs/signing_key.pem
Type of module signing key to be generated
1. RSA (MODULE_SIG_KEY_TYPE_RSA)
> 2. ECDSA (MODULE_SIG_KEY_TYPE_ECDSA)
3. ML-DSA-44 (MODULE_SIG_KEY_TYPE_MLDSA_44) (NEW)
4. ML-DSA-65 (MODULE_SIG_KEY_TYPE_MLDSA_65) (NEW)
5. ML-DSA-87 (MODULE_SIG_KEY_TYPE_MLDSA_87) (NEW)
choice[1-5?]: 2
Provide system-wide ring of trusted keys (SYSTEM_TRUSTED_KEYRING) [Y/?] y
Additional X.509 keys for default system keyring (SYSTEM_TRUSTED_KEYS) []
Reserve area for inserting a certificate without recompiling (SYSTEM_EXTRA_CERTIFICATE) [N/y/?] n
Provide a keyring to which extra trustable keys may be added (SECONDARY_TRUSTED_KEYRING) [Y/n/?] y
Only allow additional certs signed by keys on the builtin trusted keyring (SECONDARY_TRUSTED_KEYRING_SIGNED_BY_BUILTIN) [N/y/?] n
Provide system-wide ring of blacklisted keys (SYSTEM_BLACKLIST_KEYRING) [Y/n/?] y
Hashes to be preloaded into the system blacklist keyring (SYSTEM_BLACKLIST_HASH_LIST) []
Provide system-wide ring of revocation certificates (SYSTEM_REVOCATION_LIST) [Y/n/?] y
X.509 certificates to be preloaded into the system blacklist keyring (SYSTEM_REVOCATION_KEYS) []
Allow root to add signed blacklist keys (SYSTEM_BLACKLIST_AUTH_UPDATE) [Y/n/?] y

so of course i was like:

Waive rejection of authenticatedAttributes for ML-DSA (PKCS7_WAIVE_AUTHATTRS_REJECTION_FOR_MLDSA) [N/y/?] (NEW) n

ok

crypto/asymmetric_keys/Kconfig
47-config PKCS7_MESSAGE_PARSER
48- tristate "PKCS#7 message parser"
49- depends on X509_CERTIFICATE_PARSER
50- select CRYPTO_HASH
51- select ASN1
52- select OID_REGISTRY
53- help
54- This option provides support for parsing PKCS#7 format messages for
55- signature data and provides the ability to verify the signature.
56-
57:config PKCS7_WAIVE_AUTHATTRS_REJECTION_FOR_MLDSA
58- bool "Waive rejection of authenticatedAttributes for ML-DSA"
59- depends on PKCS7_MESSAGE_PARSER
60- depends on CRYPTO_MLDSA
61- help
62- Due to use of CMS_NOATTR with ML-DSA not being supported in
63- OpenSSL < 4.0 (and thus any released version), enabling this
64- allows authenticatedAttributes to be used with ML-DSA for
65- module signing. Use of authenticatedAttributes in this
66- context is normally rejected.
67-

crypto/asymmetric_keys/pkcs7_parser.c
85- */
86-static int pkcs7_check_authattrs(struct pkcs7_message *msg)
87-{
88- struct pkcs7_signed_info *sinfo;
89- bool want = false;
90-
91- sinfo = msg->signed_infos;
92- if (!sinfo)
93- goto inconsistent;
94-
95:#ifdef CONFIG_PKCS7_WAIVE_AUTHATTRS_REJECTION_FOR_MLDSA
96- msg->authattrs_rej_waivable = true;
97-#endif
98-
99- if (sinfo->authattrs) {
100- want = true;
101- msg->have_authattrs = true;
102:#ifdef CONFIG_PKCS7_WAIVE_AUTHATTRS_REJECTION_FOR_MLDSA
103- if (strncmp(sinfo->sig->pkey_algo, "mldsa", 5) != 0)
104- msg->authattrs_rej_waivable = false;
105-#endif
106- } else if (sinfo->sig->algo_takes_data) {
107- sinfo->sig->hash_algo = "none";
108- }
109-
110- for (sinfo = sinfo->next; sinfo; sinfo = sinfo->next) {
111- if (!!sinfo->authattrs != want)
112- goto inconsistent;
so the reason i was concerned about this was because of linus telling an mm maintainer https://lore.kernel.org/linux-mm/CAHk-[email protected]/ hey you can't remove anything from gitignore anymore because of some drive-by contributor who might commit ? ? a build output? with security implications ? i was going to propose a checksummed cache dir scheme to the kernel build (seriously) and was typing up an email (not to linus but on the subject) and this kept fucking up my config
Re: [GIT PULL] MM updates for 7.0-rc1 - Linus Torvalds

the thing about kconfig is that it notifies you for new values but not for outdated ones. it will produce a warning for invalid values. so anyway if you waive that now and it stays in kconfig you (or whoever uses that config of yours are going to have a silent vuln
for that matter why is .config gitignored in the first place? the exact same as bootstrap.toml in the rustc repo, despite being incredibly important and not remotely something you want to risk deleting. many hours/days of work i've put into both

If ML-DSA signing is implemented in a hardware device such as a hardware security module (HSM) or a portable cryptographic token, implementers might want to avoid sending the full content to the device for performance reasons.

it seems like performance characteristics are not necessarily just a matter of being research-quality mathematics but rather a feature in themselves (for the IETF)

OMG LOL

Additionally, the pure variant of ML-DSA does support a form of pre-hash via external
calculation of the "μ" (GREEK SMALL LETTER MU, U+03BC) "message representative" value
described in Section 6.2 of [FIPS204].

first unicode symbol in an IETF spec.....they must be desperate

Federal Information Processing Standard (FIPS) 205, Stateless Hash-Based Digital Signature Standard

This standard specifies the stateless hash-based digital signature algorithm (SLH-DSA). Digital signatures are used to detect unauthorized modifications to data and to authenticate the identity of the signatory. In addition, the recipient of signed data can use a digital signature as evidence in demonstrating to a third party that the signature was, in fact, generated by the claimed signatory. This is known as non-repudiation since the signatory cannot easily repudiate the signature at a later time. SLH-DSA is based on SPHINCS+, which was selected for standardization as part of the NIST Post-Quantum Cryptography Standardization process.

CSRC | NIST

@hko i was wondering why i had never ever heard that word that sounds like aliens making fun of english "repudiation"

This is known as non-repudiation since the signatory cannot easily repudiate the signature at a later time.

you know what? i can't repudiate that

@hko can i interest you in this sequence of commits pushed to master https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-pqc&showmsg=1 this user has an unused keyutils repo and is just saying falsehoods https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=keys-pqc&id=f728074f1f577565c97e465652c3d4afb0964013

i'm going to figure out how to contact someone about it because it has gone way too far for my comfort

kernel/git/dhowells/linux-fs.git - VFS and Filesystem bits

@hko NO WAY IT'S LITERALLY JUST A SIGNATURE

@hko who writes this stuff

Agencies are advised that digital signature key pairs shall not be used for other purposes.

@hko quick someone suggest an edit

This standard becomes effective immediately upon final publication.

@hipsterelectron oh yes, ml-dsa and slh-dsa are both signing algorithms.
The latter is ridiculously heavy.

In the OpenPGP pqc draft, the first of the two is only allowed as one part of a "composite" signature that includes a traditional signature (e.g. ml-dsa + ed25519)

@hko i quite like composite keys! kyber is neat and while the nist reference implementation had that hilarious miscompile in 2023-2024 nist will do anything to harm good crypto
@hko from reading the table of contents this sounds like "what if we did tree-based hashing and made it bad"
@hipsterelectron i have not tried to understand the innards of the algorithms so far 😬 (I've just used them via libraries)
@hko i don't tend to waste my time on obfuscated work
@hipsterelectron but except their relative novelty, large key and signature sizes, they perform exactly the role that any asymmetric signature algorithm does
@hko i really disliked signal's new cryptographer explicitly trading off between key size and other security properties. the key size requires them to perform a huge number of tradeoffs which their eurocrypt paper frankly obfuscated. i would never ever be responsible for others' safety like that. i won't begin the rant again but rolfe schmidt has raised every red flag
@hko this was a lovely paper his page 60 introduced me to though https://eprint.iacr.org/2020/148.pdf
@hipsterelectron it has poor performance characteristics but security lowers to a hash function's
@leo similar to bazel which is used as the trojan horse for the hardcoded python binary you cannot change
@leo bazel would OOM actually
kernel/git/dhowells/linux-fs.git - VFS and Filesystem bits