6 ms·

Show HN: Dat-keyserver: a distributed PGP keyserver based on the Dat protocol

106 points by tdjsnelling 7y ago

jnbiche 7y ago
I like the ability to remove keys. I understand the theoretical reason for append-only keyservers, but in practice it just turns people off from using them. No one wants to look at their entries from 2005 from when they screwed up while learning about subkeys, or their defunct 2008 entry which they never could revoke because they lost the revocation certificate (all examples purely fictional). In any case, a keyservers job is not even to be some kind of source of trust, so all that really should matter is that it has a user's most up-to-date keys on it. Validating a key should come from web-of-trust or some secure second channel verification method (like listing your key ID on a TLS-enabled website).
- Leace 7y ago
  > No one wants to look at their entries from 2005 from when they screwed up while learning about subkeys Yeah, it's interesting that even platforms such as Keybase that allow changing or removing data timestamp them in irremovable ways sometimes (e.g. following someone snapshots their profile in the follower's sigchain). > In any case, a keyservers job is not even to be some kind of source of trust, so all that really should matter is that it has a user's most up-to-date keys on it. Validating a key should come from web-of-trust or some secure second channel verification method. Actually having a key on a keyserver was never relevant as web-of-trust runs parallel to the key origin (that is if you're connected to WoT you'd know which key is the real one). But it's not practical in general. > like listing your key ID on a TLS-enabled website Web Key Directory is something like that and it's trivial to set up: https://spacekookie.de/blog/usable-gpg-with-wkd/ https://spacekookie.de/blog/usable-gpg-with-wkd/
- livueta 7y ago
  I assume a bigger justification for not running an append-only keyserver was this dumpster fire[1] in which the append-only nature of the SKS keyserver ecosystem was abused as a DOS vector. --- [1] https://news.ycombinator.com/item?id=20312826 https://news.ycombinator.com/item?id=20312826
Leace 7y ago
Project looks definitely interesting. Too bad the code looks like callback-hell from 10 years ago: https://github.com/tdjsnelling/dat-keyserver/commit/12fa3e8389a6f90d312e1e664006df4d8391ecd5 https://github.com/tdjsnelling/dat-keyserver/commit/12fa3e83... Still, an interesting alternative for people who consider https://keys.openpgp.org https://keys.openpgp.org too radical.
- snek 7y ago
  OP, please Google "promise chaining", it will make your life so much better.
  - sltkr 7y ago
    At that point, why not go straight to async functions? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    - agentultra 7y ago
      At that point, why not go straight to monads? https://github.com/fluture-js/Fluture/tree/11.x https://github.com/fluture-js/Fluture/tree/11.x
      - vimslayer 7y ago
        Because one is a language feature and the other is yet another JS library made by some person.
    - ofrzeta 7y ago
      I don't really get why people need to use async methods (regardless if they are promises or something else) when in fact they are implementing a blocking workflow where one method call needs the results of a preceding method call. It would be much easier to just use synchronized/blocking functions because then you get the desired behaviour for free and need not jump through hoops like promises chaining. I get that there are APIs that are only available in an async fashion these days and I was forced to bolt on an blocking workflow on an async API myself and didn't particularly enjoy it.
fwip 7y ago
I'm concerned about the key-removal functionality. The website (https://keys.tdjs.tech https://keys.tdjs.tech) reads: "Enter a message clearsigned with the key you wish to remove (message content is not important)" My understanding of this is that anyone with a copy of anything you've ever signed can revoke your key. I hope I'm misunderstanding.
- Deadsunrise 7y ago
  The message has to be signed with the private key of the key so no one but the real owner can delete it. In fact, in the readme: > If a user can prove that a key belongs to them (by signing a message with their private key) then they are able to remove their public key with no interaction needed from the server operator. Once a key is removed, it is removed from all servers in the pool. This is a pretty fucking awesome idea.
  - daxelrod 7y ago
    The attack that I believe fwip is concerned about is: Alice sends an email to Bob and clearsigns the message. Bob, or anyone else who intercepts the email is now able to paste that message into the form and remove Alice's key from the keyserver. This could be mitigated by requiring it to be a specific message.
  - sp332 7y ago
    To prove that you have the private key, they should send you a challenge message and make you send back that message with a signature. If you can send any signed message, anyone who has ever received a signed message from a person can upload it and revoke that person's key.
    - progval 7y ago
      > If you can send any signed message Reading the code, it does indeed allow any signed message: https://github.com/tdjsnelling/dat-keyserver/blob/12fa3e8389a6f90d312e1e664006df4d8391ecd5/index.js#L288-L369 https://github.com/tdjsnelling/dat-keyserver/blob/12fa3e8389...
progval 7y ago
I'm not fluent in modern JS, but I think the level of callbacks nesting makes it hard to see what else/catch belong to what if/then, especially: https://github.com/tdjsnelling/dat-keyserver/blob/12fa3e8389a6f90d312e1e664006df4d8391ecd5/index.js#L288-L369 https://github.com/tdjsnelling/dat-keyserver/blob/12fa3e8389... You could try splitting this big function into smaller functions to reduce the length of the code largest callbacks. It also makes commits harder to read. eg. for https://github.com/tdjsnelling/dat-keyserver/commit/12fa3e8389a6f90d312e1e664006df4d8391ecd5 https://github.com/tdjsnelling/dat-keyserver/commit/12fa3e83... a reader can't see easily what changed in the function, as every line's indentation was changed. (And the commit message does not explain what the bug was)
- dbetteridge 7y ago
  Would agree, my personal preference with this would be functions for each of the if/else cases for some extra readability/documentation.
- namibj 7y ago
  I can greatly recommend git log -p --color-words git show --color-words <commut-ref> for that problem. There are weaker options to only ignore indentation, iirc.
  - atombender 7y ago
    Diff-so-fancy [1] is even better at visualizing this, in my opinion. [1] https://github.com/so-fancy/diff-so-fancy https://github.com/so-fancy/diff-so-fancy
- wesleytodd 7y ago
  Ha, omg this is impossible to read. Using async/await here would go a long way to helping. But honestly this just seems like a work in progress, so code cleanliness and ability for others to read and contribute might not be the focus. Also, generally people do not put all their logic in the same file , in express apps. Just breaking out the business logic from the express app setup would also help to make it more readable/understandable.
marknadal 7y ago
Yeah, most dWeb protocols can't handle updating/changing data. I highly recommend you try out mine, as it supports mutable & immutable data (GUN https://github.com/amark/gun https://github.com/amark/gun ) AND cryptographic identities. We've seen a ton of companies move over to it: Internet Archive, DTube, HackerNoon, Notabug, etc. ~ 15M monthly active users, in production!

106 points by tdjsnelling 7y ago

I like the ability to remove keys. I understand the theoretical reason for append-only keyservers, but in practice it just turns people off from using them. No one wants to look at their entries from 2005 from when they screwed up while learning about subkeys, or their defunct 2008 entry which they never could revoke because they lost the revocation certificate (all examples purely fictional). In any case, a keyservers job is not even to be some kind of source of trust, so all that really should matter is that it has a user's most up-to-date keys on it. Validating a key should come from web-of-trust or some secure second channel verification method (like listing your key ID on a TLS-enabled website).

Leace 7y ago
> No one wants to look at their entries from 2005 from when they screwed up while learning about subkeys Yeah, it's interesting that even platforms such as Keybase that allow changing or removing data timestamp them in irremovable ways sometimes (e.g. following someone snapshots their profile in the follower's sigchain). > In any case, a keyservers job is not even to be some kind of source of trust, so all that really should matter is that it has a user's most up-to-date keys on it. Validating a key should come from web-of-trust or some secure second channel verification method. Actually having a key on a keyserver was never relevant as web-of-trust runs parallel to the key origin (that is if you're connected to WoT you'd know which key is the real one). But it's not practical in general. > like listing your key ID on a TLS-enabled website Web Key Directory is something like that and it's trivial to set up: https://spacekookie.de/blog/usable-gpg-with-wkd/ https://spacekookie.de/blog/usable-gpg-with-wkd/
livueta 7y ago
I assume a bigger justification for not running an append-only keyserver was this dumpster fire[1] in which the append-only nature of the SKS keyserver ecosystem was abused as a DOS vector. --- [1] https://news.ycombinator.com/item?id=20312826 https://news.ycombinator.com/item?id=20312826

Leace 7y ago

Project looks definitely interesting. Too bad the code looks like callback-hell from 10 years ago: https://github.com/tdjsnelling/dat-keyserver/commit/12fa3e8389a6f90d312e1e664006df4d8391ecd5 https://github.com/tdjsnelling/dat-keyserver/commit/12fa3e83... Still, an interesting alternative for people who consider https://keys.openpgp.org https://keys.openpgp.org too radical.

snek 7y ago
OP, please Google "promise chaining", it will make your life so much better.
- sltkr 7y ago
  At that point, why not go straight to async functions? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - agentultra 7y ago
    At that point, why not go straight to monads? https://github.com/fluture-js/Fluture/tree/11.x https://github.com/fluture-js/Fluture/tree/11.x
    - vimslayer 7y ago
      Because one is a language feature and the other is yet another JS library made by some person.
  - ofrzeta 7y ago
    I don't really get why people need to use async methods (regardless if they are promises or something else) when in fact they are implementing a blocking workflow where one method call needs the results of a preceding method call. It would be much easier to just use synchronized/blocking functions because then you get the desired behaviour for free and need not jump through hoops like promises chaining. I get that there are APIs that are only available in an async fashion these days and I was forced to bolt on an blocking workflow on an async API myself and didn't particularly enjoy it.

fwip 7y ago

I'm concerned about the key-removal functionality. The website (https://keys.tdjs.tech https://keys.tdjs.tech) reads: "Enter a message clearsigned with the key you wish to remove (message content is not important)" My understanding of this is that anyone with a copy of anything you've ever signed can revoke your key. I hope I'm misunderstanding.

Deadsunrise 7y ago
The message has to be signed with the private key of the key so no one but the real owner can delete it. In fact, in the readme: > If a user can prove that a key belongs to them (by signing a message with their private key) then they are able to remove their public key with no interaction needed from the server operator. Once a key is removed, it is removed from all servers in the pool. This is a pretty fucking awesome idea.
- daxelrod 7y ago
  The attack that I believe fwip is concerned about is: Alice sends an email to Bob and clearsigns the message. Bob, or anyone else who intercepts the email is now able to paste that message into the form and remove Alice's key from the keyserver. This could be mitigated by requiring it to be a specific message.
- sp332 7y ago
  To prove that you have the private key, they should send you a challenge message and make you send back that message with a signature. If you can send any signed message, anyone who has ever received a signed message from a person can upload it and revoke that person's key.
  - progval 7y ago
    > If you can send any signed message Reading the code, it does indeed allow any signed message: https://github.com/tdjsnelling/dat-keyserver/blob/12fa3e8389a6f90d312e1e664006df4d8391ecd5/index.js#L288-L369 https://github.com/tdjsnelling/dat-keyserver/blob/12fa3e8389...

progval 7y ago

I'm not fluent in modern JS, but I think the level of callbacks nesting makes it hard to see what else/catch belong to what if/then, especially: https://github.com/tdjsnelling/dat-keyserver/blob/12fa3e8389a6f90d312e1e664006df4d8391ecd5/index.js#L288-L369 https://github.com/tdjsnelling/dat-keyserver/blob/12fa3e8389... You could try splitting this big function into smaller functions to reduce the length of the code largest callbacks. It also makes commits harder to read. eg. for https://github.com/tdjsnelling/dat-keyserver/commit/12fa3e8389a6f90d312e1e664006df4d8391ecd5 https://github.com/tdjsnelling/dat-keyserver/commit/12fa3e83... a reader can't see easily what changed in the function, as every line's indentation was changed. (And the commit message does not explain what the bug was)

dbetteridge 7y ago
Would agree, my personal preference with this would be functions for each of the if/else cases for some extra readability/documentation.
namibj 7y ago
I can greatly recommend git log -p --color-words git show --color-words <commut-ref> for that problem. There are weaker options to only ignore indentation, iirc.
- atombender 7y ago
  Diff-so-fancy [1] is even better at visualizing this, in my opinion. [1] https://github.com/so-fancy/diff-so-fancy https://github.com/so-fancy/diff-so-fancy
wesleytodd 7y ago
Ha, omg this is impossible to read. Using async/await here would go a long way to helping. But honestly this just seems like a work in progress, so code cleanliness and ability for others to read and contribute might not be the focus. Also, generally people do not put all their logic in the same file , in express apps. Just breaking out the business logic from the express app setup would also help to make it more readable/understandable.

marknadal 7y ago

Yeah, most dWeb protocols can't handle updating/changing data. I highly recommend you try out mine, as it supports mutable & immutable data (GUN https://github.com/amark/gun https://github.com/amark/gun ) AND cryptographic identities. We've seen a ton of companies move over to it: Internet Archive, DTube, HackerNoon, Notabug, etc. ~ 15M monthly active users, in production!