[Cfrg] Fwd: New Version Notification for draft-whyte-select-pkc-qsh-00.txt

William Whyte <wwhyte@securityinnovation.com> Mon, 21 September 2015 02:52 UTC

Return-Path: <wwhyte@securityinnovation.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1700C1A1EF1 for <cfrg@ietfa.amsl.com>; Sun, 20 Sep 2015 19:52:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 RpkEAh7IEVV1 for <cfrg@ietfa.amsl.com>; Sun, 20 Sep 2015 19:52:42 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 2A9061A1EEC for <cfrg@irtf.org>; Sun, 20 Sep 2015 19:52:42 -0700 (PDT)
Received: by wicfx3 with SMTP id fx3so126683492wic.1 for <cfrg@irtf.org>; Sun, 20 Sep 2015 19:52:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7+im5Q+w2w4A7R0U9i8FWTiTfmw/uhznaWO8kUBc7DQ=; b=Zu0/uJQOx74PAP4Z1Trvm57NsaL+w9u07KJyLNPPl1uJ5IUXBmvirnGneujGXRHAF2 9o6OuCwDJGCA9srpzlzgQTpuZboAWz5bNrfXNPPLIdapQCWt3mugClFlkomAYFvKpF3G X05M3nzExYf3olTbXR6ukz6E6r1QHvuBZQIKc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=7+im5Q+w2w4A7R0U9i8FWTiTfmw/uhznaWO8kUBc7DQ=; b=PzbE19QFWvGdTcIRCjtlonqqVqgS2WJaAHl+tKlvyyRC5LP6AY3NkhI2KovJRnBaar R0h/eZy71xEzxfyCJjf8iXFFMOyU86w5BY2QO++hSeJXKFmob0+hItdjTE2qcY4q0bit MFLnxRz4R/x/ww0fYXYBPQJgQt2VMM3rpX29pozGUtrJIVYvmcWll8OBTYdUXfacuapx mz+R8zXjyrxi5WzjGMQLMkNpCDvTCSDdUvlTsOpzs9zu7/q52PwOWxIlCF3Tus9kuZ3L A45VyfLTOhd4XGfUqwJmkv0lTWV2X0lPmebeULVuF1KjjnKwulo+woAvs1LrbEnVGmiQ O+Fw==
X-Gm-Message-State: ALoCoQlBqfe7EfIB02fUq4AOxlIRNx5bahQKXqRVqc/MweXrdSZakAJrOJb8kPqvEDbTiuOssOoK
MIME-Version: 1.0
X-Received: by 10.194.178.196 with SMTP id da4mr23663004wjc.41.1442803960598; Sun, 20 Sep 2015 19:52:40 -0700 (PDT)
Received: by 10.194.216.195 with HTTP; Sun, 20 Sep 2015 19:52:40 -0700 (PDT)
In-Reply-To: <20150921024203.25496.60357.idtracker@ietfa.amsl.com>
References: <20150921024203.25496.60357.idtracker@ietfa.amsl.com>
Date: Sun, 20 Sep 2015 22:52:40 -0400
Message-ID: <CACz1E9pBAx1OROWoAJdoTViat48SE6UYcR+=E-Ejn_wBjhnZSQ@mail.gmail.com>
From: William Whyte <wwhyte@securityinnovation.com>
To: CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary=089e013d18ca8d6ad1052038f94c
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/Q6jbr1Y6yRbhcMkFLI8KpWthYjE>
Subject: [Cfrg] Fwd: New Version Notification for draft-whyte-select-pkc-qsh-00.txt
X-BeenThere: cfrg@mail.ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.mail.ietf.org>
List-Unsubscribe: <https://mail.ietf.org/mailman/options/cfrg>, <mailto:cfrg-request@mail.ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@mail.ietf.org>
List-Help: <mailto:cfrg-request@mail.ietf.org?subject=help>
List-Subscribe: <https://mail.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@mail.ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2015 02:52:45 -0000

Hi list,

following up on our discussion in Prague, I and my colleagues John Schanck
and Zhenfei Zhang have submitted an internet draft containing criteria that
can be used to select algorithms suitable for use in the quantum safe
hybrid (or "mix-in") context.

The MUST criteria are:

   The candidate algorithm MUST provide 128 bit security in the quantum-
   safe setting.

   If the candidate algorithm is subject to decryption failures, these
   MUST happen with a probability of less than 2^-74 (such that 128
   billion devices (2^7 * 2^30) each initiating 128 billion connections
   (2^7 * 2^30) will with high probability encounter no decryption
   failures).

   The candidate algorithm MUST have a set of publicly accessible
   documents specifying common techniques and implementation choices.
   [[ to the extent necessary to allow the development of interoperable
   implementations ]]

   MUST have a stable reference implementation available
   for the candidate algorithm.  The code needs to be rigorously tested
   and reviewable.

The SHOULD criteria are:

   The implementation SHOULD also be open source to allow for public
   auditing.

   The candidate algorithm MAY have a reference implementation for
   SUPERCOP.  Performance of the implementation on SUPERCOP MAY be taken
   into consideration when selections are made.

   Algorithms with provable constant time implementations SHOULD be
   preferred. However, this is not an absolute requirement as the QSH
   setting uses ephemeral keys and an implementation of QSH SHOULD only
   decrypt once with any key, so an attacker is unlikely to gain
   sufficient information from the time of a single decryption to
   recover the plaintext.

   The candidate algorithm MAY be standardized by another standards
   body, such as ANSI X.9, IEEE, or ETSI.  Algorithms that maintain
   creditability among multiple standards bodies SHOULD be preferred.

   The candidate algorithm MAY be either non-patented or patented but
   with FRAND (Free or Reasonable and Non-Discriminatory) licensing
   statement made and all relevant IETF IP declarations provided.

We've included some recommended NTRUEncrypt parameter sets as permissible
by these criteria, but this is a first draft and isn't yet intended to be
an exhaustive list. All feedback is welcome on both the criteria themselves
and whether there are other algorithms that meet them. (For example, there
may well be a spec of McBits detailed enough to support interoperability --
we didn't look hard for this in the the interests of getting this first
draft out, but if McBits meets the criteria it should of course go in).

Cheers,

William





---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Sun, Sep 20, 2015 at 10:42 PM
Subject: New Version Notification for draft-whyte-select-pkc-qsh-00.txt
To: Zhenfei Zhang <zzhang@securityinnovation.com>om>, William Whyte <
wwhyte@securityinnovation.com>gt;, "John M. Schanck" <
jschanck@securityinnovation.com>



A new version of I-D, draft-whyte-select-pkc-qsh-00.txt
has been successfully submitted by William Whyte and posted to the
IETF repository.

Name:           draft-whyte-select-pkc-qsh
Revision:       00
Title:          Criteria for selection of public-key cryptographic
algorithms for quantum-safe hybrid cryptography
Document date:  2015-09-20
Group:          Individual Submission
Pages:          14
URL:
https://www.ietf.org/internet-drafts/draft-whyte-select-pkc-qsh-00.txt
Status:         https://datatracker.ietf.org/doc/draft-whyte-select-pkc-qsh/
Htmlized:       https://tools.ietf.org/html/draft-whyte-select-pkc-qsh-00


Abstract:
   Authenticated key exchange mechanisms instantiated with cryptosystems
   based on integer factorization, finite field discrete log, or
   elliptic curve discrete log, are believed to be secure now but are
   vulnerable to a harvest-then-decrypt attack where an attacker who
   cannot currently break the mechanism records the traffic anyway, then
   decrypts it at some point in the future when quantum computers become
   available.  The Quantum-safe Hybrid approach is a modular design,
   allowing any authenticated key exchange mechanism to be protected
   against the harvest-then-decrypt attack by exchanging additional
   secret material protected with an ephemeral key for a quantum-safe
   public key cryptographic algorithm and including that secret material
   in the Key Derivation Function (KDF) run at the end of the key
   exchange.  This approach has been proposed in TLS as the Quantum-safe
   Hybrid handshake mechanism for Transport Layer Security protocol
   (QSH_TLS).  This document provides a guideline to criteria for
   selecting public key encryption algorithms approved for experimental
   use in the quantum safe hybrid setting.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat