[Crypto-panel] Reviews of draft-hao-schnorr-05 and draft-hao-jpake-05

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Tue, 07 March 2017 09:26 UTC

Return-Path: <smyshsv@gmail.com>
X-Original-To: crypto-panel@ietfa.amsl.com
Delivered-To: crypto-panel@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0270C129421 for <crypto-panel@ietfa.amsl.com>; Tue, 7 Mar 2017 01:26:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Yb3Ds4qSouC1 for <crypto-panel@ietfa.amsl.com>; Tue, 7 Mar 2017 01:26:01 -0800 (PST)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 A391512940A for <crypto-panel@irtf.org>; Tue, 7 Mar 2017 01:26:01 -0800 (PST)
Received: by mail-qk0-x232.google.com with SMTP id p64so79041681qke.1 for <crypto-panel@irtf.org>; Tue, 07 Mar 2017 01:26:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4gwsvIM86Pkc8lqRAl1h1IS9w5eaGR732NGRh/p1rFc=; b=TtZfzsd7zmxV3v81AHTRRwvKnpuCbsEyEvYULJTkQLVbjsv6E6zOl09c7jgL51baaH 4k+P7jpbHD1GtHvhx2OIAPOx81VI7jR0iI0oI4dsiM0Ruc9BixSzlQ9TvQmVLdGk7yip vIPJ4SxXo0PuFm6OobaE1J3cXWi3HL1X/22TnC8nD3dyeMqoMe//P8jWEfEhZCceyEGX 9hGVTRWxRy4pzW+GXZ8FFt2gATnyJwMmdIxin3rDFihVlWTYE2kgPlid+M/voD+naWGL BqiBZfii31B41UhBmL/Ivjz0Dw8LWD43CvzuIn5cTLU2zfkoZBbI2mtqwwFqyveFMN5B S3sA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4gwsvIM86Pkc8lqRAl1h1IS9w5eaGR732NGRh/p1rFc=; b=ehSff4KiQfwgZZHH9hipC+OzSdDbGtYZh15fwBBL1dphgEEu69eE0c96NBDuZ4lfX9 WW26CqX9Qzsa8Gbw80CeCnHT77fbWZE5BqkFCgWcVTLIMvCCUMdT+wtRYKfjxmbQw2bf Zkkc6G7Swh+TN69DMm9RvH6pF/NVtH10yB5XCn12d8MxLj33b2BxemhBLaM1If6wrfk9 DUjxJsZ/OpL9FooxUpFfZhI1Z+E83G72mcY5ojJCMhG+Ns/KiUZHurGD0qSQGOaHNboF 0zy9i3I1vvf+3/T1gZ7zqIPneat2yVOGgtS9geJolwXqJLWHwjfnoEwmKASTtKSAn46B lzaQ==
X-Gm-Message-State: AMke39mv6c+hhkGjX5r4pxoDXOQor33L5D/qH59kxBA5rDzLO/BzSM8eJpY5rkojVWhGu4YmwhmkpqFE3Wex4g==
X-Received: by with SMTP id b15mr22342218qtc.9.1488878760826; Tue, 07 Mar 2017 01:26:00 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 7 Mar 2017 01:26:00 -0800 (PST)
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Tue, 7 Mar 2017 12:26:00 +0300
Message-ID: <CAMr0u6mgh9QtN7xAsGhht=A9QeGPSjJxg=-71Pj5CVN+sJitZA@mail.gmail.com>
To: crypto-panel@irtf.org, Nevil Brownlee <rfc-ise@rfc-editor.org>, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
Content-Type: multipart/alternative; boundary=001a1139782aa73564054a20993b
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/oj0BV604h0Rc7w-EnUMt3YMMXl0>
Subject: [Crypto-panel] Reviews of draft-hao-schnorr-05 and draft-hao-jpake-05
X-BeenThere: crypto-panel@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <crypto-panel.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/crypto-panel/>
List-Post: <mailto:crypto-panel@irtf.org>
List-Help: <mailto:crypto-panel-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2017 09:26:04 -0000

Document: draft-hao-schnorr-05
Reviewer: Stanislav Smyshlyaev
Review Date: 2017-03-06

Overall opinion: Minor changes needed

The -05 version addresses most of my concerns described in my brief review
for -04 version (in October 2016), but I’d still prefer some changes to be
made. The Schnorr signature scheme and the Schnorr NIZK proof have a
difficult history (including their relationship with DSA) – and I think it
is quite a good idea to have an RFC on them. We’ve had a discussion with
Feng Hao after -04 version, now I am not against publication of Schnorr
NIZK in a separate RFC (without signature scheme, though), so, in my
opinion, only minor changes are still needed.

In my previous review I said that it would be useful to give certain
recommendations about hash functions and elliptic curve parameters. Though
some words are now given, I’d recommend to change terms a bit: collision
resistance is not the property that is really needed for random oracle
model. Tibor’s proposal of saying “secure cryptographic hash function”
seems to be a good option – in this case we won’t go too far into details,
but would prevent using something non-cryptographic (e.g. HighwayHash). And
instead of saying “Recommended hash functions include…” I’d prefer to see a
more relaxed phrase like “e.g. SHA-256, SHA-512, …”.

I am not really sure that the comment about a simultaneous exponentiation
technique in 2.4 and in 3.4 is needed. The issue is that g (or G) is always
known beforehand (even before Bob is aware of Alice’s ID and her X (or Q) )
– so the table for powers of g (or G) can be precomputed beforehand, which
would make simultaneous exponentiation (with a necessity to generate a
precomputation table for a pair of (g, X) ) ineffective. Anyway, that’s not
critical and may remain unchanged, if the author wants it.

Though originally the scheme was named “an identification scheme”, the
scheme actually implements authentication (assumed identities are known
before the start of the protocol) thus I’d prefer to revise the terms in
the paper a bit.

The comment about the public key validation (for a case of  a small
cofactor) in 3.4 should be specified a little – leaving only a reference
for [MOV96] looks not very convenient here: e.g. to say that at least it
must be verified that Q satisfies the curve equation and that 4*Q is

At the beginning of Section 4 I’d recommend to revise a phrase “to ensure
participants follow the specification properly” – maybe just to say about
participants possessing secret values?

In my opinion, the statement about equivalent proofs for DSA/ECDSA either
needs further deep comments (the models, the known results etc.) or just to
be removed. I think that in the current form it does not add anything
helpful, but leaves the reader unsatisfied, in fact there is a lot of
positive results for DSA/ECDSA (and a lot of additional results for ISO/IEC
14888-3 EC-RDSA).

In Section 5 the phrase “The assumption of an honest verifier naturally
holds because the verifier can be anyone” should be removed – it’s very
unclear and misleading, in my opinion.

It seems to me that the document is useful and should become an RFC in a
slightly revised form.

Document: draft-hao-jpake-05
Reviewer: Stanislav Smyshlyaev
Review Date: 2017-03-07

Overall opinion: Minor changes needed

The -05 version addresses most of my concerns described in my brief review
for -04 version (in October 2016), but I’d still prefer some changes to be

The PAKE topic is important for such areas as IoT, Bluetooth tokens and key
servers – for the cases when the user-remembered secret is preferred to be
used. J-PAKE is a scheme that is completely different from most other
proposals: SPAKE, SPEKE, PAK, AugPAKE SESPAKE etc. It has its problems
though: it is notably slower than any other protocols considered in IETF
and CFRG. The construction is truly original and has to be considered when
certain PAKE is chosen for some application. Hence I support publication of
an RFC on J-PAKE – but a revised version of it.

Section 1: the phrase “Third, J-PAKE is efficient” seems to be misleading
and I’d prefer that it would be removed. It’s less efficient than most of
other PAKEs considered in IETF and CFRG.

When talking about disadvantages of other schemes, it must be mentioned
that not only SPAKE2, but also SESPAKE (though, with only one point with
unknown discrete logarithm) requires trusted setup.
The “HMAC” notation is used in the paper, though SHA-3 (not requiring HMAC
construction, in contrast to SHA-2) is mentioned. In my opinion, a “MAC” or
even a “PRF” notation would be more convenient. Also later you say “an
additional secure MAC function (HMAC)”, which is also a little misleading –
HMAC is not the only one secure MAC.

In 2.1 the DDH problem intractability is required, but a few statements
later the [supposed to be a weaker property] DLP intractability is
required. I’d prefer that only the more restrictive DDH intractability
requirement would be mentioned.

Section 2.2: it should be explicitly stated (here and in other
corresponding parts of the document), which actions must be done if the
required verifications are unsuccessful. Some practical attacks occur
because of incorrect error handling in protocols, so we should be very
accurate here.

The implicit recommendation in 3.2 to derive keys only from the
x-coordinate should be removed, in my opinion. The modern hashes have at
least 64-byte block, hence there’s no reason to leave y-coordinate (with
only 1 bit of information, though) behind for 256-bit curves, for example.

In the Security considerations section you recommend to add countermeasures
against on-line dictionary attacks. I’d prefer to see more explicit
recommendations here: for example, that the false authentication counters
should be handled in such a way that any error (including ones before the
key confirmation stage) would lead to incrementing false authentication

Also in 9.2 the following change must be made: [AP05]: “Poincheval” ->

It seems to me that the document is useful and should become an RFC in a
slightly revised form.

Best regards,
Stanislav V. Smyshlyaev, Ph.D.,
Head of Information Security Department,
CryptoPro LLC