3 ms·
I can't read the article, but naively to me this sounds like it requires the app-owner to be able to access the messages when requested, and so whatever thresho
by SamBam 5y ago
I can't read the article, but naively to me this sounds like it requires the app-owner to be able to access the messages when requested, and so whatever thresholds they say they're adhering to (courts, etc), as an end-user I can't know if they might change their minds at some point and read all my messages.
- 3np 5y agoWhile what you're saying is how it may play out in practice (which is, I argue, the case for any closed-source client), it's not necessary when using threshold encryption; you can construct an encrypted message such that K out of N keys can be combined to decrypt the ciphertext. If those public keys are on the client, it does not require the message to be sent to a trusted server. mtgx's comment points to some practical implementation and logistics issues, though. Never mind how one would handle key revokations... --- In case of the main article, though, that's irrelevant, as an e-mail provider necessarily has access to each unencrypted e-mail as they deliver them to and from the user. I can see it being the least bad way to log messages (if they would need to do so). Rather than logging in cleartext, or encrypting with a single key, it could be a threshold encryption where, say, more than one entity inside law enforcement/high court/etc are required in order to decrypt intercepted traffic. I think our learned instinct has become to say "yeah, would be nice but good luck making anyone implement that"... But why not?