Re: [Cfrg] FW: SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA

Paul Lambert <> Thu, 13 October 2016 23:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3FE901294C9 for <>; Thu, 13 Oct 2016 16:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FOa3wcf1RXDO for <>; Thu, 13 Oct 2016 16:24:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 937F2124281 for <>; Thu, 13 Oct 2016 16:24:41 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u9DNJZ6v014634; Thu, 13 Oct 2016 16:24:38 -0700
Received: from ([]) by with ESMTP id 2615bthjh7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 13 Oct 2016 16:24:38 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 13 Oct 2016 16:24:37 -0700
Received: from ([fe80::6cb0:4dfa:f3f3:b8b6]) by ([fe80::6cb0:4dfa:f3f3:b8b6%21]) with mapi id 15.00.1104.000; Thu, 13 Oct 2016 16:24:37 -0700
From: Paul Lambert <>
To: Andy Lutomirski <>
Thread-Topic: [Cfrg] FW: SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA
Thread-Index: AQHSIO42d1A9QNlMOEyXQmXxW65UsKCnEA6A
Date: Thu, 13 Oct 2016 23:24:36 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-13_14:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610130392
Archived-At: <>
Cc: Gabino Solano <>, "" <>
Subject: Re: [Cfrg] FW: SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Oct 2016 23:24:43 -0000

Hi Andy,

>> Œbootstrap¹ public key (exchanged out-of-band, e.g QR code)
>>    Secret key calculation:
>>        S = (p_R + b_R) * (p_I + b_I) * G
>>      = (p_R + b_R) * (P_I + B_I)[by Responder]
>>    = (p_I + b_I) * (P_R + B_R)               [by Initiator]
>What's the need for this fanciness?  Why not create a secure channel
>using your favorite authenticated DH protocol using just the bootstrap
>keys and then exchange long-term public keys over that channel?

Yes Š this does become a little silly - especially when you look at the
end result of all the combined protocols. Specifically for DPP, PKEX is
always run first and then another 3-step authentication protocol is run to
exchange the long-term keys.

> This
>all seems to be doing something like Signal's [or whatever it's called
>these days] "triple DH" protocol, except that triple DH uses genuinely
>unauthenticated ephemeral points and triple DH hashes everything
>together instead of using EC addition.

Yes, the EC addition trick is bad. The Triple DH looks like one
alternative for the simultaneous demonstration of ownership of two keys.

On this type of integration of authenticated DH and a PAKE, it makes more
sense to me to put an optional PAKE ³inside" a authenticated DH exchange.

This way you get:
 - an ephemeral key exchange
 - the long-term keys encrypted under the ephemeral key (privacy from
third party observation)
 - a PAKE optionally within the encrypted exchange
 - the ability to securely exchange info related to the PAKE identities
and process

    R_A and R_B are ephemeral public keys

    {} indicting AEAD encryption with key derived from ephemeral exchange
    P_A and P_B are long-term keys
    ... Ellipsis indicate protecte fields outside the scope of this
    [x] brackets indicate an optional field

    R_A --->
    <--- R_B, { (proof, P_B) ... }
    { (proof, P_A) ... } --->

    <--- { ... }

Here I¹m ignoring the math to better discuss the structure of the protocol.
The Œproof¹ would be some technique (like the Triple DH) to strongly
demonstrate the joint ownership of the ephemeral

This has some interesting properties if you make the long-term key and
proof optional:

    R_A --->
    <--- R_B, {[(proof, P_B)] ... }
    {[(proof, P_A)] ... } --->
    <--- { ... }

The same exchange would then support one-sided, mutual or no
authentication to a long-term key.
The protocol could support some negotiation of which device goes first
exposing their long-term key.

    R_A --->
    <--- R_B, { Œyou first' ... }
    { (proof, P_A) ... } --->
    <--- { (proof, P_B) ... }

If there is a need to bind this exchange to human validation of a string
it could be extended to support a SAS and associated human interaction:

    R_A --->
    <--- R_B, {[(proof, P_B)] ... }
Display SAS
    {[(proof, P_A)] ... } --->
                            Display SAS
    <--- { ... }

Integration of a PAKE would look like:
    R_A --->
    <--- R_B, {(proof, P_B), pake_m1  ... }
    {(proof, P_A), pake_m2 ... } --->
    <‹ {pake_m3 ... }

First, I proposing that any PAKE should be able to be mapped into three
messages: pkae_1, pake_2 and pake_3

So protocol structure could support multiple types of
authentication (none/owe, one-sided, mutual) and provide optional support
for short authentication strings or user input passphrases.

>I guess what I'm really asking, though, is: what's the point of having
>separate bootstrap and long-term keys?

For an in-line exchange there is no benefit.

If you look at how a static QR code might contain a key it becomes more
complicated and this printed key might be called a "bootstrap key² if it
is not the long-term key.

On this type of bootstrapping, there are several different use cases with
very different requirements:
 - a static unchanging key associated directly with a device
   (a QR code printed on a device where the QR code data is associated
with a long-term key)
 - a dynamic key that is used once to introduce devices
   (e.g. A one-time QR code displayed on a TV screen where the QR code
data is associated with a long-term key)

Given the above, and working to avoid the term Œbootstrap¹, there are
three types of public keys required:
 - ephemeral keys that are used only once
 - long-term identity keys that are used for access control and
 - long-term hardware keys that are bound to a physical device

The latter two key types should not be the same key for most consumer
devices. The hardware oriented key is fixed and not reset when devices are
reset. An Œidentity¹ key should be reset as it is used by other systems to
determine access control and authorization decisions.

This implies that devices may need to support and demonstrate ownership of
multiple long-term keys. For example:

    R_A --->
    <--- R_B, { (proof, P_B), (proof, P_hw_B) ... }
    { (proof, P_A), (proof, P_hw_A) ... } --->
    <--- { Š }