I’m reading the man page and looking for the place where GPG instructs users not to render plaintext if an MDC isn’t present on a message. Can someone help me find it?
-
-
Replying to @tqbf
Hmm, I think I'm on team client bugs. I know about gpg message modification, and have found attacks before (e.g. CVE-2006-0049). If client is not waiting for the DECRYPTION_OKAY status-fd message, that seems clearly client bug to me?
3 replies 3 retweets 14 likes -
Replying to @taviso
Everybody who works in cryptography vulnerabilities is just sort of staring at you slack-jawed. Don’t provide unauthenticated plaintext to callers.
2 replies 2 retweets 10 likes -
Replying to @tqbf
Umm, I work in cryptography vulnerabilities - and have published multiple vulnerabilities in this exact area, probably more than most of the people staring at me slack-jawed
1 reply 0 retweets 15 likes -
Replying to @taviso
There a whole long annoying debates in AEAD proposal discussions about the exact right way to avoid exactly this property.
1 reply 1 retweet 8 likes -
Presenting unauthenticated plaintext to callers is itself a vulnerability, intrinsically, no matter what you print afterwards.
3 replies 4 retweets 12 likes -
Replying to @tqbf
Obviously we're on the same page on that, this case is more nuanced. The status api is a low level api that exposes legacy design decisions by necessity, it's not easy to use safely. The high level api is called gpgme, it uses the status api internally. 1/2
2 replies 1 retweet 5 likes
Gpgme has user docs, whereas the status api has some org mode README in the source distribution. I'm not convinced it's fair to say "it's a vuln if it's hard to use the low-level internal apis", is there any library that can't be misused if you access private/internal apis? 2/2
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.