Subject: [openpgp] Shared OpenPGP keys for use in test corpuses

From: Bjarni Runar Einarsson <[email-masked]>
Date: Tue, 15 Oct 2019 13:50:56 -0000

Hello OpenPGP!

One of the workgroup outcomes at the OpenPGP e-mail summit, was a
common desire for more shared test data.

As a first step towards this, dkg and juga and I sat down and put
together a minimal Internet Draft which specifies a couple of
OpenPGP certificates and keys (one Ed25519, another RSA-3072),
which we would like to propose people use when testing.

The draft:

 - https://datatracker.ietf.org/doc/draft-bre-openpgp-samples/

The gitlab where we welcome improvements:

 - https://gitlab.com/openpgp-wg/openpgp-samples

We hope this proves useful,
 - Bjarni

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 17 Oct 2019 22:09:57 -0400

If the generate key from specified seed work goes ahead, we get this for
free.

It is one of the things that made me propose this idea back in September :-)

On Tue, Oct 15, 2019 at 9:52 AM Bjarni Runar Einarsson <[email-masked]>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello OpenPGP!
>
> -----BEGIN PGP SIGNATURE-----
>
> iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl2lzrQACgkQjgA3FgDP
> lJGTnwf/YeDpEgjgkPTKohvVHqNOLwHnZ8WIRW0rAO5lCaUQTcjBmW0CCpobr7a8
> gck7BBe2cplW5Yg8tHH0dM5dL6Jjev2kXfrck4BTdQPZOXdBb4SrrPVgNoQwbn0S
> lV5cjQdfAkc2wp4zIzGifJBduESgSyNABIG4pafNabcoZCvGYUW2iukC53q2KbWr
> HXiuBtQMNKn670lWpU/z/dMZ+0gGevsXboumf+Roy2Xgjjco+YXEB4+W54NNB4RF
> StUuwTc6yjy4Ds+Xgo9ivz7N3WfgKRY+l3bvzC4rgp241xtGJbGDuGgfZG/Rl/1B
> NChZUluaISi91KZ3sdLu2NG0Ga0ArA==
> =jtT8
> -----END PGP SIGNATURE-----
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Bjarni Runar Einarsson <[email-masked]>
Date: Fri, 18 Oct 2019 07:47:53 -0000

Hello!

Phillip Hallam-Baker <[email-masked]> wrote:
> If the generate key from specified seed work goes ahead, we get
> this for free.
> 

You're working with a very flawed definition of the concept
"free". Sure, if all implementations everywhere add the same
fancy feature, we can use that feature for "free" from that point
in time onwards. Well, free aside from maintenance and bugfix
costs... But getting there is expensive and I don't actually see
consensus that we're moving in that direction. I'm not a fan, but
I'll refrain from derailing this thread to pontificate on why.

This approach works right now. It will still work even after
people have started generating from specified seeds. And the cost
is sunk, the work has been done.

It would be a shame if people decided not to collaborate in this
way, because they're waiting for the Next Big Thing to land.

 - Bjarni

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 18 Oct 2019 09:00:42 -0400

> 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 proposed this idea September 28. I expect writing the draft and shipping
code to take no more than a day. So I don't see a problem with
implementation complexity. Nor do I see a need for this to be widely
implemented to address an issue that only affects developers.

The issue of test data for specifications is something that we should
probably address using a mechanism other than the ID series. Documents
should have illustrative examples. Test vectors are really something else.
Its like the supporting data now required for certain types of academic
paper.

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.

---

From: Bjarni Runar Einarsson <[email-masked]>
Date: Fri, 18 Oct 2019 15:38:47 -0000

Hello!

Phillip Hallam-Baker <[email-masked]> wrote:
> On Fri, Oct 18, 2019 at 3:51 AM Bjarni Runar Einarsson <[email-masked]> wrote:
> 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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 18 Oct 2019 13:24:48 -0400

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

> insufficient for many (most?) real world use-cases
>

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

> compatibility layer that can regenerate previous generations of

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

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

> For openpgp.js, Sequoia, GnuPG, and PgPy? All in one day?

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.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 18 Oct 2019 14:47:27 -0400

> or don't state them at all.

Can we tone it down a bit?  Bjarni's objections seem explicitly stated
to me: he's objecting on the grounds of simplicity.  The draft he points
to (which i'm a co-author on) provides material that people can use
today, without any additional effort.

Phil's proposal offers a wider feature set, it's true, but requires more
development of consensus about how to design the key derivation, and
also requires more work on the side of implementers.

Standards develoment can support both of these approaches, there's no
reason to queue one behind the other.

       --dkg

---

From: Bjarni Runar Einarsson <[email-masked]>
Date: Fri, 18 Oct 2019 20:46:43 -0000

Hello again,

Phillip Hallam-Baker <[email-masked]> wrote:
> On Fri, Oct 18, 2019 at 11:39 AM Bjarni Runar Einarsson <[email-masked]> wrote:
> >
> 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.

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

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

> 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