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

Loup Vaillant-David <> Fri, 19 June 2020 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C92AF3A0D41 for <>; Fri, 19 Jun 2020 14:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id acDp0MmteYvO for <>; Fri, 19 Jun 2020 14:46:58 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E4B43A0EAA for <>; Fri, 19 Jun 2020 14:46:58 -0700 (PDT)
Received: from grey-fade ( []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loup) by (Postfix) with ESMTPSA id 980CC165F; Fri, 19 Jun 2020 23:36:48 +0200 (CEST)
Message-ID: <>
From: Loup Vaillant-David <>
To: =?ISO-8859-1?Q?Bj=F6rn?= Haase <>, "" <>
Date: Fri, 19 Jun 2020 23:46:56 +0200
In-Reply-To: <>
References: <> <>
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: <>
Subject: Re: [Cfrg] CPACE: what the "session id" is for?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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?