Cryptographic Assumptions
Cryptographic Assumptions and Security Model
This document outlines the cryptographic assumptions underlying the security of the Roru Protocol.
Assumptions Overview
Core Assumptions
Primary Assumptions:
Discrete logarithm problem hardness
Hash function security
Commitment scheme security
Signature scheme security
Zero-knowledge proof security
Discrete Logarithm Problem
Assumption
DLP Assumption: Given a cyclic group G with generator g, and an element h = g^x, it is computationally infeasible to find x.
Application: Used in Pedersen commitments and elliptic curve cryptography.
Security Level: 128-bit security (BLS12-381 curve)
Hash Function Security
Assumptions
Collision Resistance: It is computationally infeasible to find two different inputs that hash to the same output.
Preimage Resistance: Given a hash output, it is computationally infeasible to find an input that produces that output.
Second Preimage Resistance: Given an input, it is computationally infeasible to find a different input with the same hash.
Hash Functions Used:
SHA-256: For Merkle trees
Poseidon: For zero-knowledge circuits
Blake2b: For various hashing needs
Commitment Scheme Security
Pedersen Commitments
Hiding Property: Given a commitment C = vG + rH, it is computationally infeasible to determine v without knowledge of r.
Binding Property: It is computationally infeasible to find two different (v, r) pairs that produce the same commitment.
Assumption: Discrete logarithm problem hardness in the elliptic curve group.
Zero-Knowledge Proof Security
zk-SNARK Assumptions
Knowledge Soundness: If a prover can generate a valid proof, they must know a valid witness.
Zero-Knowledge: The proof reveals no information about the witness beyond what is proven.
Assumption: q-SDH (q-Strong Diffie-Hellman) assumption for Groth16.
Security Level: 128-bit security
Signature Scheme Security
ECDSA/EdDSA Assumptions
Unforgeability: It is computationally infeasible to forge a signature without the private key.
Non-repudiation: A signer cannot deny having signed a message.
Assumption: Discrete logarithm problem hardness.
Random Oracle Model
Model Assumption
Random Oracle: Hash functions behave like truly random functions.
Application: Used in security proofs for various protocols.
Limitation: Real hash functions are not truly random, but this is a standard assumption.
Trusted Setup
Setup Assumption
Trusted Setup: The setup ceremony is performed honestly without trapdoors being leaked.
Mitigation:
Multi-party computation
Public ceremony
Verifiable setup
No trusted setup (if possible)
Security Levels
Bit Security
128-bit Security: Standard security level
Discrete log: ~384-bit keys
Hash functions: 256-bit output
Proofs: 128-bit security
256-bit Security: Higher security level
Discrete log: ~768-bit keys
Hash functions: 512-bit output
Proofs: 256-bit security
Quantum Resistance
Current Status
Classical Security: All assumptions hold against classical computers.
Quantum Security:
Hash functions: Generally quantum-resistant
Lattice-based: Quantum-resistant alternatives
Current curves: Not quantum-resistant
Future Considerations: Migration to post-quantum cryptography when needed.
Conclusion
Cryptographic assumptions provide:
Security Foundation: Basis for security
Risk Assessment: Understanding limitations
Future Planning: Migration strategies
Trust Model: What to trust
Security Guarantees: What is proven
Understanding assumptions is essential for security analysis.
Last updated