Re: [Cfrg] SPAKE2+mbDH a PAKE+PKA

Paul Lambert <paul@marvell.com> Thu, 29 September 2016 08:54 UTC

Return-Path: <paul@marvell.com>
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 6A15212B349 for <cfrg@ietfa.amsl.com>; Thu, 29 Sep 2016 01:54:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 CWn7dCkUEdta for <cfrg@ietfa.amsl.com>; Thu, 29 Sep 2016 01:54:43 -0700 (PDT)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FAE12B32A for <cfrg@irtf.org>; Thu, 29 Sep 2016 01:54:43 -0700 (PDT)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8T8oEM7008530; Thu, 29 Sep 2016 01:54:41 -0700
Received: from sc-exch01.marvell.com ([199.233.58.181]) by mx0b-0016f401.pphosted.com with ESMTP id 25rq6hb7ff-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 29 Sep 2016 01:54:41 -0700
Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 29 Sep 2016 01:54:39 -0700
Received: from SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6]) by SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6%21]) with mapi id 15.00.1104.000; Thu, 29 Sep 2016 01:54:39 -0700
From: Paul Lambert <paul@marvell.com>
To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Thread-Topic: [Cfrg] SPAKE2+mbDH a PAKE+PKA
Thread-Index: AQHSGfBbeJIBs4ds2U2ef/ktt+6StKCQXyAA///LNYA=
Date: Thu, 29 Sep 2016 08:54:39 +0000
Message-ID: <D4121C90.A249D%paul@marvell.com>
References: <D411B584.A2445%paul@marvell.com> <CAMr0u6n_OEe772s2b55iND7zYL_CN0F8k6DFaq6K7z-0gH1Mpg@mail.gmail.com>
In-Reply-To: <CAMr0u6n_OEe772s2b55iND7zYL_CN0F8k6DFaq6K7z-0gH1Mpg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.5.160527
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.94.250.30]
Content-Type: multipart/alternative; boundary="_000_D4121C90A249Dpaulmarvellcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-29_04:, , signatures=0
X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609290152
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/BJIEs-h-gihv58Y0RHmHZQF2OwQ>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] SPAKE2+mbDH a PAKE+PKA
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, 29 Sep 2016 08:54:47 -0000

Dear Stanislav,

Thank you for these links - they give a slightly new viewpoint on PAKEs applications (I think the most discussed question will be "for which applications will combining public keys and passwords be most useful?").
Yes ... it may be useful as a type of 'introduction' process.


An editorial comment on the description of the protocol in the slides: it seemts that after the second message A should check that "R_B - w*M_B == x_B * P_B", not "R_B == x_B * P_B" as it is shown now. Similarly with the B's check.

And a tiny remark: there is a misprint in the plaintext that A encrypts on sk_AB for the third message: "(x_A, P_A)" should be there, not "(m_A, P_A)".

Many thanks for catching my errors!

I've updated the figures and reposted: https://mentor.ieee.org/802.11/dcn/16/11-16-1142-06-00ai-cryptographic-review-and-pkex.ppt


About the protocol itself, I'll try my best to give you our opinion today or tomorrow.

At a glance, it seems to be useful to add some specific requirements for the used "encrypt" functions now or some concrete cipher modes (e.g. GCM or CTR + HMAC)

Yes, this is not clear. The notation slide mentions  AEAD encryption but could say more on requirements. The 'additional data' is not being used, so AEAD is not strictly required. For concrete examples, I'm considering AES-SIV or GCM-SIV or something similar.


due to the words "decrypt is successful" (is it a real data authentication or just some padding check?). EMVco used to check PIN-blocks just by correctness of ECB decryption of IUN, so we should have more details here.

Yes, exactly.  The decryption provides the validity check for the password based authentication and does need a better description.

Best Regards,

Paul


Kindest regards,
Stanislav



2016-09-29 4:25 GMT+03:00 Paul Lambert <paul@marvell.com<mailto:paul@marvell.com>>:

The PKEX protocol ( https://tools.ietf.org/html/draft-harkins-pkex-00 )
provides PAKE functionality (with SPAKE2) and adds public key
authentication (PAKE+PKA).

In looking at alternatives to PKEX, combining an existing and evaluated
authenticated public key exchange with a PAKE seems like an interesting
design path. To this end, the SPAKE2 protocol (
https://tools.ietf.org/html/draft-irtf-cfrg-spake2-03 ) combines nicely
with mutually blinded Diffie-Hellman (mbDH). Blinded DH (bDH) is described
in https://www.emvco.com/specifications.aspx?id=285

A brief description of the resulting SPAKE2+mbDH protocol is contained in
slides 13 to 18 of:

        https://mentor.ieee.org/802.11/dcn/16/11-16-1142-04-00ai-cryptographic-rev
iew-and-pkex.ppt

Comments would be appreciated.

If this protocol seems useful an RFC could be developed.

Paul



_______________________________________________
Cfrg mailing list
Cfrg@irtf.org<mailto:Cfrg@irtf.org>
https://www.irtf.org/mailman/listinfo/cfrg