-----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.
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.
(Consider the kind of changes people made to cryptographic
algorithms to avoid timing attacks - that's the sort of work that
will break known seeds. Any bugfixes or code reorg runs this
risk.)
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?
The main benefit I see, is that a known seed can be very small
and thus facilitate certain types of synchronization in extremely
low-bandwidth environments (e.g. QR codes). If you're not
bandwidth constrained, I strongly suspect known seeds are a false
economy.
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
Nor do I see a need for
this to be widely implemented to address an issue that only
affects developers.
Shared test data, by its very nature, is the sort of thing you
use to test and compare different implementations. The whole
point is compatibility, and the lower the bar for that, the
better.
The model I think we need here is to have an interop event in
which implementations demonstrate that they can generate and
consume a particular corpus. And then publish a report on that
interop event with the names of the tested implementations and
the results.
That is one of an almost infinite number of testing activities
people could undertake with a shared corpus of test messages.
Cheers,
- Bjarni
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2p3K0ACgkQjgA3FgDP
lJHnaggAgCydMNe2kngEKKKG+2Ha8ssgeR91zOXttSVNPHv2HuIXq1G+cztgdfhc
XgR3Nk3AOzD0z3j8nl0CP6I3aCugu/fINFu7UDpetLwMpjUiKUTE+KV46xit3WvY
rJpVexiNclyIDLtJHxWPZAOqZFZoDbRjqYrhvxJWYKIfxP22QMxew4foytve1bTd
4cYAxHGWyItMaBTZTvUiCi1BGYRHZ+AHnD2h/oC5ByaXT2Trbqfc+3z/6fcfRJYr
ahhi4tMdiRsULa5r9KE3NOlLQRxhOQ+xiXGoZBIOcb508pMAL5+fSe974R4DJuNO
hCHq0a8SYMwlwayzRvZzYLtstQAUfw==
=Fjyb
-----END PGP SIGNATURE-----
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp