cryptosystem, introduced already in 2010.
* There is a cost of 2-step migration (to hybrid and then pure PQ), I don’t
believe it’s good to force you to pay the cost.
Additionally, I think I would also get a codepoint for MLKEM-512.
--
Kris Kwiatkowski
Cryptography Dev
So, based on FIPS 140-3 I.G., section C.K., resolution 5, [1]. "SP800-186 does
not impact the curves permitted under SP 800-56Arev3. Curves that are included
in SP 800-186 but not included in SP 800-56Arev3 are not approved for key
agreement. E.g., the ECDH X25519 and X448 key agreement schemes
However, the difference is stated to be UncompressedPointRepresentation
for P256 from TLS 1.3. AFACIT, that is 65 bytes (1 legacy_form byte,
32 bytes for x, 32 bytes for y).
Right, one byte for the legacy_form is missing. Let me fix it.___
TLS
Hello,
The codepoint for P-256+Kyber768 has been just assigned by IANA. The value is
0x639A.
Thanks Rich for pointing to the request form.
Kind regards,
Kris
On 18/05/2023 22:00, Christopher Wood wrote:
Thanks, Rich!
On May 17, 2023, at 3:44 PM, Salz, Rich wrote:
* Can we get
On 23/08/2022 01:39, Martin Thomson wrote:
On Tue, Aug 23, 2022, at 00:11, Kris Kwiatkowski wrote:
As X25519 is not FIPS-approved, the lab won't be able to test it,
OK, hypothetical question, but maybe an important one.
Why would a certification lab care? We compose secrets with non-secrets
On 22/08/2022 14:24, Bas Westerbaan wrote:
Here they're speaking about adding non-FIPS PQ to a non-PQ FIPS kex,[2] but
the other way around is also ok — what am I missing?
Let's assume Kyber is FIPS-approved. Indeed, you'll be able to have
a FIPS library with Z generated by Kyber and T
I support those choices, but would also add P256+Kyber512.
* (1) same reason as below (by Scott)
* (2) to be able to declare security of generated keys in FIPS-mode for
_both_ - classical and post-quantum schemes (once Kyber is standardized).
After double-checking with NIST today, currently
