Re: [Cfrg] Weak Diffie-Hellman Primes

Dan Brown <> Mon, 12 October 2020 18:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6948F3A15FE for <>; Mon, 12 Oct 2020 11:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 cq9kmz5g5Q35 for <>; Mon, 12 Oct 2020 11:22:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D19913A15FB for <>; Mon, 12 Oct 2020 11:22:42 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 09CIMf6d135973; Mon, 12 Oct 2020 14:22:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=corp19; bh=Vjfm4Ads9T4wRjsunBNpNG2eiMtmF6OncDMxzipUo58=; b=QolzGtacI8uVeNkBAkqLzEV41CRayh93ySQ/Pw44xgE2mtCLAbRUZaQP/W8HIBtD3LRB vW+UsJjxCqDlvDlVBaCQ3r1Qi1/F3doUj+sXofE9h6EyUzjn07V3uQvf5Suvl/D5CQbt 0DlwLiiTWPPRLdfaZUxxct4ZAkRH6sj2T4PtG48K/Z+nc+qYuGIdFMx8DAErtlw9rOSb bNrgl/PX0+Cuu4n/UK+4LOU+gTpToS89/USsXAEUygQdK1VVTR1ErooIzAHU1r8vkU1E +b64ghvif3kw3f1MwWQ8EXr9EA0CWoMtNulJuEiW9WZObaJlONg0sbc+EeVdebBRD4Rk SA==
Received: from ( []) by with ESMTP id 3439qg4cgx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 12 Oct 2020 14:22:40 -0400
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Mon, 12 Oct 2020 14:22:40 -0400
Received: from ([fe80::ac8d:3541:704c:478a]) by ([fe80::ac8d:3541:704c:478a%5]) with mapi id 15.01.2044.006; Mon, 12 Oct 2020 14:22:40 -0400
From: Dan Brown <>
To: "" <>, "" <>
Thread-Topic: [Cfrg] Weak Diffie-Hellman Primes
Thread-Index: AQHWn1D34pYtvany5EGirh9LlmK08amUSrQp
Date: Mon, 12 Oct 2020 18:22:40 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_da998077e86749298c5e158c322c06fablackberrycom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-12_15:2020-10-12, 2020-10-12 signatures=0
Archived-At: <>
Subject: Re: [Cfrg] Weak Diffie-Hellman Primes
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Oct 2020 18:22:46 -0000

Hi Mike and CFRG list,

Not sure where to draw line between false alarms and well-intentioned concerns, since these can intersect, so I tried to understand Mike's DLP attack strategy ...

Somehow he aims to find bits, the 2^j, in the quotient of 2^X over P.  But there are nearly X/2 such bits, so finding them all would cost as much as exhaustive search.

(C.f. Polar rho method, taking sqrt(X) steps.) ​

Likely misunderstood the proposed method, but am at least trying.

Sent with BlackBerry Work (
From: Michael D'Errico <>
Sent: Oct 10, 2020 6:01 PM
Subject: [Cfrg] Weak Diffie-Hellman Primes


I'm not a member of this list, but was encouraged to
start a discussion here about a discovery I made
w.r.t. the published Diffie-Hellman prime numbers in
RFC's 2409, 3526, and 7919.  These primes all have
a very interesting property where you get 64 or more
bits (the least significant bits of 2^X mod P for some
secret X and prime P) detailing how the modulo
operation was done.  These 64 bits probably reduce
the security of Diffie-Hellman key exchanges though
I have not tried to figure out how.

The number 2^X is going to be a single bit with value
1 followed by a lot of zeros.  All of the primes in the
above mentioned RFC's have 64 bits of 1 in the most
and least significant positions.  The 2's complement
of these primes will have a one in the least significant
bit and at least 63 zeros to the left.

When you think about how a modulo operation is done
manually, you compare a shifted version of P against
the current value of the operand (which is initially 2^X)
and if it's larger than the (shifted) P, you subtract P at
that position and shift P to the right, or if the operand
is smaller than (the shifted) P, you just shift P to the
right without subtracting.

Instead of subtracting, you can add the 2's complement
I mentioned above.  Because of the fact that there are
63 zeros followed by a 1 in the lowest position, you will
see a record of when the modulo operation performed
a subtraction (there's a one) and when it didn't (there's
a zero).

You can use the value of the result you were given by
your peer (which is 2^X mod P) and then add back the
various 2^j * P's detailed wherever the lowest 64 bits
had a value of 1 to find the state of the mod  P operation
when it wasn't yet finished.  This intermediate result is
likely going to make it easier to determine X than just a
brute force search.

I don't plan to join this list, though I am flattered to have
been asked to do so.  I'm not a cryptographer.


Cfrg mailing list

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.