[Crypto-panel] Review of draft-irtf-cfrg-voprf-12
Julia Hesse <juliahesse2@gmail.com> Thu, 25 August 2022 05:25 UTC
Return-Path: <juliahesse2@gmail.com>
X-Original-To: crypto-panel@ietfa.amsl.com
Delivered-To: crypto-panel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B440C14F748; Wed, 24 Aug 2022 22:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.859
X-Spam-Level:
X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 BzoHoqjhqmH8; Wed, 24 Aug 2022 22:25:39 -0700 (PDT)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 985D2C1524C8; Wed, 24 Aug 2022 22:25:39 -0700 (PDT)
Received: by mail-ej1-x629.google.com with SMTP id lx1so953789ejb.12; Wed, 24 Aug 2022 22:25:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:subject:from:to:user-agent:mime-version :date:message-id:from:to:cc; bh=094i2v94hyeBZenqszaAs2e/lSp+wrsk5MrycbOmAyg=; b=HEFC5FDIAAOscmI2vkyDPaz2QjNCKAiL6h3onlqc/BOvR5K+Mfkyabyi26HBAVPNTN CwZVNGNoYslYIWFR2H7UcYl0XD2T8r21HXFa8RbRXTe7a9/mJ4IA12ASUw+3VuK4fLgf CLQdGgDL7ud0yNTmvzuEnbVPwqjI5j4TB3U6fJPt7pqe1edv8wys9Rz24t87K5yIRoBm nYCfT6RNqvu5PD6g07cD0IE1aRWGEydTjBxl0rUA473Ky1PXYsDxbd3Eh8yn2KjgE0X/ gGR9V7uzEPewGhdX1mDvBb2mbAS9nggz6a2GnUsMl/SzGizVTN/nyvv07Prnt7dO9P1p Ntyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:subject:from:to:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc; bh=094i2v94hyeBZenqszaAs2e/lSp+wrsk5MrycbOmAyg=; b=W+VAPzyewPYNnLdW/nf0hMYo9PaE7V4knIO9jB4T7QZUlK3xEAbF0H8n+ndJJwAZqk dFjHeZbGVKU599zcpaOX7/r7qIkD9dl+wvYoBfjQscybxMBjiQzADmQ6GxmkrS131/0Y GW/3xub/ZeqiwMmMMW8L5HhK5gc+RCOeC7k7PjEPleEWf+VK5/ACyfzKiSTcz5eGEjDd 4J9fm5LQE977wNWpMQNeIXCxk2RMnyiDAkY3z+6cjTU4BdaWFECtvfWk+dvWVHKIHxqL jf1IisWpF35y0PgfUbaC51uWDb+Cv3qT+9djaigIl7uCDdMBj39xDrn/Q8uC6cX7exSG Hwig==
X-Gm-Message-State: ACgBeo0SP8k8EGX86Ud8ISmpEMDDkDz3Oh8NC97RbmyD9XqeO9VHB56L HbSCQ6+4cCuYAFp+VTCbFXJmOZZEB9VUS2v9
X-Google-Smtp-Source: AA6agR6RPV8gckU/rdhZIKT0r96irgSsxM7Zdhu/PH8wR5FeWb0AubfmnpNoaTQAEh3bjcRQcZ3ieQ==
X-Received: by 2002:a17:906:5a50:b0:73d:ad57:e02e with SMTP id my16-20020a1709065a5000b0073dad57e02emr1302323ejc.431.1661405138038; Wed, 24 Aug 2022 22:25:38 -0700 (PDT)
Received: from ?IPV6:2a02:aa12:a780:5480:8f:a168:8c53:baed? ([2a02:aa12:a780:5480:8f:a168:8c53:baed]) by smtp.gmail.com with ESMTPSA id m26-20020a056402051a00b004464c3de6dasm4102632edv.65.2022.08.24.22.25.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Aug 2022 22:25:37 -0700 (PDT)
Message-ID: <6337f79d-6424-d4d6-786b-8d5c699c3491@gmail.com>
Date: Thu, 25 Aug 2022 07:25:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0
To: crypto-panel@irtf.org, cfrg@irtf.org
From: Julia Hesse <juliahesse2@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/lHye9ZZYQBJJJcsBxKoGU4hVp2c>
Subject: [Crypto-panel] Review of draft-irtf-cfrg-voprf-12
X-BeenThere: crypto-panel@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Crypto Review Panel review coordination <crypto-panel.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/crypto-panel/>
List-Post: <mailto:crypto-panel@irtf.org>
List-Help: <mailto:crypto-panel-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Aug 2022 05:25:40 -0000
Hi all, this is a review of draft-irtf-cfrg-voprf-12. Disclaimer: I did not implement the scheme, and hence did not go through the test vector section. I work with Stas Jarecki, Chris Wood and Hugo Krawczyk, whose works this draft is based upon, and Chris is an author of it. Overall I find the draft in very good shape. There are only a few things I would like to see clarified in the document. Detailed comments follow. - "Verifiable POPRF": the verifiability property is not optional in the draft, but the fact that it is sometimes called "verifiable POPRF" hints that it is. Why not avoid any confusion by calling it VPOPRF throughout the document? - The introduction mentions POPRFs have been used for PPSS in JKK14, but that paper uses only VOPRFs explicitly and I cannot spot implicit use of a partially oblivious protocol in their PPSS construction. - Section 1.3 introduces PrivateInput and PublicInput as the exact same data types. What distinguishes them? The terms Private and Public hint at something, but it seems never spelled out in the document. - In general the distinction between "Input" and "Parameters" in the function descriptions confused me. What are the semantics here? First I thought Parameters are implementation-wide and fixed objects, like the Group, but then the OPRF key skS appears as a Parameter of BlindEvaluate. Since the document also hints that keys can be updated during the run of the protocol ("key rotation"), skS does not seem to be a long-term parameter to me. Sometimes both the terms Input and Parameter areĀ mixed, for example when "PublicInput contextString" appears under Parameters. Another example is in the flow diagram of POPRF, where both Inputs (info) and Parameters (pkS,skS) appear in parantheses after a party's name. Overall it would be good to clarify why the function descriptions distinguish between "Inputs" and "Parameters", as otherwise implementors might interpret their own meaning to these terms. - The document uses both "base point" and "group generator". Maybe unify? - Member functions of the group are sometimes referred to as Group.function() and sometimes just as function(). Some of the appearances, e.g., of Order() in 4.1.4, do appear in the context of a group Group, so the write-up could be clarified by putting Group.Order() instead. - First paragraph of 2.2.1 "k*C[i]==D[i] for each element in the list." Better "for each i in {1,...,m}". - Explain the list notation [] - Section 3, protocol overviews: skS and pkS appear as input to the parties but are not used in the protocols. E.g., it should be BlindEvaluate(skS,blindedElement) instead of BlindEvaluate(blindedElement). - Still protocol overviews: I find the term "evaluatedElement" computed by the server a bit misleading, as it sounds like the server is learning the evaluation. On the other hand I don't have a better idea. BlindedEvaluatedElement would indicate more precisely what happens, but is probably too long. - "client and server augment the pkS and skS, respectively, using the info value": this could be modified to explain the (otherwise unexplained) "tweakedKey" term that appears in the protocol overview. Maybe "client and server tweak their pkS and skS, respectively, using the info value"? - *If* I would implement this, I would wonder about Input "opaque seed[Ns]". Ns is an integer, and this seed appears to be a list of Ns opaque values. In the text it says "randomly generated seed". The seeds suggested in the test vector section do not appear very random to me ;) Not sure if this is underspecified or just common knowledge. - The terms (functions?) OPRFServerContext, VOPRFClientContext etc. do not seem to be defined. - "Recall that servers may batch multiple client inputs to BlindEvaluate." - Maybe one more sentence how this is done? Just repeated execution of BlindEvaluate and concatenating the evaluatedElements in the message to the client? - "certain public inputs that map to invalid public keys for server evaluation." I could not parse "public key for server evaluation" here. - Section 4.1.1 and following: some numbers are missing "bytes", e.g., the Nh values, L = 48,... - I could not make any sense of 5.2, but again, not an implementor... - Section 6, first paragraph, has one POPRF that should be VOPRF - 6.1 Pseudorandomness: pull "for a random sampling of k" to the first part of the sentence. - "with infinite compute" - infinite computing power? - "Additionally, for the.... additional" - remove the first one? - Partial obliviousness: I don't understand this definition. Everything but the last sentence are properties of any OPRF, as described already in the other properties. The sentence "Both client and server learn the public input (info)" does not seem to have any meaning, since info is *input* to both parties and hence they of course learn it. The partial obliviousness property rather seems to enforce usage of info in an evaluation. I was also surprised that partial obliviousness is equivalent to unlinkability. Are OPRFs linkable, in the sense of linkability described in the draft? - "One-More Gap Computational Diffie Hellman (CDH)" This is not what CDH usually stands for. - Risking a few hits on my head: JKK14 does *not* give a security proof for the VOPRF protocol in Section 6.1. JKK14 requires session identifiers and is in the random oracle model. Unless, e.g., hash domain separation is put as a MUST in the draft, the analysis of JKK14 does not apply to the protocol in Section 6.1. - "variant is based on" - are based on? - In reference [SJKS17] typos in Jareckiy, Krawczykz Best, Julia