Conversation

Notices

1. Jeff Martin (cuchaz@gladtech.social)'s status on Wednesday, 14-Jun-2023 08:49:10 JST Jeff Martin

   Ooof! I think I'm finally done with the big refactor/rewrite of the JS side of Burger Identities! :blobcatcheer: 🍔

   Hopefully the high-level APIs should be damn near impossible to misuse now. And anything not high-level is hidden away (to the extent JS even allows), or otherwise clearly marked as not intended for applications to use.

   Also, Domain Separation for All The Things! :allthethings:

   Plus, Identities are separated into two different types now. "Personal" identities are for ... you know, people. "App" identities are for software and automated systems. They have different ways of protecting the private keys. Keys for personal identities are protected with passphrases. Keys for app identities need to be protected by access controls, since passphrases aren't a good fit there.

   And finally, Identities get a kind of sibling called an "Anonym". An anonym is kind of like a symmetric version of an Identity, but without any of the identity metadata, like a name. An anonym lets anyone who has a copy of it communicate securely with each other. Anoynms are also extremely compact (about 36 bytes), so they can be easily transmitted over just about any channel, like a URL, a QR code, or even a phone call! Just send someone an anonym (securely), keep a copy for yourself, and boom! Instant secure messaging channel. Useful for bootstrapping initial identity exchanges, or for anonymizing communications between identities.

   Now I just need to get the Rust side of the equation up to parity. Then I can finally use this stuff in my next project. :blobcatscience:

   • silverpill (silverpill@mitra.social)'s status on Wednesday, 14-Jun-2023 08:57:13 JST silverpill

     in reply to

     @cuchaz What about browser extension? Are you still working on it?

   • silverpill (silverpill@mitra.social)'s status on Wednesday, 14-Jun-2023 09:30:02 JST silverpill

     in reply to

     @cuchaz Cool. I need this kind of identity manager extension for my Fediverse project. So if you don't abandon it, I'll probably be one of the early adopters.

   • Jeff Martin (cuchaz@gladtech.social)'s status on Wednesday, 14-Jun-2023 09:30:03 JST Jeff Martin

     in reply to

     • silverpill

     @silverpill Yes! The browser extension will be need to be updated, but it's lagging behind the identity implementation at the moment.

     My short term plan is to work more on my P2P network using the new "App" identities which is all server stuff (in Rust) rather than client stuff. After that's done, I'll go back and update the browser side of things and work on more end-user facing stuff.

   • Jeff Martin (cuchaz@gladtech.social)'s status on Thursday, 15-Jun-2023 22:35:36 JST Jeff Martin

     in reply to

     • silverpill

     @silverpill Awesome! That sounds really great. Let me know what I can do to help.

   • silverpill (silverpill@mitra.social)'s status on Thursday, 15-Jun-2023 22:35:36 JST silverpill

     in reply to

     @cuchaz Basically, I need a signing tool. The web application should be able to send signing request to the extension, which in turn presents request to the user. When the user approves request, extension sends signed data back to the web app.

     I checked Burger docs, and it appears to be working this way, but I can't find documentation for its API. Is it available?

     Speaking of signature algorithms, I'm mostly interested in EdDSA, because several Fediverse servers already support EdDSA or planning to support it in the future.

   • silverpill (silverpill@mitra.social)'s status on Friday, 16-Jun-2023 02:40:21 JST silverpill

     in reply to

     @cuchaz

     >having the sender write ciphertexts and signed messages according to some other non-burger standard is not supported

     So this extension can't sign an arbitrary string and return raw signature? Would it be possible to add this functionality?

     For my use case, either raw signature is necessary, or a very specific kind of object representing signature and its parameters. I'm signing various JSON objects (mainly ActivityPub objects) and generation of a signature needs to be done in accordance with Verifiable Credential Data Integrity standard. Per this specification, cryptographic primitives are grouped into "cryptosuites", such as eddsa-2022, and while it is possible to create new cryptosuites, it is not recommended, and will hurt interoperability.

   • Jeff Martin (cuchaz@gladtech.social)'s status on Friday, 16-Jun-2023 02:40:22 JST Jeff Martin

     in reply to

     • silverpill

     @silverpill Sorry, the documentation is practically non-existent at the moment.

     But the way the extension works is: You generate your identity in the extension, which takes care of creating all the keys and such. Then you unlock your identity by entering your passphrase. While the identity is unlocked, you can send signing/encryption requests to it. They're all automatically approved while the identity is unlocked. If the identity is locked again, the requests are all denied.

     The actual format of the ciphertexts and signed messages is probably unique to burger identities. It's designed so that both sender and recipient should be using libraries that implement the standard for burger identities. ie, having the sender write ciphertexts and signed messages according to some other non-burger standard is not supported.

     The burger identity standard hasn't been written yet though. Right now, there are just two implementations of the library (JS and Rust) that have been written with standardization in mind, but that's as far as I've gotten.

     Hope that helps!