Yarmo - keyoxide

Keyoxide Project Update #5

2021-06-29T14:52:10+00:00

An update for all.

Accessibility</h2>
The latest 3.1.0 release of keyoxide-web</a> greatly improves accessibility and ensures that it works nicely together with screen readers.
To make sure the implementation of accessibility features was as thorough as possible, it was first ran through a series of automated tests, namely Lighthouse</a> and WAVE</a>, both giving Keyoxide respectively a 100% accessibility score and 0 accessibility errors on every page.
While automated tests are a decent start, nothing beats feedback from the actual target audience: good ol' human beings.
After posting a message</a> on the Keyoxide fediverse account (keyoxide@fosstodon.org</a>) to call for help from people who use accessibility tools like screen readers, I received plenty of feedback about little quirks that went undetected by the automated tests. These were all addressed and fixed.
So I can now gladly confirm that the Keyoxide website should be WAI-AA compliant, meaning all text has a contrast ratio higher than 4.5:1, all links and images are appropriately labeled for screen readers and even the profile pages can be navigated by keyboard alone.
I once again thank the people that have provided the invaluable feedback without whom the result of my efforts would have proven unsufficient.
If you find more quirks and/or annoyances, please do file an issue on the code repository</a> so it can be fixed as quickly as possible.

#keyoxide on IRC</h2>
Keyoxide was just about to request a channel on freenode when sadly, well, that happened.
So now, it is with delight that I can now invite you all to our #keyoxide channel on the great libera.chat</a> network. In addition to our Matrix room, this is one more place where we can hang out and discuss the future of identity on the internet. And many other things.
And yes, of course I have already proven my identity on IRC using the IRC guide on Keyoxide</a>.
Signing off</h2>
For all your questions and suggestions, be sure to join the conversation in the Keyoxide matrix room</a> or the #keyoxide channel on libera.chat</a>. Or raise an issue on Codeberg.org</a>. All contributions (including PRs!) are welcome.
As always, the source code is available at the Codeberg.org repo</a>.
All work on Keyoxide is possible thanks to donations, the project stands against VC funding. If you feel like Keyoxide is a step in the right direction for netizens worldwide, please become a patron</a> and help the project do its part in the global fight against the internet corporations.
Until next time,
Yarmo

Keyoxide Project Update #4

2021-05-04T17:52:10+00:00

The update I have been looking forward to for months.
Keyoxide 3.0.0</h2>
Every day I work on Keyoxide, I learn more and gain a deeper understanding of how powerful this Decentralized OpenPGP-based Identity verification actually can be. And as we are nearing the first anniversary of the Keyoxide project, I realized all the new ideas and major improvements—most suggested by the community—were being held back by the previous implementation of the code, restricted by my earlier understanding and imagination.
It was time not for a number of superficial additions and fixes, but for a big overhaul of the core code which would then cause a chain reaction of bugs to be fixed and features to be added or improved.
To illustrate what is new in this version, here's my Keyoxide profile</a>.
Visuals</h3>
Ok, let's do start superficial, though. Keyoxide 3.0.0 has a shiny new look. I hope you will agree with me that that was much needed. The previous design of the website was made before I even implemented the concept of decentralized proofs.
The new and cleaner design has eliminated most of the clutter and puts all the emphasis on what is important: the identity claims.
Server side rendering</h3>
Thanks to the class-based approach of the doip.js library (version 0.12.*)</a>, Keyoxide will now do most of the mundane work on the server and let the browser finish the process of identity verification. So who does exactly what now?

The server will try and find the public key associated with the profile to be generated</li>
The server will parse the identity claims stored inside the public key</li>
The server will match the identity claims to the known library of service providers</li>
The server will render the profile page, including the yet-to-be-verified identity claims, and send it to the browser</li>
The browser will parse the yet-to-be-verified identity claims and verify them</li> </ul>
Not only is the website now much faster to load, the browser will verify the identity claims in parallel! No more waiting for that one slow identity to verify before showing the result of all the other identity verifications.
rel="me"</h3>
The wait is finally over! Server-side rendering means that Mastodon instances can now detect the rel="me" links on Keyoxide profile pages and will reward you with a green tick for every Keyoxide profile you link to in your Mastodon bio!
Here's an example: @keyoxide@fosstodon.org</a>. So satisfying!
Yes, this means Keyoxide can now do and be as much as "any other" identity provider on Mastodon. By just using basic web technology. Without requiring special server protocols. And no VC-funded companies needed.
Small web truly is beautiful, isn't it? (quote from Small Tech Foundation</a>)
A claim failed, what does that mean?</h3>
The issue of a claim failing to verify is actually more complex than it seems, and something that the previous versions of Keyoxide did not handle very elegantly.
As an example, let us claim to be Alice on Github. If it fails, it could either mean that we made a mistake somewhere, or we are attempting to impersonate Alice—the very thing Keyoxide is designed to detect and prevent.
In this case, it's simple: the claim https://gist.github.com/Alice/...</code> could only reference Github so the story ends here.
But what if we wanted to verify https://alice.tld/apps/live</code>? From the looks of it, it could be anOwncast</a> server, but that is just a guess.
When this claims fails to verify, does it fail because that Owncast server is not mine (impersonation) or because it wasn't actually an Owncast server? This URL could also very well lead to a repo on a Gitea</a> server.
And what if it also fails to verify as a Gitea account? Was it one of them that genuinely failed, or neither of them?
Keyoxide 3.0.0 now recognizes "ambiguity" in URLs and acts accordingly. Does a claim with an unambiguous URL (like Github) fail? Keyoxide will let the visitor know the claim genuinely failed. Did a claim with an ambiguous URL fail? Then Keyoxide will show a message letting the visitor know that it wasn't sure what the claim was meant to be but regardless, it failed to verify.
Future improvements</h2> Keyoxide 3.0.0 brings a few tweaks, but again, the biggest change is the overhaul of the core code. This will allow a bunch more improvements to be made soon with relative ease. Here's an overview of what is in the pipeline. Requirement of JavaScript</h3> Previous versions of Keyoxide said "the browser must do everything". This meant that JavaScript had to enabled in order for Keyoxide to be able to do anything at all. As stated above, Keyoxide 3.0.0 now only lets the browser do the very last step of the whole process but this still means JavaScript is required. However, it is not difficult to imagine now that the server could do everything and just send the finished profile page to the browser. In a future version of Keyoxide, visitors who have JavaScript disabled and do not mind waiting for up to fifteen seconds (due to some claims taking more time to verify) will be able to request a fully server-side rendered profile page. a11y and i18n</h3> With more work being done server-side, it becomes simpler to implement internationalisation and render the website in different languages. Also, with the pages themselves become less dynamic, decent accessibility is also simpler to achieve and currently has the highest priority. Signing off</h2> That's about it for today. This update marks a big change that will greatly benefit future versions of Keyoxide. I can't wait to start working on the next developments and share them with you as they come along. As always, the source code is available at the Codeberg.org repo</a> (now renamed to keyoxide-web). For all your questions and suggestions, be sure to join the conversation in the Keyoxide matrix room</a> or raise an issue on Codeberg.org</a>. All contributions are welcome! Until next time.
Keyoxide Project Update #3 2021-03-09T16:00:00+00:00 Two months since the last update. Two great new additions for this one. Keyoxide 2.5.0</h2> The latest version of Keyoxide's web client has two very neat additions, all thanks to the latest 0.11.*</a> release of doip.js</a>: the verification of accounts on the IRC and Matrix platforms. This really is what Keyoxide was designed to do: making sure your online correspondances are exchanged with the intended person or entity, even as both parties use anonymous accounts with varying usernames on different platforms. To this end, it was important to integrate additional communication platforms, to join the already supported XMPP</a> protocol. Given the popularity and decentralized nature of either platform, IRC and Matrix were both prime candidates. So, let's see what goes into proving identities on IRC and Matrix. (All examples below use a certain OpenPGP fingerprint and a fictional user, make sure to use your own data when replicating the steps!) Proving IRC identity with taxonomy</h2> What is taxonomy within the context of IRC? >> /msg NickServ help TAXONOMY ***** NickServ Help ***** Help for TAXONOMY: The taxonomy command lists metadata information associated with registered users. Examples: /msg NickServ TAXONOMY foo ***** End of Help ***** </code></pre> Taxonomy is metadata information, much like the vCard data for XMPP. Let us use this to our advantage: >> /msg NickServ SET PROPERTY KEY openpgp4fpr:3637202523e7c1309ab79e99ef2dc5827b445f4b Metadata entry KEY added. >> /msg NickServ TAXONOMY foo Taxonomy for foo: KEY : openpgp4fpr:3637202523e7c1309ab79e99ef2dc5827b445f4b End of foo taxonomy. </code></pre> And there you have it: one-directional linking from IRC to an OpenPGP key. Now, to make that bidirectional, add the following notation to your key: proof@metacode.biz=irc://chat.freenode.net/foo </code></pre> Et voilà, foo has now cryptographically proven that that IRC nickname is theirs. All steps above are explained with more detail in the IRC guide</a>. It is important to note that IRC is the slowest identity to verify to date. As IRC servers lack API endpoints to query the taxonomy metadata (maybe one day? ^_^), Keyoxide has to log in into the IRC server like any other client, send a message to NickServ, parse the response and log out again. Proving Matrix identity with...</h2> Matrix</a> is an excellent decentralized communication platform, but sadly, for identity verification purposes, it completely lacks any form of customisable metadata. A shortcoming we can work with, but one which might also understandibly deter some from proving Matrix identities. One simply sends a message to a public room with the following content: [Verifying my OpenPGP key: openpgp4fpr:3637202523e7c1309ab79e99ef2dc5827b445f4b] </code></pre> Easy enough. The issue is: Keyoxide can only read messages in a public room via a Matrix account that already has access to said public room. Ergo, we can't just use any room, we'll all have to use the same room. A dedicated room named #doipver:matrix.org</a> has been created for the very purpose of receiving Matrix identity proofs. Simply join the room and send the message with your own OpenPGP fingerprint. By viewing the source of message, you get the data needed to generate the identity claim to be stored inside your OpenPGP key: the room_id</code> (shared by everyone) and the event_id</code> (unique to your proof). The notation will look like this: proof@metacode.biz=matrix:u/@foo:matrix.org?org.keyoxide.r=!dBfQZxCoGVmSTujfiv:matrix.org&org.keyoxide.e=$3dVX1nv3lmwnKxc0mgto_Sf-REVr45Z6G7LWLWal10w </code></pre> That is quite an unwieldy notation, but one designed to follow the MSC2312 Matrix URI scheme proposal</a> . Please refer to the Matrix guide</a> for detailed instructions on how to verify your own Matrix identity. Signing off</h2> As the project now supports multiple communications platforms and its versatility increases with each update, I am confident that Keyoxide is now ready for the next phase: focus on the user experience. Nothing to show just yet, but I am sure the next project update will have interesting announcements related to this. For all your questions and suggestions, be sure to join the conversation in the Keyoxide matrix room</a>. Until next time. Keyoxide Project Update #2 2021-01-11T16:30:00+00:00 A prosperous 2021 to all. Let's dive into some Keyoxide news. Signature profiles</h2> The Keyoxide web client just got updated to 2.4.0</a> which introduced a few minor bug fixes as well as a robots.txt and noindex meta tags. The most exciting new feature in this release is the support for "signature profiles", a new way of creating decentralized profiles that is both simpler to generate and solves a few drawbacks that come with the traditional method of storing identity claims as notations in cryptographic keys. From the newly added signature profiles guide</a>: Storing claims inside the key as notations is a powerful method. Wherever the public key goes, so go the identity claims. This allows one to use the existing vast network of key sharing tools to also share these identity claims. There are drawbacks to this: you lose granularity. You cannot pick and choose the claims you want to send to certain people or use for certain purposes. There is also the possibility that notations in keys could be scraped as the keys are publicly available. Putting (certain) claims in a signature profile solves both drawbacks. You can choose which claims to be associated with each other and you can choose which persons can see this by only sending it to them. You can even encrypt the signature profile! Since the signature profile is not publicly available (unless you make it so), there is no possibility to scrape the contents of it. Note that there is one catch: the person you send it to could publish it. Only send claims you wish to keep secret to people you trust! </blockquote> What does a signature profile look like?</h3> Here's an example: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hey there! Here's a signature profile with proofs related to the DOIP project (https://doip.rocks). Verify this profile at https://keyoxide.org/sig proof=dns:doip.rocks proof=https://fosstodon.org/@keyoxide -----BEGIN PGP SIGNATURE----- iQHEBAEBCgAuFiEENjcgJSPnwTCat56Z7y3FgntEX0sFAl/7L0MQHHRlc3RAZG9p cC5yb2NrcwAKCRDvLcWCe0RfS3iYC/0QQqz2lzSNrkApdIN9OJFfd/sP2qeGr/uH 98YHa+ucwBxer6yrAaTYYuBJg1uyzdxQhqF2jWno7FwN4crnj15AN5XGemjpmqat py9wG6vCVjC81q/BWMIMZ7RJ/m8F8Kz556xHiU8KbqLNDqFVcT35/PhJsw71XVCI N3HgrgD7CY/vIsZ3WIH7mne3q9O7X4TJQtFoZZ/l9lKj7qk3LrSFnL6q+JxUr2Im xfYZKaSz6lmLf+vfPc59JuQtV1z0HSNDQkpKEjmLeIlc+ZNAdSQRjkfi+UDK7eKV KGOlkcslroJO6rT3ruqx9L3hHtrM8dKQFgtRSaofB51HCyhNzmipbBHnLnKQrcf6 o8nn9OkP7F9NfbBE6xYIUCkgnv1lQbzeXsLLVuEKMW8bvZOmI7jTcthqnwzEIHj/ G4p+zPGgO+6Pzuhn47fxH+QZ0KPA8o2vx0DvOkZT6HEqG+EqpIoC/a7wD68n789c K2NLCVb9oIGarPfhIdPV3QbrA5eXRRQ= =QyNy -----END PGP SIGNATURE----- </code></pre> I only wrote the four lines after Hash: SHA512</code>! The rest is generated by an OpenPGP-compatible library. The first two lines are meant for humans. They state my intent with this signature profile as well as give an instruction to whomever receives it. The remaining two lines are my identity claims. They follow a specific syntax that Keyoxide and any other service using doip.js</a> can interpret. The text around it is the signature. They make the message both provably beyond doubt written by yours truly, and untemparable. Try it in the next step, change any character in the text, it will fail. This ensures that no bad actor could intercept my signature on its way to you and modify its content. What to do with it?</h3> When put into keyoxide.org/sig</a>, the website will perform two verifications. First, is the signature valid? Has the text been tampered with? If the signature is valid, a so-called 'fingerprint' is extracted from it and displayed. Preferably, I have already mentioned my fingerprint to you. This ensures that you didn't simply get a signature from someone else pretending to be me. The fingerprint of the key that I used for the signature above is 3637202523e7c1309ab79e99ef2dc5827b445f4b</code>. Second step is the verification of the identity claims. I could write a perfectly valid signature profile filled with absurd and incorrect identity claims! We don't want that. The fingerprint we just extracted from the signature is now used to verify these identity claims. For example, the first claim (doip.rocks) will have a DNS record with that value. And the second claim (fosstodon.org/@keyoxide) has the fingerprint in the bio section of the account. Both should verify. This allows you to say: Whoever signed this profile, holds the doip.rocks domain name and the fosstodon.org/@keyoxide account. </blockquote> Granular and non-scrapable identity claims</h3> There you have it. Identity claims that can be sent granularly (you pick and choose which to include) and are non-scrapable (signature profiles are not publicly available). And if you wish to go a step further, you can even encrypt the signature profile to make sure it can't be read while in transit to the intended recipient. Happy signing! doip.js 0.9.0</h2> Release 0.9.0</a> of doip.js</a> introduced support for the verification of signature profiles. In fact, Keyoxide simply relies on doip.js for all identity verifications. This makes it possible for new projects to get started quickly with fully decentralized identity verification and always have the same feature set that Keyoxide has. This is the way. Signing off</h2> Hope you enjoy the signature profiles. Do not hesitate to get in touch for questions, comments or suggestions. There's a Keyoxide matrix room</a> as well as a mailing list</a>. Until next time. Keyoxide CLI released 2020-12-08T16:30:00+00:00 Five months ago when I made keyoxide.org</a> public, one specific request made by quite a few people stood out: we need the ability to perform the identity verification locally. And given that it was a quite technical crowd, this meant: we need a command-line interface (CLI). The command-line interface</h2> Today, I'm pleased to announce the release of the CLI. Written in Node.js and published on Codeberg</a> under the AGPL-v3.0-or-later</a> license, the Keyoxide CLI uses the recently released doip.js</a> library and does all the things the Keyoxide website does, but locally. This means you no longer need to trust the website of the Keyoxide instance you are using, its maintainer or everything inbetween. Your machine fetches the keys, parses them locally and then directly requests the identity proofs from the service providers to verify the identity claims. Here's a quick tour. Assuming you already have Node.js installed, first install the CLI: npm install -g keyoxide </code></pre> Then go and verify the identity proofs inside a cryptographic key! To get started, try out the key I use for testing: keyoxide verify hkp:test@doip.rocks </code></pre> You should now get the following result: Verification results: Yarmo Mackenbach (material for test frameworks) <test@doip.rocks> ✓ doip.rocks (dns) </code></pre> And there you have it! Whoever generated this key verifiably owns the doip.rocks</a> domain name. Of course, the CLI can also fetch keys using WKD or get them from Keybase. More information about these protocols is available on the Keyoxide</a> website and in the source code's readme</a> document. FOSS FTW</h2> As always, this project is fully open source and I welcome all criticism and contributions, both issues and PRs. We all stand to benefit from solutions that are built for and by the people. As governments worldwide push for cryptographic backdoors, let us all keep using and promote free and open software. Many thanks to NLnet</a> for supporting me on this journey and allowing me to focus on these projects while keeping them free from VC funding and other means of monetization that could compromise the privacy of the individual. If you value my efforts and would like to donate, it's possible to do so on the project's Liberapay</a> page. Cheers and I'll see you in the next Keyoxide project update post! Keyoxide Project Update #1 2020-11-09T14:00:00+00:00 Time for the first big Keyoxide project update! A lot to cover, so let's get to it. The Big Identity</h2> Decentralized identity is coming. DIDs</a> are coming. Awesome libraries like IDX</a> are being published. Even Microsoft</a> seems on board. My point is this: decentralized identity is an exciting field to be working on right now and I'm committed to keep learning about this domain, its technologies and contribute to our digital society's cure from the parasitic tech giants. Keyoxide and the response it generated showed me this is within the realm of the possible. A wild foundation appears!</h2> To help me achieve this, I've decided to set up a foundation. Please welcome the Key to Identity Foundation</a>! The foundation will serve as an umbrella for a couple of identity-related projects to come, which I will be glad to share more about as they progress. In fact, one of these new projects is included in this update :) Having a non-profit foundation also allows me to try and fully sustain the project on donations and grants. I truly believe this model will help the project and give it the best chance at making a significant change out there. And as it turns out, I am not the only one who wants to see that happen… NLnet grant for Keyoxide development</h2> The awesome people over at NLnet</a> have taken a good look at the current status of the Keyoxide project, my plans for its future and it is now my pleasure to announce they have decided to award me an NGI Zero grant</a> and fund the development! I couldn't be more excited about this news. Keyoxide generated a lot of positive feedback and ideas on how to improve it when it launched. Getting the possibility to work on it full-time and build on the aspects that were important to the community is a dream come true. More information available on the NLnet website</a>. Keyoxide endgame</h2> I would like to expand on a point that is dear to me. Today's internet is in its precarious state because we put faith in monopolistic forces that blossomed under a lack of competition. The endgame of this endeavor is not just to create a successful project. It is to build an ecosystem that will thrive on competition and ultimately deliver the best experience for netizens. It is what this in mind that I am releasing a new project today that should help new projects get started in the decentralized identity world. doip.js</h2> DOIP stands for Decentralized OpenPGP Identity Proofs, the technology that enables the identity verification that Keyoxide performs. doip.js is a Node.js library that enables any project to perform the same tricks. It is even able to run directly in the browser! What excites me most is that any contribution, like supporting new service providers, is immediately available to all those projects and websites, not just Keyoxide. Documentation is available at doip.rocks</a>. Code is licensed under Apache 2.0 and hosted by Codeberg.org</a>. Building a community</h2> Keyoxide now has a Matrix room, come hang out and discuss related topics! Invite link: #keyoxide:matrix.org</a> The road ahead</h2> We are just getting started here. A lot still needs to happen to make Keyoxide and OpenPGP-based decentralized identity practical and useful for a larger audience. With the NLnet grant and my newly-acquired ability to turn this project into a full-time job, I foresee a bright future. Hope to see you back for the next update! Keyoxide 1.0.0: switched to AGPL-v3 2020-07-30T12:48:24+00:00 The big 1.0.0</h2> Well, yes but no. It's actually a small update but with a MAJOR (get it? Because semver</a>) change: the project has switched to the AGPL-3.0-or-later</a> license. When I started the Keyoxide</a> project, it didn't have the scope and ambitions it has now. What begun as a tool to bring simple PGP operations directly to the user's browser—a side project like many others—has turned into a full-blown solution to prove online identity in a decentralized manner. The project has also seen quite a warm welcome among the tech-savvy and privacy-minded as a partial replacement for alternatives like Keybase. More importantly, the project has started receiving contributions from other people. From that point on, as was pointed out to me by @t0k@social.tchncs.de</a>, a permissive license like I was using before will no longer do. A copyleft license like AGPL-3.0-or-later</a> is much better suited to protect the project and its contributors from getting the source code—including everyone's contributions—turned into a closed-source clone. Keyoxide is for the online citizenry and will remain so. Why 1.0.0?</h2> Usually, the "big 1.0" is associated with a project coming out of a beta period or more generally, becoming a product that users can use without excessive bugs. This is not the case here. The versioning of this project adheres to semver</a>: MAJOR-MINOR-PATCH. A license change such as this one might put certain people or organizations off from using it (it shouldn't… but it might) and could therefore be considered a breaking change which, according to semver, triggers a MAJOR release. Hence 1.0.0. Keyoxide and XMPP + OMEMO 2020-07-23T14:08:02+00:00 XMPP</h2> XMPP</a> is an open messaging protocol that not only drives a thriving secure communication ecosystem for the privacy-minded, but also handles the messages sent by platforms like WhatsApp and Zoom. Knowingly or not, you have most likely used XMPP at some point in your life. For the rest of this post, we will not take into account services like WhatsApp and Zoom as their platforms are closed off from all other platforms even though they use the same XMPP protocol. That ecosystem for the privacy-minded consists of libraries for developers, server applications for the tech-savvy service providers and clients like Dino</a> (Linux), Gajim</a> (Windows, Mac, Linux) and Conversations</a> (Android) for everyone. Because there is no single server or client to rule them all, we call this is a decentralized network. I could use a different server and a different client than you do, but we would still be able to communicate with each other. Also, any server or client could cease to exist the next day without impacting the rest of the network. Care to join the XMPP ecosystem?</h2> Joining the XMPP ecosystem is as simple as making an account on a server and logging in using any XMPP-compatible client. But which server? Which client? While not the focus of this post, here is a list provided by 404.city</a> and a list provided by jabber.at</a> of XMPP servers. Notable mention for 404.city</a> itself. Not sponsored. Just a fan. With regards to clients, the three mentioned above should get you started. Need a different client? Have a look at this list provided by xmpp.org</a>. End-to-end encryption: OMEMO</h2> XMPP communication can be end-to-end encrypted with OMEMO</a> (XEP-0384</a>), the easiest and most common of XMPP-compatible end-to-end encryption schemes</a>. Verifying OMEMO fingerprints is essential to trust your communication and keep it safe from Man-in-the-Middle attacks. Each XMPP client you use will have its own OMEMO key, the content of which remains secured on your device but a "fingerprint" of which can be made public without a problem. These fingerprints are used to identify the different clients that have logged in on your XMPP account. If you wish to secure your communication with OMEMO, make sure to choose a client with full support on this website</a>. OMEMO and trust</h2> When you talk with someone over XMPP and you want to guarantee all communication is secured, it is recommended to use a different form of communication to compare and trust each others fingerprints. Ideally, you would meet in person and scan QR codes, a handy function of the Conversations app. XMPP identity proofs and Keyoxide</h2> As you can see, trusting OMEMO keys is an essential step in the process of ensuring communication is secure. Fortunately, Keyoxide</a> can assist you in that process. As of version 0.4</a>, Keyoxide generates QR codes for all verified XMPP accounts it detects. This makes it easy to add new contacts if your XMPP identity proof</a> looks like this: proof@metacode.biz=xmpp:username@domain.org </code></pre> Scan the resulting QR code on a Keyoxide profile page in the Conversations app and the contact is added. But the OMEMO keys are not yet trusted. Let's solve that! Integrating OMEMO in the XMPP identity proof</h2> It is also possible to add a more advanced XMPP identity proof</a> to your OpenPGP key that includes the OMEMO fingerprints: proof@metacode.biz=xmpp:user@domain.org?omemo-sid-123456789=A1B2C3D4E5F6G7H8I9... </code></pre> Obtaining the correct URI for the proof can be difficult when doing so manually. Fortunately, this can be assisted by the Conversations app. As you can tell, using the Conversations app brings a ton of advantages. In the main menu of that app, press Manage accounts > [your account] > Share > Share as XMPP URI and add the resulting URI to your key using this Keyoxide guide</a>. Scan the resulting QR code on a Keyoxide profile page and not only is the contact added, their OMEMO fingerprints are also fully trusted and verified. Why trust the Keyoxide identity proof?</h2> Anyone can add any XMPP proof to their OpenPGP key, whether they own it or not. So why trust the identity proof on Keyoxide? STEP 1 The QR code is only shown if a XMPP identity proof is verified. Verifying a XMPP account requires the holder of said account to add a small line of code to their XMPP bio as described in this guide</a>. Only a person with access to both the OpenPGP private key and the XMPP account can verify that XMPP account. STEP 2 While Keyoxide assists as much as possible with trusting the right proofs, a critical mind is always an asset when dealing with trusting online identities, especially when securing your communication. Do you recognize any other proofs on this person's profile page? Is this proof verified? If so, you can safely assume that the person who holds the OpenPGP key also has access to this "other proof". Combining the two steps above, you can trust that you are talking to the right person and verifying the right OMEMO fingerprints. Example</h2> You are reading this post on yarmo.eu</a>. Whether or not you trust me, I'm telling you that my OpenPGP fingerprint is: 9f0048ac0b23301e1f77e994909f6bd6f80f485d </code></pre> So you visit keyoxide.org/9f0048ac0b23301e1f77e994909f6bd6f80f485d</a>. Indeed, whoever holds the key with that fingerprint also owns the yarmo.eu</a> domain. Now, you scroll down until you reach the XMPP proof for yarmo@404.city. You read that the XMPP account is verified. Ergo, whoever holds the key with that fingerprint also has access to that XMPP account. Final conclusion: whoever owns the yarmo.eu</a> domain also has access to the yarmo@404.city XMPP account. If you wish to talk with me securely, scan the QR code and be certain that you have just added me as a contact, and that are you verifying the right OMEMO fingerprints to ensure secure and fully encrypted communication between us. Launching Keyoxide.org 2020-07-01T12:00:00+00:00 Today, I'm excited to launch Keyoxide.org</a>, the lightweight and FOSS solution to make basic cryptography operations accessible to regular humans. What is Keyoxide.org?</h2> Keyoxide.org</a> offers easy encryption, signature verification and decentralized identity proof verification based on PGP keys while demanding little in-depth knowledge about the underlying encryption program from its users. This project aims to offer comparable functionality as services like Keybase</a> while reducing friction and being more open. The project is MIT licensed, uses openpgpjs</a> and is hosted on Codeberg</a>. Why only encryption and signature verification?</h2> These are the operations that are available when only having access to public keys instead of private keys. If you wish to decrypt messages and sign them, you need a keypair. If you have a keypair, you probably have the knowledge to use dedicated tools like the CLI or Kleopatra. And if you do, you probably won't be using Keyoxide.org</a> directly yourself. Indeed, if you possess a PGP keypair, Keyoxide.org</a> is the tool you send to others to interact with your public key more easily. Allow them to encrypt a message for you, to verify one of your signatures, to verify your online identities using decentralized proofs. What are those decentralized identity proofs you keep mentioning?</h2> You know how Keybase allows you to prove you have control over accounts on certain websites and services? A great function! Fortunately for you, this function can be even better and more secure by using decentralized OpenPGP identity proofs</a>. Keyoxide.org</a> will prove your identity on multiple platforms at the same time and yet, you are not required to make an account to use this function. How is that possible? Well, it's called decentralized for a reason: Keyoxide.org</a> doesn't hold your proofs, your key does! Any software that can access your public key can verify these proofs for anyone. When better tooling comes around, you could verify those proofs using a mobile app, using a command-line utility, you name it. No single service holds your proof, only you do, stored inside your keypair. I have written a guide</a> on how to add a proof for every platform currently supported by this website: domains</a>, Lobste.rs</a>, Twitter</a>, Github</a>, a bunch more</a> and work is in progress to support even more still. Is your beloved service not in the list? Open an issue or make a PR</a>! Free open-source software FTW! Oh, that reminds me, any Mastodon</a> instance can be used to prove your identity. Yes, any</a>. So how does it compare to Keybase?</h2> There's a more complete guide on the Keyoxide website</a>, but in a nutshell: more privacy-friendly by not forcing you to create an account and handing over data</li> more secure by not asking you to trust the service with your private keys</li> open-source servers (a must</a>)</li> encrypt/verify with every public key accessible on the internet, not just those that have been uploaded to a proprietary server</li> almost all processing is done in the browser, no data is sent to servers*</li> no vendor lock-in</li> selfhostable</li> </ul> * Only exception is decentralized identity proof verification: some service providers do not have the correct CORS headers (like Reddit) or require APIs (like Twitter). In these rare cases, simple PHP scripts (also open-source) run the proof verification instead. Can I get an account?</h2> No. Keyoxide.org</a> doesn't need your data on its servers. There are already several ways of exposing public keys on the internet, including web key directory</a> (WKD) and dedicated servers like keys.openpgp.org</a>. Let's use those instead of making yet another service where you need to upload your keys to. Can I get a profile page then?</h2> Yes! Append your PGP fingerprint or WKD id to the URL and there it is! Want an example? Here's my profile at https://keyoxide.org/9f0048ac0b23301e1f77e994909f6bd6f80f485d</a>. Now you know what accounts on various services are mine, where to follow me if you wish to get updates on the project and if you wish to send me an encrypted message, that's also just two clicks away. What about my private keys?</h2> Don't upload your private keys to the internet, period. If a service wants your private keys on their (proprietary) servers, say no. You said selfhostable?</h2> Well, yes! It's not a fully supported use case just yet, but the browser does all the processing, the server is mostly just there to deliver the files to the user to perform the operations. Grab the code</a> and put it on your own PHP server! Any closing words?</h2> I built this to provide better tooling around modern-day encryption programs and reduce the friction for less tech-savvy people when interacting with public keys. For those who wish to use encryption programs beyond OpenPGP, let's talk about this</a>. Keyoxide doesn't have any reference to PGP in its name for a reason: it could serve as a platform for easy interaction with any public key, no matter the underlying encryption program. And above all, I hope you see the same benefit and potential in Keyoxide.org</a> as I do and would like to see it grow as an open and accessible platform to push forward the democratization of online privacy and security. Privacy is not a luxury. Many thanks to Wiktor</a> for helping with the decentralized identity proofs.

Signing off</h2>
Hope you enjoy the signature profiles. Do not hesitate to get in touch for questions, comments or suggestions. There's a Keyoxide matrix room</a> as well as a mailing list</a>.</p>
Until next time.</p>

You said selfhostable?</h2>
Well, yes! It's not a fully supported use case just yet, but the browser does all the processing, the server is mostly just there to deliver the files to the user to perform the operations. Grab the code</a> and put it on your own PHP server!</p>

Yarmo - keyoxide

Keyoxide Project Update #5

Keyoxide Project Update #4

Keyoxide Project Update #3

Keyoxide Project Update #2

Keyoxide CLI released

Keyoxide Project Update #1

Keyoxide 1.0.0: switched to AGPL-v3

Keyoxide and XMPP + OMEMO

Launching Keyoxide.org

Yarmo - keyoxide

Keyoxide Project Update #5

Keyoxide Project Update #4

rel="me"</h3> The wait is finally over! Server-side rendering means that Mastodon instances can now detect the rel="me"</strong> links on Keyoxide profile pages and will reward you with a green tick for every Keyoxide profile you link to in your Mastodon bio!</p>

Signing off</h2> That's about it for today. This update marks a big change that will greatly benefit future versions of Keyoxide. I can't wait to start working on the next developments and share them with you as they come along.</p>

Keyoxide Project Update #3

Keyoxide Project Update #2

What does a signature profile look like?</h3> Here's an example:</p>

Keyoxide CLI released

Keyoxide Project Update #1

Keyoxide 1.0.0: switched to AGPL-v3

Keyoxide and XMPP + OMEMO

Launching Keyoxide.org