Files are not encrypted (but 'secrets' are). Files are actually uploaded directly to a private S3 bucket over HTTPS.
Secrets (text) are sent over HTTPS and encrypted with a randomly-generated key using AES 256 bit encryption before being stored in our DB. The key is embedded in the share URL for the secret. We don't store the key or the URL anywhere on our servers, so the only way to decrypt the secret's contents is if you have that URL.
We actually use 1Password internally, but once or twice a week we were getting passwords emailed or IMed to us from clients and other people we worked with, so we added the secrets feature to Torpedo for those folks, to at least greatly reduce the chance of those passwords from falling into the wrong hands if someone's smartphone is stolen or email is hacked.
Also, the contents of secrets are encrypted with a randomly generated key, using AES 256 bit encryption, before being stored in our database. The key is then embedded in the share URL for the secret. We don't store the key nor the URL in our DB, so the only way to decrypt it is with the URL.
No, you're not missing anything. We built Torpedo to be a step-up from the way most of our clients and other people we worked with sent us stuff: files via Cloud links that sit around forever, and passwords in emails.
There are certainly more secure ways to send both of those things than Torpedo, but we wanted to make something that was more secure to send those things, while keeping it just as (or more) convenient.
We've got a few ideas that we're considering that'll offer more security, just trying to sort out how to keep it simple enough for our parents to use it.
Hey guys, sorry about that. We just rolled that message out a day or two ago. The browser-detection is based on https://github.com/gabceb/jquery-browser-plugin but obviously needs some work. Working on a fix for that now.
Hi Iburinoc, I'm one of the developers for Torpedo.
Files aren’t encrypted, but for secrets (i.e. text) the encryption happens server-side. We originally wanted to do client-side encryption (before heartbleed), but opted not to in order to keep the API simple.
When we get a secret, a random key is generated, that key is used to encrypt the secret using AES 256 bit encryption, the key is then mixed up with an identifier for the secret and that's included in the URL. We don't store the key itself anywhere on the server, nor do we store the URL (as it contains the key).
When request comes in to view/download a secret, we extract the decryption key and secret identifier from the URL, look up the secret, decrypt it using the key, then send the decrypted contents to the user (over HTTPS).
Files are not encrypted (but 'secrets' are). Files are actually uploaded directly to a private S3 bucket over HTTPS.
Secrets (text) are sent over HTTPS and encrypted with a randomly-generated key using AES 256 bit encryption before being stored in our DB. The key is embedded in the share URL for the secret. We don't store the key or the URL anywhere on our servers, so the only way to decrypt the secret's contents is if you have that URL.