
Show HN: Send encrypted secrets from the command line - paulfurley
https://www.fluidkeys.com/blog/release-0-3-send-encrypted-secrets/
======
tptacek
The tool for this that everyone I know uses is Magic Wormhole. Wormhole has a
more straightforward security model and is more thoughtfully designed: it uses
a PAKE and relies on out-of-band secret sharing, rather than attempting a
registry of "verified" public keys.

You should probably just use Wormhole.

    
    
        pip install magic-wormhole

~~~
rvnx
Isn't there only 65K passwords/magic keywords in wormhole ? What if someone
constantly bruteforce all of these combinations, wouldn't he get access to the
files that you are sending ?

~~~
lotharrr
The short answer is that PAKE is single-use, so the attacker only gets one
guess (and their attempt prevents the legitimate peer from trying either).
Each time they consume someone else's transfer attempt, they get a 1-in-65k
chance of succeeding, and a 65535-in-65536 chance of alerting the peer that
they failed.

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 :).

------
y0ghur7_xxx
I made something similar, but the payload gets encrypted with the users ssh
rsa key instead of pgp (that not many use):

    
    
      ./sshencdec.sh -p <(curl -sf "https://github.com/S2-.keys" | \
    
      grep ssh-rsa | tail -n1) < plain-text-file.txt
    

It's just a simple bash script really, but it works, and almost everyone has a
github account and an ssh key set up, so it works out of the box with most
developers.

[https://github.com/S2-/sshencdec](https://github.com/S2-/sshencdec)

~~~
paulfurley
That's cool!

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!

------
BillinghamJ
To be honest this just seems like an insecure version of Keybase.

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.

------
koolba
> Fluidkeys automatically fetches keys based on the verified email address and
> encrypts the secret to the key.

Fetches from where? Public key servers?

Anybody can upload a key for you@your-company.com to a public key server.

~~~
paulfurley
> We use our own server to store public keys and transmit encrypted secrets.

> 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!

~~~
tzs
They should add support for the OpenPGP Web Key Directory [1] system. Briefly,
the idea is that the public key for user@example.com should be available at
[https://example.com/openpgp/hu/<blah>](https://example.com/openpgp/hu/<blah>)
where <blah> is generated as described in the document.

Gpg supports looking up keys via this since 2.1.12 [2]. An example of how to
lookup and get a key this way can be seen here [3].

[1] [https://tools.ietf.org/html/draft-koch-openpgp-webkey-
servic...](https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-07)

[2] [https://wiki.gnupg.org/WKD](https://wiki.gnupg.org/WKD)

[3] [https://lists.gnupg.org/pipermail/gnupg-
devel/2018-June/0338...](https://lists.gnupg.org/pipermail/gnupg-
devel/2018-June/033814.html)

~~~
xvector
This is a clever idea. Unfortunately, it doesn't seem like most mail providers
would store something like this.

~~~
paulfurley
I can't see Gmail doing it :)

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!)

------
j1vms
Nice to see more solutions like these pop up.

Another great one is Magic Wormhole, which uses a parallel human-to-human
channel to negotiate a secure machine-to-machine exchange:

[https://github.com/warner/magic-wormhole](https://github.com/warner/magic-
wormhole)

~~~
StavrosK
I've been using Magic Wormhole for all my peer-to-peer file transfers and love
it.

~~~
walterbell
Who runs the rendezvous server for MW?

~~~
latang
> The wormhole library requires a “Rendezvous Server”: a simple WebSocket-
> based relay that delivers messages from one client to another. This allows
> the wormhole codes to omit IP addresses and port numbers. The URL of a
> public server is baked into the library for use as a default, and will be
> freely available until volume or abuse makes it infeasible to support.
> Applications which desire more reliability can easily run their own relay
> and configure their clients to use it instead. Code for the Rendezvous
> Server is included in the library. (o)

notably, you can run your own

(o) [https://magic-
wormhole.readthedocs.io/en/latest/welcome.html...](https://magic-
wormhole.readthedocs.io/en/latest/welcome.html#relays)

------
tyingq
I can see the attraction of the automation. We happen to use a simple script
that builds a self-extracting shell script. Like (passphrase is 123):

    
    
      #!/bin/sh
      gpg -d <<EOF
      -----BEGIN PGP MESSAGE-----
      jA0ECQMCnEJkjjuJ64/j0kYB4JiTGPazY81ZOn3Ph+zRRnXdtuqB3POPizEykpiZ
      CT8p5SiJfXQagTLUCDpR3VCicPw4QirQoOhkLqmzRXS4EBPjkTla
      =+soW
      -----END PGP MESSAGE-----
      EOF
    

Then the receiver doesn't have to remember any commands.

------
eterps
How does this compare to keybase?

~~~
paulfurley
I'm a user but no expert about keybase. As far as I can tell they've pivoted
to taking on Slack & friends with zero-knowledge team-chat, but global. Good
luck to them!

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!

~~~
mmcclure
> As far as I can tell they've pivoted to taking on Slack & friends with zero-
> knowledge team-chat, but global.

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.

~~~
paulfurley
Thanks for pushing back on this.

> 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.

------
huhtenberg
Nicely done. One nitpick would be that initial peer key discovery looks a bit
iffy. Do I understand correctly that fk fetches it from a key registry that is
hosted by you?

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?

~~~
paulfurley
Thanks!

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.

~~~
huhtenberg
> _It 's our strong ambition to make Fluidkeys into an honest, you're-the-
> customer business_

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.

~~~
paulfurley
That's a thoughtful analysis, thanks. I appreciate the lack of sugar coating
:)

------
lixtra
Do the messages automatically get wiped? Typically you don't want to keep the
keys in your message boxes in case they get hacked in the future.

For this reason I use something like read then burn[1,2] for passwords.

[1] [https://readthenburn.fnkr.net/](https://readthenburn.fnkr.net/) [2]
[https://github.com/Tethik/burn-after-reading](https://github.com/Tethik/burn-
after-reading)

~~~
paulfurley
They do, when you receive messages you're prompted to delete them, with a
default of "yes". And we're careful for the secrets not to end up in any log
files either.

------
jen729w
Setup is nice ... just sent a message to the Squirrel. ;-)

Don't have much time now but just wanted to give this a quick +1, worth
checking out.

~~~
paulfurley
Thanks for the kind words, and for the message ;)

------
jedisct1
Or use Piknik:
[https://github.com/jedisct1/piknik](https://github.com/jedisct1/piknik)

------
mkagenius
On a side note, PSA: do not commit your AWS keys into github. Also, now you
have the ability to make your repos private. Head over and do it now.

~~~
paulfurley
Ha! Yeah. I must admit I've accidentally committed a Github access token
before. It was in a `secrets.sh` file which I mistakenly thought was in
`.gitignore` and carelessly added to a WIP commit.

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.

