--- title: VRF description: Verifiable random function theme: gaia size: 16:9 _class: lead class: invert paginate: true backgroundColor: #000000 marp: true math: katex header: IOTA Foundation --- ![bg invert:100% left:40% 80%](https://cryptologos.cc/logos/iota-miota-logo.svg?v=014) # [VRF](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-vrf-15) # 2022-11-11 --- ## API ## $\texttt{VRF}=(\texttt{KeyGen},\texttt{Prove},\texttt{Hash},\texttt{Verify})$ $\texttt{VRF}.\texttt{KeyGen}() \mapsto (sk, pk)$ $\texttt{VRF}.\texttt{Prove}(sk, \alpha) \mapsto \pi$ $\texttt{VRF}.\texttt{Hash}(\pi) \mapsto rnd$ $\texttt{VRF}.\texttt{Verify}(pk, \alpha, \pi) \mapsto 2$ --- ## Security properties* ## - uniqueness: $\forall pk, \alpha \;\exists!\pi \implies \texttt{VRF}.\texttt{Verify}(pk, \alpha, \pi)=1$ - collision resistance: $\forall sk, \alpha_1 \neq \alpha_2 \implies rnd_1 \neq rnd_2$ - pseudorandomness ($\texttt{VRF}.\texttt{Verify}$ -- distinguisher): fix $sk$ ($sk$ and $\pi$ are **unknown**!), $\forall \alpha \implies rnd$ "looks" random - unpredictability under malicious key gen (for **leader selection**!): fix $sk$, $pk$ chosen by attacker, $\alpha \;\text{random} \implies rnd \;\text{random}$ \* hard to compute, in addition to NIZKP properties, non-malleability --- ## ECVRF ## - $sk, sk\cdot \textcolor{lightgreen}{G}$ -- keypair - $rnd = H_{rnd}(sk\cdot \textcolor{red}{H_{\alpha}(\alpha)})$ - $\pi = \texttt{DlEq}\{(\textcolor{lightgreen}{G}, \textcolor{red}{H_{\alpha}(\alpha)}, sk\cdot \textcolor{lightgreen}{G}, sk\cdot \textcolor{red}{H_{\alpha}(\alpha)}; sk):\\\quad \texttt{DL}_{\textcolor{lightgreen}{G}}(sk\cdot \textcolor{lightgreen}{G}) = \texttt{DL}_{\textcolor{red}{H_{\alpha}(\alpha)}}(sk\cdot \textcolor{red}{H_{\alpha}(\alpha)})\}$ Variants of $\texttt{DlEq}$ proofs: - Schnoor preimage proof (eg. ed25519 "compatible") - pairing-based proof (eg. BLS "compatible") --- ## ECVRF-EDWARDS25519-SHA512-ELL2 ## - Curve25519, Ristretto subgroup(?) - Elligator2 for hash-to-curve $H_{\alpha}$ - SHA512 for hash-to-rnd $H_{rnd}$ - nonce_gen, challenge_gen, salt, domain separation - point/int (de)serialization - verify: canonical encoding, low-/mixed-order points - **third-party non-malleability** - **adversarial prover** --- ## What's next? ## - Distributed VRF: - Async network - Robustness - Threshold property - ADKG - Decentralized Random Beacon: DVRF + state --- ## Thanks ## Questions?
Last changed by  
 
Protocol Team
Specing Iota Day and Night
231

Read more

Untitled

12/1/2022
VRF & ASM

VRF verifiable random function for random sortitioning medium on algorand ietf draft VRF algorand impl BLS signature for VRF? VRF RFC draft-15 API

11/7/2022
Publicly verifiable multi-user public key encryption

Introduction Public key encryption (PKE) is a standard tool used in many protocols with two parties -- sender and receiver. Sender uses receiver's public key to encrypt a secret message and receiver uses her private key to decrypt it. In modern (decentralized) protocols there's a third party -- verifier. Verifier acts as an arbiter, she verifies that both parties (sender and receiver) follow the protocol correctly. When there's a need for privacy a PKE scheme does not offer the verifier to do her job -- to get access to the encrypted message privacy property must be sacrificed. To overcome this issue there's publicly verifiable public key encryption (PVPKE). In such a scheme the sender encrypts a message and proves certain useful properties about it such that the verifier can verify the proof (ie. that the properties do actually hold for the encrypted message without decrypting it) and the receiver can decrypt the message as usual. Some useful properties about encrypted text might include the following: proof of decryptability, ie. that the receiver can indeed decrypt the message (and not claim that she can't, without revealing her private decryption key); proof of correct encryption, ie. that the sender has encrypted a valid message (and not some garbage).

6/30/2022
PVSS succinct proofs

How to aggregate PVSS proofs nicely

2/3/2022
Read more from Protocol Team
Published on HackMD