Re: [Cfrg] ISE needs reviewers/reviews for draft-smyshlyaev-sespake-09

Mike Hamburg <mike@shiftleft.org> Thu, 13 October 2016 17:54 UTC

Return-Path: <mike@shiftleft.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59570129603 for <cfrg@ietfa.amsl.com>; Thu, 13 Oct 2016 10:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.998
X-Spam-Level:
X-Spam-Status: No, score=-4.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-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=shiftleft.org
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 41j2O3dBkK5a for <cfrg@ietfa.amsl.com>; Thu, 13 Oct 2016 10:54:20 -0700 (PDT)
Received: from astral.shiftleft.org (vpn.shiftleft.org [52.40.228.30]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1BF1294DD for <cfrg@irtf.org>; Thu, 13 Oct 2016 10:54:19 -0700 (PDT)
Received: from [10.184.148.249] (unknown [209.36.6.242]) (Authenticated sender: mike) by astral.shiftleft.org (Postfix) with ESMTPSA id 4BD08A8176; Thu, 13 Oct 2016 10:54:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shiftleft.org; s=sldo; t=1476381258; bh=R6L+J8S+28F9OEt0tZMB1vnGvi/xxNiCaF6XS3Wv9s8=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=Mvy32KYIoEaumW/aMxcrwmHhY2Lz15sxJporAiu23Uinas0wI+EmQbucTZWAC4KwO Q+erciPmOwbRYvbCn6zB8HiFnY2u8YB9fwwWhQijWwknObvYfZHY2DFnTVx8IwjGzM hxnfplhnYBxeNQMm/ye7H6QDzPWsTJwG4ldYVYaw=
From: Mike Hamburg <mike@shiftleft.org>
Message-Id: <5013E14D-B7AF-4253-A659-51B13136EAF5@shiftleft.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_08ABDE4A-0B2F-475E-A661-B208D7FB8B0A"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Date: Thu, 13 Oct 2016 10:54:17 -0700
In-Reply-To: <d0a90056-86fa-1862-6cab-f438c7fb8886@auckland.ac.nz>
To: Nevil Brownlee <n.brownlee@auckland.ac.nz>
References: <d0a90056-86fa-1862-6cab-f438c7fb8886@auckland.ac.nz>
X-Mailer: Apple Mail (2.3251)
X-Virus-Scanned: clamav-milter 0.99.2 at astral
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/VHmuocZ30D9iEO2TPPZvEEapAtc>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, ISE <rfc-ise@rfc-editor.org>
Subject: Re: [Cfrg] ISE needs reviewers/reviews for draft-smyshlyaev-sespake-09
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Oct 2016 17:54:22 -0000

Hi Nevil,

I read over the document briefly, especially the diffs.

The protocol hasn’t changed much, and it’s still basically fine but I think it could be better.

I’m not sure what was gained by replacing INT with an abstract function phi.  Since phi = INT in the example, it seems to just give wiggle room that will not be used.

The new diagram is helpful.

The “Byte representation of a point X,Y” is a little unclear.  Perhaps the authors should declare a function intEncode_n :: [0,n) -> B_{ceil log_{256} n}, and say that (X,Y) encodes to intEncode_p(X) || intEncode_p(Y).  Also, the lower-case p there is correct, but it’s the characteristic and not the subgroup generator.  The subgroup generator is called capital P.  But you do want the lower-case p.

Also, the authors might want to consider point compression.  Or not.

I’m skeptical as to whether the innovative small subgroup handling gains anything.  Why does one need to test whether Q_B is in the small subgroup?  Does the protocol need to be contributory even if the adversary knows the password?  It looks to me like the small subgroup handling is a convoluted way to abort the protocol without aborting it.  Perhaps there is a reason involving the failure counters.

I’m still not a fan of the multiple Q points.  Either there is an attack on one Q or there is not.  If there is an attack, reducing its likelihood of success to 1/3 seems like a waste of time.  Just generating Q using a hash of P is enough to prevent a backdoor attack.

Cheers,
— Mike



> On Oct 12, 2016, at 6:43 PM, Nevil Brownlee <n.brownlee@auckland.ac.nz> wrote:
> 
> 
> Hi CFRG folk:
> 
> Stanislav Smyshlyaev has submitted this draft to the Independent Stream,
> so now I'm looking for reviews of it.  Any comments on this draft,
> especially in the form of brief reviewers - or offers to do a full
> review - would be much appreciated.
> 
> Please send comments, reviews or offers to review to me, that's
> ISE <rfc-ise@rfc-editor.org>
> 
> Cheers, Nevil
> 
> -- 
> Nevil Brownlee (ISE), rfc-ise@rfc-editor.org
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg