With htmlspecialchars() a & will become &, but you want %26. I’m not 100% sure if it’s a security problem as such, but it’s certainly incorrect. Same applies in some other places.
Since this loads all of its code live from an HTTPS website through the browser, its security boils down to the security of TLS and the WebPKI. On top of that the user is also trusting the website operator, the openpgpjs codebase, and the proof verification implementation.
Instead of verifying a file through this, one could download it from an HTTPS URL with equivalent or better security. For encryption, the same holds for an HTTPS form.
Maybe I misinterpret the site author’s intent but for me this looks like just a convenience profile page + some utils. The same argument holds for Keybase that also has verify and encrypt pages. So while the “browser crypto is broken by design” point is valid it’s actually nothing new. I do admit that the author could clarify this better on the page.
Or are you pointing out that there is no standalone app like Keybase has for the non-browser usage?
make basic cryptography operations accessible to regular humans
Keyoxide.org 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.
What level of knowledge does this product expect of users, though? I have only the vaguest idea what this means, so I don’t know why I would reach for this product, and I’m a programmer by trade, not even a “regular human”. Maybe this language was more intended for the usual audience of the blog?
It aims to be mostly used by people not knowing how to work with PGP. The rationale is: if you have a keypair, you probably (should) know your way around PGP to get the most out of it.
However, the (public) key is not just for your own usage as the owner of it. Others can use it to encrypt a message for you or verify one of your signatures. Keybase also allows easy encryption but only for the keys hosted on their own servers. Keyoxide can use any publicly available key using the existing infrastructure.
I certainly need to work on my communication skills. I hope this clarifies it a little.
You might want to choose a simpler wording for your fields. I was very confused when looking at this page: https://keyoxide.org/encrypt
There are 5 fields with different information to fill in order to encrypt a message, which is not really “easy” for non-initiated users (you have to know what an HKP server or web key directory is for example). I only realized that only one of those 3 fields is necessary to encrypt the message later, and that’s because I have basic understanding of PGP.
On the other hand, the keybase counterpart your provided seems way more noob-friendly: huge area for the message, and a field for “whom” the message is for. No mention of “keys” or “servers” that would confuse someone that knows nothing about crypto.
Absolutely agreed, my biggest gripe as well. I’ve been experimenting with several layouts, still haven’t quite found the balance between “giving choice” and “making it clear what exactly needs to happen”!
One of these iterations, I’ll get it right! When I do, I’ll let you know :) thanks for the comment!
Most OpenPGP usage is not using authenticated encryption, but instead has sign and encrypt as two separate steps. If you encrypt only, without signing, in PGP then your messages are subject to tampering in ways which can have unpleasant consequences.
Honestly, I applaud the attempt, but sadly it’s not enough. PGP key model IMO is fundamentally broken and anything new based on it will carry the same problems that it has.
Thanks. Looks pretty good! The “encrypt message” and “verify message” links have the last dot replace with an underscore in them, which then causes the page that loads up when clicking them to not work right.
The fingerprint is also a link to the key on the default keyserver. This is totally fine, but maybe a link to the WKD would be better for a WKD profile?
Ok, one more thing I noticed because of the hoop-jumping for the keyserver: the profile page happily shows revokes UIDs. For example, my gmail address is revoked in my key but is shown on the WKD profile page.
When using the profile view, keys are only fetched from https://keys.openpgp.org . This is the default keyserver everywhere on the website, but you always get a form with the possibility to overrule which keyserver is used. Since this profile page doesn’t have this possibility, it just uses https://keys.openpgp.org .
I’ve seen this before. Using https://dump.sequoia-pgp.org , I can see there are no identities inside the key. The keyserver does this to new keys when the uploader hasn’t confirmed the upload yet by clicking a link sent by email. Could this be happening?
Oh, weird. I’d never seen this keyserver before, so didn’t know they wanted me to go in and provide “consent” to distribute my public information that they presumably got from another keyserver already distributing it :P
I’m jumping through this hoop now, so hopefully that fixes it.
Interesting, will look into this. Thing is that 1) this defeats the purpose of decentralized identity proof and 2) Github is already supported in a manner that does respect decentralized identity proofs. But I’ll still have a look!
Would they understand/believe/trust that everything is done client-side? How do they know that the server isn’t reading their messages?
This feels a bit like the olden days, when many people were illiterate, so they had to pay a scribe to read or write for them if they received or wanted to send a letter.
I think what I’m trying to say is that this looks like asking a third party to help, rather than using a tool to do it yourself. Rightly or wrongly, many people would trust a tool where they wouldn’t trust a person.
I could imagine my family not even understanding the difference between client-side and server-side execution, let alone the benefits.
The intent for this tool is to be trusted by people who do understand how it works and recommend it to those who don’t. Currently, Keybase fills that gap the best, except I know many people who understand how Keybase works, do not appreciate it but are still forced to recommend it because of a lack of a better alternative.
Works are underway to have more (non-web) tools that can verify the identity proofs, but with regards to this particular instance, Keyoxide.org, the “regular human” might as well assume it’s as evil as any other corporate service and I couldn’t do a thing about that perception. I can only hope those who appreciate the inner workings of it to deliver the “you can trust this” message.
You want to use
urlencode()instead ofhtmlspecialchars()here: https://codeberg.org/yarmo/keyoxide/src/branch/main/server/verifyLobsters.php#L3With htmlspecialchars() a
&will become&, but you want%26. I’m not 100% sure if it’s a security problem as such, but it’s certainly incorrect. Same applies in some other places.Thanks, fixed it! https://codeberg.org/yarmo/keyoxide/commit/34cb9a073caae0a6a980bbbfd8cafc7c7817074f
Nice idea. You’ll need to work on your security against XSS and local/remote file inclusion attacks. I’ll send you a DM.
Since this loads all of its code live from an HTTPS website through the browser, its security boils down to the security of TLS and the WebPKI. On top of that the user is also trusting the website operator, the openpgpjs codebase, and the proof verification implementation.
Instead of verifying a file through this, one could download it from an HTTPS URL with equivalent or better security. For encryption, the same holds for an HTTPS form.
Maybe I misinterpret the site author’s intent but for me this looks like just a convenience profile page + some utils. The same argument holds for Keybase that also has verify and encrypt pages. So while the “browser crypto is broken by design” point is valid it’s actually nothing new. I do admit that the author could clarify this better on the page.
Or are you pointing out that there is no standalone app like Keybase has for the non-browser usage?
What level of knowledge does this product expect of users, though? I have only the vaguest idea what this means, so I don’t know why I would reach for this product, and I’m a programmer by trade, not even a “regular human”. Maybe this language was more intended for the usual audience of the blog?
It aims to be mostly used by people not knowing how to work with PGP. The rationale is: if you have a keypair, you probably (should) know your way around PGP to get the most out of it.
However, the (public) key is not just for your own usage as the owner of it. Others can use it to encrypt a message for you or verify one of your signatures. Keybase also allows easy encryption but only for the keys hosted on their own servers. Keyoxide can use any publicly available key using the existing infrastructure.
I certainly need to work on my communication skills. I hope this clarifies it a little.
You might want to choose a simpler wording for your fields. I was very confused when looking at this page: https://keyoxide.org/encrypt
There are 5 fields with different information to fill in order to encrypt a message, which is not really “easy” for non-initiated users (you have to know what an HKP server or web key directory is for example). I only realized that only one of those 3 fields is necessary to encrypt the message later, and that’s because I have basic understanding of PGP.
On the other hand, the keybase counterpart your provided seems way more noob-friendly: huge area for the message, and a field for “whom” the message is for. No mention of “keys” or “servers” that would confuse someone that knows nothing about crypto.
Absolutely agreed, my biggest gripe as well. I’ve been experimenting with several layouts, still haven’t quite found the balance between “giving choice” and “making it clear what exactly needs to happen”!
One of these iterations, I’ll get it right! When I do, I’ll let you know :) thanks for the comment!
Uploaded a new design, this should clear up that confusion :)
Most OpenPGP usage is not using authenticated encryption, but instead has sign and encrypt as two separate steps. If you encrypt only, without signing, in PGP then your messages are subject to tampering in ways which can have unpleasant consequences.
This tool might need to become verification-only.
Honestly, I applaud the attempt, but sadly it’s not enough. PGP key model IMO is fundamentally broken and anything new based on it will carry the same problems that it has.
my key fails to load https://keyoxide.org/59E682C3EAF39A210CA73534D11C2911CE519CDE
Trying with WKD (https://keyoxide.org/[email protected]) I see:
TypeError: keyData.publicKey.users[i].userId is nullThanks for the report! I have just pushed a fix, it seems to be working for me now.
Thanks. Looks pretty good! The “encrypt message” and “verify message” links have the last dot replace with an underscore in them, which then causes the page that loads up when clicking them to not work right.
The fingerprint is also a link to the key on the default keyserver. This is totally fine, but maybe a link to the WKD would be better for a WKD profile?
Fixed WKD links on WKD profiles.
Thanks!
Ok, one more thing I noticed because of the hoop-jumping for the keyserver: the profile page happily shows revokes UIDs. For example, my gmail address is revoked in my key but is shown on the WKD profile page.
That’s bad! Added to top of todo, thanks for letting me know!
The dot/underscore thing is strange, I’ll look into it right away.
WKD links for a WKD profile make a whole lot of sense :) will be fixed today.
When using the profile view, keys are only fetched from https://keys.openpgp.org . This is the default keyserver everywhere on the website, but you always get a form with the possibility to overrule which keyserver is used. Since this profile page doesn’t have this possibility, it just uses https://keys.openpgp.org .
It appears to be there: https://keys.openpgp.org/search?q=59E682C3EAF39A210CA73534D11C2911CE519CDE
I’ve seen this before. Using https://dump.sequoia-pgp.org , I can see there are no identities inside the key. The keyserver does this to new keys when the uploader hasn’t confirmed the upload yet by clicking a link sent by email. Could this be happening?
Oh, weird. I’d never seen this keyserver before, so didn’t know they wanted me to go in and provide “consent” to distribute my public information that they presumably got from another keyserver already distributing it :P
I’m jumping through this hoop now, so hopefully that fixes it.
Indeed it is! Really strange, looking into this today
Add support for GitHub keys, e.g. https://github.com/puffnfresh.keys
Interesting, will look into this. Thing is that 1) this defeats the purpose of decentralized identity proof and 2) Github is already supported in a manner that does respect decentralized identity proofs. But I’ll still have a look!
How would a ‘regular human’ perceive this site?
Would they understand/believe/trust that everything is done client-side? How do they know that the server isn’t reading their messages?
This feels a bit like the olden days, when many people were illiterate, so they had to pay a scribe to read or write for them if they received or wanted to send a letter.
I think what I’m trying to say is that this looks like asking a third party to help, rather than using a tool to do it yourself. Rightly or wrongly, many people would trust a tool where they wouldn’t trust a person.
I could imagine my family not even understanding the difference between client-side and server-side execution, let alone the benefits.
The intent for this tool is to be trusted by people who do understand how it works and recommend it to those who don’t. Currently, Keybase fills that gap the best, except I know many people who understand how Keybase works, do not appreciate it but are still forced to recommend it because of a lack of a better alternative.
Works are underway to have more (non-web) tools that can verify the identity proofs, but with regards to this particular instance, Keyoxide.org, the “regular human” might as well assume it’s as evil as any other corporate service and I couldn’t do a thing about that perception. I can only hope those who appreciate the inner workings of it to deliver the “you can trust this” message.