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

[Kai Engert <[e-mail]>]

On 16.10.19 21:27, Daniel Kahn Gillmor wrote:
> 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.

We could add the creation timestamp. To save bits, we could introduce a
new epoch, that starts in october 2019. This new recovery mechanism
wouldn't support older keys.

With a 33 bit unsigned integer, we get 272 years. To compute, calculate
the regular 64bit unix epoch (since 1970). Then substract the new epoch
start timestamp (e.g. 1572000000 for 2019-10-25). Encode that as a 33
bit unsigned integer. Will work until year 2272.


> 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.

What about a user who owns just a single computer, it breaks, and
they've lost all their files, and only the IMAP mail archive is left?

Maybe the user never uploaded their key to a key server, there's no backup.

Maybe the user has an email with the attached public key somewhere, but
can it be found reliably?

If we don't record any key information in the Mnemonic, the user must
perform some bootstrap action, prior to being able to regenerate the key:

- look at existing encrypted email, an extract the key ID, to understand
which key needs to be recovered. But that might be a subkey ID, so
further searching is required to identify the ID of the master key?

- search through existing email, in the hope that the full public key is
attached somewhere, either regular attachment, or maybe an outgoing
autocrypt header (only if user's client had autocrypt headers enabled).
Maybe there's no such email?

- contact one of the correspondents, and ask them to send the public key
back. Maybe the user doesn't want to do that?

It might be useful if recovery didn't depend on the above.


> I'm not personally very convinced about this general approach -- it's
> the equivalent of an unchangeable password that you've committed to
> publicly

Why do you consider it equivalent, if the seed was randomly generated,
and the list of words isn't influenced by the user?

Thanks
Kai