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

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 03 September 2019 14:51 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A9E1208D3 for <cfrg@ietfa.amsl.com>; Tue, 3 Sep 2019 07:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Level:
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 YDkfYLY2cHD6 for <cfrg@ietfa.amsl.com>; Tue, 3 Sep 2019 07:51:23 -0700 (PDT)
Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541DE1208A8 for <cfrg@irtf.org>; Tue, 3 Sep 2019 07:51:23 -0700 (PDT)
Received: by mail-ot1-f51.google.com with SMTP id g16so5148139otp.12 for <cfrg@irtf.org>; Tue, 03 Sep 2019 07:51:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gSOp/ald9IkSR811vnV6O+bm5gaZL0C6YCgf2HZHUwo=; b=kUSPhfEQ04hcFzsphdx3zfZOW3QxBs6yWz0NPNrd5TQcir9B7VdJ7uAw9RFgW1QrG7 QgMiixYk59daKYHpJwhj4WSp7aqVzyMwso01mirN9LFsq5jXoyDaBdVxtL82/2t/tp+S jN5PJ6VNr8JBl35YLlOeDqK780KKegjCcW6N6EypdQHr+NOOzrk1kqr+L1sbCbfH+hJc 9hwDYdi0qS+D2RJP1r6QVBOzv5f8Aal79u/f9FAyWxQvIQCXwliIc4+tUmsT5TrYblmL sRhmnD60oZC2b903ZSAWTK03XgoqCC3OT9AjRzO8YEdFPT1m2jO124TgGJuIYyAWK1SP ugnA==
X-Gm-Message-State: APjAAAW/jNZaoZYwAqD7Ax0iCqTdoiTZ3ginxLmodwtAD6IBZT5sDf6n 2viprxf5/9Ivvn9BZ9wim9/cQ0fRkHoGmY4HbFE=
X-Google-Smtp-Source: APXvYqyXPv98pVmOR+GkiTxA38uMCjEk/i83Zt0PvYqQygJVcY1pE/7bvACYQQTB5lRMLiOc86pu8MM/8TGftvY96j8=
X-Received: by 2002:a9d:4e97:: with SMTP id v23mr5232228otk.112.1567522282538; Tue, 03 Sep 2019 07:51:22 -0700 (PDT)
MIME-Version: 1.0
References: <CAMm+LwiZqA=M90YdmQOV+sAy+T-prhzphct2bsOyPmaQ4V2oOA@mail.gmail.com> <6241.1567487279@localhost>
In-Reply-To: <6241.1567487279@localhost>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 03 Sep 2019 10:51:11 -0400
Message-ID: <CAMm+LwhKHHz8e6b2C61zjFDv+shsLsBgxaAv=88dFG3kdJ9Fiw@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: mathmesh@ietf.org, cfrg@irtf.org
Content-Type: multipart/alternative; boundary="000000000000d40d720591a7388c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/RktvL2m0I-QHFTdk9CJlX5rSBjk>
Subject: Re: [Cfrg] [Mathmesh] A different approach to key escrow
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 14:51:26 -0000

OK so here is the difference.

In each case

Alice's master secret is
     97 BE C3 8C  EC 32 E3 A8  14 BE 38 AC  49 B3 58 D0

This has the UDF representation:
   ECL3-5Q4M-5QZO-HKAU-XY4K-YSNT-LDIA


We can split that using shamir secret sharing:

   f(1) = SAYE-UHOY-TVZO-LPGT-ZAGE-7JUW-6MTJ-I
   f(2) = SAYX-4HWP-3753-L4P3-N4S6-C2G4-QVPA-A
   f(3) = SAZD-HQNJ-KSDK-HAY7-BIFO-34Y2-NH7O-C
   f(4) = SAZW-WBTE-7MJ2-44B6-TC5X-KRKQ-UEEW-U
   f(5) = SA2C-H3IC-2ORN-NOK2-DM3X-OX37-FJ6W-Q


The difference is how we generate the private key pairs.

What is done now is that the Master Profile key pairs for encryption and
signature are generated in the normal way. The private keys are wrtiten out
to an escrow record that is encrypted under ECL3-5Q4M...

So recovery requires at least three of the key shares plus the encrypted
escrow record.


The other way to go about it is to use a KDF to generate the private keys
for the master profile:

Signing Key = HKDF ( [97 BE C3 8C EC 32 E3 A8 14 BE 38 AC 49 B3 58 D0],
"mmm/mesh-signature/Ed448". 448)
Escrow Key = HKDF ( [97 BE C3 8C EC 32 E3 A8 14 BE 38 AC 49 B3 58 D0],
"mmm/mesh-escrow/X448", 448)

So now recovery of the escrow record ONLY requires the master secret
ECL3-5Q4M-5QZO-HKAU-XY4K-YSNT-LDIA.
There is no encrypted escrow record.

Pros: More convenient.
Cons: The private keys have less ergodicity and are related by means of the
HMAC function.

If we are confident of our algorithms being secure, 2^128 is an infeasible
work factor. And if you look into how the scheme is implemented, we are not
talking about SHA-2-512 (x), we are talking about SHA-2-512 ( SHA-2-512 (
SHA-2-512 ( SHA-2-512 (x)  )  )  ).

If we are not confident of our algorithms being secure, we can use any size
work factor we like up to the size of our private key size. The recovery
shares just get a bit larger.


What I like about this is that I can easily specify an example key set just
by giving the master secret.


On Tue, Sep 3, 2019 at 1:08 AM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Phillip Hallam-Baker <phill@hallambaker.com> wrote:
>     > This works with any public key algorithm but it requires a service.
>
> ....
>
>     > * 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 understand how the need for the service is different.
>
>     > 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.
>
> please expand.
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> --
> Mathmesh mailing list
> Mathmesh@ietf.org
> https://www.ietf.org/mailman/listinfo/mathmesh
>