[CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13

Hugo Krawczyk <hugo@ee.technion.ac.il> Fri, 10 May 2024 15:28 UTC

Return-Path: <hugokraw@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DA7C14F748 for <cfrg@ietfa.amsl.com>; Fri, 10 May 2024 08:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.648
X-Spam-Level:
X-Spam-Status: No, score=-6.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl7G7mA5FMrO for <cfrg@ietfa.amsl.com>; Fri, 10 May 2024 08:28:05 -0700 (PDT)
Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5173CC14F73E for <cfrg@irtf.org>; Fri, 10 May 2024 08:28:05 -0700 (PDT)
Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-2e1fa824504so28021391fa.0 for <cfrg@irtf.org>; Fri, 10 May 2024 08:28:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715354883; x=1715959683; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RgjeCIcYn46t+yLVYL6haP8dRir0/dt5scYoCRxGi1E=; b=kOfLpKM6ooJMr+t2+XpGFHJJiWBc42SQHjlnmCR8cMyhlQ3SUbfCuJ/fwlZSWrOvfL 3rmKM2vx6fBZGcnPdl6YnLfgtnLBpu4QHZ6afF6+r6FRdloHXELY6RPRNoEOo4shpXqx RKA6IdxT1gLUzMXW7oHxE6aoxVPdLCUiMTIvjf82KMTf0BQ4Y5cv/O2Sqed+3/U95JTO eLvQaza2ThaX2mOAb75NH8n6uye7b9zCjLnZY5zQe1NidZxRETgThlmZVSucdnMtCdlC cbMuKCxGg3B0zaSrSQDlBePeCE8rS2JjFnUmcaYoNbrEktkCP/ZJcEyRebevkCmwoDQ7 hhBA==
X-Gm-Message-State: AOJu0YysOmUvYwRumkseBhQzvJC4qn9jcvoWoRg9OU/fF3IQvEa0RtTT EIpjyhtkSTuNDiB3MuA6RPN4W7t+cIOxjfNbIYOIZFCbybEFk1FrASPUD4JktqwS47NfGp6IJyT YiSLFIAYpfzIm/Kl6FF0T8nSvAxI=
X-Google-Smtp-Source: AGHT+IGeoDA0TwV26TMmXcjQH02POPTlXzq/3qtRapVL7ZM2wfg6SsnYCtbHb9r49kJp+30nhWMdlI03ktadZti2IXo=
X-Received: by 2002:a2e:602:0:b0:2e5:3ea9:8d26 with SMTP id 38308e7fff4ca-2e53ea98d95mr11060161fa.45.1715354883070; Fri, 10 May 2024 08:28:03 -0700 (PDT)
MIME-Version: 1.0
References: <CAMr0u6kOrbwdHEDmmGsVYzqjsEbzBCCtGL39jckNbSWsEumOQg@mail.gmail.com> <994001115.165708.1706765982169@email.ionos.com> <CACitvs8zzoQVY4uo1zOtoBWrSVOLfzGFBCsMnevxnCMXg-CJGw@mail.gmail.com> <CACitvs_kEOgBC0eZNbHZ1EBy6v7kqL2-99-A1kRD_QqTaTuQKw@mail.gmail.com> <CAMr0u6khy2oo6GpxYYWq803NPYvKHLk4=9Lf7Z5ddNVu8KbiZw@mail.gmail.com> <CACitvs-_iZ145ok1A8peN642Z2DmA=Pd1T2cJwrFnQo_PZxWqw@mail.gmail.com> <4277693.8349904.1713368966703@email.ionos.com> <CADi0yUPxQsktpso7htB5+6M+ZJRyhax+QiUBNJQa3RG5GwLfCw@mail.gmail.com> <1916772043.8833957.1713572703792@email.ionos.com> <CADi0yUPJP+PrLYxw1iCay3VFLYDqktja_51QLdW3YiKC9RW=Uw@mail.gmail.com> <CAMr0u6kypySZrDx5zMz9Y7S4U5-Z16vYSuwKvkOV89tgAh4C=w@mail.gmail.com> <GV1PR01MB8436DA9FC923665CE88FF637D61B2@GV1PR01MB8436.eurprd01.prod.exchangelabs.com> <CADi0yUOoKRFxO85cYygX7V3jxL6kZE8hkW6S91eLa2fr_pgQ4g@mail.gmail.com> <GV1PR01MB8436A8B3E01489A85372BAAAD6192@GV1PR01MB8436.eurprd01.prod.exchangelabs.com> <CADi0yUP9RuR9c_jC-hDezOKz4TqqRurCPqFd18yBriZEVs1gEw@mail.gmail.com> <GV1PR01MB8436B1FCDC974F04182A5FF3D6E72@GV1PR01MB8436.eurprd01.prod.exchangelabs.com>
In-Reply-To: <GV1PR01MB8436B1FCDC974F04182A5FF3D6E72@GV1PR01MB8436.eurprd01.prod.exchangelabs.com>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Fri, 10 May 2024 11:27:35 -0400
Message-ID: <CADi0yUNBzX2Lp5x9v+ed232vMCbXjt9U0yUs6nOEAuXJW4WETg@mail.gmail.com>
To: "Hao, Feng" <Feng.Hao@warwick.ac.uk>
Content-Type: multipart/alternative; boundary="00000000000078244e06181b2e6b"
Message-ID-Hash: VUPG6QXTNMYALEACXFTCQVG2EA3HLYSP
X-Message-ID-Hash: VUPG6QXTNMYALEACXFTCQVG2EA3HLYSP
X-MailFrom: hugokraw@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: IRTF CFRG <cfrg@irtf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/fyRl9RwBs8TLbKm22YjbgsraTqQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Owner: <mailto:cfrg-owner@irtf.org>
List-Post: <mailto:cfrg@irtf.org>
List-Subscribe: <mailto:cfrg-join@irtf.org>
List-Unsubscribe: <mailto:cfrg-leave@irtf.org>

Defense against enumeration attacks is obtained via two mechanisms:
derivation of OPRF keys from a PRF and post-encryption of OPAQUE message
with the masking key. These two do not affect the analysis of OPAQUE as an
augmented PAKE. Derivation via PRF is consistent with OPAQUE analysis that
assumes OPRF keys to be random or pseudorandom. The additional
post-encryption of the OPAQUE messages under the masking key,
pseudorandomly derived from randomized_password, is simply simulated with a
random independent masking key (as noted in the current draft).

On Fri, May 10, 2024 at 10:33 AM Hao, Feng <Feng.Hao@warwick.ac.uk> wrote:

>
>
>    - Feng, we believe that the current draft explains the protection
>    against enumeration attacks in sufficient detail (including its two main
>    elements: deriving the OPRF key from a PRF and the use of the masking key).
>
>
>
> OK. It seems clear that the protocol as specified in the 2018 paper has
> been modified. There was no masking key in the original spec. This looks
> like a non-trivial change, and the implications are not immediately clear.
> I don’t know to what extent this modification has been publicly
> peer-reviewed.
>
>
>
> Modifying a protocol can be extremely delicate. Some people may remember
> that the SRP-3 protocol defined in Wu’s 1998 paper was selected by IEEE
> P1363.2 in 2000, but was modified in 2002 to address a subtle
> two-for-one-guess attack. It took people another 7 years to realize that
> the modified protocol was still unable to prevent the attack, and the
> protocol had to be modified again in 2009 to a new version SRP-6a. Part of
> the problem is that modifications made to the original 1998 protocol were
> never fully explained in any peer-reviewed document.
>