Re: [Cfrg] Threshold signatures

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 03 January 2020 16:15 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 22867120043 for <cfrg@ietfa.amsl.com>; Fri, 3 Jan 2020 08:15:52 -0800 (PST)
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.25, 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] 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 lOHB37ecquYn for <cfrg@ietfa.amsl.com>; Fri, 3 Jan 2020 08:15:51 -0800 (PST)
Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) (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 DFD0012000F for <cfrg@irtf.org>; Fri, 3 Jan 2020 08:15:50 -0800 (PST)
Received: by mail-ot1-f52.google.com with SMTP id k8so44557136otl.13 for <cfrg@irtf.org>; Fri, 03 Jan 2020 08:15:50 -0800 (PST)
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=TwaGbBm9UIdRyV78A4ToTWJJNGaXe2wpFI9lGEekFME=; b=eGbBqFp2/BlI7Mj0en+whEQ7kViXVhU8H7sXJhY/HYF7JpefeYeeuZDHL7hXee+Bwp 6Q1UuvAf9+aepR95HXl/DIHb5wl9Ks2ke0gys0Y8Bobzso6WJ/HlB0iPxM3d3gi4rnwQ lLqaDiu0vmcXJsirawhi7Zm20BFiP9Eszpo1o5bo3w9uaNpZelSdxHFGrEDuXOg9/x1+ WpFmi07KpNcGWeox5B0lGEmNnC8rBv/S+mhTv5tjUtuW4mUNXva0lXpFYT2ZJfCjJc8t jjnlbmNiYBca+fPWj1gML2ADGmygU8xo8kWXcYwljNwWR8sBmpiPLx8cr82sY/efaTbU HBlA==
X-Gm-Message-State: APjAAAXGDKb7Hmv77Ij15/LlBgq9QB/yA0CchPr1+r7Xro3liqPy8kqt rhIvuSG9eevHPfkrYo+pONmtb1FONF3oAEd0icA=
X-Google-Smtp-Source: APXvYqzhKawNnOLpNMGx5AqeoHKFAFUtPlmt3uQ5gxMNDOoDBnpggXrJa1TMDBq5jLDNrEApio1IYu3rEUBSsYqnJeg=
X-Received: by 2002:a9d:7c8a:: with SMTP id q10mr93004609otn.124.1578068150175; Fri, 03 Jan 2020 08:15:50 -0800 (PST)
MIME-Version: 1.0
References: <CAMm+LwiXTA7UoFwSWE_c-cy_EdtYE5qFAm594UfFkdAVLNhimg@mail.gmail.com> <902BF3DD-4515-4A23-B7B7-0C9D8726E56F@gnunet.org> <CAOLP8p5Q=xswL7vkXVpSbVHUZ1dV+1wT3YdViq+1re1=fiSpRA@mail.gmail.com> <CAMm+LwiC5tBCd=fUo9e1tuQFVJ8C6hMXSxRZk2xff1238_9HRA@mail.gmail.com> <BY5PR11MB40863C934F2381D4701A5156C1230@BY5PR11MB4086.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB40863C934F2381D4701A5156C1230@BY5PR11MB4086.namprd11.prod.outlook.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 03 Jan 2020 11:15:38 -0500
Message-ID: <CAMm+Lwj4WVXiExsbHQcPYSDEcBz0Ghiv_hGu8Tf7OKE17d8-EQ@mail.gmail.com>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
Cc: Bill Cox <waywardgeek@gmail.com>, IRTF CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="00000000000085cb62059b3e9fb7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/t3eO_a_97EYM6l0rcVxqKjSslp0>
Subject: Re: [Cfrg] Threshold signatures
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: Fri, 03 Jan 2020 16:15:52 -0000

On Fri, Jan 3, 2020 at 10:24 AM Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com>
wrote:

>
>
> *From:* Cfrg <cfrg-bounces@irtf.org> *On Behalf Of * Phillip Hallam-Baker
>


> We take a long time to get comfortable with it. NSA nagged us about
> Suite-B for how many decades before we started using ECC?
>
>
>
> At this point, I think we need to focus on making X25519/448 and
> Ed25519/448 the basis for the next gen of security products. It took about
> five years from AES being announced as a winner for it to become the new
> normal.
>
>
>
> Hmmmm, it is likely at some point someone will have a cryptographically
> relevant Quantum Computer, such a Quantum Computer can break elliptic
> curves (and, in fact, Elliptic Curves appear to be the easiest
> cryptographical object to break, as it requires the fewest qubits and
> circuit depth).  No one is certain when (or if) such a Quantum Computer
> will exist; maybe in 10 years, or 20.  However, if we are planning for the
> future, it would appear to be reasonable to take that into account, and
> include a postquantum scheme (possibly in conjunction with a classical ECC
> or RSA scheme)
>

Building a post-quantum PKI is a worthwhile project that the IRTF should
pursue and I would be very interested in participating in such a scheme.

But why should anyone believe we are capable of building a PKI with the
next generation of crypto technology that we haven't invented yet if we
still haven't deployed a PKI capable of meeting the needs of user
authentication across multiple devices, IoT onboarding or Data at Rest
security?

I am just as skilled in the art of procrastination as anyone else. The
reason I am focused on existing PKI technology is because that is what I
believe the world needs right now.

If we are serious about quantum, we should consider the worst case
scenario. That is someone has a working quantum machine capable of breaking
all existing public key systems in 2030 and we do not have a post quantum
algorithm we are confident in.

That is the only scenario I have currently considered for the Mesh and my
proposed approach is to use PKI while we still have it to establish shared
secrets and Lamport signatures that we can then use to establish a Kerberos
type key distribution scheme.

I do not think it is very likely the quantum folk will have such a machine
in 2030. But I am very confident that if they can build a machine capable
of breaking X25519 then it is game over for RSA4096. Don't be fooled by
Moore's law, the barrier to building bigger quantum machines is not minimum
feature size. Building a 1000 QBit machine today would be well within the
capabilities of the fabs. There would just be no way to use it before
losing coherence. The time to get worried is not when someone shows a 50 or
100 QBit machine, the time to get worried is when they can make it work
without the fridge. If they get trapped ions to work at scale, worry.
Biggly.

Right now, nobody is paying me to do any of this stuff. If people are
seriously worried about post quantum PKI, cut me a check and I will be more
than happy spending the next three, six months or however long it takes to
get something. But as things stand, the probability that we will see more
billion dollar data at rest breaches is 100% and the probability of a
quantum computer breaking x25519 by 2030 is less than 5%.