So we've made a new product to address this. It is a one-click way to share one-off secrets, end-to-end encrypted with links that auto-expire after a certain number of views and days.
All the encryption is done browser-side so our servers never see the raw secret or the encryption key. We use AES-GCM to encrypt your secrets, with a symmetric key derived from a cryptographically random 64 character passphrase using PBKDF2. If you want to dive deeper into how the data flows, we documented every step of the send and receive flows: https://docs.doppler.com/docs/share-security
We built this so anyone can use it immediately without needing to create an account or jump through any hoops.
Try it out: https://share.doppler.com/s/zg5aqzfbidn9femgnaas2wf2syedqf0s...
Would love to hear what you guys think!
Shameless plug: I made a similar tool base off another project after FirefoxSend shuts down but deploy on AWS instead of GCP :) It is hosted here if anyone wanna take a look or roll their own https://www.relaysecret.com/. The design philosophy is the same (everything is encrypted on clientside, no plaintext or password leave clients browser, minimal backend).
OSS which you host internally.
[1] https://plic.ml
I have an OCD where I want the examples to be complete, sorry for that. Otherwise the service looks interesting.
It seems that the main doppler product is not end-to-end encrypted, is that correct?
You are correct, the main Doppler product is not end-to-end encrypted. We use tokenization instead to secure the data. Here's a link that goes more in-depth on how that works: https://docs.doppler.com/docs/security-fact-sheet
I'm using Firefox with uBlock Origin, it might be hiding your field based on its ID if it's called "share" or something. I was very confused.
From the docs at https://docs.doppler.com/docs/share-security :
> 2. Client-side JavaScript generates a cryptographically random 64 character passphrase > 3. Client-side JavaScript generates a symmetric key using the passphrase, random salt, and 100,000 rounds of PBKDF2. > .. > 5. Client-side JavaScript create SHA256 hash of the passphrase > 6. Client-side JavaScript sends the encrypted secret, hashed passphrase, and expiration details (days/views) to the server.
Using PBKDF (or any other "key-stretching" algorithm) is appropriate to prevent someone from cheaply building a table that maps from potential passphrase (+salt) to the potential symmetric key, ahead of time, and then quickly testing lots of potential keys against the encrypted data. If the passphrase is not full-strength to begin with, this is an important step.
But.. if you then send a non-stretched, simple hash of the passphrase to the server, you're giving up all that benefit. The server, anyone who breaks into it, or someone who can snoop on the conversation, gets to perform the fast pre-computed dictionary attack against the passphrase. You've prevented the ciphertext from being used as a cheap oracle, but allowed the server's hashed-passphrase to serve that role instead.
The document didn't say what character set was used for each of the 64 characters of the passphrase, but even if it's just hex, that still gives you a 256-bit key, which is effectively infinite. So in this case, I don't think you need the PBKDF.
If the passphrase were not that strong, then I'd recommend protecting both values against being used as an oracle:
1: run the passphrase through PBKDF (or Argon2, or bcrypt, whatever) to produce the "stretched passphrase" 2: hash the stretched passphrase one way to produce the encryption key, e.g. key = sha256("key:" + stretchedPassphrase) 3: hash the stretched passphrase a different way to produce the hash that you reveal to the server, hash = sha256("hash:" + stretchedPassphrase) 4: never reveal stretchedPassphase to anyone else, or use it directly for any other purpose
That way a dictionary attack against any of the revealed values are equally difficult. This is effectively the scheme we used on Firefox Accounts to protect the Sync password: https://github.com/mozilla/fxa-auth-server/wiki/onepw-protoc... .
Also note: don't use different PBKDF round counts as a distinguisher, i.e. hash = PBKDF(rounds=10000, passphrase) and key = PBKDF(rounds=10001, passphrase). That amounts to the same thing, someone who learns the hash will get a cheap attack against the passphrase.
thanks for building this!
We move fast, don't have any brain teasers, and a care deeply about the culture we create.
Role: https://jobs.lever.co/doppler/63e3511b-5463-4d02-a1f9-0bc463...
and this one has much advanced features like build up a site. https://github.com/privapps/
All end to end encrypted.
https://news.ycombinator.com/item?id=26289683
I think e2e encryption and share is not new, especially compare to the privatebin, which has been out there for quite a long time, and it is mature with a lot of features, such as docker / K8s deployment.
If Droppler want to success, it might need to do slack integration, SSO and customize work. Since the space is very crowd there.
In addition, it can be very easy to be used for other purposes.
Edit: I read your site again, it is like try to make e2e encryption as a SaaS platform, for fast app development. This direction is kind of overlapping with vault: https://spring.io/projects/spring-vault
Many cloud platform like AMZ, GCP have secrets management services, it can be a hard battle.