Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

the additional pseudorandomness property #28

Open
goldbe opened this issue Jun 21, 2017 · 1 comment
Open

the additional pseudorandomness property #28

goldbe opened this issue Jun 21, 2017 · 1 comment
Labels

Comments

@goldbe
Copy link
Collaborator

goldbe commented Jun 21, 2017

I just added in aaa83e5 discussion of VRF security property that is used by some applications, but not for any of the applications that we (NSEC5) or the CONIKS folks are using.

This is a different type of pseudorandomness than that one we use. The pseudorandomness we use only holds if VRF keys are generated in correct way.

What this is, is pseudorandomness that must hold even if the VRF keys are generated adversarially, as long as the VRF input alpha is unpredictable.

Specifically, suppose the VRF keys are generated by an adversary. Then, a VRF hash output beta should look pseudorandom to the adversary as long as (1) its corresponding VRF hash alpha is chosen randomly and independently of the VRF key, (2) alpha is unknown to the adversary, (3) the corresponding proof pi is unknown to the adversary, and (4) the VRF public key chosen by the adversary is valid.

An additional TODO is to figure out what checks are needed to make sure the adversarially-chosen VRF public key is valid.

@goldbe goldbe assigned goldbe and unassigned goldbe Jun 21, 2017
@goldbe goldbe changed the title the additional pseudorandomness property needed by algorand the additional pseudorandomness property Jun 21, 2017
@goldbe goldbe added the VRF label Jun 21, 2017
@goldbe
Copy link
Collaborator Author

goldbe commented Jun 28, 2018

@reyzin just talked to S. Gorbunov about this. What we had was not correct for algorand.
See commit 5aae74b

Here are some rough notes on how this might work.

Game one.
Suppose adv commits to key pk
Suppose alpha chosen randomly, made public
Adv computes VRF_proof_sk(alpha) = gamma
Should have that for most inputs alpha, you get a different gamma (ie gamma is unique)

Game 2:
Adversary commits to pk1 and pk2
Suppose that alpha chosen randomly, made public
Adv wins if VRF_proof_sk1(alpha) = gamma= VRF_sk2(alpha)

[Why algorand needs Game 2: to avoid the risk of all members of a malicious committee choosing a different pk that actually produces exactly the same VRF outputs. (collusion in the committee.)]

So now, if you want pseudorandomness in the output "even if the pk is chosen maliciously" (this needs to be formalized) then you change proof2hash so it becomes proof2hash(alpha, gamma, pk) . Currently we have proof2hash(gamma).

Notice that if (alpha, gamma, pk) is unique then by the randomness of the random oracle the output is well distributed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant