-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hello again,
Phillip Hallam-Baker <phill(_at_)hallambaker(_dot_)com> wrote:
On Fri, Oct 18, 2019 at 11:39 AM Bjarni Runar Einarsson
<bre(_at_)mailpile(_dot_)is> wrote:
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.
I think you're missing the point. I'm contending that if you need
a backup of your secret key material, it's because you've used it
for something of value. Which means you probably also need
backups for that "something", whatever it may be.
I have little use for a scheme which only lets me restore/sync
private key material and nothing else. This is the crux of my
"not a fan" comment from earlier.
This is an important difference between the world of OpenPGP and
the world of Bitcoin. In the world of Bitcoin, all that data
you're interacting with is in the public block-chain, so the
world backs it up for you. That's why keys like this are useful
there. These conditions do not hold in the world of OpenPGP and
probably never will.
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.
Not what? Which of my points are you responding to here? I don't
see any of my points addressed by this response.
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.
I don't understand this response either. I don't think we're
communicating.
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.
All of those libraries/tools are used to generate and manage
keys. Apps are built on top of them.
If your vision is that someone create a totally separate tool for
generating keys from human readable seeds, I have no problem with
that (hasn't this already been done?). In fact, I think it's
probably a good idea, because it minimizes the amount of code
that has to be kept stable and unchanging so key (re)generation
can be trusted long term.
But... I still see no reason to make my test suites depend on
that tool, when I can just import a pre-published key.
Kind regards,
- Bjarni
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2qJKYACgkQjgA3FgDP
lJHiowgAhKvqQi7QV+VovSf2ZCDfNooH06cuvvg/lvzjTLVVpNxIjA4Gr+++qhDQ
4WK7Z3q6hurlqoSyU9aVNBD3PnILyYEeyfrA5w0W6H97aLIoHnrZHLhUfHvk/8gL
OIka77BNitSIN+/MbsTMOlr+BFUZvVagwbw8oLS02QnS7SdNvLxKHbI1ot0xyu86
q0PmHieGmy1T0SH2STJQqv37sunoqqkvf4MFiEV8ppjqG+qC52aOcAKQg1PXrsRX
VZuDW+8NNNTxMHzto6hMO8Nyce2r16DVs9K3sYtpLQx9GlDenuDj9qsbW9oh+4SK
1xhxN3xxvr6NshhCfnGgE7Vl/EMAYg==
=FOHV
-----END PGP SIGNATURE-----
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp