Keys.pub – Manage cryptographic keys and user identities | Hacker News Reader

Keys.pub – Manage cryptographic keys and user identities

keys.pub

386 pointsqertoip88 comments

This loses something important about Keybase sigchains: on Keybase, a sigchain represents an identity and not a single key, which makes it possible to add separate keys for different devices and to seamlessly replace and revoke keys over time. (Non-key-specific sigchains let the Keybase client do interesting things like automatically re-encrypting shared data when someone revokes an old key.)

Tying sigchains to keys seems limiting, and I'm curious if there's a reason for it. Otherwise, I like this a bunch.

Indeed, in a perfect UX you'd never manipulate keys, always identities; that gives keys less importance and allow them to be rotated in a period that's closer to 10 weeks than 10 years. Also, exchanges are done with identities, not keys.

80/20 rule? Make the problem simpler and deliver a better solution for it. Revisit and grow the problem space as needed.

I, for one, am happy Keybase user, excited about their new features and can see it already becoming a much better (but not ideal) alternative to Signal for private IM (proper encryption, every device is first-class, usable CLI, no phone-number bullshit, good team chats, etc).

But I do see that the same reason I am optimistic is the same reason many users are disappointed and they're right - Keybase seems to have pivoted and they are headed in a completely different direction than they were when we joined.

Keys.pub looks to fulfill precisely the promise of "what Keybase was supposed to be". And crucially, I think; looks to be fully open source (server-side included, no sketchy opaque metadata spider-web by a US corporate).

I do see these two projects as fully complementary.

It would be interesting if this could, optionally, import pubkeys from Keybase as well. I think these could be complementary.

Agree. This could be a useful way to expand the ecosystem that Keybase kick-started. We really need a modern alternative to the PGP ecosystem, and Keybase has been clear that they only want to do a subset of that.

Of course I also really like the client-facing stuff that Keybase has done. Roll out hasn't been perfect, but they provide a lot of useful, secure collaboration tools.

Keybase jumped the shark with their crypto coin offering.

I keep hearing people say this, but I don't understand it. It was a fun little giveaway experiment funded by someone else, in the spirit of the company's focus on cryptography.

I don't visit the cryptocurrency tab anymore, and it's not like it gets in the way or anything.

> It was a fun little giveaway experiment funded by someone else, in the spirit of the company's focus on cryptography.

It was not "someone else". Keybase is directly funded by Stellar (source: https://keybase.io/blog/keybase-stellar) and the crypto offering was just a PR/marketing move to increase adoption for crypto of Stellar not something "in the spirit of the company's focus on cryptography".

It was a trainwreck that damaged the project's reputation and harmed its users.

If you know crypto, it had several problems. There are worse coins to airdrop on your users but not many. The user experience resembled that used by scammers on Telegram and the project's overall behaviour looked like a de-anonymization attack (I mean that seems to be Keybase's business model but this looked exactly like one). All of this led to crypto chats on Keybase being targeted by social engineering attacks, and Keybase's famously bad moderation tools made that much harder to deal with than it could have been.

If you don't know crypto it made Keybase look like a crazy crypto project, which isn't an easy sell.

In either case you could be forgiven for wondering when Keybase got their money transmitter license.

So this did get in the way, and the sooner Keybase remove the tab the sooner it will be clear that they are past the denial stage.

This was a bad enough fuck-up that I removed my social proofs and now recommend that people not use Keybase. But if they fixed a few things (remove the Crypto tab, fix moderation, fix name changes) I'd pay them a subscription in a heartbeat.

> This was a bad enough fuck-up that I removed my social proofs and now recommend that people not use Keybase

What do you recommend people use instead?

In all honesty I believe the crypto offerings were a smart idea that didn’t undermine Keybases reputation , it attempted to highlight a user friendly exchange of Stellar and any further crypto to come along . What did undermine the reputation was allowing a system that could be scammed which called for the closing of the offering . Clearly not thought out enough .

I for one didn’t appreciate being spammed by them in the app I only keep running for secure private messages.

They added a wallet feature that was compatible with an existing crypto coin, there was no offering.

This is very misleading, they didn't "offer" any coin, and they don't have their own coin. They added a wallet for a coin that already existed. A pretty good wallet, too.

It seems this has literally nothing to do with the main functionality of keybase though.

>proper encryption

Keybase does not have PFS, unfortunately...

One of the things I liked about keybase is that it pooled identity proofs from different providers. If somebody manages to replace a proof in my gihub account, other people can (independently) verify that there is something wrong.

I'm not sure if I misread the documentation, but it seems that with keys.pub each "service" offers a disconnected world. If somebody manages to publish a proof in my github account, it can trick people using keys.pub to think that's still me.

OTOH, with keys.pub I don't need to trust any server.

Am I misunderstanding something?

Lots of keybase early users here. I started really using it relatively recently, and mostly like it, regardless of "losing its way".

What I use are is the chat, git and filesystem. Verifying other people's identities - not so much.

The only problems are related to the GUI having hiccups, opening images posted to the chat, say. Git and filesystem are relatively slow, but can live with that.

I feel like if they did some decoupling and got rid of the persistent running connection / filesystem stuff for features that did not need it as a mandatory thing that early users wouldn't mind as much. For all I know it actually does work that way too.

I was a very early user of Keybase and I've been super disappointed in the direction they've gone. They've had some neat ideas along the way but packing them onto the key service and the cryptocurrency missteps have caused me to shy away from them.

This looks like a good start for a real competitor. Obviously it's early but I'm seeing the right things.

I see this from a lot of people and I'm puzzled, can you not just avoid using the features you don't like? I don't see anyone going "I used to use VS Code but they added a database viewer so I stopped".

This is kind of different. It’s more like, “I used this database viewer and suddenly it became VS Code”. It used to be something lean and simple, but now you’re simply not the target audience anymore at all.

I'm one of those people, and the thing that worries me is the huge amount of code that I'm not interested in that is hovering around my keys. If it was a collection of smaller tools I doubt I'd feel the same, but as things stand grabbing a binary means a 500mb installed package with very little functionality I actually want.

Not that I'm saying they should support just me, everyone has their own set of a magical does-just-enough feature set.

I stopped using Keybase when they started sending me cryptocurrency spam.

No. When they started doing cryptocurrency spam every device I had Keybase on alerted me to each new message, even with the spamming bot blocked

> can you not just avoid using the features you don't like

No: people cat take a moral stance against things that look sleazy like asking for uploading private keys or trying to sell cryptocurrencies.

> can you not just avoid

"can you just" is a bit patronizing, would you mind not using that tone?

The keybase client went from a small CLI to a persistently connected app that ties into a filesystem, cryptocurrency platform, chat ecosystem and more.

Nothing is free. Adding features takes up resources, adds complexity and errors and increases attack surface. Sometimes that's an OK tradeoff - I like being able to see images in my email client. Sometimes the tradeoff is not worth it - my text centric IDE has no business touching database files.

That's fair, my question was more about the cryptocurrency feature specifically. "General bloat" I can understand, if you only care about the keys.

It seems to me, though, that the key part is just the first step in an entire featureset: Once you have a reliable way to get trusted encryption keys for any person, you can build a whole lot of useful functionality on top of that, which is what they've been doing.

Personally, I wouldn't have much use for just the key exchange, and I really like the encrypted chat/repos/files/etc on top, but I can understand different preferences there.

The entire cryptocurrency airdrop thing has caused lots of noise, triggered campaigns to try and hack/social engineer accounts that would qualify the attacker to grab more cryptocurrency, ... It makes it vastly less likely I'll recommend Keybase with those associations, which diminishes the value of the "key part". (Not recommending it both because it makes me question the long-term priorities of the product and because I don't want to explain why I'm recommending "weird cryptocurrency-stuff", which is the impressions others could have)

Isn't Keybase built exactly for this though? To be able to look at the connected accounts/proofs, and know that a given Keybase user has proven control of those accounts? An attacker looking for crypto may have hacked someone's HN or GitHub. However, with Keybase, you can establish someone you want to talk to has linked their Twitter and their web domain and the like, whereas an attacker probably does not have access to all of their various identities around the Internet.

Keybase promised to give out free cryptocurrency to everyone who linked an existing Github and HN account, which lead to an attack wave on such accounts from people wanting to claim that: https://essays.suryad.com/hnhack/

If you are an identity service and do things that paint a target on others online identities, causing attackers to want to link my account with their fake accounts on your service for profit, you have an image problem. Similarly, that's not something I particularly want important services to be funded through long-term.

It would be possible to build an ignorable cryptocurrency feature, and if that had been the case, I probably wouldn't have noticed or cared. Instead Keybase tied into the launch of a questionable currency which involved giving the currency to people as a marketing tool and then resulted in a spree of attackers, disclosure attacks and other problems.

There's a difference between "Hey, we've built in a small wallet feature" and "Congratulations user, we've now given you 200 Lumens of tax liability and sent you marketing emails disguised as information, please prepare for a horde of hackers. Also we've fussed with your keys to make this new feature work. Thanks!"

> tied into the launch of a questionable currency

A small correction, Stellar/XLM has been around since 2014 [0]

[0]: https://en.wikipedia.org/wiki/Stellar_(payment_network)

I haven't found a use for it yet, but I'm not upset that they gave me money. It's the only crypto I've ever owned, but it's mine I guess?

Also, my understanding is (at least in the US) that you don't need to declare gifted cryptocurrency until/unless you realize it's value by either selling it or sending it to someone else as payment for a service.

What if there was a lightweight keybase cli that only did the basics (official or community)?

If they didn’t insist on putting a kext on my system (comes with the app for kbfs), or registering a persistent launchd agent that can’t be disabled (comes with the kbfs-free CLI, always reinstalls itself), then sure, I could ignore the features.

But they did, so their clients got kicked out of my system.

I also got spammy alerts mentioned by siblings (in email).

Keybase went from a command-line tool with a clear purpose to a behemoth requiring an installer, a resident daemon, and a permanent menu-bar icon. I can't even trust a tool that is so complex (and likely has a huge attack surface).

These days, I don't even know what keybase is for. What is it for, really?

I haven't followed them too closely for a while but wasn't the cryptocurrency misstep an answer to critics about the safety of keybase as keeper of the database[0]?

Now that I'm looking it although their docs don't mention anything[1] I'd assume it's related to their funding[2].

[0]: https://keybase.io/docs/server_security/merkle_root_in_stell...

[1]: https://keybase.io/docs/server_security/merkle_root_in_stell...

[2]: https://keybase.io/blog/keybase-stellar

> This project is in development and has not been audited.

I love seeing notes like this. Everyone needs to start somewhere, and for security projects there is a danger of overselling initially, which undermines credibility. This sounds like someone who understands that theres a lot of complex challenges to get this to production level security.

This seems like a cool project. Keybase has kinda lost it's way and has no idea what it is anymore. Where this seems pretty focused on doing one thing and one thing well.

Hi all,

I'm the author of keys.pub.

Can the mods change the title of this post at all? This project is meant to be supportive of ideas from Keybase and to promote Saltpack and this title is weirdly disparaging. (Edit: Title was changed, thanks!)

Thanks everyone for the feedback. This project is in its early stages but the goal is to make it easier to manage and securely store keys and secrets.

I'm currently working on hardware key support and FIDO2 integration, so be on the lookout for that.

You can reach the mods at hn@ycombinator.com

I am indeed glad I saw this comment, because as someone who likes Keybase, when I saw the title, I was like "ugh". Hopefully dang or sctb will edit it soon!

You might want to put some sort of identifying information about yourself somewhere, on the site or the github project? Maybe a key of some kind? :-)

Sure, no problem. I've used the HTML doc title but I had to shorten it to fit 80 chars. If there's a better—more accurate and neutral title—let us know.

(Submitted title was "Keys.pub – Keybase Without the Cruft".)

Edit: I changed the title to something the author suggested in an email. Before that it was "Keys.pub – Manage keys, sigchains, identities, signing, encryption, passwords".

That's great, thank you.

Your project is very cool. Could you help me fix my account though? I messed up two of the IDs: mfrager@github & mfrager@reddit. Will these be automatically purged from the keys.pub server after a certain amount of time for being invalid?

You can revoke, and generate them again, perhaps?

I was able to do that, yes.

What are the algorithms used for encryption? What are the defaults, do they now match the currently best known approaches?

Also why can't I use the application to do symmetric encryption? Namely the problem with GPG is that its defaults are still ancient (maybefor compatibility with whatever, I don't remember the excuse) and to reach the currently best settings one has to jump many, many hoops, even for simple task of symmetric encryption.

You're right - Key Management is (very) hard. It looks like you have some nice primitives there, personally I'd love to see you take a few weeks to discuss /gather feedback and refine your plans before copying the flawed Keybase approach wholly. I'm especially skeptical of the idea of linking 3rd party accounts into a global identity descriptor. Iirc there's also been some good Keybase criticism in previous HN threads.

In light of Zoom buying keybase (https://news.ycombinator.com/item?id=23102430), this project might be more interesting to users of keybase now.

I get that this is new and in development, but I'd really like to see a more in-depth comparison to keybase than:

> This project borrows many ideas from Keybase, including sigchains and user (proofs), and uses Saltpack and keybase/go-keychain and other packages. However, this project only links a single key to a user.

I say this while noting I've seen that "Better documentation" is an item in the todo list. However, it just isn't clear - to me - where they plan to move or draw a finish line for features.

If you have a better comparison please post it, and I guess a PR for the project too ;)

Keys seems to have taken the `back to the basics` approach and follow KISS to solve the original problem(s) Keybase was trying to solve (key & user ID management for human beings).

Obviously Keybase has strayed away from its original heart, added all those unrelated elements like social chat, Dropbox like (fuse) filesystem (this is actually OK), team collaboration, SCM, and even crypto currency wallet, so bloated [1], hmm... Do we really need all those? No for me, but I don't have a choice if I want to use the core bits and pieces (good part) of Keybase.

Glad to see Keys, gave it a try on Linux (thumbs up for packaging it using `AppImage` instead of snap or flatpak). However, it had gnome-keyring dependencies (wrong assumption that people use GNOME Shell or variants as default Desktop Environment), issue reported [2] and being worked on. I did run it in a Windows VM and it seems to be exactly what I need for key & user id management, looking forward to its development and adoption.

[1]: Keybase GUI for Linux https://pbs.twimg.com/media/EW0wKs4VcAAL3Qi?format=jpg

[2]: https://github.com/keys-pub/app/issues/6

One of the killer features for Keybase is the combination of teams + KeybaseFS. Unfortunately this doesn't look like it has either of those features.

That's the cruft. If they separated those out into separate apps, I'd be happy. It's an E2E-encrypted Slack-clone, public key management system, encrypted file storage, and a crypto wallet.

I guess one man's cruft is another man's crucial feature.

Precisely the reasoning for writing tools that do one thing very well.

There is a downside to that, though... an integrated product that can do more than one thing can often be easier to use than two separate ones

I wonder if Keybase could re-factor in a way that makes the core functions and various features available as small, focused tools, but still allows them to build the comprehensive binary for general users who want everything.

The problem with that is that it completely disregards one market, i.e., the one that wants an integrated system. You could probably install six programs that do these individual things, but then you'd have to install six programs. That's a non-starter for those looking for the integrated solution.

What if you made a unified installer that installs those six tools configured in a certain default way?

Certainly there are plenty programs that are designed modularly, componentized, plugin-based, compositional, whatever... They just never feel as good as purpose-built apps with good workflows. If you know of one that does, please do forward it on because I'd love the inspiration.

I think Keybase does what it intends to do, which is to make PKI accessible to non-experts and to cultivate a community of users achieve the usefulness that network effect affords.

If you're really just looking for encryption and signing, encrypted filesystems, encrypted chat, distributed filesystems, and you're an expert, you have the tools you need.

> They just never feel as good as purpose-built apps with good workflows. If you know of one that does, please do forward it on because I'd love the inspiration.

I think the flaw here is that you're (likely) comparing purpose-built with unrelated unix-like apps.

What could have been done here with Keybase, is a purpose built app composed of unix-like tools, all controlled and implemented towards the purpose-built app. Aka the IM would be unique if you wanted it, or bundled with the FS, but both would be first-class Keybase citizens.

Unfortunately most companies don't put the time or effort into letting people consume parts of their offerings. It's all or nothing. Which is the complaint here, imo.

Sounds interesting, how is this feature useful?

One way we use it is for shared team secrets (e.g. API tokens) in infrastructure scripts.

https://github.com/plyint/encpass.sh/blob/master/extensions/...

Used a similar strategy to great success at a previous startup for various credentials. Everything else had higher friction and was causing devs to do insecure things to avoid that friction.

Teams + git repositories for secrets is great too.

Makes it less likely that our secrets end up on Github where if Github were hacked, or an web account was hacked that our secrets become public.

This is very cool but I screwed up 2 of my "sigchains" to Reddit and to GitHub by deleting the underlying messages (I didn't realize I wasn't supposed to) so now two of my identities are messed up and I can't even use the app. I get this message: "panic: Unknown user status content-invalid (13)". Great project, but needs a better way to clean up invalid keys and re-issue them.

So there is no network that connects all the keys.pub clients together? Are you just supposed to do point-to-point connections through Wormhole? Still trying to understand it.

I keep hoping for a decentralized/federated network implementation for Keybase (or forked version) that will basically take the place of the centrally managed Keybase servers.

I might have to give this a try. Keybase has turned into something that I don't enjoy for a variety of reasons.

I think it might be a good idea to use something like IPFS to distribute keys. Now that cloudflare seems to want to support it officially, the only exception to why they might not are the same kind of lawsuits that brought down the pirate bay but cloudflare has opted to offer content blacklisting/cache refuse in their terms of service so I'm not sure how that's going to work out, but so far since 2018 nothing seems to have changed. I'm not really sure what their takeaway is though, it must provide them some benefit otherwise it's just a waste of their money to provide a gateway service. I'm not sure how well it's going to scale once people start building on it and actually use it more.

I want to add to that the ethereum name service, https://www.increaseo.com/eth-domains-ipfs/ could also potentially play a role in a means to efficiently and reliably distribute public keys in conjunction with IPFS? Seems worth considering at least.

and it's not the fastest thing but in theory it's simple enough that you can just do something like this:

ipfs add test.asc added QmX1yKeerXb9vSYoQXcZuuw1QFTu5UxDCec4hY9htjRYE7 test.asc

and retrieve it https://cloudflare-ipfs.com/ipfs/QmX1yKeerXb9vSYoQXcZuuw1QFT...

if you have an ENS name you can access it this way: https://cloudflare-ipfs.com/ipns/atmarketplace.eth/

Can anyone suggest a serialization format that can be implemented across languages without being a language lawyer?

JSON seems like it fits the bill but I have seen soooo many complaints about UNICODE encodings, whitespace or some other things, and people saying secure scuttlebutt suxx because it relies on perfectly copying Node’s JSON implementation. But dudes, what format is better out there?

The SSB issue with json is that it plays with the json after signing it. Just don't do that.

Please elaborate

What specifically do you mean? I have so far resorted to using http_build_query type algorithms to make it for sure canonical.

It's not a fun format to work in but ASN.1 is aimed at that and there's also protocol buffers, Avro, and messagePack, among others.

What does this wormhole exactly do? The docs just say it's a secure connection, but how exactly do you interact with it?

I was wondering how these wormholes compares to an SSH tunnel or wireguard.

i find it weird they reused the name "wormhole" without refering to the original "magic wormhole" either in design or credit... Seems like the potential for user confusion is kind of huge there...

it's https://github.com/warner/magic-wormhole

but see in particular https://github.com/warner/magic-wormhole/issues/107 . It uses a static wordlist and by default uses a shared pool of rendezvous servers.

The (an?) author addresses this here https://magic-wormhole.readthedocs.io/en/latest/attacks.html but I think characterizes the attack poorly: it's not important that it's low-probability that an attacker can pull off a MitM transparently, all an attacker needs to do is be able to guess the channel + code words before the receiver receives the message. The default is to only use two code words, so 65536 possibilities. I don't think it would be hard to open 64k connections very quickly, so this seems like an easy-to-win race. Maybe I misunderstand the math.

I don't think wormhole should be used for anything important without a private rendesvous server, and if you have secure access to a private rendezvous server, why bother with wormhole?

That's not how the protocol works. A single failed guess terminates the connection and alerts the sender that an incorrect code was used and someone might be attacking them.

If you are concerned about guessability you can use more than 2 words. You can also use strings that are not in the default word list (the only thing the default word list gives you is tab completions).

edit: Also the "wormhole" spec that keys.pub has is not related to magic-wormhole.

I happily stand corrected on both counts, thanks

Question is, will this become a useful tool or a bloated multi-purpose behemoth (with no clearly defined purpose) like Keybase did?

We badly need good simple tools for encryption. For all the criticism of GPG coming from the savvy crypto-crowd, there is still no other tool that performs common encryption-related tasks quickly and easily.

age is the standard answer to this https://age-encryption.org/

I like where age is going. It only does a fraction of what I need (for example, I need to sign and keep detached signatures), but I have high hopes for it.

Still, it is nowhere near a replacement for GnuPG.

GnuPG - Keys.pub without the cruft

Jokes aside, gpg does exactly key management, signing, encryption and so on.

Plus, it's nice to acknowledge and support the work of the author.

A tiny wrapper that provides a friendly CLI/TUI would be welcome.

Reply on news.ycombinator.com