[CFRG] Does OPRF/OPAQUE require full implementation of RFC 9380

Stefan Santesson <stefan@aaa-sec.com> Sat, 30 March 2024 11:56 UTC

Return-Path: <stefan@aaa-sec.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 4B2C4C14CEFD for <cfrg@ietfa.amsl.com>; Sat, 30 Mar 2024 04:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aaa-sec.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 w7YoUjpBrNpG for <cfrg@ietfa.amsl.com>; Sat, 30 Mar 2024 04:56:15 -0700 (PDT)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [93.188.3.37]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 880C7C14F71C for <cfrg@irtf.org>; Sat, 30 Mar 2024 04:56:14 -0700 (PDT)
Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id EEF2A3008A30 for <cfrg@irtf.org>; Sat, 30 Mar 2024 12:56:11 +0100 (CET)
Received: from s899.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id DDD822E2A3F4 for <cfrg@irtf.org>; Sat, 30 Mar 2024 12:56:11 +0100 (CET)
Received: from s473.loopia.se (unknown [172.22.191.6]) by s899.loopia.se (Postfix) with ESMTP id DC84F2C8B9E7 for <cfrg@irtf.org>; Sat, 30 Mar 2024 12:56:11 +0100 (CET)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Authentication-Results: s473.loopia.se (amavisd-new); dkim=pass (2048-bit key) header.d=aaa-sec.com
Received: from s979.loopia.se ([172.22.191.6]) by s473.loopia.se (s473.loopia.se [172.22.190.13]) (amavisd-new, port 10024) with LMTP id xqlF-1wnbnVR for <cfrg@irtf.org>; Sat, 30 Mar 2024 12:56:11 +0100 (CET)
X-Loopia-Auth: user
X-Loopia-User: mailstore2@aaa-sec.com
X-Loopia-Originating-IP: 90.228.170.155
Received: from [10.10.0.158] (unknown [90.228.170.155]) (Authenticated sender: mailstore2@aaa-sec.com) by s979.loopia.se (Postfix) with ESMTPSA id 2189910BC3D4 for <cfrg@irtf.org>; Sat, 30 Mar 2024 12:56:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aaa-sec.com; s=loopiadkim1707241022; t=1711799771; bh=hLguS8YplAy3cIRUGNxot0KIr4K1FXmJEChv+TUcHwY=; h=Date:To:From:Subject; b=DCtEBt9Lw/CG11FIucfQ97kOU0ilQOQE3uBgJcQxNk6W1tJ6NvTApCVsDXeHyuRGE V16p6w4FR+HzTsT9VvjAYEyzfqFM3xDBEBSrvJDnBbSHnMStH6i6r/cOqW5tNXLw6G uH2SYMMPMPuBcNEl5s0Gj7Dp0AZAOwzQ9yMxIpwN3evOb3gDWEltKgo7uFgU3tgD6y m9RoZj/S4k5j1q63qab8z0wegUnxiHfreutnA59tW3H6segmsd9ii88f0mGVDxbywJ Y/dKm3iYgoW4v+IXSadszk1wXZoCNW6dWiLNBIJw5X5NA1sAcbZAc3LfOvu5LShIFw HDiJUTlDkDiRg==
Content-Type: multipart/alternative; boundary="------------vHdVoe4kipGm9gx0NYoUOPOn"
Message-ID: <410a0800-78ff-422f-8ca3-5a0211478cbd@aaa-sec.com>
Date: Sat, 30 Mar 2024 12:56:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird Beta
Content-Language: sv-SE, en-GB
To: IRTF CFRG <cfrg@irtf.org>
From: Stefan Santesson <stefan@aaa-sec.com>
Autocrypt: addr=stefan@aaa-sec.com; keydata= xsDNBGB0SQwBDADRZIRQH2PciJEmsZ7noEFV8jdtUoB/3AiNPg5CYWJz3YlB1ZyqizIYRXlY EzhIcHRCdn+NrJvReq3Xi3kvycqvhUrrxMIxMYY7YZEripjrbyleFbbZjX4oCu+CTRj8y1Wo V6h9fLlpdqEriXwQ1brs1F/4KmHXTli4FIAmRTzdGBDWgD9sg2UmuloC4+A3d2Zoo6D6Tbjv Piyy3hwqdxjOF0tXSrtH9OXkyoIlmOdaHKLT3hB7nRlurq7dWZYGsnWIIg6YIMwA/eo6OHry nq9OpQ2Zktz40r6WaOARM4RTJgBI45BgR0IVXGJG3ie05lrORYxfLKJ9//JR+4VqY/6RC85C L5Ch6KH7smzraNZXZWPlDjrs25O0X2PwEwv676vJ9tDY7oLN0RHpVMYFx2GOKAYtH0K1BAwY yFlSNRmLbSjNPnGN4yk6ad5J6HB/Z9A0On/Ud2R8eXR5ZJVBNDdcCjM2L2WleRoTbh52DmhX yisi1loEROOZjaqfBf03jlsAEQEAAc0lU3RlZmFuIFNhbnRlc3NvbiA8c3RlZmFuQGFhYS1z ZWMuY29tPsLBDwQTAQgAORYhBKkgqX8QoC/CtVBH1S8bGjmXZjPRBQJgdEkMBQkFo5qAAhsD BQsJCAcCBhUICQoLAgUWAgMBAAAKCRAvGxo5l2Yz0S+7C/94cy3pZYEK9E1PCSwtSYcVrpuJ FwEioeoswoCVU5JzCdiyv4kSP3+lY35Z71Dw1pzoBrSsLb7xbRLrEdoM05AQqRK3eaioI/8R nbPg5M+H86m7Y7bxYzBpcJ+ipNCvA2BbE+2YLSmHEEA0nTWbXtamqib+5jWRd0i/DTtTCzaP /IVSxy7PVcyB8KEF09Go5LFeZOJquIyfHU1KVjG+8UxKSjcyO3Rku5Rdt1D4tX7M6G5d1PMj BqLZPFYUvi5hB2sftMcmZzy9QLkP+2oLlo0R+vc50JO5jpUC1czAXRdp6Rr2r0mFbz1mV6Je AvN4PcFoepTwq97c0lg+zZL5swfcNSAEFKXWZgKJxo6b2iby2wDqaWORjQSNlqKETFOUeQDH dcqLPioQbW95MPa8DtfHGYbdKjk5esyY/PFQw0xR4XvrZx7CeIb6gwGgQByZqTP/lbzWnPHE zpL0DslrtBdfF+i90xGlz0FB4GVQVmygfB4g/l0bajzCb06cyjMiqTrOwM0EYHRJDAEMALsD BRBzhRH3qTcPvO3sFG3VvWlNlKiAKW5XlVp3yw/mBdaVhg0BMb0LlmEamz4HHMoL5hmfUDLS 4TJfJhZMY3ZufvGwVYsiZpl5YtebkH3M8ik5dfUz15xg0ievm3foJLjOwAutS1BKRJSrEnMt YjPqS8APSYs3pd1s1zPfvwaTYy5MrNE6mS2LDqbKA4nJVdq3LpEaBmSW+njfQAIZTRKmgxsb 6kxn4JWVseVRKKDMbqSHZpm8a4RO194FOqdXEz9fTVz2Zn8nJ1zJZTNWzcsHq3gBtM84kwUo NghYDqExuIHahojUHXHntfjZ5ZDW4/ZbOcCrVRDNWWoIoxBvxz10+TPgM+/ytA8VFr4Sglnj 1pnnRFs7aUXa5zIoFUC7NKWCR158ujnYD6S6Ap4nkDhdovL54azvt+/ChWiuQqoQSPE2ihLo vkM8cR9UNPjBVAuLA+pr6RPeg8LrjMRD86lBCfc5KkiP22oTOVzZal+jGgdgiYvD13KM2jUd VB8H9QARAQABwsD8BBgBCAAmFiEEqSCpfxCgL8K1UEfVLxsaOZdmM9EFAmB0SQ0FCQWjmoAC GwwACgkQLxsaOZdmM9Gc3wv/Wyquulv2Y7kUPXITDs/oLugd2Lx6KhFfPOhaoe2amQqhWk8H Hhauqb2Qx8rMFeDmaqzfxLsRpM0FMjtovH3XswPuZoZ3mLw0XuHGgU5QVS/zL6NrNVdwq8dv OV5m6QCm0RomI1cPRAB8P6/bbJy+FUBWvqqCUbQo5T5KXYgNwA/m1Y/S5cej/Wz3V7/Ixwkl 2t63TTrhnXBBGkAz5ApBT/YJ7L89eHLZJUMJJXaNewfhb3dIcZgza705BU5jHchpmJtTzgnS PaYqhKciMQUxd8/8jJ/XqlNVw7XxY77mNK+9BDf7y2EG6bRrzQExhS08vtuPexOE66IXdRId kENY+UQeopSb6EXU6eRD7BsXHLRfxzvs0+wMU7lRUigiONMUv54p6PqBa8PMFV4Jv8NcB9Qu Phy/7YtaBjmJn0FDTKpbDYILwh0WNoxjFqWI3jMo2ZTVjKY0aJMndJ0MxB3eAHjhQLkeKtIL 4831tbIM6eKC9gY3xUsE4vSV/CPdPKjV
Organization: 3xA Security AB
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/5MiZFTmu43KiucuXM57UFK5u84U>
Subject: [CFRG] Does OPRF/OPAQUE require full implementation of RFC 9380
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://mailman.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://mailman.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Mar 2024 11:56:20 -0000

This question has lead to intense discussions in our project regarding 
implementation of OPRF in general and OPAQUE specifically.


Section 2.1 in OPR (RFC 9497) states:

"HashToGroup(x):  Deterministically maps an array of bytes x to an 
element of Group.  The map must ensure that, for any adversary receiving 
R = HashToGroup(x), it is computationally difficult to reverse the mapping."

Note that there are not even a "MUST" expressed here. Just a "must" and 
therefore not a requirement according to section 1.1.


It continues to say that "Security properties of this function are 
described in [RFC9380]".

This does not seem like a strong requirement either. Just guidance, 
given that you understand the security requirements here which seems to 
be "computationally difficult to reverse the mapping".


In our evaluation of OPAQUE we did not implement RFC 9380. We just used 
some very simplified functions:


@Override public ECPoint hashToGroup(byte[]elementData) {
   BigInteger inputScalar =new BigInteger(1,hashFunctions.hash(elementData)).mod(
     parameterSpec.getCurve().getOrder());
   return parameterSpec.getG().multiply(inputScalar);
}

@Override public BigInteger randomScalar() {
   return new BigInteger(512,RNG).mod(parameterSpec.getCurve().getOrder().subtract(BigInteger.ONE))
     .add(BigInteger.ONE);
}


This is then used to hash a password into an element before applying the 
OPRF blind at the client side.

Now this is just a mock for evaluation, but I have a hard time 
understanding the rationale why this simplified approach would not work 
in production.

The downside here is, for what I understand, that the "inputScalar" is 
known, and not just the result element. This is problematic for some use 
of hashToGroup, but I'm not sure there is any significant issues for use 
with OPRF Blind(password) function to blind the password input.

I would really appreciate help. Has this been discussed already to any 
detail. Is there any guidance available?

If this is not good enough. Can you take any simpler path than full RFC 
9380 implementation?

Finally, is there any support for G.hashToGroup being planned in any 
major libraries supporting OPRF/OPAQUE?


Thanks for any help.


-- 
________________
Stefan Santesson