Yarmo - cryptography

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.

The Future of Online Identity is Decentralized 2020-07-12T16:23:31+00:00 Online identity</h2> Online identity</a> refers to the concept of "being" in the digital world. As an internet user, you exist. You create accounts on websites. You write on social media and blogs. You post photos. All this online activity has in common that one and the same person performed these actions; it defines your "online identity". However, your "online identity" is not per se representative of your "social identity" in the physical world. You may choose to use your own name or a pseudonym. You may choose to publish personally identifiable information or not. You may choose to remain truthful to your social identity or deceive. In short, you may choose for authenticity or for anonymity. Authenticity versus anonymity</h2> Authenticity and anonymity aren't mutually exclusive and that is the beauty of the internet. In the physical realm, you are (mostly) limited to a single social identity. In the digital space, there are no such restrictions. While you can't embody multiple persons in the offline world, you can have several identities online. In fact, you can even have multiple accounts on the same platform, opting for a different balance between authenticity and anonymity for each one of them. The anonymity has its downsides, creating psychological artifacts like online disinhibition</a> and facilitating cyberharassment</a>. However, even though we are far from completely overcoming these challenges, the internet that allows us to remain anonymous is still the one we should want and fight for. Consolidation of identity and internet corporations</h2> Removing the possibility for anonymity could solve the problem of online toxicity. Large internet corporations like Google and Facebook allow all to create an account on condition that some personally identifiable information is revealed, usually a phone number. The benefit is that it deters most from repeatably creating new accounts when older accounts have been flagged or banned due to improper behavior. These companies gain the function of "identity provider": they manage your online identity that can be used to login in different locations of the internet. We all know many websites that offer a "Google login" or "Facebook login". But there is a problem: handling the entire online identity of a single person is too much responsibility for any corporation or organization, especially if it is in their interest to gain intimate individual knowledge and sell it (Google) or use it to manipulate moods and influence decision making (Facebook). That phone number that was once used to prevent online toxicity is now the first of many pieces of personally identifiable information that these corporations will seek and use to figure out who you are. "You have nothing to hide"? Great. The internet corporations will still make money hand over fist by selling your personality, your preferences, your buying patterns and your vote. And not just yours. That of entire populations. Know that profits are just the tip of the iceberg. Governments all around the world are also interested in knowing what their citizens think, say and do for very different motives. Going decentralized</h2> The solution is relatively simple. When you create a new account and get to choose between "Google login", "Facebook login" and "Email login", pick "Email login". The benefit of not giving away any more personal data and tracking possibilities outweigh the inconvenience of having to fill in your email address and a password, especially when using a password manager. As tempting as the alternative is, making these changes will improve your life and ultimately, when enough people join these efforts, that of the world population. A different problem arises: how to prove online identity when decentralized? Decentralized online identity</h2> When you are no longer relying on an identity provider to manage your entire online identity, you lose the one common thing all your accounts on different platforms had: if two accounts on different online platforms are created by the same Google or Facebook account, we can safely assume they belong to the same person. But this "trust by proxy" is lost when the accounts on those platforms were created without identity provider. And whether authentic or anonymous, it can sometimes be extremely useful to know and trust that separate accounts on the internet belong to the same person, even when not knowing who this person is. The username is not sufficient to identify accounts across platforms. If you are "Alice" on one website, chances are you might need to be "Alice123" on the next one. And what if someone close to you is contacted by an "Aliss" requesting an amount of money to be transferred because they believe you to be in some sort of trouble? A poor attempt at impersonation, I know… Don't worry, a real bad actor will put in more effort and make a much more convincing act. Proving decentralized online identity</h2> What if not only your online identity is decentralized, but also the tool to prove said online identity? This would mean that you wouldn't need to depend on a single company or entity to prove your identity across platforms. Decentralized identity, decentralized proofs! Such solutions are already being deployed in industry, for example by firms like Indicio.tech</a> which focus on blockchain technology. Built for individuals, I recently launched Keyoxide</a> which uses cryptographic keypairs to accomplish decentralized identity verification. While it doesn't (and shouldn't!) link an account to a person in the physical realm, it links accounts across platforms. If you trust an account on one platform, you can trust any other account on any other platform as long as they are both verified by "identity proofs" stored in the same keypair. Whether you choose authenticity or anonymity, decentralized identity proofs allow you to build a cross-platform online identity. Here's my Keyoxide profile</a>. In this case, I link to several "authentic" accounts but I could easily generate a new keypair void of personal data that links to several anonymous accounts. The accounts don't need to be authentic to create an online persona. All the accounts listed in the link above belong to me. No one else could claim these accounts. Here's how. Identity proofs</h2> An "identity proof" is nothing more than a link to an account A on some platform P stored inside your keypair K. If a "proof verification tool" such as Keyoxide follows this link and discovers some piece of data linking back to keypair K (which is only possible if keypair K and account A on platform P belong to the same person), the account is verified. If this proof verification is done for several accounts on different platforms, it is beyond reasonable doubt that the same person owns said accounts. No bad actor could claim one of your accounts: the piece of data that links back is specific to your keypair, not the bad actor's keypair. And the bad actor also couldn't insert a proof inside your keypair as long as your keypair isn't compromised. Only you, the owner of the keypair, can add new proofs. But the entire world can read and verify them. These identity proofs are decentralized because Keyoxide doesn't store them, your cryptographic keypair does. Keyoxide simply reads the keys and verifies the proofs. When you remove a proof from your keypair, Keyoxide will no longer have access to it. You own your proofs and your online identity. In fact, the proofs are readable by everyone and are not specifically designed for Keyoxide. Anyone can use any tool or create new ones to verify these proofs and developers are encouraged to enrich this field with additional tools and services. Let's build a decentralized identity ecosystem we can all trust. Online identity beyond today's internet</h2> Initiatives like Solid</a> by Sir Tim Berners-Lee</a> are paving the way for a new internet where all data is owned by the user and shared with platforms with consent and restrictions. This would solve the online identity problem: you get the benefits of a "pseudo centralized" account while maintaining full ownership over all account-related data stored on a decentralized platform. Social media would be allowed to see some data, messaging platforms some other data. But there would still be one single account to rule all the platforms. On today's internet, the best we can do is make fully separated accounts, link them using technologies like decentralized online identity proofs and create our own online personas, with our own open tools that ensure we maintain ownership over them. 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. OPSV: Open PGP Signature Verification 2020-06-17T11:51:39+00:00 Introduction to OPSV</h1> I'd like to introduce a new project of mine named Open PGP Signature Verification</a> or OPSV, a FOSS solution for easy PGP signature verification. I have copy-pasted the README from the Codeberg repo</a> below and added a "Why make this project?" section containing opinions. About</h2> This project uses openpgp.js</a> loaded in the browser, meaning all processing is done on the device itself and no data is ever sent to the server. It supports loading public keys directly through: plaintext input</li> web key directory (WKD)</li> HTTP Keyserver Protocol (HKP).</li> </ol> OPSV will always use the first input method it detects in the order described above. It's also possible to not provide a public key. Read more about this in the Using no public key at all</code> section below. Usage</h2> Visit https://opsv.foss.guru/. On this website, you can enter a signed message (see example below) and any of the three supported public key inputs to verify that the owner of that public key was indeed the person to have signed that message. Example</h2> Let's say I, Yarmo, would really like the world to know that I like pineapple. Using my private key, I've signed that statement so you can verify I wrote that message. The signed statement: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I like pineapple. -----BEGIN PGP SIGNATURE----- iQJDBAEBCAAtFiEEog/Pt4tEmnyVrrtlNzZ/SvQIetEFAl70mVUPHHlhcm1vQHlh cm1vLmV1AAoJEDc2f0r0CHrRQXIP/08uza9zOtmZXv5K+uPGVzDKwkgPgZJEezX7 6iQ358f1pjSRvYfQ5aB13k2epUHoqCKArMYu1zPqxhvLvvAvp8uOHABnr9NGL3El u7UUgaeUNHkr0gxCKEq3p81abrrbbWveP8OBP4RyxmaFx13Xcj7mfDluiBHmjVvv WU09EdH9VPlJ7WfZ+2G2ZZDHuE5XiaeP7ocugTxXXLkp33zwpDX0+ZuCIXM6fQGe OccSffglFPdNBnfasuuxDWxTQPsEbWGOPJV+CAPmBDeApX+TBF9bovO3hw4Uozk2 VT7EAy8Hb0SOrUb3UNGxzoKv++5676IxyB4JXX0Tr9O4ZxhO8o9pEEHwirtn/J1+ MWven4gVlWM/6bMeUqx6ydyNc2nqF5059yfRmwGMlp09x82G4x1bcf6aDZ+5njDG fS5T2OpXRIkZHJx8BhmZjsxiDR0KV44zwHpt06+96ef3EDWB0BcP6M+a5Rtc33zf irRmQd2M6RLyXCYtdGIiiAFRuomw802U4F0P4LwVrZdbGA6ObqBv1k8BUFCMbMz8 Ab4hF7kO4z0Vh3JaKzcHey0pOzdNCPpAHZ51sAoAnFDM4PdMBgQxxVweCMu4KYMZ FN8sNn42oY/b7gDmwCelVhgD+rvUn/a8+B7CDmCp+wIquyrjrTt00voATcb+ZPMJ pTXJ/NcM =rqTX -----END PGP SIGNATURE----- </code></pre> Use this as "Signature" on OPSV</a>. Using plaintext public key</h3> Now, let's check the signature. Go to my personal website</a> and copy-paste the "plaintext" key in the "Public Key (1: plaintext)" field. You will see a green message confirming that my key was used to sign this message. I really do like pineapple. Using web key directory (WKD)</h3> Remove the contents from the "Public Key (1: plaintext)" field. Now, in the "Public Key (2: web key directory)", write yarmo@yarmo.eu</code> and verify the signature again. It is still verified. Try using jane@doe.org</code> or any other input, it won't verify. Using HTTP Keyserver Protocol (HKP)</h3> Remove the contents from the "Public Key (2: web key directory)" field. I uploaded my keys to the https://keys.openpgp.org/ HKP server, which is the default server used by OPSV. All you need to do is once again go to my personal website</a> and copy-paste the "Fingerprint" in the "Public Key (3: HKP)" field (the second field!). Still verified! Using no public key at all</h3> Wait, what? Then what am I verifying the signature against? PGP signatures can contain the userId</code> of the signer. If OPSV finds a userId</code>, it will use it to perform a HKP lookup. Remove the contents from the "Public Key (3: HKP)" field. It again verifies BUT against the information contained within the signature itself. You should carefully check the information OPSV returns. In this case, the authenticity is confirmed because the userId</code> (yarmo@yarmo.eu) matches the one I use. The signature below does not contain a userId</code>: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I like pineapple. -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEog/Pt4tEmnyVrrtlNzZ/SvQIetEFAl70mT4ACgkQNzZ/SvQI etHUNBAAlswF4Q5IkPTsMELZPNHBps8CUJUeDWu3HlSz7c2U+4h2jJztHD0mDtxH PqKzUnqQqNF1Bot//5xoOcn+m6UaSCzDk1oQFwD6LlQA+ScnIXddoV3xLqzTRAMe dyuqOoDzoVeD+fWlwisnGElYX5jHRX6tgyKNh0auR3/crQUIJazAyeDwZFdJiwaL ntd+d8T0BcVlVVPYN7RIp1hpT+PLIcwIsr64Myfy8SOa4cjVcQgnrhR/Lfz9680T LCpnSohHRiA82nMGRiapEv+s+zy1NUZnVYbU2Li+Q0nYdSoDFu0xEBYmLOxwS50H j6kK0ZyRicNeq2T25aIlieliTmSFLHHpzi/Zw8Yt1+FtZvWf4pstA19ahk7AQK5W zYF2bMO2xn5D4/pRz1P4e2NTWYeIK+ZHttc7T9ZSS9Ffo03fjcJXhson3WcQZKB5 VIGVVFnlWujNYYotmxys84OtE6ePfVRwHasIOLfknVq64RVo68Y1Pgw/KPXSb1k6 3r+YD0mt5i/NWpwm79G/Aq54WI5JT905div88d0Bbpa3dScTZ2MiBJbP96pZBcKl dpm3RnjsbCFgZqEpclrEh2SD1e8eCjrNcouWK3jIfOkaWB2xk1KvNmdyQQTs3dkP /CpKcCJiNVvY9ogWxg9aUuQZUn4WvCvaEkmP4dfkk9s8yAKPQf8= =QqCq -----END PGP SIGNATURE----- </code></pre> Once again, the signature verifies. And again, it only verifies against the information contained within itself so that doesn't prove anything about its authenticity. Anyone can write this and the signature will return verified. Except now, there is no userId</code> for easy manual verification. So, you need to either take the keyId</code> or the fingerprint</code> and find some other way of verifying it, for example by contacting the person who supposedly wrote the message. In my case, you can simply visit my personal website</a> and compare the fingerprint</code>. What can a bad actor do?</h3> One could not sign a statement with my private key: I, and only I, have access to it. One could however simply take any of my signed messages and change the content. Like so: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I like privacy invasion. -----BEGIN PGP SIGNATURE----- iQJDBAEBCAAtFiEEog/Pt4tEmnyVrrtlNzZ/SvQIetEFAl70la8PHHlhcm1vQHlh cm1vLmV1AAoJEDc2f0r0CHrRDcYP/R4Yo+xiBLHtrOEMAQQkwbxWyQgCbjS4h9iF As86o9a+t5dKSsL4gSoB3sdNAL0a1ZOhaAU8kWaR6xN1RvCQjFr878hEf631yai6 DfF2eRZPEsjXkAzlOKlPrAvtrNwUUMSDk20rGa4A9HHdxpfrmDRIgVaz3uNr1qqc N/Ag3OK/2l1pZFTqjPekqDnXwblLiuTTLFlMlS80LFKoa7zZLkE5SD5O6WQFpOK7 DwYJk1+UjWDgVugz8rSLWag0mag9Z815furPIkU9yRmE1tIjsgpCR+uJA/e0I4bn 4Ei0M29df1QucDNv6q2WoW/7rCMz1IY796TY/BbdqbFk6vOUUHu596mQB+fJDNTX jGC0SpJPhzhgoZICzK8yWJMJGoLXScYj95rCAqjYdnW/LDdAgODCyjSOxnzdI1zi prQf4OmayHzDjI8Bo4bl22toPdSIDt3r5MmSGXcmBrNU16ea7FC9MnR8dkKfHD55 tC3UL2Ps/iU76kqzGAei1PKvaVqKogUGi/kqWzfi2eg+useHRyZpJrJv3R2mE0Y2 eSLMMJ5cTuM60c0GSIPOxzBBsMRwa0HmEQ3HKgpnpkVYxoA00/hq91kuNavqUqM+ OyOgbb21woPAG+S4OCHkOINEAooeCfhpSFtmpa87sUcfvDHUuX1ivL4rYoQO3cT2 gNfjdSiB =tqZV -----END PGP SIGNATURE----- </code></pre> Given the wording of the statement, you naturally doubt the origin of it being me. You run it through OPSV and indeed, this is not what I wrote! You know me, "I despise privacy invasion." (hint hint). Why make this project? (with opinions)</h2> This project directly targets a specific use-case of Keybase</a>. It is possible to upload your public key (don't upload your private key…) to the Keybase servers. When you sign a message using your private key, anyone can verify that you wrote that message by simply using their verify page</a>. It's really simple to use, but you'll notice something is missing: a field asking you which key to use for the verification. What Keybase does is check the message against all of the keys it knows about and then let you know which of its users wrote and signed that message. It is my humble opinion that this is an anti-pattern. By not being able to verify against a single key, you open the door to impersonation: I can make an account named j0hn</code> and pretend to be john</code>. If I write a false statement and sign it with j0hn</code>'s key, Keybase will gladly tell you that the message is legit and signed: it is, but by the wrong person. It is up to the user to then investigate j0hn</code>'s Keybase account and figure out if it belongs to john</code> or some bad actor. Considering recent events, namely Keybase's acquihire by Zoom</a> and Zoom's willingness to bend to US law enforcement</a> and Chinese</a> influence, combined with their unwillingness to release the server source code</a>, I strongly urge all to #deletekeybase</a>. They are not worthy of your keys and your data. It is a mystery what happens to your keys once you give them to Keybase, and with their employers working for a company eager to please privacy-invading governments, why would you? Seriously, why would you ever give your valuable private keys to Keybase? I was having this discussion on the fediverse recently and a privacy-minded individual still was forced to use Keybase for the simple reason it was the easiest and beginner-friendly way of verifying PGP signatures that didn't involve installing complicated software and handling PGP keys. Well now, there is OPSV</a>. It has the same intuitive copy-paste workflow as Keybase does, with the only additional step of having to copy-paste a plaintext key, email address or fingerprint (which, in my book, is a feature!). Processing is done client-side, so no data is sent to any server. Why include privacy-friendly plausible.io stats?</h3> Well, without sounding cocky, I humbly believe this is the first project I made that could actually make a difference to people's workflow on the internet. As such, if usage suddenly spikes, I need to know if the server can handle it. Because asking users to accept website statistics is much in my opinion, I decided a nice compromise was to make the statistics public</a>. If open statistics or any statistics at all is not to your liking, please do let me know by opening an issue</a>. Final words</h2> I hope you like this project, I know I do. OPSV allows me to use signed messages more and provide a simple and secure way to verify their authenticity without relying on big corporations. This is our web, so it's also our duty to keep it secure. Update 1</h2> Added the Using no public key at all</code> section. Mailvelope: PGP for all 2020-05-18T16:29:21+00:00 #100DaysToOffload >> 2020-05-18 >> 020/100</code> PGP</a> is a "pretty good" way of encrypting messages and files but gets often criticised for being too cumbersome to work with, which is sadly true. To counter this, certain products and services use PGP internally and provide an easy-to-use interface. Take Protonmail who uses PGP to automatically encrypt emails between protonmail addresses</a>. Handy, but we are forgetting something. If the PGP protocol is the lock, then the PGP keys are, well, the keys. Protonmail has both the lock and the key on their servers. That's not secure… Luckily, there are more tools, like Mailvelope</a> (source code</a>). It's nothing more than a browser add-on, meaning it will automatically work with any webmail service out there. Encrypting your emails becomes very simple (I also have a more detailed guide</a>). Load the recipient's public key in Mailvelope</li> Open your webmail service</li> Click the pink Mailvelope logo</li> Choose the key of the recipient</li> Write the email</li> Click encrypt and send the email</li> </ul> That is actually quite easy and feasible for the less tech-savvy people. But keep in mind (the usual email/PGP disclaimer): email is inherently insecure. Email metadata (including title!) is not encrypted, only the body is. Information about your secret communication can be infered from the metadata. Though PGP-encrypted emails are nice to have, truly private communication is achieved using encrypted instant messengers</a>.

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>

Using plaintext public key</h3>
Now, let's check the signature. Go to my personal website</a> and copy-paste the "plaintext" key in the "Public Key (1: plaintext)" field.</p>
You will see a green message confirming that my key was used to sign this message. I really do like pineapple.</p>

Update 1</h2>
Added the `Using no public key at all</code> section.</p>`

Yarmo - cryptography

Keyoxide and XMPP + OMEMO

The Future of Online Identity is Decentralized

Launching Keyoxide.org

OPSV: Open PGP Signature Verification

Mailvelope: PGP for all

Yarmo - cryptography

Keyoxide and XMPP + OMEMO

The Future of Online Identity is Decentralized

Launching Keyoxide.org

OPSV: Open PGP Signature Verification

Example</h2> Let's say I, Yarmo, would really like the world to know that I like pineapple. Using my private key, I've signed that statement so you can verify I wrote that message.</p> The signed statement:</p>

Update 1</h2> Added the Using no public key at all</code> section.</p>

Mailvelope: PGP for all

Update 1</h2>
Added the `Using no public key at all</code> section.</p>`