Re: [Cfrg] What groups to use for Diffie Hellman?

Martin Thomson <martin.thomson@gmail.com> Fri, 28 October 2016 05:24 UTC

Return-Path: <martin.thomson@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 54A1D129610 for <cfrg@ietfa.amsl.com>; Thu, 27 Oct 2016 22:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vJxgFV0010bS for <cfrg@ietfa.amsl.com>; Thu, 27 Oct 2016 22:24:06 -0700 (PDT)
Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 54060129503 for <cfrg@irtf.org>; Thu, 27 Oct 2016 22:24:06 -0700 (PDT)
Received: by mail-qk0-x242.google.com with SMTP id v138so1394561qka.2 for <cfrg@irtf.org>; Thu, 27 Oct 2016 22:24:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ShVHFHlWFZdVrDrS8UP/A0Vz71id2Q7qgPJ/WCs3IWE=; b=corprSbuCxW9fC98LoV+GFqvAFo5v8JhziWxUj5on5xj85H8OtxxmSMOakk6x9BZkz Zx+uKetMGmPaRIXwC1091kJRLiN9fTjGun0ImGZ036MeTxFNcvFzeeGdD5g6NrG0TrfX n79ReZhkTpQGE4VpfDv32jfsHim9TEEwGMX0q/z6kUWdKhvln3/FpLpPEudryxZAIieS /TA5AVqCqeTe1/cNvp0A1GCVh+LOrf4fuWsBkPSZLGqDuFE4txyITZm7jbf8arvo3zdv MgosBFczc/xaTS1e8zz1HkM44Z3Cwh6S1DGjgq2Hctklw18fh+EMtahhz5Gy4k0leEzE u7Lg==
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:from:date :message-id:subject:to:cc; bh=ShVHFHlWFZdVrDrS8UP/A0Vz71id2Q7qgPJ/WCs3IWE=; b=dANBuRQdb5g5Wn8PBVSIIr2SPD+I3sIWIN5tCw+Oe6ooFQv1zdsa1veCf6AEDAKttb LJpawaOtJM0RIejj8Xbbbx9F2GB/aBfR5ZZ5d1MGDZrVPc3aABUBkw9dTtVwatCwmJNo HGJ7ORXfEZ3bG+ZOeaV0zautj2ealH9IWIAGgWjvA51InXeHZtUyEgi3VgZCOuI0wqRq 5FVP0Y33OVwFWPEMJ91tvHnjnHyhRPHda6PMHpmh4JWr1umlr/c43h8WRbKk/2po9QTk Q2AZmWX7AjwRxrVFhAh70zs5DPVGYNsnKaVUAz/5IevLzJ8w0umnAzsgIaxy1qukdHoK xfiw==
X-Gm-Message-State: ABUngvfKdqQtt5KQ+YAFQQ43QI+lGKpzdW3zrTcMHSL6mgWnB6jmDQAkGoukwEcWnxBUaB1BzgoRgz02rQBXnA==
X-Received: by 10.55.165.16 with SMTP id o16mr9866676qke.5.1477632245419; Thu, 27 Oct 2016 22:24:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Thu, 27 Oct 2016 22:24:04 -0700 (PDT)
In-Reply-To: <CAMm+LwjZX=xsq7xM8Tti6u4ecNKHjXW_rsEUSV=63so816uNWw@mail.gmail.com>
References: <CAMm+LwjZX=xsq7xM8Tti6u4ecNKHjXW_rsEUSV=63so816uNWw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 28 Oct 2016 16:24:04 +1100
Message-ID: <CABkgnnWg9iHL7jAQcNJZV-Fv6PpDUB=Q-_OAUTqOA5jp+cA0_Q@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/IN_AjxJ9UK-fcV6HKk9IMlPgOTw>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] What groups to use for Diffie Hellman?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
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, 28 Oct 2016 05:24:08 -0000

RFC 7919 (and RFC 3526, as Peter points out) haven't been called into question.



On 28 October 2016 at 01:47, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> I am currently working on a set of APIs to support the use of proxy
> recryption within a cryptography application. Recryption solves many
> problems in designing end-to-end secure messaging applications.
>
> The following draft shows where I am headed:
> https://datatracker.ietf.org/doc/draft-hallambaker-mesh-recrypt/
>
> Links to the code libraries and API documentation can be found here:
> http://www.prismproof.org/code.html
>
> The beginnings of the recryption API are to be found here:
> http://www.prismproof.org/code/portable/html/1a1794fd-cbe8-6e8b-9868-64028331fad8.htm
>
> [All the code is under MIT license]
>
> The API does not change much for recryption. The first step is identical,
> the only difference being that instead of putting the key agreement
> BigInteger result through a hash function, you send it on to the recipient
> who then calls an agreement method that takes it as an additional parameter.
>
>
> For ease of debugging, I would prefer to have as few moving parts to debug
> at one time. So even though the intention is to us ECDH with curves x25519
> and x448 for production, I am developing using straight DH with the
> parameters in RFC 5114. (DH might also turn out to be necessary in
> deployment if quantum resistance becomes an issue though I suspect if people
> can build a 64 QBit quantum computer they will have solved most of the
> problems they need to solve to go to several thousand)
>
> The reason I am using this is that I don't want to spend time debugging
> Miller-Rabin primality tests and getting them to run fast enough to be
> useful. And that is the only RFC with DH parameters I could find that
> specifies p and q values.
>
> While finding it, I also found a lot of people complaining that RFC5114 is
> not rigidly constructed. And there are good reasons for concern.
>
>
> While writing 5114 die die die might be a good idea. A precondition for
> having people take notice is to propose a set of alternative shared
> parameters that have been constructed in a form that is 'sufficiently
> rigid'.
>
> One thing that seems to be a source of confusion is what the boundary
> between the public and the shared parameters is. And this is different in
> different protocols and while there are vast volumes of opinion on the
> subject, it is hard to get a reading.
>
>
> DH has the following parameters:
>
> The modulus prime - p
> The sub group prime - q
> The generator - g = h^{(p-1)/q} mod p
> The private key - x
> The public key - g^x mod p
>
> From my point of view as a protocol designer, the shared parameters are
> anything that is common between all the users and the public key is anything
> that isn't a shared parameter and isn't part of the private key. So there
> are multiple choices for the boundary between public and shared:
>
> 1) Share nothing
> 2) Share p
> 3) Share p, q
> 4) Share p, q, g
>
> There are two reasons to share a parameter
>
> 1) The parameter is expensive to generate.
> 2) The parameter might introduce a weakness if it isn't generated correctly.
>
> There is one good reason not to
>
> 1) Using a shared parameter may allow an attacker to attack multiple private
> keys in parallel.
>
>
> Generating p and q is costly. I don't want to do that on a constrained
> device. So the choice comes down to g. And here I have a few choices.
>
> 1) Use fixed h and thus g.
> 2) Include h in the public key parameters.
> 3) Include g in the public key parameters.
>
> The reason to include h rather than g is that it ensures that the generator
> has been correctly generated. The reason not to is that this takes extra
> time and knowing h might reduce the work factor for an attacker.
>
>
> Any ideas?
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>