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?
-
-
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 -
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 -
Without nuance: Unauthenticated encryption is insecure.
1 reply 0 retweets 2 likes
That's not the discussion here, obviously we agree on that. The discussion is if it's a vulnerability in the library if clients go poking around inside undocumented private apis and then use them incorrectly. I would say it's a client problem - use the high-level supported api.
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.