On 2021-02-28 at 03:49:45, Peter Gutmann wrote:
brian m. carlson <sandals(_at_)crustytoothpaste(_dot_)net> writes:
I'm interested in seeing if we can require v5 SKESK packets with RSA use RSA-
OAEP with SHA-256 and MGF1-SHA-256 and require that v5 signatures with RSA
use RSA-PSS, with the MGF using the same digest as the signature.
Apart from adding a huge amount of complexity and potential interop problems,
you're not really gaining anything by this that isn't already addressed by
"MUST use encode-them-memcmp() for signatures". PKCS #1 signing is perfectly
secure if you do that, and PKCS #1 encryption doesn't matter much because PGP
isn't likely to be used in situations where it acts as an online million-
message oracle.
I've already outlined that people definitely do use OpenPGP in online
situations in <YDvQG0Qif46wPlUT(_at_)camp(_dot_)crustytoothpaste(_dot_)net>.
IIRC, we've
seen people report online usages to the list, and I provided examples
where users do indeed sign online. And despite the fact that we clearly
issue CVEs against people who people who create Bleichenbacher oracles,
people still write them. These attacks have been known for years and
previously fixed and yet in 2018, we had another round of them in TLS.
PKCS #1 is very hard to get right. We've seen many implementations have
problems with it, some multiple times. The fact that people continue to
get it wrong means that it's easy to misuse. We specifically use
techniques such as AEADs because they are _harder_ to misuse than
techniques which are equally secure in the theoretic sense, such as
encrypt-then-MAC with CTR and HMAC. Using RSA-PSS and RSA-OAEP doesn't
mean that implementers don't have to be careful and prudent, but it does
mean that if they make a mistake that the consequences are less
terrible.
I agree that this requires additional code and adds additional
complexity, but we're also adding support for entirely new cipher modes
and other security improvements which do as well. Most cryptographic
libraries already support RSA-PSS and RSA-OAEP, so there's little code
to add. OpenSSL, libgcrypt, RustCrypto, and Go's standard library all
already support this. It's pretty much a matter of substituting a
handful of lines of code based on a branch on the version number.
See also my post to the cryptography list last year about all the games an
attacker can play with OAEP because the parameters aren't authenticated and
therefore attacker-controlled.
I was unable to find anything that looked like a relevant thread in the
archives for 2020. Could you provide a citation?
--
brian m. carlson (he/him or they/them)
Houston, Texas, US
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp