11–20 of 43 posts
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/ [2] https://github.com/Tethik/burn-after-reading
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.
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 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
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!
How does this compare to keybase?
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!
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 pe…
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.
> 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.
> 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!
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...
[2] https://wiki.gnupg.org/WKD
[3] https://lists.gnupg.org/pipermail/gnupg-devel/2018-June/0338...
Earlier quoted context omitted.
> 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!
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 " rel="nofollow">https://example.com/openpgp/hu/ where 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-…
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.
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.
Earlier quoted context omitted.
> 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!
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 " rel="nofollow">https://example.com/openpgp/hu/ where 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-…
We've got WKD working on our own hello@fluidkeys.com email address using a rather cheeky hack[1].
Server side, we're adding this to Fluidkeys Server soon.
That way, teams that use Fluidkeys could redirect `/.well-known/openpgpkey/(.*)$` to our server, and voila, we'll serve their keys via WKD