Skip to content
This repository has been archived by the owner on Oct 11, 2024. It is now read-only.

VRF uniqueness is violated #567

Closed
gdbelvin opened this issue Apr 26, 2017 · 0 comments
Closed

VRF uniqueness is violated #567

gdbelvin opened this issue Apr 26, 2017 · 0 comments
Assignees
Labels

Comments

@gdbelvin
Copy link
Contributor

gdbelvin commented Apr 26, 2017

Thanks to Sharon Goldberg and Leonid Reyzin for finding the error.

An attacker can choose a different rs when computing s. Rather than
s = H2(m, [r]G, [r]H), the attacker computes
s = H2(m, [a]G, [b]H) and claims that the VRF output is
[(b-a)/s + k] H rather than [k]H and t = a-sk.

This checks out because the verifier checks that
s == H2(m, [t]G + [s]([k]G), [t]H + [s]VRF).
s == H2(m, [a]G, [b]H)
Because
[t]G+[s]([k]G) = [a]G.
[t]H + [s]VRF = [a-sk]H + [b-a+sk]H = [b]H.
The attack succeeds at producing a non-unique value for VRF.

http://eprint.iacr.org/2012/577.pdf Page 4:

Goldberg and Reyzin (March 2017) discovered that if one does not hash the unique identifier when computing the challenge of the proof system, the uniqueness of the VRF from DDH assumption is violated. Therefore, when using the VRF, it is important to hash the unique identifier as well.

@gdbelvin gdbelvin added the bug label Apr 26, 2017
@gdbelvin gdbelvin self-assigned this Apr 26, 2017
gdbelvin added a commit to gdbelvin/keytransparency that referenced this issue Apr 26, 2017
Fixes google#567

VRF uniqueness could be violated because the VRF output itself was not
included in the the computation of `s`, the commitment to the VRF and
zero knowledge proof.
gdbelvin added a commit to gdbelvin/keytransparency that referenced this issue Apr 26, 2017
Fixes google#567

VRF uniqueness could be violated because the VRF output itself was not
included in the the computation of `s`, the commitment to the VRF and
zero knowledge proof.
gdbelvin added a commit to gdbelvin/keytransparency that referenced this issue May 11, 2017
Fixes google#567

VRF uniqueness could be violated because the VRF output itself was not
included in the the computation of `s`, the commitment to the VRF and
zero knowledge proof.
gdbelvin added a commit to gdbelvin/keytransparency that referenced this issue Jun 15, 2017
Fixes google#567

VRF uniqueness could be violated because the VRF output itself was not
included in the the computation of `s`, the commitment to the VRF and
zero knowledge proof.
gdbelvin added a commit to gdbelvin/keytransparency that referenced this issue Jun 20, 2017
Fixes google#567

VRF uniqueness could be violated because the VRF output itself was not
included in the the computation of `s`, the commitment to the VRF and
zero knowledge proof.
gdbelvin added a commit to gdbelvin/keytransparency that referenced this issue Jun 20, 2017
Fixes google#567

VRF uniqueness could be violated because the VRF output itself was not
included in the the computation of `s`, the commitment to the VRF and
zero knowledge proof.
gdbelvin added a commit to gdbelvin/keytransparency that referenced this issue Jun 21, 2017
Fixes google#567

VRF uniqueness could be violated because the VRF output itself was not
included in the the computation of `s`, the commitment to the VRF and
zero knowledge proof.
gdbelvin added a commit that referenced this issue Jun 21, 2017
* Ensure VRF uniqueness

Fixes #567

VRF uniqueness could be violated because the VRF output itself was not
included in the the computation of `s`, the commitment to the VRF and
zero knowledge proof.

* Reorder vrf to match CONIKS paper

* Add TODOs for migrating to NSEC5

* Use binary.Write to write fixed with integers

* Add test vectors

* Adjust notation for code clarity
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant