simon-git: putty (main): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  423ce20f Pageant core: separate public and private key storage.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2022-08-06 12:03:04

commit 423ce20ffbf0f9366cb184c7ad792143f0726e4e
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=423ce20ffbf0f9366cb184c7ad792143f0726e4e;hp=cd7f6c4407ff0df2ee7c9ced4e0ffea3c3dff969
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Aug 6 10:41:41 2022 +0100

    Pageant core: separate public and private key storage.
    
    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.)

 crypto/rsa.c |  15 ++
 pageant.c    | 752 ++++++++++++++++++++++++++++++++++++++---------------------
 ssh.h        |   1 +
 3 files changed, 505 insertions(+), 263 deletions(-)