Excerpts from the MIT Kyber patent license: https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/selected-algos-2022/nist-pqc-license-summary-and-excerpts.pdf — What do you think @kemitchell @lifeext @brianbehlendorf?
It looks like NIST has selected Kyber https://pq-crystals.org/kyber/index.shtml for post-quantum encryption, and has negotiated a royalty-free patent license by the parties if usage conforms to the standard (ala ECDSA in the 90s). But I doubt it will pass muster with the open source community.
We have submitted “The Envelope Structured Data Format” to the IETF as an Internet-Draft, and it is now available at https://datatracker.ietf.org/doc/draft-mcnally-envelope/
ABSTRACT: The envelope protocol specifies a structured format for hierarchical binary data…
…focused on the ability to transmit it in a privacy-focused way. Envelopes are designed to facilitate “smart documents” and have a number of unique features including easy representation of a variety of semantic structures, a built-in Merkle-like digest tree, …
…deterministic representation using CBOR, and the ability for the holder of a document to selectively encrypt or elide specific parts of a document without invalidating the document structure including the digest tree, or any cryptographic signatures that rely on it.
Replying to @BitMEXResearch
You might also want to look at Gordian Envelope, which also uses hash trees for privacy. https://twitter.com/ChristopherA/status/1598787610805436416
RT @317070: Did you know, that you can build a virtual machine inside ChatGPT? And that you can use this machine to create files, program a…
RT @btnaughton: @317070 this is mind-bending
Trust Architecture is one of my major goals at @BlockchainComns. I want to develop systems that help people to create trust on the internet. I’ve started a new series of articles on the topic called “Musings of a Trust Architect”. [1/8] https://www.blockchaincommons.com/musings.html
My first Musings article talks about Progressive Trust. How do we make online trust match real-world experiences, where we gradually get to know someone and expose little bits of knowledge about ourselves as we do? [2/8] https://www.blockchaincommons.com/musings/musings-progressive-trust/
This is very different from traditional trust mechanisms on the internet, which depend on authentication or require that you be in a trusted zone. Generations of hackers have shown these defenses are easily defeated. [3/8]
Progressive trust is going to require technologies like data minimization, elision/redaction, escrowed encryption, and various cryptographic selective disclosure techniques. Cryptography can support how we really grow trust over time! [6/8] https://www.blockchaincommons.com/introduction/Envelope-Intro/
Real trust requires support for the autonomy and agency of all parties. That’s where Progressive Trust comes in: trust as we experience in real life. Read my article for why. [5/8] https://www.blockchaincommons.com/musings/musings-progressive-trust/
Newer zero-trust mechanisms have come to depend on trust frameworks or trust registries. They have many problems, including centralization, inconsistent updates, and the possibility of third-party bias. [4/8]
To support this type of work at Blockchain Commons, please become a sponsor. [8/8] https://github.com/sponsors/BlockchainCommons
How else do online models fail real-life models of trust? What other technologies can help them to succeed? I’d love to hear your feedback too! Trust architectures are ever-evolving! [7/8]
Replying to @rot13maxi, @geyserfund and @BtcpayServer
We do accept bitcoin at https://btcpay.BlockchainCommons.com — Thanks! 🙏
Replying to @rot13maxi, @geyserfund and @BtcpayServer
I don’t know if you’ve seen our Bitcoin projects, like Learning Bitcoin from the Command Line, our #SmartCustody book for self-sovereign assets, and our work towards better multisig wallets. All available on Github.
Replying to @mbrandolph
I wrote in 2006 an article on my adventures on being an angel investor. Like you, I was good at identifying good startups. The challenge is that when they are successful, the deck is stacked against the angel. http://www.lifewithalacrity.com/2006/01/on_being_an_ang.html
But the newest RWOT paper talks about more than that. How do we manage cross-border, multi-jurisdictional usage, especially with modern data protection laws such as the GDPR? [3/9]
Prescriptions have always been a great use case for self-sovereign identity. You should be able to control your prescriptions. You should be able to move them without being beholden to pharmacists and corps. We published this at #RWOT2 in 2016 [2/9]. https://github.com/WebOfTrustInfo/rwot2-id2020/blob/master/final-documents/physician-patient-relationship.pdf
I am pleased to see the second paper from our #RWOT11 The Hague today: “Linking Credentials with Data Exchange Agreements through Secured Inclusive Interfaces,” by a team led by @philippePage1 & @lalchandran 🧵[1/9]. https://twitter.com/RWOTEvents/status/1603840047559475200
It’s an interesting paper! Take a look! [8/9] The pdf at https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/data-exchange-agreements-with-oca.pdf or markdown https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/data-exchange-agreements-with-oca.md
Also, that VERIFIABLE CREDENTIALS might be less relevant than VERIFIABLE INFORMATION [7/9]
The paper’s conclusions: Naked VCs do not scale, they must be dressed! [6/9]
Fortunately, we’ve also seen lots of technical development since 2016. The RWOT paper talks about that with Data Exchange Agreements (DEXA) and introduces an Overlay Capture Architecture (OCA). [5/9]
How do we ensure that prescriptions (and other data) remains accessible to all people? [4/9]
Sign up to get notification of future Rebooting Web of Trust Events at our web page! [9/9] https://www.weboftrust.info/subscribe/
There is new functionality available now for Gordian Envelopes to support the ability to produce a set of edits (a “diff”) that will transform one Envelope’s graph data into another Envelope. 🧵[1/8]
https://youtu.be/kXk_XTACqh8
In addition, every Envelope diff is also itself an Envelope. Thus the edits can be authenticated by signing, encrypted, or anything else that Envelopes can do. [4/8] https://youtu.be/3G70mUYQB18
This diffs function offers support for both semantic equivalence and structural identicality and supports diffs between Gordian Envelopes that contain elided and encrypted data. Docs: [3/8] https://github.com/BlockchainCommons/BCSwiftSecureComponents/blob/master/Docs/11-DIFFING.md
Gordian Envelopes are a new type of “smart document” to support the storage, backup, encryption & authentication of data, with explicit support for Merkle-based selective disclosure. Here is a high-level introduction: [2/8] https://www.blockchaincommons.com/introduction/Envelope-Intro/
Contact me if you’d like to become involved in the future of Gordian Envelopes. You can also support the future development of interoperable specs like these by becoming a Blockchain Commons supporter! [8/8] https://github.com/sponsors/blockchaincommons
We’d like to be able to offer both state-based “convergent replicate states” or non-state-based “commutative replicated” CRDTs. This is a 2023 stretch goal for Blockchain Commons. [7/8]
By itself, Envelope Diff is most useful for debugging & docs; but it also demonstrates the plausibility of future support of more complex functionality for Gordian Envelopes, such as use in CRDT (Conflict-Free Replicated Data Type) scenarios. [6/8] https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type
We also support Envelope diff in the latest version of the Envelope-CLI reference implementation: [5/8] https://github.com/BlockchainCommons/envelope-cli-swift/blob/master/Docs/9-DIFFING.md
I have been worried for some time that the plans to reorganize the W3C international standards org, which has a very weird legal 3-party setup, would go awry. It looks like the reorg may be failing, as MIT is not cooperating. https://twitter.com/robinberjon/status/1603834995830816769
RT @kanzure: “Towards a more open secure element chip”
1) blag https://www.bunniestudios.com/blog/?p=6606
2) discuss https://news.ycombinator.com/item?id=34061511
3) join workshop…
Replying to @HirokiSayama
Feels like some organizational principles are missing, from the human side (like Ostrom’s Commons, participatory orgs, group size issues) to the computer side (such as decentralization, computer consensus, incentive design, etc)
Replying to @HirokiSayama
https://github.com/ParticipatoryOrgs/Participatory-Organizations-Overview-and-Taxonomy
Replying to @HirokiSayama
Replying to @HirokiSayama
Lots more links available, not so organized.
Replying to @VictorTaelin
Have you reached out to Russell O’Connor of @Blockstream? His Simplicity language is also based on a lambda calculus.
Replying to @cronokirby and @MarciIlunga
We do that on our submission of Gordian Envelope to IETF. Instead of specifying a particular AEAD, we specify an AEAD in general first. Then we show us cha-cha poly. See section 3.2.3 of https://www.ietf.org/id/draft-mcnally-envelope-00.html#section-3.2.3
Another collaborative paper has been published by @RWOTEvents from this fall’s #RWOT11 event in The Hague: “Verifiable Issuers & Verifiers” from a team led by @manusporny [1/7] https://twitter.com/RWOTEvents/status/1605020738431291392
But it turns out there is a real need for Verifiable Verifier lists too. Who is allowed to see what credentials? How can we automatically minimize what any person can see? There are use cases for that too! [4/7]
To explain the need, the paper outlines medical, employment, financial, and (yes) educational use cases for Verifiable Issuer lists. They support accreditation, certification, supply-chain issues and more. [3/7]
The need for Verifiable Issuers is old. In the past, governments and other agencies have kept lists of Trusted Registries that could issue credentials — such as universities, who can issue diplomas. However, digitally sharing lists of Verifiable Issuers is quite new. [2/7]
If you’d like to be part of the discussion, take a look at the full paper. [7/7] https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/verifiable-issuers-and-verifiers.pdf
After being incubated at RWOT11, “Verifiable Issuers & Verifiers” was introduced for discussion at the 35th #IIW, and the authors suggest that future technical specs could be overseen by the W3C CCG [6/7] https://w3c-ccg.github.io
The “Verifiable Issuers & Verifiers” paper also covers prior art and unified requirements and offers a concrete data model and plenty of examples. It’s an impressively comprehensive overview of the topic! [5/7]
We learned over 20 years ago to minimize the reuse of keys, and Bitcoin perfected this. Thus I’m quite concerned that new projects have lost site of this design principle. Same with ENS names and other protocols that don’t support key rotation (or at least ratcheting). https://twitter.com/pippellia/status/1605970280580632578
RT @pippellia: Using simple public keys like your identity is not a new idea, but it doesn’t work.
Or rather, it works until it doesn’t wo…
RT @pippellia: Encrypting every message with the same private key for a lifetime is not a good idea.
Thus, this 👇 is the paradox of #Nostr
RT @pippellia: In Keet, the process of mapping a peer to its public key is done through a Distributed Hash Table (DHT).
In this table, It…