Move VOPRF into spec. #257

dvorak42 · 2023-05-25T16:26:10Z

This removes issuer protocol and moves some of the VOPRF serialization into the bikeshed spec.

Partially resolves #230.

This removes issuer protocol and moves some of the VOPRF serialization into the bikeshed spec. Partially resolves #230.

colinbendell

The variance from voprf draft21 should generally be made more explicit. For places that might change (eg: the serialization of the nonces) we could offer recommendations such as:

const count = bytes.readInt(2);
// calculate blinded length to handle Ne=49 or legacy uncompressed (Ne=97)
const blindedLength = Math.round((bytes.length - 2) / count); 

for (let i = 0; i < count; i++) {
  const nonce = bytes.readBytes(blindedLength);
  ...

spec.bs

colinbendell · 2023-05-25T17:54:44Z

spec.bs

+  uint16 issued;
+  uint32 key_id = keyID;
+  SignedNonce signed[issued];
+  opaque proof<1..2^16-1>; // Length-prefixed form of DLEQProof.


Should mention that the proof is a serialized Scalar of both values each of Ns

spec.bs

johannhof

I think I'd like @jyasskin to take a look at this to tell us if there's a better way to join bikeshed language and RFC language (the VOPRF Methods section).

Had some comments but I'll defer to Jeffrey to approve this :)

johannhof · 2023-06-09T10:11:42Z

spec.bs

-
-1. Let |unmaskOperation| be the Unmask operation corresponding to |issuerKeys|["protocol_version"].
-1. Let |result| ([=list=] of byte strings) be the result of running |unmaskOperation| on |pretokens| and |response|.
+1. Let |request| be a [=byte sequence=] consisting of |numTokens| encoded as a uint16.


Not sure I fully grok this. Is it bytes or uint16? Can you say a little bit more about what this is and why it's called "request" here? Maybe we should call these fields issueHeader and pretokens like in their later usage?

Renamed and tried to clarify.

spec.bs

aykutbulut

LGTM with nit.

spec.bs

Co-authored-by: Johann Hofmann <[email protected]>

jyasskin

Quick comments; I haven't looked at the whole patch in detail.

spec.bs

Co-authored-by: Jeffrey Yasskin <[email protected]>

jyasskin

I haven't checked the details, but the interaction between bikeshed and RFCs looks pretty good.

spec.bs

jyasskin · 2023-06-14T21:10:07Z

spec.bs

@@ -666,8 +773,9 @@ To <dfn>handle a redeem response</dfn>, given [=request=] |request| and [=respon

 1. If |request|'s [=request/header list=] [=header list/contains|does not contain=] <a http-header>Sec-Private-State-Token</a>, return null.
 1. If |response|'s [=response/header list=] [=header list/contains|does not contain=] <a http-header>Sec-Private-State-Token</a>, return a [=network error=].
-1. Let |header| be the result of [=header list/get|getting=] <a http-header>Sec-Private-State-Token</a> from |response|'s [=response/header list=].
-1. If |header| is empty, return null.
+1. Let |rawHeader| be the result of [=header list/get|getting=] <a http-header>Sec-Private-State-Token</a> from |response|'s [=response/header list=].


This should use https://fetch.spec.whatwg.org/#concept-header-list-get-structured-header, right? And then check that it's a https://httpwg.org/specs/rfc8941.html#binary?

Added a step for the base64 decoding, unfortunately as currently implemented, this is just a base64 in a header and not the full structured header format.

Oh no, and simple base64 isn't forward compatible with the ':'-wrapped form used by structured field byte sequences. It'll parse as a Token instead.

@aykutbulut Since you were looking at some of the structured header bits?

PST spec is incompatible with the RFC 8941 in its current form. Created #268 for this.

Co-authored-by: Jeffrey Yasskin <[email protected]>

spec.bs

jyasskin · 2023-07-12T21:49:56Z

spec.bs

+1. Let |blinds| be an empty [=list=].
+1. Repeat the following steps, |numTokens| times:
+    1. Let |input| be an [=implementation-defined=] random value.
+    1. Let |result| ([=tuple=] ([=byte sequence=], [=byte sequence=])) be the result of running the [=Issue=] method, where the second element is encoded as a X9.62 uncompressed point.


Should be Blind, fixed and added arguments.

jyasskin · 2023-07-12T21:51:13Z

spec.bs

+1. Set |issueRequest|["count"] to |numTokens|.
+1. Let |blinds| be an empty [=list=].
+1. Repeat the following steps, |numTokens| times:
+    1. Let |input| be an [=implementation-defined=] random value.


Is |input| ever used? If it is, you need to say the type of the random value here, and you probably don't need to say it's [=implementation-defined=], unless each implementation is supposed to pick one random value and use it forever (https://xkcd.com/221/).

jyasskin · 2023-07-12T21:56:16Z

spec.bs

+
+This document encodes protocol messages in the TLS presentation language from section 3 of [[!RFC8446]].
+
+For <dfn>Issue</dfn> (corresponding to [=BlindEvaluate=] function of the [[!VOPRF]] protocol), the <dfn>IssueRequest</dfn> and <dfn>IssueResponse</dfn> are serialized as:


What's it mean for "Issue" to correspond to BlindEvaluate? Could you just have all the call sites call BlindEvaluate directly?

I also don't see obvious things in BlindEvaluate that would correspond to IssueRequest or IssueResponse. Are they just how we serialize things that'll eventually be passed to or from that algorithm?

Clarified the wording here, these are also the server-side steps so removed the Issue/Redeem function naming.

spec.bs

Co-authored-by: Jeffrey Yasskin <[email protected]>

spec.bs

aykutbulut · 2023-07-13T17:11:28Z

spec.bs

@@ -655,7 +760,8 @@ To <dfn>append private state token redemption request headers</dfn> given a [=/r
            the issuer's most recent commitments.
 1. Let |token| be the result of [=retrieve a token|retrieving a token=] for |issuer|.
 1. If |token| is null, return.
- 1. Let |record| be the result of running a cryptographic redemption procedure with |token|. If the procedure fails, return.
+ 1. Let |redeemRequest| be an empty [=RedeemRequest=].


RedeemRequest is a struct. Does step mean with empty members?

spec.bs

Add serializing/deserializing step.

jyasskin · 2023-07-13T17:10:52Z

spec.bs

+
+This document encodes protocol messages in the TLS presentation language from section 3 of [[!RFC8446]].
+
+When the server is performing the [=BlindEvaluate=] function of the [[!VOPRF]] protocol, the input <dfn>IssueRequest</dfn> and output <dfn>IssueResponse</dfn> are serialized as:


The BlindEvaluate function in https://www.ietf.org/archive/id/draft-irtf-cfrg-voprf-21.html#name-voprf-protocol has a signature of

def BlindEvaluate(skS, pkS, blindedElement):

How does that correspond to the count and nonces[count] fields in IssueRequest?

Added comments on the correspondence.

jyasskin · 2023-07-13T17:18:41Z

spec.bs

+} IssueResponse;
+```
+
+When the server is performing the [=Evaluate=] function of the [[!VOPRF]] protocol, the input <dfn>RedeemRequest</dfn> and output <dfn>RedeemResponse</dfn> are serialized as:


Similarly, Evaluate takes skS and input. While this is at least the same number of fields as in RedeemRequest, they have different names, so it's not clear they're supposed to match. Can you be clearer about how they map to each other?

Added comments and updated this to point at the PSTEvaluate version below.

jyasskin · 2023-07-13T17:46:22Z

spec.bs

+```
+struct {
+  uint32 key_id;
+  opaque nonce<nonce_size>;


Where is nonce_size defined?

Added it above along with G.

jyasskin · 2023-07-13T17:47:43Z

spec.bs

+  uint16 count;
+  ECPoint nonces[count];


Is this equivalent to

Suggested change

uint16 count;

ECPoint nonces[count];

ECPoint nonces<0..65535>;

?

Yes, though being able to refer to count separately from nonces is slightly useful from the original form.

spec.bs

jyasskin

I'll be out the rest of the week, so don't wait on me to re-review.

spec.bs

Co-authored-by: Jeffrey Yasskin <[email protected]>

Fix typos.

SHA: 9dfaf87 Reason: push, by dvorak42 Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

SHA: 9dfaf87 Reason: push, by aykutbulut Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Move VOPRF into spec.

d9a8a6d

This removes issuer protocol and moves some of the VOPRF serialization into the bikeshed spec. Partially resolves #230.

dvorak42 requested review from johannhof and aykutbulut May 25, 2023 16:26

colinbendell suggested changes May 25, 2023

View reviewed changes

dvorak42 added 2 commits May 25, 2023 14:26

Review comments.

644dee7

Add TLS reference.

7d8bc3e

johannhof reviewed Jun 9, 2023

View reviewed changes

johannhof requested a review from jyasskin June 9, 2023 10:33

aykutbulut approved these changes Jun 10, 2023

View reviewed changes

spec.bs Outdated Show resolved Hide resolved

dvorak42 and others added 2 commits June 13, 2023 09:19

Update spec.bs

014261a

Co-authored-by: Johann Hofmann <[email protected]>

Resolve some comments.

d6f1b22

jyasskin reviewed Jun 13, 2023

View reviewed changes

spec.bs Outdated Show resolved Hide resolved

spec.bs Outdated Show resolved Hide resolved

spec.bs Show resolved Hide resolved

dvorak42 and others added 2 commits June 14, 2023 09:42

Update spec.bs

b3b1f55

Co-authored-by: Jeffrey Yasskin <[email protected]>

Update spec.bs

0e6aaf3

jyasskin approved these changes Jun 14, 2023

View reviewed changes

dvorak42 and others added 3 commits June 14, 2023 17:55

Update spec.bs

eaf1a66

Co-authored-by: Jeffrey Yasskin <[email protected]>

Update spec.bs

be32483

Update spec.bs

c00ed4c

jyasskin reviewed Jul 12, 2023

View reviewed changes

dvorak42 and others added 3 commits July 13, 2023 10:07

Update spec.bs

aed53cf

Co-authored-by: Jeffrey Yasskin <[email protected]>

Update spec.bs

ea9d38b

Update spec.bs

b0a053f

aykutbulut reviewed Jul 13, 2023

View reviewed changes

spec.bs Show resolved Hide resolved

aykutbulut reviewed Jul 13, 2023

View reviewed changes

spec.bs Show resolved Hide resolved

aykutbulut reviewed Jul 13, 2023

View reviewed changes

spec.bs Outdated Show resolved Hide resolved

aykutbulut reviewed Jul 13, 2023

View reviewed changes

spec.bs Outdated Show resolved Hide resolved

jyasskin mentioned this pull request Jul 13, 2023

Multiple functions with the same names cfrg/draft-irtf-cfrg-voprf#385

Open

Update spec.bs

9fdb9b1

Add serializing/deserializing step.

jyasskin reviewed Jul 13, 2023

View reviewed changes

Update spec.bs

99ef1c6

jyasskin approved these changes Jul 17, 2023

View reviewed changes

spec.bs Outdated Show resolved Hide resolved

spec.bs Outdated Show resolved Hide resolved

spec.bs Show resolved Hide resolved

spec.bs Outdated Show resolved Hide resolved

spec.bs Outdated Show resolved Hide resolved

spec.bs Outdated Show resolved Hide resolved

dvorak42 and others added 3 commits July 18, 2023 09:35

Update spec.bs

c82278f

Co-authored-by: Jeffrey Yasskin <[email protected]>

Update spec.bs

d3c0f8b

Update spec.bs

13b5c7f

Fix typos.

dvorak42 merged commit 9dfaf87 into main Jul 18, 2023

github-actions bot added a commit that referenced this pull request Jul 18, 2023

Merge pull request #257 from WICG/move-voprf

cb0ef59

SHA: 9dfaf87 Reason: push, by dvorak42 Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Move VOPRF into spec. #257

Move VOPRF into spec. #257

dvorak42 commented May 25, 2023 •

edited by pr-preview bot

Loading

colinbendell left a comment

colinbendell May 25, 2023

johannhof left a comment

johannhof Jun 9, 2023

dvorak42 Jun 13, 2023

aykutbulut left a comment

jyasskin left a comment

jyasskin left a comment

jyasskin Jun 14, 2023

dvorak42 Jun 15, 2023

jyasskin Jun 15, 2023

dvorak42 Jun 15, 2023

aykutbulut Jul 12, 2023

jyasskin Jul 12, 2023

dvorak42 Jul 13, 2023

jyasskin Jul 12, 2023

dvorak42 Jul 13, 2023

jyasskin Jul 12, 2023

dvorak42 Jul 13, 2023

aykutbulut Jul 13, 2023

dvorak42 Jul 13, 2023

jyasskin Jul 13, 2023

dvorak42 Jul 14, 2023

jyasskin Jul 13, 2023

dvorak42 Jul 14, 2023

jyasskin Jul 13, 2023

dvorak42 Jul 14, 2023

jyasskin Jul 13, 2023

dvorak42 Jul 14, 2023

jyasskin left a comment


		This document encodes protocol messages in the TLS presentation language from section 3 of [[!RFC8446]].

		For <dfn>Issue</dfn> (corresponding to [=BlindEvaluate=] function of the [[!VOPRF]] protocol), the <dfn>IssueRequest</dfn> and <dfn>IssueResponse</dfn> are serialized as:


		This document encodes protocol messages in the TLS presentation language from section 3 of [[!RFC8446]].

		When the server is performing the [=BlindEvaluate=] function of the [[!VOPRF]] protocol, the input <dfn>IssueRequest</dfn> and output <dfn>IssueResponse</dfn> are serialized as:

	uint16 count;
	ECPoint nonces[count];
	ECPoint nonces<0..65535>;

Move VOPRF into spec. #257

Move VOPRF into spec. #257

Conversation

dvorak42 commented May 25, 2023 • edited by pr-preview bot Loading

colinbendell left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

johannhof left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aykutbulut left a comment

Choose a reason for hiding this comment

jyasskin left a comment

Choose a reason for hiding this comment

jyasskin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jyasskin left a comment

Choose a reason for hiding this comment

dvorak42 commented May 25, 2023 •

edited by pr-preview bot

Loading