Most RISC ISA chip designs are missing instructions allowing for chaining to create vector results for biginteger operation used in cryptography. @lkct & David Calderwood will be talking on this topic at Silicon Salon 4, hosted by @BlockchainComns. š§µ[1/9] https://www.eventbrite.com/e/silicon-salon-4-tickets-558196208887
(https://twitter.com/ChristopherA/status/1653075273167020033)
Luke Leighton @lkct is a leading figure in open-source hardware design and has been working on Libre-SOC, an open-source RISC-V-based system-on-chip. David Calderwood is a seasoned software developer with experience in high-performance computing. [3/9]
(https://twitter.com/ChristopherA/status/1653075262026973184)
Without these instructions, computing cryptographic hashes and signatures can be slow and resource-intensive, limiting their practical use in certain applications. [2/9]
(https://twitter.com/ChristopherA/status/1653075277747228672)
Our previous three Silicon Salons have addressed a variety of semiconductor cryptography design and hardware issues, and all the presentations are available online. [6/9] https://www.siliconsalon.info/salons/
(https://twitter.com/ChristopherA/status/1653075276019150848)
This is exactly the sort of problem that our Silicon Salons are meant to address: the interface between cryptography and hardware design. How can the next generation of semiconductors meet cryptographic needs? [5/8]
(https://twitter.com/ChristopherA/status/1653075274697949184)
At the first Silicon Salon, this team presented about Libre-SOC http://libre-soc.org project. Itās an open-source RISC-V-based system-on-chip designed for efficiency and security. Learn more about their plans at: [4/9] https://www.siliconsalon.info/salon1/presentations/#libre-soc-video
(https://twitter.com/ChristopherA/status/1653075281631154176)
Sign up now to attend the virtual salon on Wednesday, May 3rd, starting at 9am PDT until noon. To join our discussion of the topic. [8/9] https://www.eventbrite.com/e/silicon-salon-4-tickets-558196208887
(https://twitter.com/ChristopherA/status/1653075279039037440)
Silicon Salon 4 will also have presentation from Andrew Poelstra of @Blockstream on preventing key exfiltration and @cramiumlabs on challenges and best-practices of open and transparent chips, followed by a facilitated discussion. [7/9]
(https://twitter.com/ChristopherA/status/1653075283266916352)
Support future dicussions about the intersections of cryptography, secure chip design, and the requirements for secure wallet hardware by becoming a GitHub sponsor of @BlockchainComns. [9/9] https://github.com/sponsors/BlockchainCommons
Replying to @Blockstream and @fischin4sats
There is a list of more apps & devices that support transaction signing via UR at https://github.com/blockchaincommons/gordian-developer-community#urs
(https://twitter.com/ChristopherA/status/1653460856393564161)
Andrew Poelstra from @Blockstream will discuss the anti-exfil protocol, which can protect your hardware wallet from key leakage [2/5]. https://twitter.com/ChristopherA/status/1651308417187999745
The @BlockchainComns Silicon Salon 4 event is tomorrow (Wednesday) at 9am PDT until noon. Weāre bringing together wallet developers and semiconductor manufacturers to talk about the requirements for the next-gen of chips. You can still sign up! [1/5] https://www.eventbrite.com/e/silicon-salon-4-tickets-558196208887 https://twitter.com/ChristopherA/status/1651619704585490432
(https://twitter.com/ChristopherA/status/1653460857760915456)
Luke Leighton @lkcl & David Calderwood will overview the missing RISC ISA instructions related to biginteger operations [3/5]. https://twitter.com/ChristopherA/status/1653075262026973184
(https://twitter.com/ChristopherA/status/1653460862127185922)
Join us to have your say in how the next generation of semiconductors is developed to serve the needs of hardware wallets & the rest of the cryptography field [5/5]. https://www.eventbrite.com/e/silicon-salon-4-tickets-558196208887
(https://twitter.com/ChristopherA/status/1653460860243787782)
Mark Davis of Cramium Labs @cramiumlabs will talk about the challenges of merging open source with semiconductor development [4/5]. https://twitter.com/ChristopherA/status/1651619720167292928
RT @lkcl: @ChristopherA interestingly i looked recently at OpenTITANās crypto-accelerator ISA recently: they added 256-bit regs and nestablā¦
RT @lkcl: @ChristopherA christopher thank you so much for hosting siliconsalon4 and for the opportunity to present. regarding āperformanceāā¦
RT @jamesscaur: 1/6 Got up at 4am today to attend #SiliconSalon4 by @BlockchainCommons today - well worth it!
Silicion Salons gather walleā¦
RT @jamesscaur: 2/6 First talk: Andrew Poelstra from @Blockstream discussed āanti-exfil,ā a new security method for hardware wallets to preā¦
RT @jamesscaur: 3/6 Second talk: Luke Leighton & David Calderwood from http://REDsemiconductor.com & http://Libre-SOC.org emphasized ā3-in 2ā¦
RT @jamesscaur: 4/6 Third talk: Dr. Mark Davis from @crossbarinc explored challenges & legal strategies for developing open-source securityā¦
RT @jamesscaur: 5/6 Big thanks to sponsors http://Bitmark.com, @chia_project, @crossbarinc, @FOUNDATIONdvcs, @proxy, @unchainedcom andā¦
RT @FOUNDATIONdvcs: @jamesscaur @chia_project @crossbarinc @proxy @unchainedcom @ChristopherA Thank you for all the hard work you all doā¦
RT @jamesscaur: 6/6 Sign up for future salons here: https://www.siliconsalon.info/salons/
Watch previous Silicon Salon presentations here: https://t.co/ā¦
(https://twitter.com/ChristopherA/status/1653949379718557696)
One big problem is trusting hardware! Andrew Poelstra discussed anti-exfil, a protocol preventing key exfiltration in hardware wallets by securing nonce generation for EC signatures. [2/13] https://www.siliconsalon.info/salon4/presentations/#andrew-poelstra-presentation
This weekās Silicon Salon 4 explored the challenges and offered some insights into solutions at the intersection of cryptography and semiconductor manufacturing. Explore the presentations by Andrew Poelstra, Red Semiconductor, and @cramiumlabs now! [1/13] https://www.siliconsalon.info/salon4/
(https://twitter.com/ChristopherA/status/1653949383384383488)
Mark is committed to pragmatic openness, emphasizing its potential benefits despite this complex IP landscape, and @CramiumLabs hopes to publish an outbound CERN-OHL-W (weakly reciprocal) license for their chip designs. [5/13] https://ohwr.org/project/cernohl/wikis/uploads/0be6f561d2b4a686c5765c74be32daf9/CERN_OHL_rationale.pdf
(https://twitter.com/ChristopherA/status/1653949382239346689)
Our last presentation was from Mark Davis of @CramiumLabs, offering useful insights about the process of the creation of semiconductor chips, why they cause IP problems, and other challenges to open silicon initiatives. [4/13] https://www.siliconsalon.info/salon4/presentations/#cramium-labs-presentation
(https://twitter.com/ChristopherA/status/1653949380972646400)
The other problem is that current semiconductors often donāt do what we need (which is why Silicon Salon is bringing manufacturers & customers together!) Red Semiconductor talked about a new technique for bigintegers in Power-ISA chips. [3/13] https://www.siliconsalon.info/salon4/presentations/#luke-leighton-david-calderwood-presentation
(https://twitter.com/ChristopherA/status/1653949387956170753)
Inspectability is a bigger issue than just cryptography. It impacts consumer privacy, protection against hardware-based attacks, and responsible AI development. [9/13] https://www.siliconsalon.info/salon4/#key-quotes-its-not-just-about-cryptography
(https://twitter.com/ChristopherA/status/1653949386869858304)
A lot of people want open silicon so that they can have inspectability, but silicon is actually very hard to inspect! [8/13] https://www.siliconsalon.info/salon4/#key-quotes-the-desire-for-inspectability
(https://twitter.com/ChristopherA/status/1653949385796116486)
Because open silicon has been a big issue since the first Silicon Salon, we held an extended discussion period on the topic and have highlighted some notable quotes (while abiding by Chatham House rules). [7/13] https://www.siliconsalon.info/salon4/#additional-discussionsāchat
(https://twitter.com/ChristopherA/status/1653949384655249408)
The fundamental question of open silicon, however, is: Whatās the purpose & desired outcome of open-source hardware in the semiconductor industry? Having an open schematic doesnāt guarantee the chipās manufacture. [6/13]
(https://twitter.com/ChristopherA/status/1653949392267907072)
This is important work! Help ensure it continues by becoming a @BlockchainComns sponsor. [13/13] https://github.com/sponsors/BlockchainCommons
(https://twitter.com/ChristopherA/status/1653949391202578433)
Our next Silicon Salon 5 is planned for July 26. Join wallet devs, semiconductor manufacturers & academics to advance cryptographic semiconductors. Subscribe for news: https://www.siliconsalon.info/subscribe/ Share your experiences & innovations. Propose a talk! https://www.siliconsalon.info/proposals/ [12/13]
(https://twitter.com/ChristopherA/status/1653949390166593538)
Thank you to everyone who participated in these discussions at this Silicon Salon! You can find complete presentations from all four Silicon Salon events to date on the Silicon Salon website. [11/13] https://www.siliconsalon.info/salons/
(https://twitter.com/ChristopherA/status/1653949389021536256)
For example, AI Safety work requires hardware security that doesnāt exist today. Addressing this challenge is vital to ensure responsible AI development. [10/13] https://www.siliconsalon.info/salon4/#key-quotes-its-not-just-about-cryptography
Replying to @BoredElonMusk
I looked into this. Doesnāt work because of huge liability: https://www.latimes.com/california/story/2022-09-30/judge-backs-fbi-beverly-hills-safe-deposit-box-raid
Replying to @ljxie
Decentralized Identity could make for a good documentary.
My take is that both freedom of assembly and freedom of speech also require a freedom to transact. If you canāt to purchase transportation to that rally or candidate forum, or help financially support a candidate, your democratic rights are infringed. š@RobertKennedyJr https://twitter.com/RobertKennedyJr/status/1654304821724299264
Replying to @dgwbirch and @RobertKennedyJr
Limits may be reasonable. Incentive design (transparency, accountability, taxes, quadratics, etc) for large scale abuse of systems may be reasonable. But at the scale from the vulnerable to the middle class? There we need to tip the balance towards freedom to transact.
Replying to @dgwbirch and @RobertKennedyJr
I guess Iām uncomfortable with absolutes. Every freedom has edges that violate freedoms of others. I believe in supporting the vulnerable & middle class and I also have the freedom to personally boycott doing business with ogliarchs and free riders.
Replying to @dgwbirch
Sure. But Iāve made progress in my advocacy with a wide variety of people and many venues. Wyoming, Buenos Aires, The Netherlands, and more: https://advocacy.blockchaincommons.com
Replying to @dgwbirch and @RobertKennedyJr
And you are accusing Kennedy of over-simplifying? I concur that it isnāt an absolute right, but neither is freedom of speech or any constitutional right or social contract. All are not simple. I just argue on balance to help the vulnerable and common people first.
(https://twitter.com/ChristopherA/status/1656728898619707393)
In theory, digital credentials have huge benefits: universities save on admin costs, and students can share their educational details when applying for work without employers having to reach out to registrars for confirmation. [2/12]
ššEncoding diplomas, transcripts, and other qualifications as digital credentials are very powerful, but they currently ignore privacy needs, which can make them dangerous. Todayās new @BlockchainComns article explains why. [1/12] https://www.blockchaincommons.com/articles/Dangerous-Educational-Credentials/
(https://twitter.com/ChristopherA/status/1656728902738513920)
Thereās a catch. Credentials have to be signed so that they can be verified and removing content will ruin a traditional signature. Thatās where hash-based elision comes in. [6/12]
(https://twitter.com/ChristopherA/status/1656728901748682752)
Worried about ethnic discimination over the location of your university? Just share their accreditation! Worried about age discrimination because you got your degree thirty years ago? Elide that! Only share whatās necessary. [5/12]
(https://twitter.com/ChristopherA/status/1656728900695887872)
To prevent these problems, a student should be able to elide unnecessary data from their credentials when presenting them for specific purposes. Itās the general policy of data minimization. [4/12] https://www.blockchaincommons.com/musings/musings-data-minimization/
(https://twitter.com/ChristopherA/status/1656728899659927553)
The problem is that digital credentials are data-rich, containing information that could lead to identity theft, and even absent that specifics that could lead to discrimination. [3/12]
(https://twitter.com/ChristopherA/status/1656728906819567616)
We also presented on the topic to the Verifiable Credentials for Education Task Force at W3C. [10/12] https://www.youtube.com/watch?v=0YvyhdwvvB0
(https://twitter.com/ChristopherA/status/1656728905632595969)
Read the full article for all of the details on how holder-based hashed elision works. [9/12] https://www.blockchaincommons.com/articles/Dangerous-Educational-Credentials/
(https://twitter.com/ChristopherA/status/1656728904646946816)
Thereās even a working example of this sort of holder-based hashed elision: Gordian Envelope. This type of functionality is why weāve been pushing the new data format. [8/12] https://www.blockchaincommons.com/introduction/Envelope-Intro/
(https://twitter.com/ChristopherA/status/1656728903724183552)
Data can be stored in a Merkle Tree, and then only the root hash needs to be signed. Data can be elided, but required hashes kept, allowing for continued verification. [7/12] https://en.wikipedia.org/wiki/Merkle_tree
(https://twitter.com/ChristopherA/status/1656728908614754305)
Help us secure the digital future with privacy and dignity! Support @BlockchainComns by becoming a patron today. [12/12] https://github.com/sponsors/BlockchainCommons
(https://twitter.com/ChristopherA/status/1656728907742314497)
Whether you use Gordian Envelope or not, we think that holder-based hashed elision is very important for the privacy and security of digital credentials going forward. Weāre at the start of this new revolution, and we want to make sure the foundation is firm! [11/12]
The EU has released the #CRA (Cyber Resilience Act) which may have a profound negative effect on open source security, as small companies (such as @BlockchainComns and many of our patrons) that contribute to free open source may be held to same liability as a for-profit products.
(https://twitter.com/ChristopherA/status/1657061801916526592)
āWe are not suppliers. All the people writing and maintaining these projects, we are not suppliers. We do not have a business relationship with all these organisations. We are volunteers, writing code and putting it online under these Licencesā https://softwaremaxims.com/blog/Not-A-Supplier
(https://twitter.com/ChristopherA/status/1657062445939298304)
āThe notional open source developer in Nebraska, thanklessly maintaining a vital small programā¦ canāt afford to secure their software to meet EU specifications. They often have no revenue. They certainly have no control over who uses their softwareā https://www.theregister.com/2023/05/12/eu_cyber_resilience_act/
(https://twitter.com/ChristopherA/status/1657062861896847362)
(https://twitter.com/ChristopherA/status/1657063170341748736)
āThe current formulation of the CRA interferes with almost every software development model other than the case of a single company developing the entire code-base behind closed doors and making periodical releases.ā @OSBAlliance to EU: https://ec.europa.eu/info/law/better-regulation/
(https://twitter.com/ChristopherA/status/1657064197874941952)
āthe requirement to āremediate vulnerabilities without delayā may undermine established practices of coordinated vulnerability disclosure and risk-based assessments from manufacturers on when to push and how to coordinate security updatesā @github to EU: https://ec.europa.eu/info/law/better-regulation/
(https://twitter.com/ChristopherA/status/1657065622663217153)
āIf the proposed law is enforced as currently written, the authors of open source components might bear legal and financial responsibility for the way their components are applied in someone elseās commercial product.ā @ThePSF https://pyfound.blogspot.com/2023/04/the-eus-proposed-cra-law-may-have.html
I pointed to the risks to ācognitive libertyā back in 2019, but I now consider the threat even greater. Today, parties leverage cognitive bias and network effects. Tomorrow, new tech, such as personal-health & eye-glance sensors, combined with AI tools, will make it more risky. https://twitter.com/ChristopherA/status/1168241485302702082
(https://twitter.com/ChristopherA/status/1657585261273022464)
Here is a collection of my links on the #CognitiveLiberty topic. Do you have any to add https://gist.github.com/ChristopherA/0bdaefeae88d9be8f342ead0b107cdcd
Replying to @DevonRJames
I donāt have enough knowledge about @Ledger implementation. They have not been involved so far in the Gordian Wallet community toward an open protocol for CSR āCollaborative Seed Recoveryā. @FOUNDATIONdvcs is involved as are many others. https://github.com/blockchainCommons/Gordian-Developer-Community/
RT @DevonRJames: Moreover, @Ledger could be more collaborative with the rest of the industry. A more open, cooperative approach could yieldā¦
Replying to @cronokirby
We have Shamir in our SSKR spec, a security reviewed implementation in C, and reference libraries and reference apps in multiple languages, and there is a new implementation for JavaCard. Multiple wallet companies are supporting it. https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/sskr-developers.md
Replying to @christophergdf and @iamtexture
I personally like VSS over SSS, and VSS is also useful for FROST multisig. But weāll well reviewed VSS cryptographic proposals, much less code, is scarce. So we use SSS in the SSKR spec today, but our plan is to upgrade it: https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/sskr-developers.md
Replying to @rmhrisk, @veikkoeeva, @ElTimuro, @tropicsquare and @peculiarventure
We are trying to do an open standard. https://github.com/BlockchainCommons/Gordian/blob/master/CSR/README.md
Replying to @rmhrisk, @veikkoeeva, @ElTimuro, @tropicsquare and @peculiarventure
The focus topic for our 3rd Silicon Salons was support for MPC in the chip. https://www.siliconsalon.info/salon3/ Weād love a proposal from your team to present a SS5: https://www.siliconsalon.info/proposals/
Replying to @rmhrisk, @veikkoeeva, @ElTimuro, @tropicsquare and @peculiarventure
The last two Silicon Salonās had great presentations about Open Silicon. Iāve also written some at https://www.blockchaincommons.com/musings/musings-open-silicon/
Replying to @lopp
We have some interesting thoughts on various scenarios using secret sharing as part of the custody scenario. This is on design: https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/SSKR-Sharing.md
Replying to @lopp
This is in dangers of secret sharing: https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/SSKR-Dangers.md
Replying to @lopp
Here is a fairly powerful combination of multisig and some secret sharing. https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/Scenario-Multisig.md
Replying to @lopp
ā¦there are no single points of compromise (SPoC) or single points of failure (SPoF) in that scenario, but still too hard for regular people to do, so we are working on CSR (Collaborative Seed Recovery) process can be initiated with a single QR code. https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/Scenario-Multisig.md
Replying to @lopp
Longer term we want to move from SSS to VSS, which has some advantages, and can be useful in combination with FROST multisig. Just awaiting some maturity of cryptographic specs and code.
Replying to @cuilleog and @matthew_d_green
Only businesses are subject to GDPR.
RT @matthew_d_green: The EU Council is continuing to debate a law that would require communication providers to scan all communications, poā¦
Replying to @technologypoet
At @BlockchainComns weāve been working closely with multiple wallet vendors in the Gordian Developer community on open designs for Collaborative Seed Recovery https://github.com/BlockchainCommons/Gordian/blob/master/CSR/README.md. Some problems also require open silicon, thus also we hist Silicon Salon.ā¦
Replying to @BanklessHQ and @P3b7_
Replying to @BanklessHQ and @P3b7_
What is interesting about this solution that uses a standards-based SSKR for secret share sharding is that you canāt shard your key on your #LedgerWallet until you prove that you have a backup of the key. No backdoor to the seed is required, it just verifies the two seeds match. https://twitter.com/jonf3n/status/1650922639941042176
Replying to @AbsoluteGnosis, @Ledger_Support, @DPDegen88 and @zkstorm_
An alternative architecture is that you can shard your keys to SSKR without a firmware change if you prove possession of a backup. This reduces attack surface. Seeā¦ https://twitter.com/ChristopherA/status/1658965253596786688
Replying to @paulsalis, @adietrichs and @sassal0x
Replying to @technologypoet and @NilsCodes
Replying to @ryanberckmans
Notably, if you want a more community standards approach for sharding (and more choice) you donāt need new firmware to shard with SSKR. And coming soon is Collaborative Seed Recovery which gives you many more options, including safer integrations with multisig. https://twitter.com/ChristopherA/status/1658965253596786688
Thereās been a lot of controversy over @Ledgerās new recovery service, which will shard your seed out to third-parties for storage. Why? In large part because we didnāt expect seeds to ever leave the Ledger device. [1/11] https://twitter.com/Ledger/status/1658513310541545491
(https://twitter.com/ChristopherA/status/1659031686297042944)
As it turns out (as all hardware wallet designers already know), all it requires is a signed firmware update, and seeds can go wherever they want. Why?ā¦ [2/11]
(https://twitter.com/ChristopherA/status/1659031721210433537)
The problem is that no existing SE chips can do secp256k1 (the curve used by Bitcoin & Ethereum) natively and safely in semiconductor logic. This isnāt an issue with Ledger; itās an issue with all current chips used by wallets today. [4/11]
(https://twitter.com/ChristopherA/status/1659031719822102529)
Ledgerās hardware is based on a Secure Enclave (aka āSEā). Thatās is what generates and stores your private keys. [3/11] https://www.ledger.com/academy/security/the-secure-element-whistanding-security-attacks
(https://twitter.com/ChristopherA/status/1659031724532314113)
In other words, the public might have had the expectation that keys werenāt going to ever leave the Ledger, but that expectation is actually impossible to support today, because keys already have to leave the most trusted part of the Secure Enclave to be used! [6/11]
(https://twitter.com/ChristopherA/status/1659031723118841859)
This means that in order to do secp256k1, a SE has to hand a key off to a code execution process in the SE or to an MPU. Thatās what opens the doors for doing unexpected things with that key ā things that most didnāt expect from a personal hardware wallet. [5/11]
(https://twitter.com/ChristopherA/status/1659031730240761856)
Based on presentations over the last year, weāll actually be able to fulfill the promise that seeds canāt leave a device, something thatās impossible today! And we can still offer future-proofing to enable new approaches like multisig & zk-proofs [9/11] https://www.siliconsalon.info/salons/
(https://twitter.com/ChristopherA/status/1659031728932151299)
This is why @BlockchainComns hosts #SiliconSalon. We have been working with chip manufacturers such as @cramiumlabs, @tropicsquare, and RED Semicondutor. They recognize the need for new chips that support cryptography natively in silicon logic. [8/11] https://www.siliconsalon.info
(https://twitter.com/ChristopherA/status/1659031727602532352)
There are some advantages of this architecture āĀ flexibility & future proofing. Doing cryptography using updatable code means as standards change, new curves are needed, the hardware wallet can adapt. [7/11]
(https://twitter.com/ChristopherA/status/1659031733197737984)
This is essential work to bridge between the cryptographic engineers, wallet developers, and semiconductor designers. Financially support @Blockchaincomns to ensure that we can continue to protect your keys and self-sovereignty! [11/11] https://github.com/sponsors/BlockchainCommons
(https://twitter.com/ChristopherA/status/1659031731771682816)
If you are interested in this topic, join the #SiliconSalon community so that you can attend our next salon and talk about the future of cryptographic semiconductors. [10/11] https://www.blockchaincommons.com/subscribe.html#silicon-salon
One of my concerns with the new @Ledger Recover service is that they appears to be sharding via Shamirās Secret Sharing, but doing so in a proprietary way and possibly in a naive fashion. We donāt know, as it is not open source. [1/11] https://twitter.com/Ledger/status/1658518313083731974
(https://twitter.com/ChristopherA/status/1659061359278174210)
Casaās Jameson @lopp has written even more about a whole slew of other dangers. [4/11] https://blog.keys.casa/shamirs-secret-sharing-security-shortcomings/
(https://twitter.com/ChristopherA/status/1659061357764046848)
Eavesdropping, trojan-horsing, or just faking authentication for the seed holder can all lead to a stolen seed! The process of restoring the shares, reconstruction device is a serious single point of compromise. And then there are concerns with how you distribute shares! [3/11]
(https://twitter.com/ChristopherA/status/1659061319004454913)
Obviously, Shamirās Secret Sharing has a long history and is widely used, but it also has real drawbacks. As weāve written at @BlockchainComns, one of the biggest dangers comes in reconstruction. [2/11] https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/SSKR-Dangers.md
(https://twitter.com/ChristopherA/status/1659061362063200258)
There are ways to mitigate problems with Shamir, such as using a multsig and then using Shamir to protect some of the keys. Even if your reconstruction is attacked, thatās just one key! For instance see this scenario: [6/11] https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/Scenario-Multisig.md
(https://twitter.com/ChristopherA/status/1659061360620351488)
As with concerns over the ability for a seed to leave a Ledger, this is a problem that isnāt focused just on Ledger. It just exposes a larger problem in the world of resilience of digital assets. [5/11]
(https://twitter.com/ChristopherA/status/1659061367264145409)
Fundamentally, Shamirās Secret Sharing isnāt bad, but it has definite limitations and concerns that must be mitigated. Weād love to see more discussion of that in projects like our CSR & Ledger Recover (and more usage of those mitigation strategies).[9/11] https://github.com/BlockchainCommons/Gordian/tree/master/CSR
(https://twitter.com/ChristopherA/status/1659061365762568192)
Our āDesign of SSKR Scenariosā doc talks more about distribution strategies, but even with good sharding strategies, Shamirās Secret Sharing can still be fraught with problems. [8/11] https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/SSKR-Sharing.md
(https://twitter.com/ChristopherA/status/1659061363535396866)
The SSKR library at @BlockchainComns also supports multilevel sharding, which can offset some concerns about who you give shares to [7/11] https://github.com/BlockchainCommons/bc-sskr#-blockchain-commons-sskr
(https://twitter.com/ChristopherA/status/1659061370154024960)
Support SSKR, multilevel secret-sharing, and other #SmartCustody initiatives by becoming a Blockchain Commons patron. Even $20 a month from individuals is helpful to demonstrate support so that we can get others to fund our work. [11/11] https://github.com/sponsors/BlockchainCommons
(https://twitter.com/ChristopherA/status/1659061368702771207)
Managing #SmartCustody so that digital assets remain safe is one of the major initiatives at @BlockchainComns. [10/11] https://www.smartcustody.com/index.html#the-articles
(https://twitter.com/ChristopherA/status/1659031734548328448)
A related thread on Shamirās Secret Sharingā¦ https://twitter.com/ChristopherA/status/1659061319004454913
Perhaps my biggest problems with the @Ledger Recover program as itās currently conceived are that itās not open and itās not independent. Users will be locked into decisions that Ledger made, for its own business reasons. [1/12] https://twitter.com/Ledger_Support/status/1658824425192521728
(https://twitter.com/ChristopherA/status/1659068940226805760)
From what weāre heard, the Recover share holders will actually be requiring KYC checks. That doesnāt just go across our Principles, but also the general ethos of Bitcoin! [3/12]
(https://twitter.com/ChristopherA/status/1659068890553651201)
The Gordian Principles from @BlockchainComns suggest that digital assets should be held in a way thatās independent, private, resilient, and open. Ledger Recover increases resilience, but thatās it. [2/12] https://github.com/BlockchainCommons/Gordian#gordian-principles
(https://twitter.com/ChristopherA/status/1659068944970395648)
The @BlockchainComns Collaborative Seed Recovery (CSR) system has some similar ideas to Ledger Recover, but itās founded on the principle that the asset holder gets to decide exactly how their key is protected. [5/12] https://github.com/BlockchainCommons/Gordian/blob/master/CSR/README.md
(https://twitter.com/ChristopherA/status/1659068942500106240)
But the core issue here isnāt necessarily those decisions, but the fact that Ledger is locking you into them. And maybe encourage other wallet developers like @spiralbtc to lock you into their own different choices. [4/12]
(https://twitter.com/ChristopherA/status/1659068955368263680)
You decide your personal privacy needs. You can shard and store all the shares yourself. Based on your personal risk profile, you decide if you want help from with third-parties or to get help from family or close friends. Or pay a high-end service you trust. You decide. [8/11]
(https://twitter.com/ChristopherA/status/1659068952952324097)
There are even some wallet companies talking about backing up shards from other wallet companies! Our open source Collaborative Seed Recovery architecture offers many ways for us to cooperate to benefit us all. [7/12]
(https://twitter.com/ChristopherA/status/1659068948309221376)
You want to back up some of your shares on a metal plate, such as the innovative QR plates using SSKR shards from @SeedHammer? Thatās OK! Your assets, your choice. [6/112]
(https://twitter.com/ChristopherA/status/1659068958128082944)
For instance, a community member took our open source SSKR code to create a Ledger app that can shard your seed without needing a firmware upgrade that risks adding new attack surface: [10/12] https://twitter.com/ChristopherA/status/1658965253596786688 https://twitter.com/ChristopherA/status/1658965253596786688
(https://twitter.com/ChristopherA/status/1659068956756541440)
Weāve worked with @Ledger before. They were one of our original sponsors for @BlockchainComnās #SmartCustody program. Weād love to work with them again, so that the community can work through some of the problems with Ledger Recover. [9/12]
(https://twitter.com/ChristopherA/status/1659068961194115086)
Support our community efforts to give you a choice. Become a patron of Blockchain Commons! [12/12] https://github.com/sponsors/BlockchainCommons
(https://twitter.com/ChristopherA/status/1659068959189274624)
Are you a wallet developer? We have a Gordian Developers meeting the first Wednesday of every month as the center of our collaboration. Feel free to join us! [11/12] https://www.blockchaincommons.com/subscribe.html#gordian-developers
(https://twitter.com/ChristopherA/status/1659061652472627200)
Another related thread on being free to make your own choices: https://twitter.com/ChristopherA/status/1659068890553651201
RT @eastdakota: This is an extremely bad local court decision. It inherently violates basic principles of the Rule of Law and the sovereignā¦
(https://twitter.com/ChristopherA/status/1659302287901335554)
The first obstacle to multisig is that our experience is that they are too complex for normal usage. We know that even professionals using one of our well-tested secure scenarios find the hour it takes is too long. [2/13] https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/Scenario-Multisig.md
At @BlockchainComns we believe that multisig offers superior #SmartCustody over using Shamirās Secret Sharing (which was recently implemented as part of @Ledger Recover). Unfortunately, there are few practical alternatives to sharding a seed, and multisig is complex. š§µā¦ [1/13] https://twitter.com/ChristopherA/status/1659061319004454913
(https://twitter.com/ChristopherA/status/1659302290522775559)
The advantage of Shamir Secret Sharing cryptography is it can be used for any secret, not just private keys. Thus it can also be used to secure Ethereum keys, NFTs, other blockchains, etc. But you do still have to be very careful: [4/13] https://twitter.com/ChristopherA/status/1659061357764046848
The second obstacle is that true multisig really is available only for Bitcoin. There are multi-account smart contracts that resemble cryptographic multisig, but they donāt offer the same level of hardware security, and each transaction costs gas. [3/13] https://shivanisb10.medium.com/multisig-contracts-in-ethereum-ffd8a1a9a025
Finally, CSR works to improve usability by getting things started with a simple QR code and ensure consent by asking for permission step by step. No need to find some specific button in yet another wallet UX, the flow takes you through the scenario to successful completion [8/13]
CSR also allows for more secure storage of shares through SSKRās support for multilevel sharding [7/13] https://github.com/BlockchainCommons/bc-sskr#-blockchain-commons-sskr
CSR addresses some of the limitations of Shamirās Secret Sharing by allowing multi-modal, automated authentication, by implementing progressive recovery revelation, and by recognizing reconstruction as the most vulnerable point in the process. [6/13] https://github.com/blockchaincommons/gordian-developer-community
Our CSR (Collaborative Seed Recovery) open source project in the Gordian Developer community at @BlockchainComns is meant to make Shamirās Secret Sharing more accessible and safer while keeping the door open for a future that includes multisig. [5/13] https://github.com/BlockchainCommons/Gordian/blob/master/CSR/README.md
However, CSR (and more than that CKM) still lies in the future. If you are a wallet customer, demand your vendor to get involved with CSR. If you are a dev interested in working with us on these initiatives, join the Gordian Developer community. [12/13] https://www.blockchaincommons.com/subscribe.html
Then, if a hardware device maker makes a change that it can share out your seed, that might be OK. Because one single seed can no longer be a single point of compromise. (And ensuring itās not a point of failure also remains important for resilience!) [11/13]
Our ultimate goal is to evolve CSR into Collaborative Key Management (CKM), which will take advantage of Multi-Party Computing (MPC), so that the seed on your device combines with others on the net to dynamically reconstruct your key as needed. [10/13] https://github.com/BlockchainCommons/Gordian/blob/master/CKM/README.md
We hope to see the first commercial implementation of CSR this year, but ultimately itās just a stepping stone. In the future CSR will be able to adapt to new techniques that include VSS, MuSig2 and FROST. [9/13]
We also need your financial support ā it is through sponsors like these that weāve been able to get to where we are today: https://www.blockchaincommons.com/sponsors.html Become a patron of @BlockchainComns to help ensure these possibilities become reality! [13/13] https://github.com/sponsors/BlockchainCommons
A thread on Shamir vs multisig, and why the open source work toward Collaborative Seed Recovery (aka CSR) by the wallet devs that are part of the Gordian Wallet Community is important: https://twitter.com/ChristopherA/status/1659302287901335554
A thread on Shamir vs multisig, and why the open source work toward Collaborative Seed Recovery (aka CSR) by the wallet devs that are part of the Gordian Wallet Community is important: https://twitter.com/ChristopherA/status/1659302287901335554
A related thread on Shamir vs multisig, and why the open source work toward Collaborative Seed Recovery (aka CSR) by the wallet devs that are part of the Gordian Wallet Community is important: https://twitter.com/ChristopherA/status/1659302287901335554
Replying to @Rob1Ham and @BlockchainComns
We definitely like miniscript as an important future, but found the limited support for it in core and various libraries a challenge. We did some experiments with time-locks in https://github.com/BlockchainCommons/mori-cli using bdk, but it was clunky. However, bdk & rust-bitcoin are getting better.
Replying to @OneSirMeow
I know that @cramiumlabs is thinking about putting both an ARM and RISCV cpu in addition to their SE in a single chip solution. I like the heterogeneity, but until it more specs are released not sure if will be able to do this. But maybe!
Replying to @btc_21mil
Iām anticipating that there may be some hardware wallets deploying open source Collaborative Seed Recovery within a year. The problem with hardware is lead time due to manufacturing, but Iām hoping some dev kits out this year to polish ease-of-use.
Replying to @DEFICHAINFACTOR and @Ledger
I am intrigued by the double SE approach. Iām more in general concerned about details of authenticity of the firmware. @FOUNDATIONdvcs does a great job explaining how they do it in a video from Silicon Salon 2: https://youtu.be/ZCZ_dwui-X0
Replying to @gimly_io, @Ledger, @Tangem and @casparroelofs
Weād love a proposal for a presentation! https://www.siliconsalon.info/proposals/
Replying to @dstadulis
We hoping to transition in future to VSS as you can verify shares without needing to risk restoration. Keeping an eye out as those libraries mature. In particular the one used by FROST is interesting. Long-term MCP, but current chips need acceleration to do that.
I also presented at an IACR meeting about adding secp256k1, and notably got no objections from people like Bernstein (25519 designer). But no one wanted to fight the battle. There are still good reasons why k1 is better than 25519 especially for multisig. https://twitter.com/csuwildcat/status/1659533242603536388
Replying to @csuwildcat
Here is my presentation to IETF IACR at the 2017 CFRG meeting on using #secp256k1 in international standards:
RT @ChristopherA: Here is my presentation to IETF IACR at the 2017 CFRG meeting on using #secp256k1 in international standards:
RT @mer__edith: āThere are real measures that the Government can take to protect children & I sincerely hope that Parliament will look to aā¦
RT @arthistorynews: In other words, the need for art historians to have to pay excessive fees for images, to further knowledge of *publiclyā¦
Replying to @oscpacey
Keys that are truly āsilicon lockedā (my term, not a standard name) exist on chips today, but you canāt do the common blockchain cryptographic operations with them. In particular they canāt do secp256k1 public keys, derivations, and signatures, and longer term other operationsā¦
Replying to @oscpacey
Once you can do the latter, you donāt need to recover the silicon-locked secret, create a quorum with others for a collaborative key. If one device is lost or compromised it is not a single point of failure.
Replying to @oscpacey
There are also some ideas being played around with that would allow seed to be encrypted with a common chip key (more likely a derivative of it) such that another device of the same type can be a backup of that child key. Lots of interesting challenges to that though.
Replying to @oscpacey
There are also multi-chip SOC (system on a chip) ideas where each chip is heterogeneous, and there is a secure/hardened backplane that allows the chips to collaborate. See #SiliconSalon videos about ARM + RISCV on a SOC from @cramiumlabs.
Replying to @rileyphughes and @TimoGlastra
How much of the problem was BBS+ proofs? Hash-based elision isnāt perfect but addresses a lot of use cases: https://github.com/BlockchainCommons/Gordian/blob/master/Envelope/Use-Cases/Educational.md
Replying to @decentralgabe, @rileyphughes and @TimoGlastra
BBS+ proofs are a powerful anti-correlation tool, but are inherently complex to implement. First, it uses pairing crypto, which is not inherently bad but is comparatively new (and quite different) than elliptic curves. Then it is also zk-proof, which also complicated.
Replying to @decentralgabe, @rileyphughes and @TimoGlastra
The combo of pairing based zk-proof allows for a proof of knowledge of an undisclosed signature, which supports anti-correlation of signatures & public keys. But this is not intuitive to implement. Hash-based elision (aka redaction) is much easier, but does have limitations.
Replying to @decentralgabe, @rileyphughes and @TimoGlastra
My proposal is that all signed data at rest needs to support minimal disclosure and some measure of anti-correlation, and hash-based elision meets the 80/20 test. If you need more, then add BBS+ or other methods once you understand the use case and threats.
Replying to @decentralgabe, @rileyphughes and @TimoGlastra
I would love more people to support Gordian Envelopeās architecture for this, but I do ask that we begin to demand hash-based elision in the future for signed data at rest whether it be ISO mDOC, IETF SD-JWT, or LD Merkle Disclosure Proof. A MUST not MAY or SHOULD.
Replying to @decentralgabe, @rileyphughes and @TimoGlastra
You donāt need anything but a hash algo like sha256 to do hash-based elision. Salting can address most anti-correlation requirements (but not for signatures). But often you need correlation for signatures, as that is their whole point. https://youtu.be/OcnpYqHn8NQ
Replying to @decentralgabe, @rileyphughes and @TimoGlastra
If you are more tech oriented and understand CLI, thus video is a deeper (but still an introduction) to Gordian Envelope https://youtu.be/K2gFTyjbiYk
Replying to @decentralgabe, @rileyphughes and @TimoGlastra
And this one even deeper into species of elision. https://youtu.be/3G70mUYQB18
Replying to @decentralgabe, @rileyphughes and @TimoGlastra
Iād need to understand the use case to say if BBS+ās ability to obfuscate a signature is required for any particular use case. But even then, trying to shoehorn it to solve all data-minimization problems when 80% donāt require it is overwhelming.
Replying to @decentralgabe, @rileyphughes and @TimoGlastra
I like the concept and we have designed the Gordian architecture to support it, but focused on fundamentals first. 80/20 rule & āthe perfect is the enemy of the goodā. When I helped lead the design of TLS, perfect forward secrecy was hard, but in the architecture.
Replying to @decentralgabe, @rileyphughes and @TimoGlastra
In my opinion that there are certain things that Gordian Envelopes can do easy, like inclusion proofs and herd privacy, that BBS+ proofs canāt. There are also other interesting blinded signature and zk approaches to these problems emerging that work better with multisig futures.
Signed šļø! TO FEDERAL CONGRESS OF BRAZIL, TO PROTECT THE TERRITORIAL RIGHTS OF INDIGENOUS PEOPLES - Sign the Petition! https://chng.it/mHysqgk9 via @Change https://twitter.com/ev/status/1663265869420703746