Most message encryption schemes don't use this alone. This is a Key Encapsulation Method (KEM) and it's designed as a way to exchange key information between two parties, much like Ephemeral Diffie Hellman (EDH) with Ed25519. However many are using Kyber _with_ Ed25519 as a hybrid system. The keying material generates using both schemes are fed into a Key Derivation Function (KDF) to generate a shared symmetric key and then uses AES-GCM or ChaCha20Poly1305 to encrypt any subsequent messages.
The reason why we want Kyber is that it's supposed to be post-quantum secure. Ed25519 does not have evidence that it is post-quantum secure, so using a hybrid system does at least guarantee that your scheme is post-quantum ready. The reason you don't immediately switch to Kyber is in case of dodgy initial Kyber implementations, or unknown protocol issues we have not yet discovered.
There's already a named attack on kyber as well. `KyberSlash`
http://kyberslash.cr.yp.to/
as best I can tell it seems to be implementation specific rather than about kyber as a spec, but still worth knowing about
It's just not that they're implementation specific, but they're also side-channel timing attacks. Not that they shouldn't be discovered and fixed, but this sort of thing is kind of inevitable in the first days of a brand-new protocol, and I don't really think it deserves a named vulnerability. I can't imagine it won't be fixed in short order.
there is quite a heated argument in the NIST comments regarding kyber. DJB is not impressed with how they calculated some kind of security bound. The kyber folks (and maybe some others) seem to think DJB is a prick.
This is so far above my pay grade that I don't know what to think. DJB has a tendency to be right, but then again: he is the kind of guy that checks the return value of printf even in non-critical paths. As one wants a crypto guy to be, I guess...
Indeed, Zig's crypto library is on point. For example, the aforementioned KyberSlash was already patched two months ago[1], by jedisct1 (author of the inimitable libsodium).
10 comments
[ 0.22 ms ] story [ 30.9 ms ] threadAlso, why use this and not AES-256 or ed25519 ?
The reason why we want Kyber is that it's supposed to be post-quantum secure. Ed25519 does not have evidence that it is post-quantum secure, so using a hybrid system does at least guarantee that your scheme is post-quantum ready. The reason you don't immediately switch to Kyber is in case of dodgy initial Kyber implementations, or unknown protocol issues we have not yet discovered.
AES is still safe. It is a replacement for public key crypto schemes, like Ed25519.
This is so far above my pay grade that I don't know what to think. DJB has a tendency to be right, but then again: he is the kind of guy that checks the return value of printf even in non-critical paths. As one wants a crypto guy to be, I guess...
There's also ECC, numerous hashes, stream ciphers... impressive!(?)[0]
[0] https://ziglang.org/documentation/master/std/#A;std:crypto
[1] https://github.com/ziglang/zig/commit/21ae64852a531c36ae3166...