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

Show HN: Dat-keyserver: a distributed PGP keyserver based on the Dat protocol(github.com)

106 points by tdjsnelling 6 years ago | 30 comments

jnbiche 6 years 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 6 years 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/

livueta 6 years 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

progval 6 years 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/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/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)

wesleytodd 6 years 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.

dang 6 years ago | | |

> Ha, omg this is impossible to read

Please edit swipes like this out of your HN comments, particularly in Show HN threads: https://news.ycombinator.com/showhn.html.

buu700 6 years ago | | |

It's also incorrect usage of promises; idiomatically no part of that code should be nested more than two levels deep. But yeah, async/await would be both cleaner to read and easier to write correctly.

(Ultimately a minor issue at this stage of what's otherwise a really neat project!)

namibj 6 years 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 6 years ago | | |

Diff-so-fancy [1] is even better at visualizing this, in my opinion.

[1] https://github.com/so-fancy/diff-so-fancy

dbetteridge 6 years ago | |

Would agree, my personal preference with this would be functions for each of the if/else cases for some extra readability/documentation.

AgentME 6 years ago | |

The linked code block is basically the poster child of why async/await was made.

vimslayer 6 years ago | | |

Even without async/await, it could be better if some unnecessary nesting would be cleaned up

    openpgp.cleartext
      .readArmored(req.body.message)
      .then(message => {
        openpgp.key
          .readArmored(nodes[0].value.key)
          .then(key => {
            ...
          })
      })

could be

    openpgp.cleartext
      .readArmored(req.body.message)
      .then(message =>
        openpgp.key.readArmored(nodes[0].value.key)
      )
      .then(key => {
        ...
      })

fwip 6 years ago |

I'm concerned about the key-removal functionality. The website (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.

tdjsnelling 6 years ago | |

That is something glaringly obvious that I should have considered, thanks for pointing it out. I'll make the change to require a specific message.

a1369209993 6 years ago | | |

Probably glaringly obvious (but in this case also), but you should make sure that the specific message starts with something highly conspicuous like "DAT KEYSERVER KEY REVOCATION REQUEST ID#<token>" to avoid social engineering someone with "Hey can you sign this token so I know you're you?".

Deadsunrise 6 years 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.

sp332 6 years 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.

daxelrod 6 years 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.

edwintorok 6 years ago | | |

GnuPG generates a revocation certificate when you're creating a new key, import that and it requires no interaction from you or the keyserver operator. And it works even if you've forgotten the passphrase of your GPG key. Obviously you don't want to put that file anywhere public, and if it gets compromised you can just publish the file to the keyservers yourself and generate a new key.

Leace 6 years ago |

Project looks definitely interesting. Too bad the code looks like callback-hell from 10 years ago: https://github.com/tdjsnelling/dat-keyserver/commit/12fa3e83...

Still, an interesting alternative for people who consider https://keys.openpgp.org too radical.

snek 6 years ago | |

OP, please Google "promise chaining", it will make your life so much better.

sltkr 6 years ago | | |

At that point, why not go straight to async functions?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

openpgp.cleartext .readArmored(req.body.message) .then(message => { openpgp.key .readArmored(nodes[0].value.key) .then(key => { ... }) })