mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-09 17:38:00 +00:00
e98615f0ba
As standardised by NIST in FIPS 203, this is a lattice-based post-quantum KEM. Very vaguely, the idea of it is that your public key is a matrix A and vector t, and the private key is the knowledge of how to decompose t into two vectors with all their coefficients small, one transformed by A relative to the other. Encryption of a binary secret starts by turning each bit into one of two maximally separated residues mod a prime q, and then adding 'noise' based on the public key in the form of small increments and decrements mod q, again with some of the noise transformed by A relative to the rest. Decryption uses the knowledge of t's decomposition to align the two sets of noise so that the _large_ changes (which masked the secret from an eavesdropper) cancel out, leaving only a collection of small changes to the original secret vector. Then the vector of input bits can be recovered by assuming that those accumulated small pieces of noise haven't concentrated in any particular residue enough to push it more than half way to the other of its possible starting values. A weird feature of it is that decryption is not a true mathematical inverse of encryption. The assumption that the noise doesn't get large enough to flip any bit of the secret is only probabilistically valid, not a hard guarantee. In other words, key agreement can fail, simply by getting particularly unlucky with the distribution of your random noise! However, the probability of a failure is very low - less than 2^-138 even for ML-KEM-512, and gets even smaller with the larger variants. An awkward feature for our purposes is that the matrix A, containing a large number of residues mod the prime q=3329, is required to be constructed by a process of rejection sampling, i.e. generating random 12-bit values and throwing away the out-of-range ones. That would be a real pain for our side-channel testing system, which generally handles rejection sampling badly (since it necessarily involves data-dependent control flow and timing variation). Fortunately, the matrix and the random seed it was made from are both public: the matrix seed is transmitted as part of the public key, so it's not necessary to try to hide it. Accordingly, I was able to get the implementation to pass testsc by means of not varying the matrix seed between runs, which is justified by the principle of testsc that you vary the _secrets_ to ensure timing is independent of them - and the matrix seed isn't a secret, so you're allowed to keep it the same. The three hybrid algorithms, defined by the current Internet-Draft draft-kampanakis-curdle-ssh-pq-ke, include one hybrid of ML-KEM-768 with Curve25519 in exactly the same way we were already hybridising NTRU Prime with Curve25519, and two more hybrids of ML-KEM with ECDH over a NIST curve. The former hybrid interoperates with the implementation in OpenSSH 9.9; all three interoperate with the fork 'openssh-oqs' at github.com/open-quantum-safe/openssh, and also with the Python library AsyncSSH. |
||
|---|---|---|
| .. | ||
| agentf.c | ||
| bpp1.c | ||
| bpp2.c | ||
| bpp-bare.c | ||
| bpp.h | ||
| ca-config.c | ||
| censor1.c | ||
| censor2.c | ||
| channel.h | ||
| CMakeLists.txt | ||
| common.c | ||
| connection1-client.c | ||
| connection1-server.c | ||
| connection1.c | ||
| connection1.h | ||
| connection2-client.c | ||
| connection2-server.c | ||
| connection2.c | ||
| connection2.h | ||
| crc-attack-detector.c | ||
| gss.h | ||
| gssc.c | ||
| gssc.h | ||
| kex2-client.c | ||
| kex2-server.c | ||
| login1-server.c | ||
| login1.c | ||
| mainchan.c | ||
| nogss.c | ||
| nosharing.c | ||
| pgssapi.c | ||
| pgssapi.h | ||
| portfwd.c | ||
| ppl.h | ||
| scpserver.c | ||
| server.c | ||
| server.h | ||
| sesschan.c | ||
| sftp.c | ||
| sftp.h | ||
| sftpcommon.c | ||
| sftpserver.c | ||
| sharing.c | ||
| signal-list.h | ||
| ssh.c | ||
| transient-hostkey-cache.c | ||
| transport2.c | ||
| transport2.h | ||
| ttymode-list.h | ||
| userauth2-client.c | ||
| userauth2-server.c | ||
| verstring.c | ||
| x11fwd.c | ||
| zlib.c | ||