Re: [openpgp] Known seed key generation

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Oct 18, 2019 at 11:39 AM Bjarni Runar Einarsson <[e-mail]>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello!
>
> Phillip Hallam-Baker <[e-mail]> wrote:
> > On Fri, Oct 18, 2019 at 3:51 AM Bjarni Runar Einarsson <[e-mail]>
> wrote:
> > > I'll refrain from derailing this thread to pontificate on why.
> >
> > Saying that you have technical objections which you will not
> > reveal is incredibly rude. Either state your objections so they
> > can be responded to or don't state them at all.
>
> I apologise, I meant no offence. Just that I didn't want to get
> too far off topic.
>
> But since you feel strongly, I'm happy to elaborate.
>
> As I understand it, generating keys from a known seed is intended
> as a backup/restore/sync strategy for the secret key material.
> But as such, it does nothing to address all the metadata
> surrounding the key (or keys), which tends to be rather
> important. Schemes based on a shared seed are therefore (IMO)
> insufficient for many (most?) real world use-cases
>

The metadata is generally associated with the public key rather than the
private.




> Furthermore, generating keys from a known seed implies a lot of
> hidden dependencies. If people do not take care to implement the
> critical algorithms in exactly the same way, different
> implementations will generated different keys from the same seed.
> If using code-words, dictionaries have to be standardized and
> kept unchanged, across all supported languages. If there are bugs
> or mistakes in the scheme, you can't fix them without adding a
> compatibility layer that can regenerate previous generations of
> keys.
>

Not for the new CFRG keys. They are simply random blobs. Generating the
blob from a seed using a KDF is straightforward.

Everything has to go exactly right for your restoration procedure
> to work; which is really not a characteristic you want in a
> backup system. Do you really want to attempt a restore 10 years
> later, discover that a security update changed the algorithms,
> and you need to go digging up obsolete versions of GnuPG to
> restore your data? Why expose yourself to that risk?
>

I don't think this type of key management should be part of apps. It is
probably something that is most useful for disk level encryption and for
SSH. OpenPGP would only be using it for establishing the same key across
devices.

In particular, for shared test data, there is no bandwidth
> constraint and there is absolutely no reason to take on all the
> above complexity and constraints. Just do the simple thing and
> copy the key material. It works.
>
> > I proposed this idea September 28. I expect writing the draft
> > and shipping code to take no more than a day.
>
> For openpgp.js, Sequoia, GnuPG, and PgPy? All in one day?
> Impressive! :-D
>

They can all import a P12 or PEM encoded key or they are useless. I don't
think key generation or management should be part of the crypto apps that
make use of the keys. It is a separate function.