3 ms·
> and messages can potentially be decrypted without access to private key This is about e-fail, right? As far as I know this has been migrated and it worked in
by dependenttypes 7y ago
> and messages can potentially be decrypted without access to private key
This is about e-fail, right? As far as I know this has been migrated and it worked in the first place only because of html messages. In addition to that it was not really the fault of gpg but rather the fault of badly implemented programs (because they did not check the mdc tag).
> Archived messages will leak
This is a bold assumption
> An e2e channel needs to have a way to inform receivers that messages should be deleted after some time
Surely the sender could mention this in the message.
> 4. Private keys eventually leak, therefore it is important that when it happens, the system makes it hard to decrypt old messages (by combining it with ephemeral keys).
This is a big usability trade-off. I avoid using wire because it takes ages (as in hours) to decrypt messages if I have not used it for a while.
- lvh 7y agoIf a bug happens in more than a handful of implementations, there’s a good chance the protocol is to blame. Perfect examples of where this emphatically is the case is MDC (PGP and Telegram are the only two common protocols in use I can think of where you don’t get a real MAC) and JWT’s alg debacle. Both were obviously ridiculous, and both led to serious vulnerabilities in almost every implementation under the sun. Mind you: with efail, some tools were using GPG directly. GPG produced unauthenticated ciphertext. GPG is also the dominant implementation. If GPG itself does this obviously broken thing, how do you expect third party implementations to get it right?