Re: [openpgp] Deriving an OpenPGP secret key from a human readable seed

Thanks for writing this up, Kai!

On Tue 2019-10-15 14:16:31 +0200, Kai Engert wrote:
> 7 bits
>     Number of entropy bytes that will be encoded as a mnemonic.
>     Encoded as a multiple of 32 minus 1.
>     Smallest value possible is 32, encoded as 0: (0 + 1) * 32 = 32
>     Largest value possible is 4096, encoded as 127:
>       ((127 + 1) * 32) = 4096
>     (Maybe 4096 is unnecessarily large, and we could use a smaller
>      amount of bits for this.)
>
> 7 bits
>     Identifier of the public key algorithm, as defined in RFC 4880
>     section 9.1
>     (Assumption that this implies the usual associated sub key
>      algorithm. If not possible, we'd need additional bits to
>      encode the sub key algorithm.)
>
> 18 bits
>     Key size plus 1
>     Smallest value possible, encoded as 0: 1
>     Largest value possible, encoded as 262143: 262144
>     (Maybe again that's unnecessarily large and we could use the
>      bits for something else.)
I'm not sure i see the value of any of the above fields for such a seed.
If they're needed for OpenPGP, i think they're incomplete (lacking key
creation timestamp at least) -- but i don't think they're needed.

For initial secret key generation, these parameters -- key algo, key
size, creation timestamp, etc -- can be made at key creation time and
don't need to be recorded in the phrase.

For secret key recovery, presumably the user has the OpenPGP certificate
("transferable public key") available to them already, which contains
all the above information already.  I'd imagine that the recovery
process in the OpenPGP context would take the certificate and the
mnemonic, deriving all of the above fields from the certificate.

I think there are at least three ideas in this e-mail:

 a) The general idea of a loadable seed to a well-defined, well-known
    DRBG.  This requires declaring the size of the seed, and choosing
    the DRBG algorithm.  This might also include "stretching"
    (e.g. argon2) needed to make the seed resistant to large-scale
    automated attack when parts of the seed are accidentally revealed
    (e.g. imagine muttering memorized words/phrases while sleeping).

 b) The (bi-directional?) mapping between that seed and a string that
    humans can handle (record easily? commit to and recall from memory?
    replay without ambiguity?).  This requires defining the goals of the
    mapping (is it for recovery? daily use? verification?), and a
    (language-specific?)  vocabulary list that offers the relevant
    properties.  (this sounds a little like p≡p's "Trust Words"
    proposal, except that that proposal isn't bi-directional and the
    vocabulary lists don't appear to have any analysis for dealing with
    phonetic or orthographic ambiguity)

 c) The use of such a DRBG to generate OpenPGP secret key material,
    given baseline parameters (or deriving those parameters from a
    certificate, in the case of recovery)

I'm not personally very convinced about this general approach -- it's
the equivalent of an unchangeable password that you've committed to
publicly (so anyone who thinks they have a good guess at your password
can verify it offline against your public key fingerprint).

I know it's something that some folks are excited about, though, and
part (c) might be in-scope for this mailing list, particularly the
OpenPGP-specific parameters.  I'd encourage anyone excited about this
work to try to write down how to do (c) alone in a way that could be
interoperably implemented.

It sounds like Phil's UDF draft outlines the general idea for raw
cryptographic objects, but doesn't have a mechanism specified yet, or a
mapping between them and OpenPGP.

     --dkg

signature.asc
Description: PGP signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp