Collaborative Seed Recovery Group Meeting Agendas

## <img src="https://i.imgur.com/QyDl5nK.png" width=192 height="192"> ## Collaborative Seed Recovery Group Meeting (2012-10-13) --- ### <img src="https://i.imgur.com/QyDl5nK.png" width="256" height="256"> What is Blockchain Commons? * We bring together blockchain, Web3 and digital identity stakeholders to collaboratively develop interoperable infrastructure. * We design decentralized solutions where everyone wins. * We are a neutral "not-for-profit" that enables people to control their own digital destiny. --- ## Chatham House Rules Apply * _"participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s) ... may be revealed."_ * We may record presentations and Q&A for YouTube, but not business discussions. * We do make private recordings for member who miss a session. Just ask. --- ## Agenda (2012-10-13) * Introductions & Reintroductions * ___Since Last Session…___ * Rebooting Web of Trust * Presented as advance readings: * [Collaborative Seed Recovery](https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/collaborative-seed-recovery-csr.md) * [Elision, Redaction, and Noncorrelation in Smart Documents](https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/elision-redaction-correlation-smart-documents.md) * [Selective Correlation](https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/draft-documents/selective-correlation.md) became collaborative paper * MVA of `envelope-cli` nearing feature complete * [Playlist of demo videos](https://www.youtube.com/playlist?list=PLCkrqxOY1FbooYwJ7ZhpJ_QQk8Az1aCnG) * [Existence proofs](https://github.com/BlockchainCommons/BCSwiftSecureComponents/blob/master/Docs/09-EXISTENCE-PROOFS.md) and [video](https://www.youtube.com/watch?v=LUQ-n9EZa0U&list=PLCkrqxOY1FbooYwJ7ZhpJ_QQk8Az1aCnG&index=11) * Other progress reports? --- ## Agenda (continued) * @WolfMcNally walk-through an MVP for CSR * Goal review: Public CSR Servers EoQ4? * Discussion on next steps: * Is our MVA sufficiently complete? * SCIDs * Event receipts * Scripting ("Smart signatures") * Security architecture review? * What languages does the community need to port envelopes and SSKR to? * Do we want to pursue W3C or IETF standardization * Future Collaborative Key Management plans? * Other agenda items --- # END OF SESSION --- ## Agenda (2012-08-07) * ___Since Last Session…___ * Seed Tool 1.6 Alpha TestFlight (iOS & Mac) * first Crypto-Requests for UR:Envelope, using updated spec * testing reference seeds/keys/derivations/output descriptors * Silicon Salon 2 for Sept. 14th * Secure Boot, Firmware, Updates & Supply Chain --- * This Session: * ***Bitmark*** Scenario Question * MVA for Gordian Architecture: * Opinionated Cryptographic Choices * Non-Correlation, Elision (Redaction & Reference), CID Features * Updated Request/Response Architecture for Envelopes * … --- * Updated Request/Response Architecture for Envelopes * No longer called crypto-request * Distributed Function Calls * We need to create spec & reference for sharding and encrypted shares * We need to understand your auth scenarios * Swimlanes? --- ## MVA for Gordian Architecture * What is MVA? * Minimum Viable architecture * Focuses on larger strategy, ecosystem viability & future expansion * But then constrains them for release * Think of it as "Future Proofing" an MVP --- #### Cryptographic Choices for MVA * **Organization:** Suites * Carefully combine opinionated decisions about cryptography * Not kitchen sink! (Avoid footguns!) * Initially useful constraints for test code using in: * envelope-cli app in Swift * Security Architecture Review release --- ### MVA Suite * Data Size: 256 * Hash: Black3 * AEAD cipher: ChachaPoly * Curve: Secp256k1 * Signing: Schnorr * Sharding: Shamir Secret Sharing * Non-Correlation & Selective Disclosure: Redaction Hash Tree * Data Architecture: Directed Graph --- * **Data Size:** 256 Bit (when possible) * Input & ouput values are indistinguishable * Hashes, public keys, other values * non-correalation techniques are easier * see CID * 256 bit matches Bitcoin security * CON: Not 256 now * nonce for chacha, Schnorr sig is 2x (512 bytes) --- * **Hash Function:** BLAKE3 * 256 bit version. * New, but worthwhile! * Allows streaming, incremental updates * BLAKE2 is mature, BLAKE3 is well-supported * CON: No hardware acceleration --- * **AEAD Cipher Function:** ChaChaPoly * ChaCha20 cipher + Poly1305 MAC * Modern, robust, IETF standard, overcomes AES weaknesses * Faster in software than AES * CON: But is it too strong? * ? Proxy to test ? * CON: No hardware acceleration * Alt: AES-XTS (block cipher but tweakable, used by Apple's FileVault) --- * **Curve:** Secp256k1 * Familiar, well-tested with Bitcoin * Curve25519 is not multisig safe * Curve25519 has other inconsistencies * CON: Not IETF/NIST/chip, etc. --- * **Signing:** Schnorr (x-only) * Also new, but worthwhile! * Public keys aren't embedded in signature * Signatures are 512 bits * plus 256 for x-only public key * Features for future: * FROST quorum, adapter sigs, etc.) * CON: No silicon support (yet!) * CON: x-only signatures may bite us in future for some advanced protocols. TBD. --- * **Sharding:** Shamir with Groups * Shamir's Secret Sharing is mature & limitations well known * SSKR implementation also allows groups * Groups offers scenarios with increased resilience against collusion * Blockchain Commons SSS & SSKR have security review * VSS is emerging, and plan to integrate in SSKR, but feels unstable today. --- * **Non-Correlation & Selective Disclosure:** Redaction Hash Tree * Data can be redacted with a hash tree (using BLAKE3) * Not just issuers, but holders can redact information * Alternative ZKPs (often complex and use new curves like BLS) * CONS: some cryptographic questions on variable salts and malleable signing --- * **Data Architecture:** Directed Graph * Data storage is triples (subject / predicate / object) * Deterministic CBOR address canonicalization problems of JSON * Schema-less, but Envelopes are designed with option for quads (i.e. RDF and schemas are possible) * Should overcome historic problems such as RDF * CON: Purist RDF (JSON-LD) proponents may object to no requirement schema --- ### Other Possible Suites * optimized for constrained hardware * for instance AES-XTS, SHA-256, ECDSA) * zk-optimized * (Ciminion AEAD, Poseidon hash, BLS12-381 or Halo curves, Pairing signature, BBS+ redaction) --- # Old Agendas --- ## Agenda (2012-08-03) * Since Last Session * Refactored [BCSwiftSecureComponents](https://github.com/BlockchainCommons/BCSwiftSecureComponents) out of [BCSwiftFoundation](https://github.com/BlockchainCommons/BCSwiftFoundation) * Update [envelope test vectors](https://github.com/BlockchainCommons/BCSwiftSecureComponents/blob/master/Docs/7-ENVELOPE-TEST-VECTORS.md) & [SSKR Test Vectors](https://github.com/BlockchainCommons/BCSwiftSecureComponents/blob/master/Docs/8-ENVELOPE-SSKR-TEST-VECTORS.md) * Proposal for [envelope-cli](https://hackmd.io/@wolfmcnally/SyWqN9Dp5) * Bitmark Demo * Proxy SSKR Doc Page * Wolf overview envelop tool * Questions * Blake3 vs SHA256 * Priorities?