That’s great to hear, thanks! Do you know roughly when 3.5.0 is planned for release? Also, I know that many people here want Hybrids. My use case, however, requires “pure” ML-KEM and ML-DSA. Will they be available in 3.5? Both directly (like in the CLI examples you showed) and in TLS? Thank you very much! And enjoy the Holidays! — Regards, Uri Secure Resilient Systems and Technologies MIT Lincoln Laboratory > On Dec 29, 2024, at 23:38, Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> wrote: > > !-------------------------------------------------------------------| > This Message Is From an External Sender > This message came from outside the Laboratory. > |-------------------------------------------------------------------! > > On Mon, Dec 30, 2024 at 02:53:24AM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > >>> Once OpenSSL 3.5 is released, that'll be ML-KEM-1024, we'll be using the >>> NIST names for the algorithms. Only the TLS groups will be hyphen-free. >> >> Now I’m getting PQ algorithms from the OQS provider available from >> Open Quantum Safe >> <https://github.com/open-quantum-safe/oqs-provider.git>. Does the >> above mean that once OpenSSL 3.5 is released, I won’t need to use an >> extra provider, and OQS provider would be included in the standard >> distribution? Making the “outside” provider I’m currently using – >> obsolete? > > We won't in fact bundle the OQS provider, rather it won't be needed, > because we'll ship an integrated ML-KEM, Hybrids for TLS and ML-DSA > implementation in the OpenSSL default provider (and at some point also > the FIPS provider). The ML-KEM and related TLS hybrids are working > already, but still need some reviews and some polish of the error > reporting, which is in some places still a bit skimpy. > >>> The "untrusted" (not a priori trusted) certificates were not from the >>> trust store, I think I mentioned this during the presentation. >> >> I’ll hold off my questions about this part until I watch the >> presentation then. I guess, merely stating “-trusted some_ca_cert.pem” >> on the command line isn’t going to cut it… > > There's nothing to do here, if you believe that something needs to be > done to make these not show up, you're quire mistaken, the verification > succeeded, just pretend you did not see those "untrusted" markers, they > can be useful diagnostics if you know what they mean, but can be safely > ignored. > > The only time you won't see "untrusted" is when the certificate you're > verifying is one of the ones from your trust store, that's not a common > thing to need/want to do. Usually you're verifying certificates > ultimately issued by some trust-anchor, but that are not themselves > trust anchors. > > -- > Viktor. > > -- > You received this message because you are subscribed to the Google Groups "openssl-users" group. > To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe@xxxxxxxxxxx. > To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/Z3IjoEJoVnXbZO00%40chardros.imrryr.org. -- You received this message because you are subscribed to the Google Groups "openssl-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe@xxxxxxxxxxx. To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/4981CB45-2FE5-46DB-9A2E-ED823957B2C3%40ll.mit.edu.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
