-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathcrypto-panel-review-by-Chloe-Martindale.txt
85 lines (51 loc) · 3.56 KB
/
crypto-panel-review-by-Chloe-Martindale.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
Overall I think that this is a very well written document, precise and easy to read, and mostly covering everything that needs to be there. I would like to recommend it for continuing on in the CFRG process, once the small things in this review are addressed. My only personal wishes for additions would be (a) including some technical details on RSAVRF and (b) a subsection discussing pros and cons of RSAVRF vs. ECVRF.
Below are some small comments:
Abstract
Eliptic -> Elliptic
2.
"The VRF_hash algorithm is deterministic, in the sense that it always
produces the same output beta given a pair of inputs (SK, alpha)."
->
"The VRF_hash algorithm is deterministic, in the sense that it always
produces the same output beta given the same pair of inputs (SK, alpha)."
"Notice that this means that
VRF_hash(SK, alpha) = VRF_proof_to_hash(VRF_prove(SK, alpha))
and thus this document will specify VRF_prove and VRF_proof_to_hash
rather than VRF_hash."
: I find this logical implication confusing. Do you mean "and in fact VRF_hash is always computed in this way, thus.."?
3.1
sufficies -> suffices
3.3
"Also, the VRF output beta does not look random to any party that
knows valid VRF proof pi corresponding to the VRF input alpha"
->
"Also, the VRF output beta does not look random to any party that
knows the valid VRF proof pi corresponding to the VRF input alpha"
3.4
"Pseudorandomness, as defined in Section 3.3, does not hold if the VRF
keys were generated adversarially."
: This statement is stronger than you intend, I think. Strictly speaking, this reads as 'any attack gives rise to non-pseudorandom keys'. I'm not sure what you want to say here. Perhaps 'Algorithms for generating pseudorandom keys allow for transparency in VRF key generation, ensuring that keys are not generated by an adversary'?
satisify -> satisfy
4.
I appreciate you don't want to repeat things from elsewhere, but I think it would add to the readability of the document if you added a subsection / appendix briefly recalling the RSASP1 and RSAVP1 primitives.
definition of I2OSP: personally I would say what both inputs are here.
5.
Under 'Type conversions': "integer a to to octet" -> "integer a to octet"
5.4.1.1.
Under step 6, "or H is EC point at infinity": I think you mean "or H is the identity of the elliptic curve group" (since you want this to be independent of the implementation choice here, and the point at infinity is not the identity for all forms of elliptic curves--especially relevant is that the identity on Edwards curves is (0,c), not a point at infinity!).
5.6.1.
-I think that the definition of (this) cofactor is not mentioned above anywhere.
-Under step 3, again "point at infinity" is used instead of the more general (and so always correct) "identity".
-Also fix the reference to "the point at infinity" in the paragraph following the steps 1-4.
6, paragraph 1: "effecient" -> "efficient"
6: link https://github.com/google/keytransparency/blob/master/core/vrf/vrf.go leads nowhere
7.1 "(e.g., if RSA is not permutation)". Do you mean not permutation-invariant?
7.1.2 "Diffie Hellman" -> "Diffie--Hellman"
7.2.
-"the the VRFs" -> "that the VRFs"
-for the second bullet point, do you have / know of a reference to point readers towards where this is worked out in more detail?
7.3 "the fact that nonce" -> "the fact that the nonce"
7.4 "primatives" -> "primitives"
7.5 subsection title is capitalized, unlike the other subsection titles in the document
7.7 first two bullets missing a full stop at the end.
Disclaimer: I haven't checked the calculations in the Appendix.