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

Nico Williams <> Tue, 03 September 2019 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2E0E12006F for <>; Tue, 3 Sep 2019 11:07:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S6xLeXWsGHRV for <>; Tue, 3 Sep 2019 11:07:42 -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 AFC2F12013A for <>; Tue, 3 Sep 2019 11:07:42 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id DA3C320FC7; Tue, 3 Sep 2019 18:07:41 +0000 (UTC)
Received: from (100-96-168-83.trex.outbound.svc.cluster.local []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id B9C5021CBD; Tue, 3 Sep 2019 18:07:40 +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); Tue, 03 Sep 2019 18:07:41 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Chief-Abortive: 6a2b3752748f4f63_1567534061176_1320022940
X-MC-Loop-Signature: 1567534061176:4214927047
X-MC-Ingress-Time: 1567534061175
Received: from (localhost []) by (Postfix) with ESMTP id 503E280764; Tue, 3 Sep 2019 11:07:35 -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=QZW30cTlLZXq3C 2ssT0qd5uF8l8=; b=QhxjMBOlhhlbNioF2fxfeU/JMMVK0akKG88ELaJ9+ZlZ88 vf0vRFnMQn67U5IyLKwgt3eX2S3Oe3F86TCHeAe6TiCNU0y/u1nXIhTcs+1dH8aL s3N2yJEOa1LMIMeKb66nrKxC+pYBuChcCr5mwr3dNNHlhcVlIf2+AWaXdWXpM=
Received: from localhost ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 022A48076A; Tue, 3 Sep 2019 11:07:32 -0700 (PDT)
Date: Tue, 3 Sep 2019 13:07:30 -0500
X-DH-BACKEND: pdx1-sub0-mail-a94
From: Nico Williams <>
To: Phillip Hallam-Baker <>
Message-ID: <20190903180729.GF7920@localhost>
References: <>
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: gggruggvucftvghtrhhoucdtuddrgeduvddrudejfedgledvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepkedrvddruddthedrudejnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepkedrvddruddthedrudejpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt
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: Tue, 03 Sep 2019 18:07:45 -0000

On Mon, Sep 02, 2019 at 05:20:30PM -0400, Phillip Hallam-Baker wrote:
> At the moment, the approach used to escrow Mesh keys is
> * Generate a master secret of at least 128 bits
> * Use the master secret to derive an AES 256 encryption key and
> initialization vector under which the private key information is encrypted.
> * Use a content digest of the master secret as the identifier under which
> the escrow record is stored on some sort of service (TBS).
> * Use Shamir secret sharing to split the master secret  n out of m ways
> This works with any public key algorithm but it requires a service. It has
> since occurred to me that I may have gone down a blind alley because I
> designed this part of the system back when RSA was still the default
> algorithm (we were discussing the CFRG curves at the time). I am now
> thinking about using this approach:
> * Generate a master secret of at least 128 bits
> * Use a KDF to generate the master key pairs for Encryption and Signature
> from the master secret
> * Use Shamir secret sharing to split the master secret  n out of m ways
> Thoughts?

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.

In any case, both of these approaches have similar security properties.
Most importantly, compromise of a master secret compromises all the
private keys it protects.

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.

> One side benefit of this approach is that it becomes quite easy to give
> test vectors, just give the master secret used to generate the key pairs.
> I know 128 bits is short, my preference is for 256 bits. But given the
> number of times this ends up going through SHA-2-512, I am not really
> worried.

In a PQ world you want 256 bits of entropy, otherwise 128 bits is