Re: [openpgp] Known seed key generation

Bjarni Runar Einarsson <bre@mailpile.is> Fri, 18 October 2019 20:48 UTC

Return-Path: <bre@mailpile.is>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1AA120804 for <openpgp@ietfa.amsl.com>; Fri, 18 Oct 2019 13:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vjo8B22uyBqj for <openpgp@ietfa.amsl.com>; Fri, 18 Oct 2019 13:48:10 -0700 (PDT)
Received: from mailpile.is (mailpile.is [139.162.218.203]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECFC1201E5 for <openpgp@ietf.org>; Fri, 18 Oct 2019 13:48:10 -0700 (PDT)
Received: from mailpile.local (exit1.rathhansen.com [51.158.147.12]) by mailpile.is (Postfix) with ESMTPSA id 08FA89CB4D; Fri, 18 Oct 2019 20:48:06 +0000 (UTC)
Content-Type: multipart/mixed; boundary="==34TaMSEKLG84igU4bfqBLugncyIhGe=="
MIME-Version: 1.0
From: Bjarni Runar Einarsson <bre@mailpile.is>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: IETF OpenPGP <openpgp@ietf.org>
In-Reply-To: <CAMm+LwjLbhK1f45_brmZVTx3_GtZ2CfQBNV201mw=OnX+f2asw@mail.gmail.com>
References: <CAMm+LwjLbhK1f45_brmZVTx3_GtZ2CfQBNV201mw=OnX+f2asw@mail.gmail.com>
User-Agent: Mailpile
Message-Id: <SUkd5BCsFjXDfB2vmwt6ec632IVPy3zxHhHhTKD22385@mailpile>
Date: Fri, 18 Oct 2019 20:46:43 -0000
Autocrypt: addr=bre@mailpile.is; prefer-encrypt=mutual; keydata=xsFNBE4tgKYBEA DI8ULBJPw1a4h/D9Re5AZZ7xBtI9hIljUKz/bBovBGmRsrG6+IjKZ4um1kkJDhwiY0SzrzqE4L1hr cPRA46WbX0/aUuxL7LWbNDl6i7GBP28eU4I+mQcri2oS/rMfx3rnqe2dF85KKdTvS/9SsGAYNwK49 a+DMdsgDT3xMTf1JMrV5lRI7JCzop7v0AVbt9pyJAySJvQWcmkiWEZCWGpQxlYn/CnBVhv3iKToFt oIYKfcWLK/ADZ5CikwF7jDQM30mHovY4Ui31gVWnlhOw+UKpNviwbH7lr6flo2wFuaiD1jutKwqnG s6gH5A/tF6RtUCt6KzYoXpNochk8DGzm3G//sMDdreyUZeiXsF665IdUZ1V8OxU+S17MrxNiGjvY5 gRlD6a4oMsEZQPLQia4j7mCX/kTRsm5Xo+NqBMigNIvH7BJ+DcAqYnMT3kCbLyM3cAPhPn6zrSlXA mSsjAYk0bSLV9Ow0CITVcfrLB+2k+KFPFLl0ewXD75tspRk3wNBJ6GbhekOwzZE7xjrqWgR9Tfmlg DWArZT6oxqtKTiYnwiuQqPixONsc1jdR8bhqDZaJh7HkrZcY7yMDKQWe+1MxwBTV/DbbkrTmTT4ff RWCKi0Dv1do3NDgFXDC/3XpvFD2h2HPMs6pu8rG3CqS8YRJeE+p8TV7RJePSrb50rx4wARAQABzTB CamFybmkgUi4gRWluYXJzc29uIChNYWlscGlsZSkgPGJyZUBtYWlscGlsZS5pcz7CwY8EEwECADkC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAFiEEYaAVdj0o1BCoexlzKBkdmztBmbQFAl0X+KQAC gkQKBkdmztBmbT72hAAit87DtuEM74doeqYa2nYj5iba7wgnnZVnSLK/tN1g0mLYMrXX/nsI8elFM lB4o/qw/y3SlSvXSe2+MJ3OImIjSR2t7yeQuA3rNcZE1wTN9+FL+OVtOzNzAHvI/+2A7NQAgxOd83 nDOe1N6g4lzJZgNbWyvlUUpqGe1uRJwCxrVAW0BnxQuFLmUM+ypx+Ht5lX05JYzJh2lt05g2QBgNg GHZ2iMSl+uTaq1K5Y62jIFeP5PutPXwDFtKgUg2zY30SLYdp/SVl19fH4SSTTgXuYj9nACZ/UKy8l h7t5liUOmTi8QjlVLXQUJflgEwm8OJhnuWODNZQwAx0msqG5AsHI9nv48fTSnBACpGq58GxSmnWUv yO4Eqrbi+2HKzoRymDyzuPLwrPNyTJITxhhj5g0613isttdiM9+vX73jpWOilyKbyKfmCdOoUliEB Vt/+QGD9lt6iUfotgvgGpS/JkBi+X9otEN+wb1vJBCzK1Dfy7CrEHx7tD3+5FJi8mrSlaKeUqjLkR UbdWbBIc+kfVFpkqDzJmz6QoKWAevTk+GwETbD2aFTjX37M9EWkk3sDaEXSYFIT1X6++ykOl7bX+4 Sm2kRaBr8O8B1+26T+ZeVKvg14nYvr4Ck92/y/cPUgrW6meE1WC/9bXqrsMR1pY9Y7N8cw8h6GIpk ehy+XiuYrOwE0EVbaWEQEIAM0AUqE7vyJSdoCpKVMydXcnpzGSv+NUeTPxYObfjcQiAjeSDVgbhRQ eb8jRmhMpTY8mwd7o1soJlJ71JewXmLw7/u2ixYOWUtdLU6w8C2bXTWqq5gTJFMtUvq+Lt2AcWgcQ WCyVbzSjVvHR+Djy6qGiO1Tf90K9fYpdEOQKJrcFCVL88gz3qpP6H5vm29xNUZQWb3E6F6cSRiGYW QZ4mTmJFE1hOKGHsmLaFFeJy6sVMOE62y4FejA5p2R9lQ/u2sGkgKfQ0OfOCk778w07u6XtYHX/7X zRA0ma4PWL4/nXt7bjOqSC119+yLYYL6f/qQeMbJIX3qOIDxsfqxm+6/UAEQEAAcLBfAQYAQIAJgI bDBYhBGGgFXY9KNQQqHsZcygZHZs7QZm0BQJdF/kZBQkLI8oHAAoJECgZHZs7QZm0yfQP/0K9lm6C m6s2Q5Z3e0AevmZOaGIOVIq4UK+GoRTyKGC0gzya5oXlDQGsefS+I5iAZiwlFfQPwZ0TCujXawrwq OKpNjaoUiMMLaRMNP17yVcfvrNN23YWMAOFZoxJyczXveVDgEC/VDRWVguV6LbRv3ovIb9VlsbJ9R WvdzmZEtOWJ+PK0yeBaM2EmH7B3Liq6WKEv+PwPTt1giwB20Lf5wgUGROF2hBF9spd2J1p0ZzWarx keuMDGEh8djVSBqwP2pqrTQWArPvONRGcl/pOgfCyx6fVdrUMTW79KuWTyK+Re9zctpwCKAURCikD qFAupFh2kJmbobOE2miYZ50YdhmoejHK3iBzdEijfPiOqWoStapd44q3o8s+KEWvRymMfp7tQiTEH OxNga9hIomntAqYT/6F5En0RhnVjK3ZRaxoI2VPWa5AA878k9GpqfFO9h5z7e18b+4ukVl1PY4S4w FV+lqqq/ODbWiZS+lKXkcVQoVCFhDEhenV8uuKSMfZR/PrjShaMI/AjP6ESHowlEdDaus6TeiJWfI P5QQViZAQg/tWtwPq2YzMVCS/S1rK+EjZp4Db55N4VxDAE5N0jSV+2LsJhFg+57UW9genrOAzkZZE DRQLjVPAPmR2uUx5A13TTX7TNM07D6j+5I9FnLGd/sW3wcyxlMWwN4IMY1bt
OpenPGP: id=61A015763D28D410A87B197328191D9B3B4199B4; preference=signencrypt
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/147UOeBkGTFbS8knDKFe2vHKN04>
Subject: Re: [openpgp] Known seed key generation
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Oct 2019 20:48:13 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello again,

Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> On Fri, Oct 18, 2019 at 11:39 AM Bjarni Runar Einarsson <bre@mailpile.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-----