út 28. 10. 2025 v 6:55 odesílatel Michael Paquier <[email protected]> napsal:
> On Sun, Oct 26, 2025 at 11:20:53AM +0100, Filip Janus wrote: > > I have prepared a test case following the pattern from commit > 9244c11afe23 > > (RSA-PSS fix). > > Thanks, I'm able to reproduce your problem with the error you have, > after generating the certs. > > + my $mldsa_cert = "ssl/server-mldsa65.crt"; > + skip "ML-DSA-65 requires OpenSSL 3.5+ for certificate generation",1 > + unless -f $mldsa_cert; > > The certs are stored in the tree, regenerated by a `make sslfiles` run > in src/test/ssl/. We cannot rely on such a check to decide if this > scenario should be skipped or not. In past branches, like > REL_13_STABLE, one example of a "correct" way is done in 002_scram.pl > with HAVE_X509_GET_SIGNATURE_NID, where we rely on a compile check > when running the test. > While fixing the actual issue will take some time, I’ve fixed the requested test. Since I’m still quite new to the PG community, would it make sense to propose a patch that only adds the test? > > You are correct that, according to RFC 5929, we should ideally use the > hash > > function associated with the certificate's signatureAlgorithm. However, > if > > I understand it correctly, there are distinctions with ML-DSA: > > I investigated OpenSSL's API to retrieve the hash algorithm used by > ML-DSA, > > and I haven't found a suitable solution. > > > > ML-DSA seems to have an internal structure but no public API to extract > > SHAKE128/256 configuration. > > Hmm. Has this question been asked to upstream OpenSSL? Perhaps their > reply would be "you-are-doing-it-wrong", but it may be something where > their input may drive the implementation. > > > The ML-DSA Specifies > > > > ML-DSA (FIPS 204) uses SHAKE internally: > > - ML-DSA-44: SHAKE128 (128-bit security) > > - ML-DSA-65: SHAKE256 (192-bit security) > > - ML-DSA-87: SHAKE256 (256-bit security) > > Yeah, I've been reading around this area as well, while browsing the > code: > https://github.com/openssl/openssl/blob/master/doc/designs/ml-dsa.md > https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf > > There are traces in the OpenSSL code of the following things, not sure > if these could point at something: > NID_HASH_ML_DSA_44_WITH_SHA512 > NID_HASH_ML_DSA_65_WITH_SHA512 > NID_HASH_ML_DSA_87_WITH_SHA512 > > > ML-DSA doesn't have an "associated" hash function in the sense that > > RSA-SHA256 does. The SHAKE function is internal to the signing process, > not > > a separate digest step. For the purpose of channel binding (hashing the > > entire certificate), we need a traditional hash function. So that's why > > I've chosen SHA-256 > > Another thing that bugs me is that this patch would force sha-256 for > everything, without at least checks based on NID_ML_DSA_44, > NID_ML_DSA_65 or NID_ML_DSA_87. That may be more flexible, but I'm > wondering if it could become a problem long-term to enforce blindly > such a policy every time algo_nid is undefined. > > > Regarding NIDs and Future Extensions, I would expect growth, but I am > not a > > security specialist. > > This needs more study on my part, at least. Adding a couple more > folks in CC for now. Perhaps they have an opinion on the matter, I am > not the most familiar with these new toys in OpenSSL 3.5. > > Anyway, even with these points, I am not much a fan of adding again > a dependency to X509_get_signature_nid() while we have switched to > X509_get_signature_info() to be able to support RSA-PSS signatures. > It is annoying to have to rely again on X509_get_signature_nid() for > what's a new special case, NID_undef being the synonym of an error > usually, and that's what EVP_get_digestbynid() is complaining about in > this case. > -- > Michael >
0001-Add-regression-test-for-ML-DSA-channel-binding-suppo.patch
Description: Binary data
