Re: [Cfrg] OPAQUE at Facebook

Bill Cox <> Wed, 28 August 2019 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 000481208B9 for <>; Wed, 28 Aug 2019 09:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hZnEOsYMrTUN for <>; Wed, 28 Aug 2019 09:36:03 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 771B21208D7 for <>; Wed, 28 Aug 2019 09:36:03 -0700 (PDT)
Received: by with SMTP id l1so113165lji.12 for <>; Wed, 28 Aug 2019 09:36:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rgQqhk9tPlg4R3IZmFIkq55Pu6Kzxxi5ik+6gbdNX/g=; b=qrPuVJfyeyGXXNvA7Z48Qbhx9tjEAmzgi9s2zqYDsoE1sAAauek2dKIbrtmgfOATE0 ycqw8CbfVEyiHdr2nz3NsmeabByh1q+iDvt3c02Mf4UYkuzDuFPv+CGDtkEDxGyLRCdd dD1EDit2OnDet2ADDqt57ZtSXU4KnF0rW7sh9VN1n2aP2Hj8T5MhdPJD6ttM9qQMuaa4 yw5K4/DpSaf7dkNVcRmhmpxNOGnKcJMI6XfzxoqI8uA3LmXWZc9F6Qco4t93JUdtAHS8 /Lv7OQ4PYTkoMdqL5ri7HaRPPYLHS1f3nM8Dbj6sg3jeYjg6kGiudMjIKvaFv0WSN2+6 6Qmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rgQqhk9tPlg4R3IZmFIkq55Pu6Kzxxi5ik+6gbdNX/g=; b=FJAA/Nr/UGvwD+jqJK4ZsfauSXbFUDez9dajao/rEGjAoVAhn42DDCuiOH8JsasQlq 47Bsg+DX+YZzLDP74uajFxAtc+tiF81zhsh8jH3Ic10JuKoB9+2dgqZhZm+29IajjWei +dKLP9/aMtTaG/lHowIQXKMJvK1f1dDy21/Eu3tE9ciGLinW6cI89n7JVs79iEpopIj8 2rYT6NFAWSPwHSXaLFulFNJ3pMakzowhzwzX1mtg0DYiHIM0fOOqB4uZqKMwsSYA4Tos es/wo76wDWZluKWq2KGP20rhEDBthK45JIHnYqiFaUsrmIfcSZ4GKL9jvreI79KfTayh z6MQ==
X-Gm-Message-State: APjAAAXegXsJKeAr3tYU42+vvU63FEbrYYWuOwfKcVxKwARYB/Fg3U9x NbxM43GllkO2fSha0FNKiG+W3oy9jojfXN8m1wQ=
X-Google-Smtp-Source: APXvYqw/nI3aNUU9CazYz4UQ7b85oBQik813MinLMGcc/hcuiMaV4jk+A6AKoiJFSo8g7Y1xpU+Tk48dRAYJP2OBgf8=
X-Received: by 2002:a2e:3a05:: with SMTP id h5mr2623768lja.135.1567010161439; Wed, 28 Aug 2019 09:36:01 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Bill Cox <>
Date: Wed, 28 Aug 2019 09:35:50 -0700
Message-ID: <>
To: Kathleen Moriarty <>
Cc: Neil Madden <>, IRTF CFRG <>
Content-Type: multipart/alternative; boundary="0000000000000837e205912ffc29"
Archived-At: <>
Subject: Re: [Cfrg] OPAQUE at Facebook
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: Wed, 28 Aug 2019 16:36:13 -0000

I have concerns about HOBA.  From the RFC:

> Servers using HOBA define their own policies for binding
>>>       CPKs with accounts during account registration.
>>> I assume this step involves sending the sever a password, which it would
have to check against a password hash database.  If this is true, it would
defeat the point of HOBA.  This RFC appears to be a partial solution only.

As for SCRAM, it still stores a salted password hash server-side.

OPAQUE has some interesting properties:

- The security proofs under the UC model provide some confidence in the
OPAQUE framework.
- The specific instantiations of the framework in the RFC look pretty good.
- If the aPAKE verifier is stored in a different security domain than the
OPRF secrets, an attacker mus PWN both to learn anyting when attacking
- The OPRF oracle can be an independent service, not controlled by the
aPAKE server in any way.
- The resulting 2-way authenticated shared key is interesting, and may
prove useful at some point (not sure how...).

Downsides include:

- The OPRF servers have to forward key exchange info learnied in the first
message to aPAKE server.  Can this be fixed?
- Only client-side password hashing is supported.
- Servers store password-derived public keys, and if an attacker has both
the OPRF secrets (sid) and these keys, they can brute-force passwords.
- 3 messages are involved vs the usual 1 message for authentication.