Re: [Cfrg] Fwd: New Version Notification for draft-harkins-pkex-03.txt

Greg Hudson <> Wed, 01 November 2017 14:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E3A113FCA6 for <>; Wed, 1 Nov 2017 07:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id umm25_nKl1O0 for <>; Wed, 1 Nov 2017 07:41:10 -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 ED64113FC88 for <>; Wed, 1 Nov 2017 07:41:09 -0700 (PDT)
X-AuditID: 1209190e-e3fff70000006ad1-da-59f9dd02c027
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 19.BB.27345.30DD9F95; Wed, 1 Nov 2017 10:41:07 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id vA1Ef3FO007798; Wed, 1 Nov 2017 10:41:04 -0400
Received: from [] (VPN-18-101-8-118.MIT.EDU []) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id vA1Ef1tI020947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Nov 2017 10:41:02 -0400
To: "Stanislav V. Smyshlyaev" <>, Dan Harkins <>
References: <> <> <>
Cc: "" <>
From: Greg Hudson <>
Message-ID: <>
Date: Wed, 01 Nov 2017 10:41:00 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT0WW++zPS4PQSa4vuHweZLJb++8Ji cfbmZiYHZo+ds+6ye0zeeJjN49nulywBzFFcNimpOZllqUX6dglcGfv/nmIvWMVZcXHBJbYG xr3sXYycHBICJhLH/h5jAbGFBBYzSbzaqNXFyAVkb2CU+DTrGzOEc4RJov9xAytIlbBAoMTW fcvAbBGBWInzq/qhik4ySlxbsJEJJMEsoCyx7ttMNhCbDchev38r2ApeASuJGTN/ga1mEVCR +LP1BVi9qECExMPOXewQNYISJ2c+AavnBFr25fkTRoiZehI7rv9ihbDlJba/ncM8gVFgFpKW WUjKZiEpW8DIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXWC83s0QvNaV0EyMofDkl+XYwTmrw PsQowMGoxMPrcO1HpBBrYllxZe4hRkkOJiVR3p2O3yOF+JLyUyozEosz4otKc1KLDzFKcDAr ifCeO/MzUog3JbGyKrUoHyYlzcGiJM67LWhXpJBAemJJanZqakFqEUxWhoNDSYJX7Q5Qo2BR anpqRVpmTglCmomDE2Q4D9Dwy7dBhhcXJOYWZ6ZD5E8x6nI8m/m6gVmIJS8/L1VKnHceSJEA SFFGaR7cHHDaSeUoe8UoDvSWMK8IyDoeYMqCm/QKaAkT0BIviR8gS0oSEVJSDYxb7E2FAoyk WKOXcYQsjzCTdnr3osRY6dztmlQzCRnGgJXz3L6a2nSnbbb+Kdb87fXzvTJG4f4eb+aqH6ha eJf5smTZ5k9K20tbo62MRPKPtrwo1Fj33cNV4sxKL55YlkutHS7hm2NE/DQj3zwSPv6wMn9V 4XKrRRy/f8/cdJH730MtgYUB35RYijMSDbWYi4oTAejkx/EWAwAA
Archived-At: <>
Subject: Re: [Cfrg] Fwd: New Version Notification for draft-harkins-pkex-03.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Nov 2017 14:41:12 -0000

On 11/01/2017 01:45 AM, Stanislav V. Smyshlyaev wrote:
> 4. The PKEX protocol translates code into an elliptic curve point in the
> following way. The code is hashed within other parameters and the hash
> value is used as a scalar which an elliptic curve point is multiplied
> by. There exists small but still non-null probability that this hash
> value turns to zero modulo q, where q is the order of the used elliptic
> curve point group. If that happens, an ephemeral key is not masked and
> the overall security of the PKEX protocol is violated. It seems useful
> to add checks here and introduce some algorithm that changes zero hash
> value to a nonzero value in a deterministic way.

An active attack against this case (attempting to subvert the DH
exchange as if there is no mask) succeeds with probability 1/q, which is
no more likely than attempting to subvert the DH exchange using any
other specific mask value as an offset.  Is that a sufficient reason to
add an impossible-to-test special case?

> 2. It seems useful to add checks of X' and Y' for not being equal to the
> point at infinity.

Similarly, what's the justification for adding this special case?