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

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Tue, 7 Mar 2017 12:26:00 +0300

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
nonzero.

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
made.

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
counters.

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

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