Re: [EXT] Re: How to generate ML-KEM key-pair?

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 <[email protected]> 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-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
> 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-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/4981CB45-2FE5-46DB-9A2E-ED823957B2C3%40ll.mit.edu.