You should probably just use Wormhole.
pip install magic-wormhole
For the attacker to have a 50/50 chance of successfully stealing your file transfer, you'd have to (on average) re-run the `wormhole send` program over 30000 times. I don't know about you, but I'm not that patient, and I'd give up long before they had a significant chance of success :).
> The two endpoints are identified by using identical "wormhole codes": in general, the sending machine generates and displays the code, which must then be typed into the receiving machine.
> The codes are short and human-pronounceable, using a phonetically-distinct wordlist. The receiving side offers tab-completion on the codewords, so usually only a few characters must be typed. Wormhole codes are single-use and do not need to be memorized.
I love that they've put some thought into usability here: that's nice.
./sshencdec.sh -p <(curl -sf "https://github.com/S2-.keys" | \
grep ssh-rsa | tail -n1) < plain-text-file.txt
We were doing similar things ourselves with GPG. But ultimately we'd forget the exact command, or the copy-pasting in then out of Slack was enough of a barrier that we'd basically never bother.
Curious how such a small barrier was a blocker. Our hypothesis is that, if we can make `fk secret send` easier than literally everything else, people will default to it, and it'll be a win for security. We shall see!
The key thing with Keybase is that it cryptographically verifies your public keys against public statements published to accounts people know you by - eg your Twitter, Facebook, etc.
The difficult bit isn't encrypting and sending. The difficult bit is the original key exchange. Keybase has dealt with this without you having to trust Keybase itself.
Fetches from where? Public key servers?
Anybody can upload a key for email@example.com to a public key server.
> We chose not to use the public keyserver network until it supports deleting keys and cryptographic validation.
... as well as the fact that there's no email validation, yep!
Gpg supports looking up keys via this since 2.1.12 . An example of how to lookup and get a key this way can be seen here .
We've got WKD working on our own firstname.lastname@example.org email address using a rather cheeky hack.
Server side, we're adding this to Fluidkeys Server soon.
That way, teams that use Fluidkeys could redirect `<team-domain>/.well-known/openpgpkey/(.*)$` to our server, and voila, we'll serve their keys via WKD
But mostly teams control their own mail domain, so they can do what they like (for example, use Fluidkeys, and we'll do WKD for them!)
Another great one is Magic Wormhole, which uses a parallel human-to-human channel to negotiate a secure machine-to-machine exchange:
notably, you can run your own
I do. You can use your own, but then both sides have to type in the same --relay-url=URL value (instead of using the one that's baked into the app).
magic-wormhole is both a file-transfer tool and a library for provisioning/transferring secrets via a code. If you were embedding the library in your own app, you might want to bake in a different relay server (which you run) to avoid depending upon me for your uptime.
- Rendezvous server is a public one
- You can run your own
- Code is in the `wormhole` library.
gpg -d <<EOF
-----BEGIN PGP MESSAGE-----
-----END PGP MESSAGE-----
We're not in a hurry to try and move people off Slack or GnuPG: teams have their existing services (Slack, G-suite) and other workflows like Thunderbird + Enigmail, git signing etc. We think complementing those existing flows is the way to go.
The longer term vision is that your team can sign up to Fluidkeys, download it and it sets up everyone's email client, git, pass etc according to your team's configuration. Then it quietly keeps everyone's keys updated when people join and leave the team. (and we rotate encryption subkeys every month)
Back to today: 0.3's sending secrets feature is a small diversion from that goal, but we hope a useful feature in its own right :)
I'd love your feedback on the vision above!
What? I'm pretty curious what gave you this impression, as I've always seen their chat app as an interesting use built on top of their encrypted file system work, but in no way their primary use-case or business.
We (and everyone else I know that uses Keybase) use it for passing around sensitive information, either through chat, their encrypted Git repos, encrypted messages plopped into emails, etc.
I think Fluidkeys is cool and all, but I definitely wouldn't switch off of Keybase for it, and I think you're doing yourself a disservice by pretending that Keybase is "just another chat app" now and not a direct competitor that also has secure communication built in.
> We (and everyone else I know that uses Keybase) use it for passing around sensitive information, either through chat, their encrypted Git repos, encrypted messages plopped into emails, etc.
That is interesting. I'm gonna put my hand up and admit I haven't done my homework here. It's been a while since I used it properly and I've relied too heavily on their website:
> Keybase is for anyone. Imagine a Slack for the whole world, except end-to-end encrypted across all your devices. Or a Team Dropbox where the server can't leak your files or be hacked.
> I think Fluidkeys is cool and all, but I definitely wouldn't switch off of Keybase for it,
Thanks, and I wouldn't expect you to have to switch. We're gonna think properly about where we're competing. I appreciate your input.
Is a self-hosted version of the same possible?
Additionally, there should probably be
a) Some sort of "paranoid" mode whereby it would show me peer's key (in some form) so that I could, if really wanted, manually verify it.
b) An option to cache peer keys locally. I assume this is done already and that the local cache lookup is given a priority over the registry search. Correct?
Yes, we're currently hosting public keys.
> Is a self-hosted version of the same possible?
The honest answer is, we're not sure yet. It's our strong ambition to make Fluidkeys into an honest, you're-the-customer business, and we aren't sure how we'll license the server. Is self-hosting something your team would be willing to pay for? If so, that might help our business model development! :)
> a) Some sort of "paranoid" mode whereby it would show me peer's key (in some form) so that I could, if really wanted, manually verify it.
This is a great idea. In that mode, it could output the key fingerprint and prompt before sending. Would that work for you?
> b) An option to cache peer keys locally. I assume this is done already and that the local cache lookup is given a priority over the registry search. Correct?
Not yet, mostly for simplicity of getting this release shipped. It's currently pretty naive (and I'm not thrilled about it): the key lookup API call is done every time you send a secret. Thinking of fimiliar patterns, perhaps we should take the SSH trust-on-first-use approach, where we record the fingerprint we saw last time, and warn if it changes? That would make it significantly harder for us to subsequently serve you bad keys.
Somewhat related, there was a good discussion about how to deal with multiple key discovery mechanisms (e.g. local cache vs server response) at the latest OpenPGP summit. Prioritising local cache (say, your GnuPG keyring) can be quite scary too, if you downloaded a key from the keyservers and subsequently realised it was a fake (and don't use web-of-trust which, well, enough said).
Thanks for thinking about this and taking the time to share your ideas.
Without sugar-coating it - a service like this, with the scope it has now, has * zero * chance of successful monetization. 100% guaranteed.
This is a cosmetic service that aims to address a security need. People who actually need this AND have money to pay for it are in position to explore self-hosted options, which is what they will be looking for in the first place since they DO want proper security. Having a random third party in their security pipeline is not really an option. And people who are not concerned with this part, won't think twice about sending API keys over regular email. In fact, even security-minded people won't have much objection to relaying secrets through their corporate, properly secured email server.
Then, there's an option of productized (self-hosted) version. This is not likely to work either, because the whole thing looks rather trivial and, put bluntly, not worth paying for. Like you aren't likely to pay for hugs, no matter how good they are. Same here - nice to have, but only if free.
All that said, the website is nicely designed and the whole thing is well-presented. It certainly has a potential to be a good demo/promo piece for something larger.
For this reason I use something like read then burn[1,2] for passwords.
Don't have much time now but just wanted to give this a quick +1, worth checking out.
Github was amazing, they detected it, saw that it was valid, and revoked the token. Big love.
On private repos: it would be a sad, sad thing if all those half-baked pet projects went away, there's an awful lot of valuable random stuff in public repos.