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 
-
-
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 -
Replying to @taviso
I think there’s blame to go around, but exposing unauthenticated plaintext is a vulnerability for a secure messaging SDK, full stop.
1 reply 2 retweets 3 likes -
Replying to @tqbf
To be clear, your position is that if *any* api - even undocumented, not exported and only if used incorrectly - can provide access to unauthenticated plaintext, then that is a vulnerability?
3 replies 1 retweet 2 likes -
The lowest-level decryption API should never return the plaintext if the authentication tag fails. The opportunity to pass plaintext along should almost never be an option.
3 replies 1 retweet 3 likes -
Replying to @CiPHPerCoder @tqbf
So, for example, you consider it a vulnerability that you can use internal BIO routines to extract plaintext from objects in OpenSSL? That is a very high bar, I think I disagree. I think it's okay to assume clients use the documented apis and don't poke internals.
1 reply 0 retweets 1 like -
Replying to @taviso @CiPHPerCoder
ptrace isn’t a vulnerability; we can confine the discussion to reasonable interfaces, which are what’s implicated in this vulnerability.
1 reply 0 retweets 0 likes -
The POV of the GPG project is clearly: callers might _want_ the unauth’d plaintext, so we’ll provide it with a warning. The POV of modern cryptography is: fuck what you want, unauth’d plaintext is hazmat.
1 reply 1 retweet 6 likes
Again: we're obviously on the same page for the unauth'd issue. We differ here because I think the status api is effectively an internal low-level api, and it is unreasonable to hold that to the same bar as a documented and supported high-level api.
-
-
Tavis Ormandy Retweeted Tavis Ormandy
See this tweet.https://twitter.com/taviso/status/996136722546081793 …
Tavis Ormandy added,
Tavis OrmandyVerified account @tavisoReplying to @taviso @tqbfGpgme 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/21 reply 0 retweets 0 likes -
Replying to @taviso @CiPHPerCoder
We may be in distinction-without-a-difference land here. If you’re arguing that nothing in the GPG stack should be using the interfaces they’re using, I don’t have a strong POV on that. Sorry if I’m being obstinate.
1 reply 0 retweets 2 likes - 7 more replies
New conversation -
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.