[HN Gopher] Kyber
       ___________________________________________________________________
        
       Kyber
        
       Author : tosh
       Score  : 18 points
       Date   : 2024-02-22 08:09 UTC (1 days ago)
        
 (HTM) web link (pq-crystals.org)
 (TXT) w3m dump (pq-crystals.org)
        
       | FirmwareBurner wrote:
       | Question from the n00bs, this is the encryption algo used in
       | Signal and iMessage, right?
       | 
       | Also, why use this and not AES-256 or ed25519 ?
        
         | conradludgate wrote:
         | 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.
        
         | bjoli wrote:
         | They use it for key exchange. That removes the part that
         | quantum computing will break easily.
         | 
         | AES is still safe. It is a replacement for public key crypto
         | schemes, like Ed25519.
        
       | DeepYogurt wrote:
       | 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
        
         | Analemma_ wrote:
         | 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.
        
         | bjoli wrote:
         | 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...
        
         | xcdzvyn wrote:
         | This page taught me Zig not only has _an_ implementation of
         | Kyber, but an implementation of Kyber in the stdlib.
         | 
         | There's also ECC, numerous hashes, stream ciphers...
         | impressive!(?)[0]
         | 
         | [0] https://ziglang.org/documentation/master/std/#A;std:crypto
        
           | thadt wrote:
           | 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).
           | 
           | [1] https://github.com/ziglang/zig/commit/21ae64852a531c36ae3
           | 166...
        
       ___________________________________________________________________
       (page generated 2024-02-23 23:01 UTC)