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.
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.
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.
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 .
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.
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.
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.
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".
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!"
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.
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.
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).
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.
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].
> 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.
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'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.
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.
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".
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?
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!
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.
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.
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.
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.
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.
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.
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 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.
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 (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 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...
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.
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.
Tying sigchains to keys seems limiting, and I'm curious if there's a reason for it. Otherwise, I like this a bunch.