Hacker News new | ask | show | jobs
by Iburinoc 4407 days ago
Looks interesting, although more information on the encryption schemes used, how the key is stored/represented/generated would be nice given that the idea is to trust the service with my private data.
1 comments

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

Ok, thanks for the reply. Do you guys have any plans to try client-side encryption at some point in the future and/or do file encryption as well? I have to agree with kenrikm to some degree, if the encryption and decryption is all done server side then we are really just trusting you not to cheat (Not saying you're untrustworthy, but it does seem to be a service built on security, which is a field in which I'd rather trust as few people as possible).
If it's happening server side the best you guys can give is "we won't look, pinky swear" - sorry, might as well just use Dropbox.
I think you need to add client side encryption with an open source client. for the super paranoid. but, then I would be too paranoid to use that.