Yarmo - project

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.</p>

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.</p>
This project aims to offer comparable functionality as services like Keybase</a> while reducing friction and being more open.</p>
The project is MIT licensed, uses openpgpjs</a> and is hosted on Codeberg</a>.</p>

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.</p>
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.</p>

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?</p>
Well, it's called decentralized</em> 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.</p>
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!</p>
Oh, that reminds me, any Mastodon</a> instance can be used to prove your identity. Yes, any</a>.</p>

So how does it compare to Keybase?</h2>
There's a more complete guide on the Keyoxide website</a>, but in a nutshell:</p>

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.</p>
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.</p>
Can I get a profile page then?</h2>
Yes! Append your PGP fingerprint or WKD id to the URL and there it is!</p>
Want an example? Here's my profile at
https://keyoxide.org/9f0048ac0b23301e1f77e994909f6bd6f80f485d</a>.</p>
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.</p>
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.</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>
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.</p>
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.</p>
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.</p>
Privacy is not a luxury.</p>
Many thanks to Wiktor</a> for helping with the decentralized identity proofs.</p>

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.</p>
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:</p>

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.</p>
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.</p>
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.</p>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> -----BEGIN PGP SIGNED MESSAGE----- </span>Hash: SHA256 </span> </span>I like pineapple. </span>-----BEGIN PGP SIGNATURE----- </span> </span>iQJDBAEBCAAtFiEEog/Pt4tEmnyVrrtlNzZ/SvQIetEFAl70mVUPHHlhcm1vQHlh </span>cm1vLmV1AAoJEDc2f0r0CHrRQXIP/08uza9zOtmZXv5K+uPGVzDKwkgPgZJEezX7 </span>6iQ358f1pjSRvYfQ5aB13k2epUHoqCKArMYu1zPqxhvLvvAvp8uOHABnr9NGL3El </span>u7UUgaeUNHkr0gxCKEq3p81abrrbbWveP8OBP4RyxmaFx13Xcj7mfDluiBHmjVvv </span>WU09EdH9VPlJ7WfZ+2G2ZZDHuE5XiaeP7ocugTxXXLkp33zwpDX0+ZuCIXM6fQGe </span>OccSffglFPdNBnfasuuxDWxTQPsEbWGOPJV+CAPmBDeApX+TBF9bovO3hw4Uozk2 </span>VT7EAy8Hb0SOrUb3UNGxzoKv++5676IxyB4JXX0Tr9O4ZxhO8o9pEEHwirtn/J1+ </span>MWven4gVlWM/6bMeUqx6ydyNc2nqF5059yfRmwGMlp09x82G4x1bcf6aDZ+5njDG </span>fS5T2OpXRIkZHJx8BhmZjsxiDR0KV44zwHpt06+96ef3EDWB0BcP6M+a5Rtc33zf </span>irRmQd2M6RLyXCYtdGIiiAFRuomw802U4F0P4LwVrZdbGA6ObqBv1k8BUFCMbMz8 </span>Ab4hF7kO4z0Vh3JaKzcHey0pOzdNCPpAHZ51sAoAnFDM4PdMBgQxxVweCMu4KYMZ </span>FN8sNn42oY/b7gDmwCelVhgD+rvUn/a8+B7CDmCp+wIquyrjrTt00voATcb+ZPMJ </span>pTXJ/NcM </span>=rqTX </span>-----END PGP SIGNATURE----- </span></code></pre> Use this as "Signature" on OPSV</a>.</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> 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.</p> 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!</p> Using no public key at all</h3> Wait, what? Then what am I verifying the signature against?</p> 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.</p> 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.</p> The signature below does not contain a userId</code>:</p> -----BEGIN PGP SIGNED MESSAGE----- </span>Hash: SHA256 </span> </span>I like pineapple. </span>-----BEGIN PGP SIGNATURE----- </span> </span>iQIzBAEBCAAdFiEEog/Pt4tEmnyVrrtlNzZ/SvQIetEFAl70mT4ACgkQNzZ/SvQI </span>etHUNBAAlswF4Q5IkPTsMELZPNHBps8CUJUeDWu3HlSz7c2U+4h2jJztHD0mDtxH </span>PqKzUnqQqNF1Bot//5xoOcn+m6UaSCzDk1oQFwD6LlQA+ScnIXddoV3xLqzTRAMe </span>dyuqOoDzoVeD+fWlwisnGElYX5jHRX6tgyKNh0auR3/crQUIJazAyeDwZFdJiwaL </span>ntd+d8T0BcVlVVPYN7RIp1hpT+PLIcwIsr64Myfy8SOa4cjVcQgnrhR/Lfz9680T </span>LCpnSohHRiA82nMGRiapEv+s+zy1NUZnVYbU2Li+Q0nYdSoDFu0xEBYmLOxwS50H </span>j6kK0ZyRicNeq2T25aIlieliTmSFLHHpzi/Zw8Yt1+FtZvWf4pstA19ahk7AQK5W </span>zYF2bMO2xn5D4/pRz1P4e2NTWYeIK+ZHttc7T9ZSS9Ffo03fjcJXhson3WcQZKB5 </span>VIGVVFnlWujNYYotmxys84OtE6ePfVRwHasIOLfknVq64RVo68Y1Pgw/KPXSb1k6 </span>3r+YD0mt5i/NWpwm79G/Aq54WI5JT905div88d0Bbpa3dScTZ2MiBJbP96pZBcKl </span>dpm3RnjsbCFgZqEpclrEh2SD1e8eCjrNcouWK3jIfOkaWB2xk1KvNmdyQQTs3dkP </span>/CpKcCJiNVvY9ogWxg9aUuQZUn4WvCvaEkmP4dfkk9s8yAKPQf8= </span>=QqCq </span>-----END PGP SIGNATURE----- </span></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</strong>. Anyone can write this and the signature will return verified.</p> 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.</p> In my case, you can simply visit my personal website</a> and compare the fingerprint</code>.</p> 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.</p> One could however simply take any of my signed messages and change the content. Like so:</p> -----BEGIN PGP SIGNED MESSAGE----- </span>Hash: SHA256 </span> </span>I like privacy invasion. </span>-----BEGIN PGP SIGNATURE----- </span> </span>iQJDBAEBCAAtFiEEog/Pt4tEmnyVrrtlNzZ/SvQIetEFAl70la8PHHlhcm1vQHlh </span>cm1vLmV1AAoJEDc2f0r0CHrRDcYP/R4Yo+xiBLHtrOEMAQQkwbxWyQgCbjS4h9iF </span>As86o9a+t5dKSsL4gSoB3sdNAL0a1ZOhaAU8kWaR6xN1RvCQjFr878hEf631yai6 </span>DfF2eRZPEsjXkAzlOKlPrAvtrNwUUMSDk20rGa4A9HHdxpfrmDRIgVaz3uNr1qqc </span>N/Ag3OK/2l1pZFTqjPekqDnXwblLiuTTLFlMlS80LFKoa7zZLkE5SD5O6WQFpOK7 </span>DwYJk1+UjWDgVugz8rSLWag0mag9Z815furPIkU9yRmE1tIjsgpCR+uJA/e0I4bn </span>4Ei0M29df1QucDNv6q2WoW/7rCMz1IY796TY/BbdqbFk6vOUUHu596mQB+fJDNTX </span>jGC0SpJPhzhgoZICzK8yWJMJGoLXScYj95rCAqjYdnW/LDdAgODCyjSOxnzdI1zi </span>prQf4OmayHzDjI8Bo4bl22toPdSIDt3r5MmSGXcmBrNU16ea7FC9MnR8dkKfHD55 </span>tC3UL2Ps/iU76kqzGAei1PKvaVqKogUGi/kqWzfi2eg+useHRyZpJrJv3R2mE0Y2 </span>eSLMMJ5cTuM60c0GSIPOxzBBsMRwa0HmEQ3HKgpnpkVYxoA00/hq91kuNavqUqM+ </span>OyOgbb21woPAG+S4OCHkOINEAooeCfhpSFtmpa87sUcfvDHUuX1ivL4rYoQO3cT2 </span>gNfjdSiB </span>=tqZV </span>-----END PGP SIGNATURE----- </span></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!</p> You know me, "I despise privacy invasion." (hint hint).</p> Why make this project? (with opinions)</h2> This project directly targets a specific use-case of Keybase</a>.</p> 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.</p> 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.</p> 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?</p> 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.</p> 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.</p> 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.</p> Because asking users to accept website statistics is much in my opinion, I decided a nice compromise was to make the statistics public</a>.</p> If open statistics or any statistics at all is not to your liking, please do let me know by opening an issue</a>.</p> 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.</p> Update 1</h2> Added the Using no public key at all</code> section.</p>
Proposal for a Distributed Content Verification System 2020-05-16T14:49:39+00:00 #100DaysToOffload >> 2020-05-16 >> 018/100</code></p> Preamble</h2> This is going to be a long post. In it, I will describe a system that I have been thinking of for the last week. The way I see it, there are three possible outcomes: a) it's genius, I've outdone myself and I should build it; b) it's genius but other people have already solved this issue (perhaps in a different way); c) it's a mediocre/inadequate solution to a problem that doesn't need solving. I need help in figuring out which description suits this idea the best. Let me know on the fediverse</a>.</p> Background</h2> Story 1 - Linux Mint hack</h3> Two short stories are required. The first is based around Linux Mint and what happened in 2016</a>. TLDR from the blog post: "Hackers made a modified Linux Mint ISO, with a backdoor in it, and managed to hack our website to point to it". In addition to just linking to the modified ISO file, they also changed the MD5 hash to match their modified version.</p> The web is fragile. If you post MD5 hashes on your website so people can trust your software and your website gets hacked and the hashes changed, there's no trust. This is not Linux Mint's fault, this is the way the internet works. I have had hackers on my shared hosting servers who uploaded a whole bunch of suspicious files. Because of this, the fix was easy. But what if they just made a minor change in a single file? I would have been none the wiser.</p> Story 2 - Keybase</h3> You need an external source of truth and this is what the second short story is about: Keybase. I verified my website and my accounts on various services through their website. If you know me through my fosstodon.org account, you could check if that Keybase account was really mine, and if so, you could verify that this website is really mine as well as some other accounts. A nifty solution for authenticity proof of my distributed online presence.</p> But there are drawbacks. The actual content on my website is not verified. The system is centralised and also not FOSS. Lastly, due to their recent acquiring, I will no longer be using Keybase.</p> So my new authenticity proof? My website. The links on my website are who I am on various online services. I curated those links. I checked for each one if they link to what I intended them to link to.</p> But that's not enough. What if my website gets hacked? And a social link gets replaced? "Well, that doesn't happen to me", some might say. Fine, let's look at a second example. Visit someone else's personal site and click their social links. How do you know if you can trust those links? "So what", you say? Let's go further. You want to donate to someone using a cryptocurrency. They have their wallet on their website. Is that really their wallet though?</p> I think we can solve this issue the way we would want to: using a distributed system.</p> Proposal for a Distributed Content Verification System</h2> Overview</h3> The concept is based around a network of two different types of nodes: the "content" nodes and the "truth" nodes. The "content" nodes are websites with content that need to be verified. The "truth" nodes are servers that periodically check all known pages for changes.</p> The idea is that a hacker needs to obtain a developer's cryptographic keypair and infiltrate both a "content" node and one or more "truth" nodes in order to get away with their malicious activity.</p> Step 1 - Linking a "content" node to a "truth" node</h3> First, the website owner needs to make their website ("content" node) known to the network of "truth" nodes. This can either be done manually by asking someone they trust and owns a "truth" node, or "truth" nodes could implement some sort of registration form.</p> A valid contact method like an email address is mandatory to communicate irregularities to the website owner. A public cryptographic key is also required in order to check the signature of the hashes (see below).</p> Step 2 - Updating the "truth"</h3> During the process of uploading the updated content of their website to their server, the website owner also sends the hashes of the updated files to the "truth" node they registered with. This could be done by using a command-line tool on the server, on the developer's machine, it could even be part of the CI/CD/CD pipeline. Hashes are signed using a cryptographic keypair to make sure the website owner is the one who updated the content.</p> Alternatively, the "truth" node could have a web interface with a button to trigger the (near-)immediate download of the pages and computation of the hashes. However, this method does not easily allow for the cryptographic signing of the hashes and should therefore not be advised or even accepted.</p> Once updated, the "truth" nodes exchange the updated hashes with each other.</p> One thing to consider: websites can be dynamic, for example by including posts from social networks. HTML tags that contain dynamically generated content should get a specific tag so they get excluded from the hashing.</p> Step 3 - Verification of content</h3> On a regular basis, the "truth" nodes download the pages and compute the hashes. If they match with the hashes in their database, all is well.</p> If a discrepancy is found, a "truth" node should ask other "truth" nodes if updates exist for this particular website and the updated hashes simply haven't propagated yet. If so, fetch the new hashes and run this step again.</p> If no updated hashes are found or the new hashes still don't match, contact the website owner and let them know something has changed on their website that they haven't told the "truth" nodes about.</p> Optional step 4 - User benefits</h3> In addition to the measures taken in step 3 when detecting anomalies, browser plugins could warn visitors of websites that the content they are seeing may not be what the website owner intended it to be.</p> Possible attack surfaces</h3> If a "truth" node is hacked, hashes could easily be changed. However, signing the hashes using a cryptographic keypair should mitigate this problem. Other nodes will not trust the newly propagated hashes and will flag that "truth" node as corrupted.</p> If a "truth" node is hacked and the website owner's credentials are changed, they would no longer receives notifications. Credentials should also be signed by the cryptographic keypair to make changes like these detectable.</p> If a "truth" node is hacked and the stored public key is modified, we have a problem. "Truth" nodes should verify each other as well to make sure no funny business like this happens.</p> If a "truth" node is hacked and the "content verification" code is changed, we have a problem. Again, some form of collaboration between "truth" nodes should prevent hacked "truth" nodes from doing harm to the system.</p> If a "content" node is hacked and new files are uploaded, the "truth" node will not be triggered as it won't handle these files. But at least, the content displayed to visitors remains unchanged.</p> If a "content" node is hacked and existing files are modified, the "truth" nodes will be triggered and there's no code on the "content" node that could prevent this from happening.</p> If a "content" node is hacked and existing files are modified in such a way that the hashes match, we have a problem. Proper research needs to be done to correctly implement cyptographic hashing functions to avoid this issue.</p> Things that need to be worked out</h3> How exactly does a new website enter the network?</li> How to coordinate page downloading and hash computation to avoid redundancy and load on the hosting server?</li> How to measure credibility among "truth" nodes and detect corruption of individual nodes?</li> How to prevent hash collision?</li> </ul> Federated AND peer-to-peer</h3> The concept described above is technically based on federation. However, I initially imagined several websites hosting both their own websites and the hashes of websites they selected. This is still possible: the concept described above should support both a federated content verification system and a peer-to-peer content verification system.</p>