Tying sigchains to keys seems limiting, and I'm curious if there's a reason for it. Otherwise, I like this a bunch.
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 don't visit the cryptocurrency tab anymore, and it's not like it gets in the way or anything.
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".
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.
What do you recommend people use instead?
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 does not have PFS, unfortunately...
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?
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.
This looks like a good start for a real competitor. Obviously it's early but I'm seeing the right things.
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.
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.
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.
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!"
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.
A small correction, Stellar/XLM has been around since 2014 
Not that I'm saying they should support just me, everyone has their own set of a magical does-just-enough feature set.
But they did, so their clients got kicked out of my system.
I also got spammy alerts mentioned by siblings (in email).
These days, I don't even know what keybase is for. What is it for, really?
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?
Now that I'm looking it although their docs don't mention anything I'd assume it's related to their funding.
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.
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.
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.
(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".
> 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 ;)
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 , 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  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.
: Keybase GUI for Linux https://pbs.twimg.com/media/EW0wKs4VcAAL3Qi?format=jpg
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.
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.
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.
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.
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:
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?
What specifically do you mean? I have so far resorted to using http_build_query type algorithms to make it for sure canonical.
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?
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.
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.
Still, it is nowhere near a replacement for GnuPG.
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.