Re: [Cfrg] CPACE: what the "session id" is for?

Loup Vaillant-David <loup@loup-vaillant.fr> Fri, 19 June 2020 21:46 UTC

Return-Path: <loup@loup-vaillant.fr>
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 C92AF3A0D41 for <cfrg@ietfa.amsl.com>; Fri, 19 Jun 2020 14:46:59 -0700 (PDT)
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, SPF_HELO_NONE=0.001, 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 acDp0MmteYvO for <cfrg@ietfa.amsl.com>; Fri, 19 Jun 2020 14:46:58 -0700 (PDT)
Received: from smtp.loup-vaillant.fr (smtp.loup-vaillant.fr [92.243.1.174]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4B43A0EAA for <cfrg@irtf.org>; Fri, 19 Jun 2020 14:46:58 -0700 (PDT)
Received: from grey-fade (lns-bzn-60-82-254-246-40.adsl.proxad.net [82.254.246.40]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loup) by smtp.loup-vaillant.fr (Postfix) with ESMTPSA id 980CC165F; Fri, 19 Jun 2020 23:36:48 +0200 (CEST)
Message-ID: <573119cc053b78d7878f42918b38d5c1b499b213.camel@loup-vaillant.fr>
From: Loup Vaillant-David <loup@loup-vaillant.fr>
To: =?ISO-8859-1?Q?Bj=F6rn?= Haase <bjoern.haase@endress.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Date: Fri, 19 Jun 2020 23:46:56 +0200
In-Reply-To: <AM0PR05MB4786FCB65F850DD7C6528CBE83980@AM0PR05MB4786.eurprd05.prod.outlook.com>
References: <326ebefc65c17f7fc11879b9b966a1e4585b1f16.camel@loup-vaillant.fr> <AM0PR05MB4786FCB65F850DD7C6528CBE83980@AM0PR05MB4786.eurprd05.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/1b3H_VKyZR-UbE6FoNeOdOOPqRE>
Subject: Re: [Cfrg] CPACE: what the "session id" is for?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
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: Fri, 19 Jun 2020 21:47:00 -0000

Dear Björn,

Thank you for the lightning quick response. Overall, I reckon I must
agree with your conclusions.


> Any output of a possibly concurrently running other CPace session
> could not provide any valuable input to the attacker.

Yes, it wouldn't do to be able to mess with the protocol by picking a
messages from several runs together. I confess I was too lazy to
seriously consider the possibility.


> The sid also serves for making each generator ephemeral for each
> session and this could be useful for mitigating side-channel analysis
> since the adversary has essentially only one single trace available.

Didn't think of the side channel.  A quick mention of that in the draft
could help.


> This "ephemeral generator G" feature that comes with the inclusion of
> the sid is IMO also relevant for the "quantum annoying" property.

Let's see… Perform discrete logarithm, guess G once, we can now compute
a working yb/Yb pair forever. Instead of "1 DLP per password guess", we
get "1 DLP per user". Not great indeed, good point.


> I have also tried to discuss this topic roughly in slides #53 to #58
> in [AuCPace presentation PDF]

The current draft does not match those slides.  The slides says *both*
parties should transmit a random string, and the sid is then a hash of
the two (or, if sid is always the input of a hash, they may be just
concatenated together?). The draft instead says:

""" If no such ssid is available from a higher-level protocol, a
""" suitable approach is including ssid in the first message from B to
""" A as shown in the figure below.

That may not be what you intended: with that method, the client is free
to repeat the sid, and the generator would now be only as ephemeral as
the x/X key pair.

If I may, the server *can* contribute to the sid without increasing the
number of messages:

    Client sends Csid, name, U
    Server sends Ssid, salt/UQ, X, sigma, Ya

    sid = H(Csid || Ssid)  -- safe
    sid =   Csid || Ssid   -- maybe that would work too?

Maybe for the next draft?

Loup.