Re: [Cfrg] OPAQUE at Facebook

Kathleen Moriarty <> Wed, 28 August 2019 17:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3C9412023E for <>; Wed, 28 Aug 2019 10:05:44 -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 yvBmhhpAZWpb for <>; Wed, 28 Aug 2019 10:05:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D2C20120232 for <>; Wed, 28 Aug 2019 10:05:42 -0700 (PDT)
Received: by with SMTP id b1so525076otp.6 for <>; Wed, 28 Aug 2019 10:05:42 -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=R2Fq2QCI5yto+3YGMIG/w+19yxLni10ML05LlNa/y1k=; b=q30w1SHzNKk61iIPa50J4QKZZLXcne3CmOc/uMk1nM+oFbiJKQUtXZTvQ19lkI3d53 zCeup5LMIPYbO4Eya6sFGeY2L0L6fnYMBmLNSdsRafgFDY84DlDSZKfROVcdZrz/wDWL cOQG/5cuJrESc1QW/j/U5dezSi9uA6OpmJ4pvLUzWZHJlCOPveKCc69Gzdt5EVs7zpDr 1TveEeI7eIIQ1yMYEhaprMz47/3kQGahqgBm7W+QdD9TNGC2AVW0u5giZq/eLuwU7TZQ unMOf78XMVRLl/QPI+CXnlEQ+ZP3ib3BV6JA43ezL9/or0qplgwhh9VFvAe1m2b8BeDB MkMg==
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=R2Fq2QCI5yto+3YGMIG/w+19yxLni10ML05LlNa/y1k=; b=SQnjuxQ5qNFgFiPpLXoMAvDdhEuUzIBHNHAbaVVG/LTtppT5/lVoUIzs/wA25ttbDI ewRwpoEvmpxVwIgEdy/ZRbjuNgqhCiWdW2vIhBMTkoTeatZFn/DdqkognloyD2nBHvTt LdfgYmVFVX96iH54Ft4TPKELL1I9mft8vIU8mDiw6KaJMWy45kbMwRbzWUzP3Xysiy/y RLOEqQ79mFcIi5+HPDqnf4L99uM0EWCVMXOkAk3860YHwBR1uT3Y6yvc2AGb8UABQLk4 8R18p+nXRPfIJKPN8pwLS53FsQLbj1e5x9Coud+O4HP0GxpdITcGoSkDPBsEyDfW1vdJ jUFg==
X-Gm-Message-State: APjAAAUrS1VAKAgmI6/e/F2wpBmzV3LulQ95lJANTk8O5h76our/MpAA 0CoTQcCIa7sRceRpZ2XrLne8dX5Fak9RSA1w6LQ=
X-Google-Smtp-Source: APXvYqznboyiiUR/MLSIATgQqGH8bUjXR6g+GfC6rDQTMcgfhy6NoidyzcGLlOL1KV0MDNhCWFe6UObffl7w5YTSLQs=
X-Received: by 2002:a9d:7516:: with SMTP id r22mr4329605otk.151.1567011942227; Wed, 28 Aug 2019 10:05:42 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Kathleen Moriarty <>
Date: Wed, 28 Aug 2019 13:05:05 -0400
Message-ID: <>
To: Bill Cox <>, Stephen Farrell <>
Cc: Neil Madden <>, IRTF CFRG <>
Content-Type: multipart/alternative; boundary="0000000000002ce54f059130669a"
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 17:05:45 -0000

On Wed, Aug 28, 2019 at 12:36 PM Bill Cox <> wrote:

> 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.

It's a public key, so I'm not sure that you would and am copying the author
in case he hasn't seen the thread.

I mentioned HOBA as it is more obscure and you may not have heard of it.
FIDO also uses raw keys, but you've likely evaluated that already too?

Best regards,

> 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
> servers.
> - 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.


Best regards,