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

Martin Thomson <> Fri, 28 October 2016 05:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54A1D129610 for <>; Thu, 27 Oct 2016 22:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vJxgFV0010bS for <>; Thu, 27 Oct 2016 22:24:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54060129503 for <>; Thu, 27 Oct 2016 22:24:06 -0700 (PDT)
Received: by with SMTP id v138so1394561qka.2 for <>; Thu, 27 Oct 2016 22:24:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id o16mr9866676qke.5.1477632245419; Thu, 27 Oct 2016 22:24:05 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 27 Oct 2016 22:24:04 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Martin Thomson <>
Date: Fri, 28 Oct 2016 16:24:04 +1100
Message-ID: <>
To: Phillip Hallam-Baker <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [Cfrg] What groups to use for Diffie Hellman?
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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:
> Links to the code libraries and API documentation can be found here:
> The beginnings of the recryption API are to be found here:
> [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