Re: [Mathmesh] [Cfrg] A different approach to key escrow

Nico Williams <> Mon, 09 September 2019 16:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB4C412080E for <>; Mon, 9 Sep 2019 09:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BAmEl2BxiE6x for <>; Mon, 9 Sep 2019 09:38:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BF58B120853 for <>; Mon, 9 Sep 2019 09:38:27 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id A66001A2631; Mon, 9 Sep 2019 16:38:26 +0000 (UTC)
Received: from (100-96-6-79.trex.outbound.svc.cluster.local []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id 7FC111A27B4; Mon, 9 Sep 2019 16:38:21 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|
Received: from ([TEMPUNAVAIL]. []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.17.5); Mon, 09 Sep 2019 16:38:26 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Dime-Quick: 03b5db5d2d24c192_1568047102028_2740679145
X-MC-Loop-Signature: 1568047102028:4210485620
X-MC-Ingress-Time: 1568047102028
Received: from (localhost []) by (Postfix) with ESMTP id 845F88009E; Mon, 9 Sep 2019 09:38:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=3AQTVD0v2j3k6E y3WBHa467iTzA=; b=dAnSvsgSosUhIw3aUnt1QOYfpv9oWzz6puZljspdM+8pej XcEuD7G6dnlZloYa65CWUpfXgPlZhur3ldzn+fXEfcODZWoHMdwBE9h8cUwoUlnM GU7r/FW25K7N4SLkpgfzw0MUhaVLVYDjcEabsWsc7RoYd0xz+eVRVFVyYYiMI=
Received: from localhost (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 6E7EA80064; Mon, 9 Sep 2019 09:38:17 -0700 (PDT)
Date: Mon, 9 Sep 2019 11:38:14 -0500
X-DH-BACKEND: pdx1-sub0-mail-a12
From: Nico Williams <>
To: Phillip Hallam-Baker <>
Cc: Michael Richardson <>,,
Message-ID: <20190909163813.GG7920@localhost>
References: <> <6241.1567487279@localhost> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrudekiedguddtvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
Archived-At: <>
Subject: Re: [Mathmesh] [Cfrg] A different approach to key escrow
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Sep 2019 16:38:42 -0000

On Thu, Sep 05, 2019 at 10:26:22PM -0400, Phillip Hallam-Baker wrote:
> On Wed, Sep 4, 2019 at 2:46 AM Michael Richardson <>;
> wrote:
> > Nico Williams <>; wrote:
> >     > I don't see why in the first case you'd need a separate
> >     > service to store the private keys encrypted in the master
> >     > secret.  All the entities that hold secret shares can also
> >     > hold copies of the encrypted record along with the secret
> >     > shares.
> >
> > This allows the secrets to split and sent to appropriate entities
> > once at the beginning of the process, and they never need to be
> > updated again.  Alice can generate as many keys (and as frequently)
> > as she wishes, interacting only with the escrow service.  Assuming
> > that I understand correctly.

If you use a master secret to to generate all the others, indeed.

The first scheme, however, requires storing updated encrypted secrets
payloads.  That's the "service" that we'd asked about, but I assumed the
services that store secret shares would also store those payloads.

> >     > However, you might find it difficult to generate key pairs
> >     > from a master secret, especially if you ever need to generate
> >     > keys on a hardware token.  If you won't have that requirement,
> >     > and if you're willing to have that as an anti-requirement,
> >     > then the second scheme is simpler, indeed, and the entities
> >     > that store key shares will need to store smaller records.
> >
> > You are saying: If you use a hardware token, then you need the escrow
> > service.
> > Isn't it the case that some hardware tokens have no mechanism to get the
> > private key out?  I guess they are SOL regardless of scheme.

Yes, though I expect wrapped key export to be generally available,

> I agree. If someone is using a hardware token, the hardware token needs to
> manage the escrow mechanism itself (e.g. like the way Luna cards do). But
> it will in any case need a way to import a private master key generated
> elsewhere.

not supporting such tokens is a reasonable thing to do.

> > Couldn't we generate per-key escrow keys from the master key using
> > the same KDF mechanism?  Doesn't that get us the best of both worlds,
> > with the confusion as to how the different

That enlarges the amount of secret share storage needed, which gets us
back to Phillip's desire to avoid that.  A nice feature of this scheme
is that there's a fixed number of fixed-sized keyshares generated early
on and this need never change unless you want to re-key everything.

Speaking of which, how does master secret change work?

> Hmm... that might be the way to do it. The only problem is that then you
> need access to the offline master to be able to generate application key
> sets and the idea of the offline master is that you should only need to
> ever use it when changing your administration device.