mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-09 17:38:00 +00:00
423ce20ffb
Previously, we had a single data structure 'keytree' containing records each involving a public and private key (the latter maybe in clear, or as an encrypted key file, or both). Now, we have separate 'pubkeytree' and 'privkeytree', the former storing public keys indexed by their full public blob (including certificate, if any), and the latter storing private keys, indexed by the _base_ public blob only (i.e. with no certificate included). The effect of this is that deferred decryption interacts more sensibly with certificates. Now, if you load certified and uncertified versions of the same key into Pageant, or two or more differently certified versions, then the separate public key records will all share the same private key record, and hence, a single state of decryption. So the first time you enter a passphrase that unlocks that private key, it will unlock it for all public keys that share the same private half. Conversely, re-encrypting any one of them will cause all of them to become re-encrypted, eliminating the risk that you deliberately re-encrypt a key you really care about and forget that another equally valuble copy of it is still in clear. The most subtle part of this turned out to be the question of what key comment you present in a deferred decryption prompt. It's very tempting to imagine that it should be the comment that goes with whichever _public_ key was involved in the signing request that triggered the prompt. But in fact, it _must_ be the comment that goes with whichever version of the encrypted key file is stored in Pageant - because what if the user chose different passphrases for their uncertified and certified PPKs? Then the decryption prompt will have to indicate which passphrase they should be typing, so it's vital to present the comment that goes with the _file we're decrypting_. (Of course, if the user has selected different passphrases for those two PPKs but the _same_ comment, they're still going to end up confused. But at least once they realise they've done that, they have a workaround.) |
||
|---|---|---|
| .. | ||
| aes-common.c | ||
| aes-neon.c | ||
| aes-ni.c | ||
| aes-select.c | ||
| aes-sw.c | ||
| aes.h | ||
| arcfour.c | ||
| argon2.c | ||
| bcrypt.c | ||
| blake2.c | ||
| blowfish.c | ||
| blowfish.h | ||
| chacha20-poly1305.c | ||
| CMakeLists.txt | ||
| crc32.c | ||
| des.c | ||
| diffie-hellman.c | ||
| dsa.c | ||
| ecc-arithmetic.c | ||
| ecc-ssh.c | ||
| ecc.h | ||
| hash_simple.c | ||
| hmac.c | ||
| mac_simple.c | ||
| mac.c | ||
| md5.c | ||
| mpint_i.h | ||
| mpint.c | ||
| ntru.c | ||
| ntru.h | ||
| openssh-certs.c | ||
| prng.c | ||
| pubkey-pem.c | ||
| pubkey-ppk.c | ||
| pubkey-ssh1.c | ||
| rsa.c | ||
| sha1-common.c | ||
| sha1-neon.c | ||
| sha1-ni.c | ||
| sha1-select.c | ||
| sha1-sw.c | ||
| sha1.h | ||
| sha3.c | ||
| sha256-common.c | ||
| sha256-neon.c | ||
| sha256-ni.c | ||
| sha256-select.c | ||
| sha256-sw.c | ||
| sha256.h | ||
| sha512-common.c | ||
| sha512-neon.c | ||
| sha512-select.c | ||
| sha512-sw.c | ||
| sha512.h | ||
| xdmauth.c | ||