On Fri, Oct 18, 2019 at 11:39 AM Bjarni Runar Einarsson
<bre(_at_)mailpile(_dot_)is>
wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hello!
Phillip Hallam-Baker <phill(_at_)hallambaker(_dot_)com> wrote:
On Fri, Oct 18, 2019 at 3:51 AM Bjarni Runar Einarsson
<bre(_at_)mailpile(_dot_)is>
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.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp