From nobody Wed Mar 1 10:21:11 2017 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1859312964D for ; Wed, 1 Mar 2017 10:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAPgi8LfZLWz for ; Wed, 1 Mar 2017 10:21:08 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BBF712964F for ; Wed, 1 Mar 2017 10:21:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E0ED8300449 for ; Wed, 1 Mar 2017 13:21:06 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9hZn7yEOZ_I4 for ; Wed, 1 Mar 2017 13:21:05 -0500 (EST) Received: from [192.168.2.107] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 74E9230024A; Wed, 1 Mar 2017 13:21:05 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: Date: Wed, 1 Mar 2017 13:21:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1D20C124-B34C-4FE5-A003-293FB04329E3@vigilsec.com> References: <00a06d56-5186-4150-5ba5-810e8961d2e8@auckland.ac.nz> To: Nevil Brownlee X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "crypto-panel@irtf.org" , ISE Subject: [Crypto-panel] Review of draft-hao-jpake-04 for ISE X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 18:21:10 -0000 Document: draft-hao-jpake-05 Reviewer: Russ Housley Review Date: 2017-03-01 The Independent Stream Editor (ISE) asked the Crypto Review Panel to review this document. Here is my review. Summary: Almost Ready Once the comments below are resolved, I think that the ISE should publish the document. Major Concerns: Section 2.2: Please remove [[Q1:: ... --Hao]] In Section 2.2, Round 2, the document says: ... Alice and Bob just need to ensure g1*g3*g4 !=3D 1 mod p and g1*g2*g3 !=3D 1 mod p. ... I realize that the probability is extremely small that either of these values will be 1, but the specification needs to say what the implementer should do if it happens. My guess is go back to Round 1, and pick new ephemeral private keys. Please explain why UserID is included in Section 2, but not Section 3. How does this difference impact the security offered by the two J-PAKE mechanisms? Minor Concerns: In Section 2.1, the document says: ... The two communicating parties, Alice and Bob, both agree on (p, q, g), which can be hard-wired in the software code. Here DSA group parameters are used only as an example. Other multiplicative groups where the discrete logarithm problem (DLP) is intractable are also suitable for the implementation. It might be useful to point to NIST FIPS 186-4, Appendix A as a way to generate p, q, and g. The, you can go on to say that other ways work too. This gives implementers algorithms to use. In Section 2.2, the first sentence of Round 1 should explain that x1, x2, x3, and x4 are ephemeral private keys. In Section 3.1, you point to [NISTCurve]. That document includes pseudo=C2=ADrandom curves over GF(p), pseudo=C2=ADrandom curves over = GF(2^m), and Koblitz curves. You only name one of them. Are all of them acceptable here? Also, that document includes some curves that offer only 80-bit security, which is considered too weak today. It is desirable for you to include some guidance to pick a secure curve. In Section 3.2, the first sentence of Round 1 should explain that x1, x2, x3, and x4 are ephemeral private keys. In Section 3.2, it says: ... In practice, it is sufficient to use only the x coordinate as the input to KDF to derive the session key. ... I understand the security claim; however, Alice and Bob need to do the same thing to produce the same key. Therefore, I suggest: ... Since it is sufficient to use only the x coordinate as the input to KDF to derive the session key, the y coordinate is not provided as an input to the KDF. ... Nits: Section 1.2 does nit define | or |a|, but it uses them: o q: a large prime divisor of p-1, i.e., q | p-1 o h: the cofactor of the subgroup generated by G, as defined by h =3D |E(Fq)|/n In addition, [a, b] should be explained in Section 1.2. Section 5 says: This key confirmation procedure needs to be completed in two rounds, as shown below. 1. Alice -> Bob: H(H(k')) 2. Bob -> Alice: H(k') This looks like two messages, but one round. Also, since both mechanisms are two messages (one round), the reason for preferring the second mechanism is incorrect. Section 6: s/latest IEEE P1363.2 standard draft D26 /the D26 draft of IEEE P1363.2/ In Section 9.1, [I-D-Schnorr] should point to draft-hao-schnorr-05 as a work-in-progress. From nobody Mon Mar 6 08:05:20 2017 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF68D129457 for ; Mon, 27 Feb 2017 19:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhYezM7Z3rVF for ; Mon, 27 Feb 2017 19:12:20 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E13127077 for ; Mon, 27 Feb 2017 19:12:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1488251540; x=1519787540; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=YegND6HX5pONt1XXqJvdQQ80QYmAAbEoyOrJpinUWCA=; b=pMEHHnpFgveFo3JibMqXHGujDmacgtHA9JsIGtVj/CesX8GysnoNxt3I n+ka/fruKtCSwkS7jwxFI2/TbR3EsGgHjWl8glMux00WKclDurWcNUXkF w1py/fzypMqhuGKs17Boh+dMuAEYufbKWONB1BDi5svR8FbyEvS/TIQsk sfkB6IaNwVgCSpugn8GuqL0tzaWKMwMMFpC9qKmxkmU/Kgf1yu7bfUKnB dYfQoQlf7jKklgv+xc9FQQ2uxT/4TPySTf6lh4FSCSH25KNBrcKMrjaXV 9Ajk3aTSl94yLsciO0qk6Pd5loJZSpQjKirHf/uR+VgiFq3w1wSV73hLj w==; X-IronPort-AV: E=Sophos;i="5.35,217,1483959600"; d="scan'208";a="138040067" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.7 - Outgoing - Outgoing-SSL Received: from sc-cs-316051.uoa.auckland.ac.nz (HELO [130.216.38.7]) ([130.216.38.7]) by mx4-int.auckland.ac.nz with ESMTP; 28 Feb 2017 16:12:17 +1300 To: "Paterson, Kenny" , "crypto-panel@irtf.org" References: <00a06d56-5186-4150-5ba5-810e8961d2e8@auckland.ac.nz> From: Nevil Brownlee Message-ID: Date: Tue, 28 Feb 2017 16:12:15 +1300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Mon, 06 Mar 2017 08:05:18 -0800 Cc: ISE Subject: Re: [Crypto-panel] [Cfrg] ISE needs reviews for draft-hao-jpake-04 and draft-hao-schnorr-04 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 03:12:23 -0000 Hi Kenny: Thanks for that; I'm sure that people on CFRG know they can find drafts using the DataTracker. I'm sorry I gave names of older versions of these two drafts, Please review the latest version of these drafts, i.e. draft-hao-jpake-05 and draft-hao-schnorr-05 Cheers, Nevil On 27/02/17 3:23 pm, Paterson, Kenny wrote: > Dear Nevil, > > I've forwarded your message to the CFRG review panel (cc-ed) > > Could you follow up by giving some pointers to the two drafts so that > individual panel members can take a look and see if they are able to > provide reviews? > > Many thanks, > > Kenny > > On 26/02/2017 23:21, "Cfrg on behalf of Nevil Brownlee" > wrote: > >> >> Hi CFRG Review Panel members: >> >> I don't have a mail alias for the review panel, so I'm sending to >> the CFRG list. >> >> These two drafts have been sent to me as Independent Submissions, >> please review them for me. >> >> Cheers, Nevil >> >> -- >> --------------------------------------------------------------------- >> Nevil Brownlee Computer Science Department >> Phone: +64 9 373 7599 x88941 The University of Auckland >> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg > -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From nobody Mon Mar 6 08:05:24 2017 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264A212955D for ; Mon, 6 Mar 2017 01:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGYqxcgq9_A9 for ; Mon, 6 Mar 2017 01:01:38 -0800 (PST) Received: from mail.uni-paderborn.de (mail.uni-paderborn.de [131.234.142.9]) (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 81EA012947F for ; Mon, 6 Mar 2017 01:01:38 -0800 (PST) To: rfc-ise@rfc-editor.org, n.brownlee@auckland.ac.nz From: Tibor Jager Message-ID: <4330c8f7-f402-2642-2f8b-0adc691723a3@upb.de> Date: Mon, 6 Mar 2017 10:01:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IMT-Spam-Score: 0.0 () X-PMX-Version: 6.3.3.2656215, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.3.6.85417, AntiVirus-Engine: 5.35.0, AntiVirus-Data: 2017.3.6.5350001 X-IMT-Authenticated-Sender: uid=tjager,ou=People,o=upb,c=de Archived-At: X-Mailman-Approved-At: Mon, 06 Mar 2017 08:05:18 -0800 Cc: crypto-panel@irtf.org, "Paterson, Kenny" Subject: [Crypto-panel] Review of draft-hao-schnorr-05 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 09:01:41 -0000 Dear Nick et al., Please find below my review of draft-hao-schnorr-05. Best regards, Tibor Document: draft-hao-schnorr-05 Reviewer: Tibor Jager Review Date: 2017-03-03 Summary: This is a review of draft-hao-schnorr-05. It proposes several changes to the specification and suggests an efficiency improvement to the non-interactive variant of the protocols. ---------------------------------------- Major comments: ---------------------------------------- §2.2, "Bob chooses challenge c ... uniformly at random from [0,2^t-1] ... (e.g. t=80)" The standard security proof of Schnorr's ID scheme assumes that c is chosen uniformly at random from [0,q-1], where q is the subgroup order. Section §5 mentions the provable security of Schnorr's ID-scheme and the resulting NIZK-PoK, however, this applies only if the protocol specified in this RFC matches the protocol considered in the security proof. In the non-interactive setting, where c is derived with a hash function, it will of course be inconvenient to demand c \in [0,q-1]. In this setting, one should require that 2^t is at least equal to the order q of the considered subgroup. In general, t=80 seems to be too small, because colliding c-values may enable attacks. Setting t to be twice the desired "security in bits" (e.g., t=256 for "128-bit security") seems more reasonable. ---------------------------------------- §2.3, "the hash function H shall be collision-resistant" Collision-resistance alone is not sufficient to instantiate the Fiat-Shamir construction securely. A contrived but illustrative example: requiring only collision-resistance may mislead people implementing this RFC into instantiating H with the identity map (or any other injective function which is not a "good" cryptographic hash function). Such an instantiation of H would be collision-resistant, but the resulting NIZK protocol derived by applying the Fiat-Shamir transform is completely insecure. Actually, the hash function must "approximate a random oracle reasonably well". Therefore I suggest to replace "the hash function H shall be collision-resistant" with "the hash function H must be a secure cryptographic hash function, like e.g. SHA-256, SHA-512, ...". (This comment applies also to §5 "Security Considerations") ---------------------------------------- §2.3, "Usually, the boundary is implicitly defined, once the length of items is publicly known" Different protocols may use parameters of different size, therefore assuming implicit boundaries seems dangerous. In particular, it may enable cross-protocol attacks that exploit the fact that different protocols may use different parameter sizes. Therefore it seems useful to always require explicit boundaries here. This would also reduce flexibility, and therefore improve interoperability of implementations. ---------------------------------------- §2.3, description of the non-interactive protocol: In the current instantiation of the non-interactive protocol, the prover sends (V,b) (along with UserID and OtherInfo), and the verifier first computes c, and then checks for V = g^b * X^c mod p. Assuming typical choices of p and q, this requires the transmission of an element V of Zp, whose size is somewhere between 1024 and 4096 bits, and an element b of Zq with expected size of about 160-512 bits. It seems possible to reduce the amount of transmitted data to two elements of Zq, by replacing (V,b) with (c,b): - The prover of this optimised variant works exactly as in the protocol described in the current document, except that it sends (c,b) instead of (V,b) - The verifier computes V = g^b * X^c, and then checks whether H(g || V || g^x || UserID || OtherInfo) = c. This is a standard trick to reduce the size of Schnorr signatures, which seems to be applicable here, too. The security of this modified variant follows from the fact that one can compute V from (c,b), and c from (V,b) (and the additional public parameters). Therefore sending (c,b) is equivalent to sending (V,c,b), which in turn is equivalent to sending (V,b). ---------------------------------------- §2.4, verification of proofs: The full verification procedure of proofs (including verification of group membership) should not be described in the "Computational Costs" section, but earlier in the protocol specification (§2.2 and §2.3). ---------------------------------------- §3.3, using only the x-coordinates of points as hash inputs: Is there any important reason why only the x-coordinates are used as input to the hash function here? Hashing the entire group element seems more compatible with the security proof of Schnorr's ID scheme, and seems not to incur significant additional costs. ---------------------------------------- §5, "The assumption of an honest verifier naturally holds because the verifier can be anyone." I was not able to follow this argument. Actually, the reason why the Fiat-Shamir transform requires only an honest-verifier ID scheme is because the hash function (more precisely, the random oracle in the security proof) implements an honest verifier, because it assigns a uniformly random challenge c to each g^v sent by the prover to the hash function oracle - this is exactly what a honest verifier would do. ---------------------------------------- §5, vulnerability to bad randomness. Using Schnorr's ID scheme or its non-interactive variant with bad randomness v in g^v mod p may reveal the secret discrete logarithm whose knowledge the prover wants to prove. For example, if the same random value V = g^v mod p is used twice by the prover (e.g. because its random number generator fails), but the verifier chooses different challenges c, c' (or the hash function is used on two different OtherData, producing two different values c, c'), then this reveals the prover's secret key: The adversary observes two proof transcripts (V,c,b) and (V,c',b'), which both verify. Then it computes (b-b')/(c'-c) = (v-xc - v+xc')/(c'-c) = x mod p which reveals the secret key x of the prover. More generally, such an attack may even work for a slightly better (but still bad) random number generator, where the value v is not repeated, but the adversary knows a relation between two values v,v', such as v' = v+r for some known value r. More precisely: Suppose that the adversary observes two proof transcripts (V,c,b) and (V',c',b'), which both verify. Suppose also that the adversary knows that V' = g^v' = g^(v+r) = V * g^r mod p. Then it computes (b-b'+r)/(c'-c) mod p = (v-xc - v-r+xc' + r) / (c-c') mod p = x mod p Such potential weaknesses of Schnorr's ID scheme should be explained very clearly in the Security Considerations section. ---------------------------------------- Minor comments: ---------------------------------------- §1.2 Notation In the "mod p" setting, q denotes the order of the (sub)group generated by generator g. In the elliptic curve setting, q denote the characteristic of the base field Fq, while n denotes the order of the group. For clarity, it would be useful to let q denote the order of (sub)groups throughout the document, to avoid confusion, and choose a different character for the characteristic of the base field of the elliptic curve group. ---------------------------------------- §2.2, "...must be a subgroup element ... which anyone can verify". Please specify here how verification works exactly, or at least refer to another part of the document which specifies this. ---------------------------------------- §3.2, "Alice publishes her public key Q = G x [x]". The double meaning of symbol "x", first denoting multiplication and then denoting a value x, is a bit unfortunate here. The earlier sections used * as a symbol for multiplication. One may consider replacing the above with "Q = G * [x]" Furthermore, the value Q is not necessarily an actual "public key" in all possible applications of the protocol standardised in this RFC. In some protocol, it may e.g. be a message sent to establish a key via a Diffie-Hellman like protocol, etc., while other values are used as actual public keys. Instead, one could simply write "Alice publishes an elliptic curve point Q = G * [x] of which she wants to prove knowledge of the discrete logarithm w.r.t. generator G". (This comment applies also to §3.4, etc.) ---------------------------------------- §4, "the OtherInfo should include extra information": As also explained in the RFC draft, the non-interactive protocol is vulnerable to replay attacks. In particular, if the protocol is used as a Proof-of-Possession of the long-term secret to a CA, then it MUST be ensured that the hash contains data that links the proof to one particular key registration procedure. ---------------------------------------- §5, "A non-interactive ZK proof is often called a signature scheme" While there exists a natural relation between ZK proofs and digital signatures, the above statement is not true and therefore misleading. E.g., one cannot simply replace a NIZK proof with a signature scheme in general. I think one can safely delete this sentence, it seems not to add anything relevant to the specification of the protocol. From nobody Tue Mar 7 01:26:05 2017 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0270C129421 for ; 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-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yb3Ds4qSouC1 for ; 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 ; Tue, 7 Mar 2017 01:26:01 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id p64so79041681qke.1 for ; 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 10.200.54.207 with SMTP id b15mr22342218qtc.9.1488878760826; Tue, 07 Mar 2017 01:26:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.132.102 with HTTP; Tue, 7 Mar 2017 01:26:00 -0800 (PST) From: "Stanislav V. Smyshlyaev" Date: Tue, 7 Mar 2017 12:26:00 +0300 Message-ID: To: crypto-panel@irtf.org, Nevil Brownlee , "Paterson, Kenny" Content-Type: multipart/alternative; boundary=001a1139782aa73564054a20993b Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 09:26:04 -0000 --001a1139782aa73564054a20993b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=E2=80=99d still prefer some change= s to be made. The Schnorr signature scheme and the Schnorr NIZK proof have a difficult history (including their relationship with DSA) =E2=80=93 and I t= hink it is quite a good idea to have an RFC on them. We=E2=80=99ve 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=E2=80=99d recommend to change terms a bit: coll= ision resistance is not the property that is really needed for random oracle model. Tibor=E2=80=99s proposal of saying =E2=80=9Csecure cryptographic has= h function=E2=80=9D seems to be a good option =E2=80=93 in this case we won=E2=80=99t go too fa= r into details, but would prevent using something non-cryptographic (e.g. HighwayHash). And instead of saying =E2=80=9CRecommended hash functions include=E2=80=A6=E2= =80=9D I=E2=80=99d prefer to see a more relaxed phrase like =E2=80=9Ce.g. SHA-256, SHA-512, =E2=80=A6=E2=80=9D= . 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=E2=80=99s ID and her X = (or Q) ) =E2=80=93 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=E2=80= =99s not critical and may remain unchanged, if the author wants it. Though originally the scheme was named =E2=80=9Can identification scheme=E2= =80=9D, the scheme actually implements authentication (assumed identities are known before the start of the protocol) thus I=E2=80=99d prefer to revise the ter= ms 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 =E2=80=93 leaving only a refe= rence 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=E2=80=99d recommend to revise a phrase =E2= =80=9Cto ensure participants follow the specification properly=E2=80=9D =E2=80=93 maybe jus= t 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 =E2=80=9CThe assumption of an honest verifier natur= ally holds because the verifier can be anyone=E2=80=9D should be removed =E2=80= =93 it=E2=80=99s 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=E2=80=99d still prefer some change= s to be made. The PAKE topic is important for such areas as IoT, Bluetooth tokens and key servers =E2=80=93 for the cases when the user-remembered secret is preferre= d 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 =E2=80=93 but a revised version of it. Section 1: the phrase =E2=80=9CThird, J-PAKE is efficient=E2=80=9D seems to= be misleading and I=E2=80=99d prefer that it would be removed. It=E2=80=99s less efficien= t 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 =E2=80=9CHMAC=E2=80=9D notation is used in the paper, though SHA-3 (not= requiring HMAC construction, in contrast to SHA-2) is mentioned. In my opinion, a =E2=80= =9CMAC=E2=80=9D or even a =E2=80=9CPRF=E2=80=9D notation would be more convenient. Also later = you say =E2=80=9Can additional secure MAC function (HMAC)=E2=80=9D, which is also a little misl= eading =E2=80=93 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=E2=80=99d prefer that only the more restrictive DDH intractabil= ity 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=E2=80=99s 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=E2=80=99d 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]: =E2=80=9CPoincheval= =E2=80=9D -> =E2=80=9CPointcheval=E2=80=9D 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 --001a1139782aa73564054a20993b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=
Document: draft-hao-schnorr-05=
Reviewer: S= tanislav Smyshlyaev
Review Date: 2017-03-06

= Overall opinion: Minor changes needed

The -05 vers= ion addresses most of my concerns described in my brief review for -04 vers= ion (in October 2016), but I=E2=80=99d 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) =E2=80=93 and I think it is= quite a good idea to have an RFC on them. We=E2=80=99ve had a discussion w= ith 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 opini= on, only minor changes are still needed.

In my pre= vious 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=E2=80=99d recommend to change terms a bit: collision resistanc= e is not the property that is really needed for random oracle model. Tibor= =E2=80=99s proposal of saying =E2=80=9Csecure cryptographic hash function= =E2=80=9D seems to be a good option =E2=80=93 in this case we won=E2=80=99t= go too far into details, but would prevent using something non-cryptograph= ic (e.g. HighwayHash). And instead of saying =E2=80=9CRecommended hash func= tions include=E2=80=A6=E2=80=9D I=E2=80=99d prefer to see a more relaxed ph= rase like =E2=80=9Ce.g. SHA-256, SHA-512, =E2=80=A6=E2=80=9D.
I am not really sure that the comment about a simultaneous expo= nentiation 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=E2=80=99s I= D and her X (or Q) ) =E2=80=93 so the table for powers of g (or G) can be p= recomputed beforehand, which would make simultaneous exponentiation (with a= necessity to generate a precomputation table for a pair of (g, X) ) ineffe= ctive. Anyway, that=E2=80=99s not critical and may remain unchanged, if the= author wants it.

Though originally the scheme was= named =E2=80=9Can identification scheme=E2=80=9D, the scheme actually impl= ements authentication (assumed identities are known before the start of the= protocol) thus I=E2=80=99d prefer to revise the terms in the paper a bit.<= /div>

The comment about the public key validation (for a= case of =C2=A0a small cofactor) in 3.4 should be specified a little =E2=80= =93 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 equa= tion and that 4*Q is nonzero.

At the beginning of = Section 4 I=E2=80=99d recommend to revise a phrase =E2=80=9Cto ensure parti= cipants follow the specification properly=E2=80=9D =E2=80=93 maybe just to = say about participants possessing secret values?

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

In Section 5 the phrase =E2=80=9CThe assum= ption of an honest verifier naturally holds because the verifier can be any= one=E2=80=9D should be removed =E2=80=93 it=E2=80=99s very unclear and misl= eading, in my opinion.

It seems to me that the doc= ument is useful and should become an RFC in a slightly revised form.
<= div>
=C2=A0

Document: draft-hao-jpak= e-05
Reviewer: Stanislav Smyshly= aev
R= eview Date: 2017-03-07

Overall opinion:= Minor changes needed

The -05 version addresses mo= st of my concerns described in my brief review for -04 version (in October = 2016), but I=E2=80=99d still prefer some changes to be made.=C2=A0

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

Section 1: the phrase =E2=80=9CThird, J-PAKE i= s efficient=E2=80=9D seems to be misleading and I=E2=80=99d prefer that it = would be removed. It=E2=80=99s less efficient than most of other PAKEs cons= idered in IETF and CFRG.

When talking about disadv= antages of other schemes, it must be mentioned that not only SPAKE2, but al= so SESPAKE (though, with only one point with unknown discrete logarithm) re= quires trusted setup.
The =E2=80=9CHMAC=E2=80=9D notation is used= in the paper, though SHA-3 (not requiring HMAC construction, in contrast t= o SHA-2) is mentioned. In my opinion, a =E2=80=9CMAC=E2=80=9D or even a =E2= =80=9CPRF=E2=80=9D notation would be more convenient. Also later you say = =E2=80=9Can additional secure MAC function (HMAC)=E2=80=9D, which is also a= little misleading =E2=80=93 HMAC is not the only one secure MAC.

In 2.1 the DDH problem intractability is required, but a fe= w statements later the [supposed to be a weaker property] DLP intractabilit= y is required. I=E2=80=99d prefer that only the more restrictive DDH intrac= tability requirement would be mentioned.

Section 2= .2: it should be explicitly stated (here and in other corresponding parts o= f the document), which actions must be done if the required verifications a= re unsuccessful. Some practical attacks occur because of incorrect error ha= ndling in protocols, so we should be very accurate here.

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

In the Security considerations section you = recommend to add countermeasures against on-line dictionary attacks. I=E2= =80=99d 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 inc= rementing false authentication counters.

Also in 9= .2 the following change must be made: [AP05]: =E2=80=9CPoincheval=E2=80=9D = -> =E2=80=9CPointcheval=E2=80=9D

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 Securi= ty Department,
CryptoPro LLC


<= /div>

--001a1139782aa73564054a20993b-- From nobody Fri Mar 10 04:10:58 2017 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC87D1298A0 for ; Fri, 10 Mar 2017 04:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id If45SHWEm9DT for ; Fri, 10 Mar 2017 04:10:56 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id D5F5912989D for ; Fri, 10 Mar 2017 04:10:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489147855; d=isode.com; s=june2016; i=@isode.com; bh=YwJmEUjAVkaK9Rs399v8LutawnuDMJT60PmHJRB+PII=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ehvy333W1mP4Wu1OAmCHTaILInplMAaLVK/+T+db0okOL1rCpN1A3HcABpevFfLVBWAsX8 6GaFrlswIF4ghpf2MJtYLkrHbEwvd7VPHvTYseg1cTq0WGXBR2zKoCSoMoAskfm43bPE3w Wf/VjKoLciW5zLavcTnrBz2ROw/qILI=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 10 Mar 2017 12:10:54 +0000 To: "crypto-panel@irtf.org" From: Alexey Melnikov Message-ID: Date: Fri, 10 Mar 2017 12:10:26 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Crypto-panel] Test message X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 12:10:57 -0000 Security ADs (old and new) should receive this. Everybody else - please ignore.