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 >
- [Cfrg] A different approach to key escrow Phillip Hallam-Baker
- Re: [Cfrg] [Mathmesh] A different approach to key… Michael Richardson
- Re: [Cfrg] [Mathmesh] A different approach to key… Phillip Hallam-Baker
- Re: [Cfrg] [Mathmesh] A different approach to key… Michael Richardson
- Re: [Cfrg] [Mathmesh] A different approach to key… Phillip Hallam-Baker
- Re: [Cfrg] [Mathmesh] A different approach to key… Michael Richardson
- Re: [Cfrg] [Mathmesh] A different approach to key… Phillip Hallam-Baker
- Re: [Cfrg] [Mathmesh] A different approach to key… Nico Williams
- Re: [Cfrg] [Mathmesh] A different approach to key… Phillip Hallam-Baker