Download as PDF, PPTX
![[a][b][c]
ZKP
Create Circuit (logical gates)
Usually thousands of them
Convert each gate to R1CS
3 (sparse) vectors that satisfy a simple equation (dot products)
R1CS to Arithmetic Quadratic Program
dot product -> polynomials
Polynomials to EC points
+ using params from trusted setup
zkSNARK
01
02
03
05zkSNARK proof generation
04](https://image.slidesharecdn.com/nyccordameetup15052018-180517202103/75/Cryptographic-Agility-in-Corda-19-2048.jpg)
More Related Content
Similar to Cryptographic Agility in Corda
![zkStudyClub: Zero-Knowledge Proofs Security, in Practice [JP Aumasson, Taurus]](https://cdn.slidesharecdn.com/ss_thumbnails/2022-secsnark-220331171948-thumbnail.jpg?width=640&height=640&fit=bounds)
Cryptographic Agility in Corda
- 1.
- 2. Blockchain-inspired: the best attributesof Bitcoin / Ethereum, but no cryptocurrency (that we know of) Enterprise grade: built specifically for financial markets Data privacy: transactions shared on a need-to-know basis Consensus: achieved at individual deal level, rather than system level. Supports a variety of consensus mechanisms Regulator-focused: design directly enables regulatory/supervisor observer nodes Smart contract: strong link between legal prose and smart contract code Easy integration: reuses existing java developer skills making integration with bank systems easy and safe Open-source, financial-grade blockchain that records, manages, and executes institutions’ legal, business, and financial agreements in perfect synchrony with their counterparties. Corda’s ecosystem consists of 200+ of the world’s leading institutions, technology companies and Fortune500 companies.
- 3. What do youknow about cryptography? 02 01 03 04 Digital Signatures & Certificates RSA, Elliptic Curves, DH Encryption AES, 3DES Hash Functions MD5, SHA Advanced primitives SGX, Zero Knowledge Proofs P@$$Words
- 4. A maze ofoptions DLT Privacy Zero Knowledge Proofs Multi-Party Computation Ring Signatures Homomorphic Secure Enclaves (SGX) Key Randomisation Merkle Trees (tear-offs) Mixing Protocols Graph Pruning Features Crypto Agility Post-Quantum Anonymity Key Exchange (TLS) Deterministic Key Gen. Random Entropy PKI Cert. Revocation Threshold Signatures Attribute-based Sig. ID-based / Timed-Release Searchable Enc.
- 5. 4 Privacy-preserving features AnonymousKeys One-time random keys Transaction tear-offs transaction parts are only visible to designated parties Graph Pruning On request, prune and re-issue a liquid asset onto the ledger with a new reference field. Transactions are not globally broadcasted TLS secure communication
- 6. Cryptographic Agility VsPluggability Agility Pluggability Multiple signature schemes Support secure and tested cryptographic schemes. The introduction of new algorithms over time will require a global upgrade of all nodes. Custom solutions Allow custom/external cryptographic implementations. Signing a transaction with an algorithm that is not a part of the base specification would result in a transaction being considered invalid by peer nodes. The set of signature schemes supported forms a part of the consensus rules for a DLT network.
- 7. Size keys signatures Security maturity side-channel +features Code Java/Kotlin implement. Compatible legacy code certification Speed key gen sign verify HSM storage cloudavail. 06 01 02 0304 05 Desired Features • There is NO single algorithm to meet all the criteria! • A serious DLT should be able to survive a sophisticated attack in the future. • Combine corporate and community requirements. • Balance security Vs speed Vs convenience What is the ideal algorithm?
- 8. Speed Vs Risk Riskaxis Speedaxis Low speed High speed HighriskLowrisk Risk factors 1. recent attacks 2. unexplained/insecure params 3. quantum resistance Speed factors 1. Key and param generation 2. signing 3. verification ECDSA R1 RSA 3072 SPHINCS EdDSA ECDSA K1 ECDSA BRAINPOOL zkSNARK BN_128
- 9. Quantum secure No advancedmaths Hash-based only Short private key Post-quantum secure Slow signing Big public key & sigs No native HSM support Not TLS compatible Sphincs-256 Key Lifetime Compatibility Standardized NIST recommended TLS support Fully compatible Fast verification Cloud HSM support Slow keygen/signing Big keys & sigs Non-Determin. keys RSA 3072 Azure HSM Community Short keys/sigs Standardized TLS support Deterministic keygen Explained curve HSM support Slow verification ECDSA K1 Bitcoin friendly Certified Short keys/sigs Standardized NIST recommended TLS support HSM support Slow verification Unexplained curve ECDSA R1 FIPS Certified Signature schemes State of the art Short keys/sigs Safe-curve ed25519 Fast implementation Side-channel secure Deterministic sigs HSM support Not standardized yet Speed EdDSA
- 10. Corda TLS schemes RSA ECDHE ECDSA ECDHE RSA DHE Serverkey RSA Recommended when server uses RSA keys Server key ECDSA Recommended scheme when ECDSA K1 or R1 keys are used Server Key RSA Only iff ECC should be avoided AES128_GCM SHA256 Ephemeral key forward secrecy
- 11. Node 1 EdDSA 25519 Node2 ECDSA R1 Node 3 Sphincs-256 Notary Cluster ECDSA R1 Node 4 ECDSA K1 Node 5 RSA 3072
- 12. Key Recommendations I useAzure: Pick RSA if you want to benefit from Azure’s secure Vault! I need speed: Use EdDSA, it’s also considered one of the most secure schemes in our days! I own an HSM: Pick ECDSA as it is more performant than RSA. Prefer EdDSA if your HSM supports it. FIPS certified? Use ECDSA R1 or RSA. Quantum Threat? Pick Sphincs-256, but please note it is slower & signatures are bigger.
- 13. Crypto library Define asupported signature scheme, here ECDSA R1
- 14. Signature scheme identification •Scheme type is attached to the signature. • Key type also helps on identifying the signature type if there is no Metadata attached. • Works for Composite keys as well. Adding metadata to signatures
- 15. I don’t trust algorithms B, Cand E I don’t trust algorithms A and E A B I don’t trust algorithms A, D and E C I don’t trust algorithms B, C and E D Challenge – a globally agreed scheme I don’t trust algorithms A, B C and D E
- 16.
- 17. Applications of ZKP ZKP Netting:offsetting the value of multiple positions or payments due to be exchanged between two or more parties Membership: prove you are part of a group, without revealing your identity Account Balance: prove that your account has enough available balance for this transaction Ownership: prove that you own a private key + + + Contract Execution: an arbitrary program/logic/contract has been executed correctly Sealed-Bid Auctions / E-voting / KYC
- 18. Homomorphic Signature Given sig(x)and sig(y) can compute sig(x•y), without knowing x and y 02 04 Ring Signature Cannot determine which of the group members' keys was used to sign 01 Witness Indistinguishability Cannot tell which “witness” the prover actually used 03 Zero Knowledge Proof of Knowledge The statement consists only of the fact that the prover possesses the secret information 05 Zero Knowledge types Multi-Party Computation Parties jointly compute a function over their inputs while keeping those inputs private
- 19. [a][b][c] ZKP Create Circuit (logicalgates) Usually thousands of them Convert each gate to R1CS 3 (sparse) vectors that satisfy a simple equation (dot products) R1CS to Arithmetic Quadratic Program dot product -> polynomials Polynomials to EC points + using params from trusted setup zkSNARK 01 02 03 05zkSNARK proof generation 04
- 20. zkSNARK zero-knowledge Succinct Non-interactiveARgument of Knowledge Non-interactive Prover does not interact with the verifier. This enables signature transfer and thus practical for DLTs and Blockchains Succinct Signature (proof) size is 288 bytes and independent on the problem size Argument Whenever a computation is executed and reaches to a result, you could think of it as a statement/argument! Zero Knowledge Prover convinces a verifier that a statement is true without revealing any further information SCIP Succinct Computational Integrity & Privacy
- 21. RSA sig: 3072bits zkSNARK (BN128) cons Verify Proof Gen ZK Proof size: 2304 bits ZK public params: 911MB ECC sig: 512 bits Trusted setup “toxic-waste”: backdoor to forge signatures. Not PQ-secure Should change to zkSTARK/Ligero? Slow Proof Generation Not practical for some applications, yet. i.e., high-frequency trading ~100 bits of security 448-bit field (or larger) needed (regulations? evolution plan?) Special Elliptic Curves pairing friendly (standardised?) SLOW due to multiple fast Fourier transforms & elliptic curve operations (exponentiations)
- 22. Size keys proofs CRS Security maturity side-channel pq Code api, UI, UX JVM,C, +++ Compatible Legislation mobile friendly Speed prove verify optimise HSM witness storage cloud avail. 06 01 02 0304 05 Desired Features • There is NO single algorithm to meet all the criteria! • A serious DLT should be able to survive a sophisticated attack in the future. We need an evolution plan. • Combine corporate and community requirements. • Balance security Vs speed Vs convenience What is the ideal algorithm?
- 23. A quick recap •Skylake+ chips have SGX: Encrypted memory, Sealed off software, Remote attestation Pretty good for DLT • NO need to train developers on how to properly write ZKP-friendly contracts • No arithmetization or special math theory • Practically unlimited contract-code logic/size. • Fast, easier evolution plans
- 24. SGX concern: Side-channels “Weare well aware side-channels are a problem for SGX, but the work to remove them inside compilers looks quite similar to the work needed to convert imperative programs into circuits” "and we think a lot of the work and experience can be shared between the two efforts"
- 25. Two ways How canDLT use ZKPs? 1. Fully automatic privacy for all transactions The holy grail! What we will use SGX for until a generic and easy to use ZKP framework is well-reviewed, user friendly and tested. 2. Ad-hoc tactical integrations What is realistically possible today (if you accept all the caveats) p25.
- 26. Arithmetization • Proofs demonstratesolutions to systems of algebraic constraints • But equations are not how programmers think of problems • Sometimes, very hard to express even simple business logic • We cannot expect non-specialists to write R1CS, Modularization? • We need a well-defined api (ZKProof Implementation track)
- 27. Fully automatic ZKP •A high quality constraint compiler, so ordinary programmers can write and maintain proof systems • A trustworthy initialization mechanism/protocol (if required) • Ideally, post-quantum ZKP • Backwards compatible deployment strategy • Extensive peer-review: side-channel, fake/unrealistic benchmarks, wrong proofs, EC curve/params security, is it actually ZKP? composition strategies and caveats p27.
- 28.
- 29. Quantum computers Symmetric Encryption Largerkeys Hash Functions Larger output ZKP zkSNARK (the end) use zkSTARK / Ligero (practical?) RSA, ECC, DSA, DH game over Shor’s algorithm – Factorization and Dlog is easy! Estimated risk that RSA & ECC will break: 15% by 2026 50% by 2031 even if this never happens, the underlying “potential” threat affects decisions. Grover’s algorithm – Symmetric ciphers in danger as well. Finds with high probability the unique input to a black box function. We should double the size of keys/output.
- 30. Quantum computers -current state 01 RSA (3072): ~ 6000 qubits ECC (256): ~1500 qubits Google Bristlecone 72 qubits largest number claimed to be factored 200,099 One-time: hashed keys ZKP: zkSTARK, Ligero Sigs: Sphincs, Ring-LWE KE: New Hope pure quantum algorithms 02 04 qubits + gates (billions of gates) 10,000 times faster D-Wave announced 2000 qubits quantum computer. But, targeted to AI ^ Controversial ^ 03 05
- 31. Crypto-Research 02 03 04 01 60% 75% ..% 100%Extend Sphincs –Blockchained Signatures Faster and Shorter signatures Key management & HSMs Cloud / Dedicated Hash and Fact-locking Smart Contracts Advanced Privacy Ring Sig / Dual Auth / ZKP Side-channel security research e.g. EdDSA RowHammer One-Time Anonymous keys SGX efficient (re)attestation