Re: [CFRG] comments on opaque-06 and voprf-07 drafts

Hugo Krawczyk <> Wed, 25 August 2021 21:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 702A53A1118 for <>; Wed, 25 Aug 2021 14:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.645
X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mv0JxN82LBfQ for <>; Wed, 25 Aug 2021 14:18:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BBF693A1116 for <>; Wed, 25 Aug 2021 14:18:44 -0700 (PDT)
Received: by with SMTP id ia27so1269360ejc.10 for <>; Wed, 25 Aug 2021 14:18:44 -0700 (PDT)
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=K1qK9WuGXfI8wVuGXdwY4nL42d3H6Ljk0KJnq+2FD9s=; b=mTW2LgZ+ZTwp8RzqtxDvAp3JGcO7z+6if+KVprdSThCvIMCSCJdP0m4chqFmLD5rsT U004pWIQiUpUafFcKqR6rKDKrOrhxnz0vEdcJ9Ilw03RMBSQDKVWT7jD6zPZ/ulLhYFg 1jb76aG0YPWXjstmgwXs1ULfsmiWsZHzjVtURtyNWFJXhhrl1Vd/AujVpVVp8iJip1Zf 1h6BkKn5H7GdXNfRZBupohg8IyNm3dRkcv9FoTGFq8iqvXnadnRObc4HEm+5NQxVePEG prRgCZJil74TDE+qfvlq4rITc2xjjEwUAhx2MsghfZ9UvmiQHc0ftPLKbvCXgP7q/P2z L6UA==
X-Gm-Message-State: AOAM5314O85IpVhSF/GcJCZk9CPeTnEiKSYV5YbWB0wnhgoRNoGEvFvt i5l63O/91x+4Dt5+u6eWDpYrwsLOkguigUnoFjqlxDKF
X-Google-Smtp-Source: ABdhPJxzq31v2j8njWT9XFIfweH2RJgI5bXB05XTIzrk/4MpDgk/TzGPK0i8uZKeby3lr1XAc597U6Jchkqp17GED4Q=
X-Received: by 2002:a17:906:c346:: with SMTP id ci6mr622286ejb.479.1629926323030; Wed, 25 Aug 2021 14:18:43 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Hugo Krawczyk <>
Date: Wed, 25 Aug 2021 17:18:17 -0400
Message-ID: <>
To: "Gajcowski, Nicholas H" <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000007e8e4005ca68cbd3"
Archived-At: <>
Subject: Re: [CFRG] comments on opaque-06 and voprf-07 drafts
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, 25 Aug 2021 21:18:52 -0000

Hi Nicholas, in regards to your first question: The server authenticates
using the server_public_key included and authenticated in the envelope. The
attack you describe is unavoidable if all the client has for authentication
and verification is the user's password, in particular, this applies to all
aPAKE protocols. As you say, the attacker can always simulate a
registration using the user's password and there is no way the user can
distinguish this fake registration from the real one just using the
password. Note that this also allows the attacker to mount a guessing
attack on a password, namely, an online dictionary attack, also unavoidable.

The important (and achievable) KCI property for an aPAKE is that if the
attacker gets the server's public key (but not the password), it still
cannot authenticate as the user.

If you run OPAQUE over TLS, where in addition to the authentication via
OPAQUE you have authentication via a server's TLS certificate then you
prevent the above attacks but it is not a "password only" protocol anymore
(as in addition to the password, the client also needs the authentic
server's TLS key).

Using the server's TLS certificate, if available and verifiable by the
client , has the added advantage that it protects the user's account
information from eavesdroppers.

I hope this answers your first question (I leave it to others to respond to
your other editorial comments).


On Wed, Aug 25, 2021 at 10:06 AM Gajcowski, Nicholas H <nhgajco=> wrote:

> Hi Folks,
> I've read through the opaque-06 and voprf-07 drafts and noticed a few
> minor typos/errors.
> First, a question for opaque-06:  Does the client authenticate the server
> based on the server_public_key provided to it in the ke2 portion of the AKE
> exchange? This seems to undermine the KCI protection afforded to the client
> by the AKE in the event the client's password is compromised.  With
> knowledge of the password, an attacker can essentially act as both the
> server and client in a faux registration phase.  Moreover, he can pick his
> own OPRF key, create his own server_public_key, and use the password to
> create a valid record with the appropriate auth_tag, etc.  When the client
> sends his ke1 message, the attacker can include his constructed record in
> the ke2 response which then would be accepted by the client.  If this
> correct, perhaps consider making a note of this feature as it may partially
> undermines an expected property of the AKE.
> Below are a list of some minor errors/typos:
> opaque-06:
> pg 18 1st paragraph:  ... "The private-public keys (client_private_key,
> client_public_key) may be randomly generated."
>   Should read "The client_private_key may be randomly generated" as the
> client_public_key is a function of the client_private_key.
> pg 27 step 7 of RecoverCredentials function:  "Output (client_private_key,
> response.server_public_key, export_key)."
>   Should read "Output (client_private_key, server_public_key,
> export_key)."  While the server_public_key is a member of
> RegistrationRespone
>   (section 5.1), it is not a member of CredentialResponse (6.1.1).
> However, server_public_key is derived in step 5.
> pg 32 outputs of ClientInit function: "ke1, blind, client_secret"
>    The function does not return blind or client_secret as an output per
> se.  Rather, it updates the value for state.blind and the
>    value state.client_secret is updated by the start function.
> pg 33 outputs of Start function:  "ke1 client_secret".
>    Return of client-secret is unnecessary as the state is updated in step
> 4.  Further, the start function is only invoked by ClientInit
>    which only expects the output of ke1.
> pg 34 step 2 of ClientFinalize
>    Preamble has an input of state.ke1 which was never updated by either
> ClientInit or Start functions.  Should the ClientInit function also
>    update the value for state.ke1, rather than return ke1, to be
> consistent with how it handles blind and client_secret?
> pg 36 step 9 of Response:  "Populate state with
> ServerState(expected_client_mac, session_key)"
>    Syntax is a little confusing as expected_client_mac and session_key can
> be mistaken as inputs to the function ServerState.
> pg 41 second to last paragraph of section 10.1:  "...Then, the client can
> verify that the client_identity and server_identity contained in its
> envelope..."
>    The client_identity and server_identity are contained in
> CleartextCredentials which is not included as part of the envelope.
> However, the auth_tag
>    is computed over the nonce, innner_env, and CleartextCredentials in
> step 7 of the CreateEnvelope function.
> voprf-07:
> pg 2 first paragraph of the introduction:  "...K(_) = F(K, _)"
>    The secound K should be lowecase, i.e., "K(_) = F(k, _ )".
> pg 12 VerifyFinalize function:  "issuedElement = Evaluate(skS, [element])"
>    Unclear why square braces appear.  Should it be just "issuedElement =
> Evaluate( sks, element )"?
> pg 12 VerifyFinalize function:  "E = GG.SerializeElement(issuedElement)"
>    The function Evaluate in the previous step returns issuedElement as a
> SerializeElement so this step should result in error.
> Best,
> Nick Gajcowski
> _______________________________________________
> CFRG mailing list