3 ms·
> functionally equivalent to a decryption key Not from a security point of view.
by JaRail 7y ago
> functionally equivalent to a decryption key
Not from a security point of view.
- gregmac 7y agoWhy? What's the threat vector that's specifically enabled by the key in the url? And why is that vector defeated by submitting the "decryption key" (password) as part of a POST body (or some other method you can explain)?
- inlined 7y agoAny URL with sufficient entropy is as unguessable as a password. The primary danger would be revocation if the user doesn’t realize their “password” has leaked.
- JaRail 7y agoGoogle doesn't embed a decryption key in their URL. AFAIK, they are just long lookup keys that are unguessable. The difference between that and local encryption is if you trust the storage provider. If you were a journalist in China, you wouldn't want your documents accessible by your hosting provider. In the above scenario, you obviously wouldn't want to submit a decryption key to the server as part of a URL/POST. Look at how services like mega.nz are designed. They popularized an approach where the decryption key is in the URL's label, which is not submitted to the server. The files are decrypted with javascript locally.
- jakear 7y agoIf you're sharing the key the same as you'd share a URL, it is the same.