Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Key discovery #14

Open
kmarekspartz opened this issue Sep 25, 2018 · 7 comments
Open

Key discovery #14

kmarekspartz opened this issue Sep 25, 2018 · 7 comments
Labels
discussion Ideas worth discussing enhancement New feature or request

Comments

@kmarekspartz
Copy link

Can the protocol be used to discover keys of other participants? Can a revoke be announced? Can keys automatically rotate?

I suspect not today, and that’s fine. Neat project!

@brannondorsey brannondorsey added enhancement New feature or request discussion Ideas worth discussing labels Sep 25, 2018
@brannondorsey
Copy link
Owner

I'm glad you brought this up. A feature similar to this is something that I've been considering, but I didn't want to put the cart before the horse. I was imagining implementing a system whereby users would automatically sign the public keys of other stations they trust, (chattervox addkey would add the key, and sign it with your private key). I was imagining certain message payloads could then trigger automatic commands by the client application (similar to irc).

Something like /requestkey KC3LZO typed in to chat would broadcast a message to all stations listening and if any of them had KC3LZO's key AND you trusted the station that claims it does, it would message it back to you. This would allow you to create a classic web of trust, where new keys for stations you haven't chatted with before could be trusted depending on how many other stations you trust also trust that station.

I'd actually like to add all of the current cli subcommands to the chat by simply prefixing any message with /, for convenience (e.g. /genkey --make-signing).

@streeetlamp
Copy link

Would some sort of simple and totally volunteer directory of users who would like to discover/chat with others could sign up for be a short term solution? Simple app, wiki page, etc?

@brannondorsey
Copy link
Owner

brannondorsey commented Oct 9, 2018

I like that idea, and not just as a short term solution. I still think some kind of key exchange mechanism built into the TypeScript client would be nice, but a shared registry actually serves a different and useful purpose. Like the MIT PGP key server.

Here are a few solutions I can think of off the top of my head. Suggestions welcome...

  • A chattervox-keys GitHub repository. Each key could be stored in a flat file using the callsign as the filename.
    • Pros
      • GitHub profiles can act as real-world identity proofs
      • Free public hosting on the web
      • GitHub API could be used to automatically fetch keys
      • Changes to a callsign's keys can be limited to the original submitter only
      • A human can vet the submitter's identity
      • Anyone can propose a key addition using a PR
    • Cons
      • A central gatekeeper (repo owner or admins)
      • Keys can't be added without a GitHub account
  • A public wiki site
    • Pros
      • Anyone can add keys without a gatekeeper
    • Cons
      • Unauthorized third parties can make changes to existing keys
  • Use IPFS (and IPNS) to host a centrally controlled list in a distributed manner. This solution is similar drawbacks to the GitHub repository solution with the added bonus of content distribution (no single point of failure).
  • Create an Ethereum Dapp for storing keys
    • Pros
      • Totally distributed with no gatekeeper
      • Smart contract could allow users to sign each other's keys
      • It's what the cool kids would do
    • Cons
      • Transaction fees for each addition, change, or signature
      • High barrier to entropy
      • Lots of work and probably not worth it. Might be fun though.
      • It's what the cool kids would do

I'd lean towards the GitHub registry as it's easy and would be simple and effective but it's easy to trust myself, so I'd welcome criticism of that idea too. Whatever solution we choose (or is proposed down the line) should incorporate the ability for users to verify each other's identities by signing each other's keys. Another thought, although I'm not sure how it fits into all of this right now, is to somehow incorporate Keybase into the equation. Perhaps keys could be signed using keybase keys, amplifying the web of trust.

Also, don't mean to creep your bio but shout out RVA, that's my hometown 🙃

@streeetlamp
Copy link

I prefer the simple and easy even if it leaves some trust up to owners. Someway of using keybase is interesting as heck too but flat files are flat files and I like the idea of adding your key via a PR. Lots of pro's and only a few downsides. I would be surprised if someone messing with this stuff wouldn't have a GH account but I guess the microsoft thing drove some off.

Also HI FROM RVA it's still pretty hot !

@jedahan
Copy link

jedahan commented Oct 10, 2018

+1 for starting simple with just a wiki page or github repo + PRs
I was seeing if there was some hacky way to add our own metadata to the FCC registry but I couldn't find one.

@brannondorsey
Copy link
Owner

Alrighty, I hear y'alls requests and have made a public key registry on GitHub at brannondorsey/chattervox-keys. Would love it if y'all would go through the motions of adding your keys and let me know what you think. Open to suggestions, but this was the quick solution, and I think I'm pleased with it. Let me know if y'all have any Qs.

@zhaofengli
Copy link

This is more related to key verification than discovery, but operators could use LotW's RSA keypair to sign (and for others, to verify) their chattervox key to ensure legitimacy. AMPRNet uses those keys to restrict VPN access to licensed hams.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Ideas worth discussing enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants