Re: [Cfrg] Applied Quantum Resistant Crypto

Kris Kwiatkowski <kris@cloudflare.com> Wed, 18 July 2018 09:44 UTC

Return-Path: <kris@cloudflare.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 4B7A213111E for <cfrg@ietfa.amsl.com>; Wed, 18 Jul 2018 02:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
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 ez8KPXERPVCq for <cfrg@ietfa.amsl.com>; Wed, 18 Jul 2018 02:44:01 -0700 (PDT)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 85A86130DD8 for <cfrg@irtf.org>; Wed, 18 Jul 2018 02:44:00 -0700 (PDT)
Received: by mail-wr1-x435.google.com with SMTP id v14-v6so3978405wro.5 for <cfrg@irtf.org>; Wed, 18 Jul 2018 02:44:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=mOZCHph6mxraQRNm45DHOAdXepO357xZsLjfU7MD+aU=; b=d7Wclbz3j3k9vYTC4vyICurzjIyqMfpMYg+afjj00ZM4MKAHabzZcHg7I+v2PayY/Z 2p6VlZ7cYnkEGxJoqnyvrWI2gbTn+hh5J4bqJX93xiZf4kcqP2JhXYYNJutIRSzhii8C hNgnkRCDFTDGTPREKqeq1wUAbzA2+IktdlRzI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=mOZCHph6mxraQRNm45DHOAdXepO357xZsLjfU7MD+aU=; b=qq1+FYb09dHH5+rcFydOUd/NcUxFRmSGtsEP5zJ08U+rccwsJkRO0xGe7k/WteNHKg 0HvDNPg4eQ/UGzNI4hCy4NQ1qkz7MGO6B2tuc2XsFiuYmSH9kkCErfy4IL0csfGjUERE Ahr94pv7DYoH9H3YZYyGKYTqfI5jckf3XiHUwazcDaZuvyP6LVSK/Yo+m54uuRAwNvUh vny3un7HYewFBLBZM4jJgXeaWZGi4gwUpwlHXXOb15sed+QDhi88mEqtReW/LxCBfrVE +8jrfOVclSmEw/mAFlzLmsObDj11/vUflBOHJ8jDzQLyFJv0Kb+kAHITnvFnxlPCUUV9 RlyQ==
X-Gm-Message-State: AOUpUlEgYi9X+n0f0FKaDE1Iis8ZjoFerCMGdmiFgwIFCEwdfermSKpC 6X1akRSqyx1HU8W2ggzMnY+Dt1NGy6s=
X-Google-Smtp-Source: AAOMgpcGtBdTXPtiKPe3ihGkZDsjpEVXk581BVjBzGa9InKFsfQNeOYDYtIVxzxftFm7NCrY19htmg==
X-Received: by 2002:adf:b112:: with SMTP id l18-v6mr4075938wra.101.1531907038650; Wed, 18 Jul 2018 02:43:58 -0700 (PDT)
Received: from ?IPv6:2a06:98c0:1000:8800:c84f:a1a4:15b9:a87b? ([2a06:98c0:1000:8800:c84f:a1a4:15b9:a87b]) by smtp.gmail.com with ESMTPSA id n198-v6sm2152941wmd.33.2018.07.18.02.43.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jul 2018 02:43:57 -0700 (PDT)
To: "Panos Kampanakis (pkampana)" <pkampana=40cisco.com@dmarc.ietf.org>, "cfrg@irtf.org" <cfrg@irtf.org>
References: <42efe1a4-0532-dbb0-a21a-10120f6656b3@openca.org> <37a4f236-6842-b1ce-68f4-805f2e3f8a48@cloudflare.com> <1b8ed08eaa56457b93e1dfd3b0e7235e@XCH-ALN-010.cisco.com>
From: Kris Kwiatkowski <kris@cloudflare.com>
Message-ID: <42b8b7c9-1440-217d-694f-2971013fddba@cloudflare.com>
Date: Wed, 18 Jul 2018 10:45:55 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <1b8ed08eaa56457b93e1dfd3b0e7235e@XCH-ALN-010.cisco.com>
Content-Type: multipart/alternative; boundary="------------D060004B8BEEB9AED4EC625B"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/jcmuo5gdUCTTINBbaZ-A-wEF9U4>
Subject: Re: [Cfrg] Applied Quantum Resistant Crypto
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.27
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: Wed, 18 Jul 2018 09:44:08 -0000

Hi Panos,

Definitely hybrid approach, I just quickly looked at a draft, but I it's
good base. Nevertheless
I'm planning to start TLS part somewhere next week and maybe.

In fact, we would like to experiment with many different KEMs (based on
different hard problems).
At a time SIDH looked quite promising (indeed key sizes). It is simply
first one to try. It's also
interesting to see if work done around ECC could be "reused" for some
parts of QR algorithms.

Kind regards,
Kris


On 7/18/18 4:01 AM, Panos Kampanakis (pkampana) wrote:
>
> Hi Kris,
>
>  
>
> Thank you for the update. Interested to see your results and SIKE’s
> performance.
>
>  
>
> Were you thinking to use SIKE in TLS 1.3 a similar manner to the one
> proposed in https://tools.ietf.org/html/draft-whyte-qsh-tls13-06 which
> uses a hybrid approach (traditional+QRC) KEM?
>
>  
>
> Also, SIKE has pretty small keys, but performance is much higher. From
> the reference benchmarks performance SIKE seemed to be 10^4 more
> expensive than the best candidate that does not have prohibitive KEM
> pk and ciphertext sizes. Any reason why you chose SIKE that you can share?
>
>  
>
> Rgs,
>
> Panos
>
>  
>
>  
>
> *From:*Cfrg [mailto:cfrg-bounces@irtf.org] *On Behalf Of *Kris Kwiatkowski
> *Sent:* Tuesday, July 17, 2018 5:28 PM
> *To:* cfrg@irtf.org
> *Subject:* Re: [Cfrg] Applied Quantum Resistant Crypto
>
>  
>
> Hi,
>
> At Cloudflare we are currently implementing SIKE/SIDH in Go
> (https://github.com/cloudflare/p751sidh/pulls). Next step will be to
> add it to TLS 1.3 (https://github.com/cloudflare/tls-tris). We may
> want to use it for some some other things.
> I'm definitely interested in discussion regarding QRC in real-world
> crypto.
>
> Kind regards,
> Kris Kwiatkowski
>
> On 7/17/18 8:35 PM, Dr. Pala wrote:
>
>     Hi all,
>
>     I was wondering if there are people interested in setting up some
>     sort of discussion forum where to discuss the deployment (from a
>     practical point of view) for QRC in their systems. The intent here
>     would be to share the experiences, provide feedback, and possibly
>     even share implementations/references/etc.
>
>     Moreover, being this quite a new field when it comes to real-world
>     applications, it would be interesting to understand the new
>     requirements so that we can plan for algorithm agility correctly
>     and not having to go through what we suffered in the past (and in
>     some cases with current protocols) to upgrade/switch among
>     different schemes/algorithms.
>
>     For example, some of the topics might include:
>
>       * How to deploy PKI services
>       * Mixed environments considerations (QRC and "Traditional" Crypto)
>       * Mixed environments (stateful vs. stateless)
>       * Encryption and Key-Exchange for QRC - what are the options
>         there (it seems auth is well understood, but other problems
>         are still open)?
>       * Are there implications for the deployment of PKIs we need to
>         be aware of and are not currently mentioned/addressed?
>       * Any real-world deployment out there (or plans for it)?
>       * Algorithm Agility, what to plan for?
>       * Applicability to Revocation Services
>
>     Most of the activities to standardize QRC in CMS/SecFirmware/etc.
>     that I can see are related to the use of Stateful HASHSIG and I
>     have not seen any "standardization" activities around stateless
>     schemes (e.g., SPHINCS), but if I am wrong, please let me know
>     (and if you could provide some interesting links, that would be
>     great). I think it would be useful to understand how to
>     practically deploy these new schemes and how to refine / provide
>     the building blocks required for their implementation and deployment.
>
>     Here's some references:
>
>     Merkle Tree Signatures (Stateful):
>
>       * https://datatracker.ietf.org/doc/draft-mcgrew-hash-sigs/
>       * https://datatracker.ietf.org/doc/draft-housley-cms-mts-hash-sig/
>       * https://www.ietf.org/id/draft-housley-suit-cose-hash-sig-04.txt
>       * https://datatracker.ietf.org/doc/rfc8391/ (XMSS)
>       * https://eprint.iacr.org/2018/063 (Viability of Post Quantum
>         X.509 Certs Paper)
>       * Implementations:
>
>           o https://github.com/cisco/hash-sigs
>
>     SPHINCS Related (Stateless):
>
>       * https://sphincs.org/
>       * Implementations:
>
>           o https://sphincs.org/data/sphincs+-reference-implementation-20180313.tar.bz2
>
>     Other Relevant Links:
>
>       * https://datatracker.ietf.org/doc/draft-truskovsky-lamps-pq-hybrid-x509/
>       * https://csrc.nist.gov/Projects/Post-Quantum-Cryptography
>       * http://test-pqpki.com/
>
>     I guess this is all for now - you can reply privately at the
>     following addresses:
>
>         director@openca.org <mailto:director@openca.org>
>         m.pala@cablelabs.com <mailto:m.pala@cablelabs.com>
>
>     Thanks,
>     Max
>
>     -- 
>
>     Best Regards,
>
>     Massimiliano Pala, Ph.D.
>     OpenCA Labs Director
>
>     OpenCA Logo
>
>
>
>     _______________________________________________
>
>     Cfrg mailing list
>
>     Cfrg@irtf.org <mailto:Cfrg@irtf.org>
>
>     https://www.irtf.org/mailman/listinfo/cfrg
>
>
>
>
> -- 
> Kris Kwiatkowski
> Cryptography Engineer
> Cloudflare

-- 
Kris Kwiatkowski
Cryptography Engineer
Cloudflare