Re: [Cfrg] Fwd: New Version Notification for draft-krawczyk-cfrg-opaque-06.txt

Hello,

A small note regarding
https://www.ietf.org/internet-drafts/draft-krawczyk-cfrg-opaque-06.txt,
could we revise the following formula in section 4 from:

   KEYS = HKDF-Expand(key=RwdU, info=(nonce | "EnvU"), Length=LS+LH+LH)

to:

   KEYS = HKDF-Expand(key=RwdU, info=(Nonce | "EnvU"), Length=LS+LH+LH)

-Clinton

On Fri, Jun 19, 2020 at 9:26 PM Hugo Krawczyk <hugokraw@gmail.com> wrote:

> A new version of draft-krawczyk-cfrg-opaque is available.
> It has an important change in the way secret information under the
> envelope EnvU is protected.
>
> There is no form of optional encryption or use of counter mode anymore.
> Instead it defines a very specific mechanism:
> Secret information included in EnvU is xor-ed with a pseudo random
> pad derived from RwdU, and HMAC is computed on the concatenation of this
> value
> and any non-secret information included in EnvU. This simple mechanism
> satisfies the encryption requirement of OPAQUE and obviates any need to
> specify
> other RKR-secure schemes. In particular, it eliminates the "temptation" to
> use
> non-RKR modes such as GCM. Performance considerations are insignificant
> here as
> EnvU requires encryption of very short plaintexts. Applications that
> require
> sending additional information (e.g., non-OPAQUE user secrets stored at the
> server) will use ExportKey (previously called KdKey) with any encryption
> scheme of their choice. No RKR requirement in this case.
> See Section 4 for the details.
>
> This version also corrects a typo in the specification of SIGMA (the
> identities
> in messages K2 and K3 got mixed up in the version 05 of the draft).
>
> Very important: This draft is still intended as a high level description
> of the
> protocol and its components. A detailed specification is underway and will
> be
> posted shortly as draft-irtf-cfrg-opaque. OPAQUE implementers should follow
> the specifications in that document.
>
> Hugo
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Sat, Jun 20, 2020 at 12:20 AM
> Subject: New Version Notification for draft-krawczyk-cfrg-opaque-06.txt
> To: Hugo Krawczyk <hugokraw@gmail.com>
>
>
>
> A new version of I-D, draft-krawczyk-cfrg-opaque-06.txt
> has been successfully submitted by Hugo Krawczyk and posted to the
> IETF repository.
>
> Name:           draft-krawczyk-cfrg-opaque
> Revision:       06
> Title:          The OPAQUE Asymmetric PAKE Protocol
> Document date:  2020-06-19
> Group:          Individual Submission
> Pages:          26
> URL:
> https://www.ietf.org/internet-drafts/draft-krawczyk-cfrg-opaque-06.txt
> Status:
> https://datatracker.ietf.org/doc/draft-krawczyk-cfrg-opaque/
> Htmlized:       https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-06
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-krawczyk-cfrg-opaque
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-krawczyk-cfrg-opaque-06
>
> Abstract:
>    This draft describes the OPAQUE protocol, a secure asymmetric
>    password authenticated key exchange (aPAKE) that supports mutual
>    authentication in a client-server setting without reliance on PKI and
>    with security against pre-computation attacks upon server compromise.
>    Prior aPAKE protocols did not use salt and if they did, the salt was
>    transmitted in the clear from server to user allowing for the
>    building of targeted pre-computed dictionaries.  OPAQUE security has
>    been proven by Jarecki et al.  (Eurocrypt 2018) in a strong and
>    universally composable formal model of aPAKE security.  In addition,
>    the protocol provides forward secrecy and the ability to hide the
>    password from the server even during password registration.
>
>    Strong security, versatility through modularity, good performance,
>    and an array of additional features make OPAQUE a natural candidate
>    for practical use and for adoption as a standard.  To this end, this
>    draft presents several instantiations of OPAQUE and ways of
>    integrating OPAQUE with TLS.
>
>    This draft presents a high-level description of OPAQUE, highlighting
>    its components and modular design.  It also provides the basis for a
>    specification for standardization but a detailed specification ready
>    for implementation is beyond the scope of this document.
>
>    Implementers of OPAQUE should ONLY follow the precise specification
>    in the upcoming draft-irtf-cfrg-opaque.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>

-- 
-Clinton M. Bowen