> On 25 Sep 2021, at 20:44, Joshua Kinard wrote: > >> [snip] >> >> ECDSA and the NIST curves have been around since > 20 years, so it's >> simply impossible that there are any valid patents covering those. >> (There is of course a slight possibility that there may be patents >> covering specific implementation details of ECDSA/NIST curves that were >> only described later.) > > Then we are either A) being too paranoid and should just drop bindist from > the OpenSSL ebuilds, or B) we are not being paranoid enough and packages > like dropbear/libtomcrypt need bindist added, no? It seems we're stuck in > the middle here because we don't have the right information. If Red Hat or > IBM are being non-responsive over this, then surely some other distro out > there has already figured things out? > Agreed. Furthermore, it's not clear to me that Debian or Ubuntu are "hobbling" their OpenSSL implementations. I may have missed something, but I don't see anything in: - https://salsa.debian.org/debian/openssl/-/tree/debian/unstable/debian/patches (or the rules file) - https://git.launchpad.net/ubuntu/+source/openssl/tree/debian/patches?h=applied/ubuntu/impish (or the rules file) The only thing I have found is an old bug report for Ubuntu (https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/597984) referencing disabling some non-EC parts. > >> I'm not entirely sure what you'd like to ask the libtomcrypt authors. >> "We think there may be patents, but we don't know. Did you consider >> that?" > > No, actually, I was thinking something more along the lines of "Hey, are you > aware of these supposed patent claims about ECC/ECDSA implementations that > Red Hat says exist, and if so, did you do any research on them that you > could possibly share that led you to feeling confident to release your > implementation into the public domain". I'd like to make some points about our continued use of the "hobble" patch for at least < OpenSSL 3 too: - RH won't publicly say what they're worried about wrt EC in OpenSSL. This could be to avoid patent trolls, but this isn't really consistent with the patch being "enough" to protect them - or us - anyway? - We don't know what patents the Fedora patch is allegedly preventing us from infringing. - If Fedora's patch is based on legal advice, there's no reason to believe that it necessarily applies to us. - We have no way of verifying the correctness (or completeness) of the Fedora patch we use because it is unclear what it is protecting against. - Even the latest version of Fedora's hobble patch _script_ only references patents expiring, at the latest, in 2020: https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/hobble-openssl. And, as you observed, this doesn't appear to be applied consistently anyway. Dropbear in Fedora appears to allow EC. Right now, I'm far more concerned about the possible security impact of applying patches whose correctness is not vouched for, nor do we truly understand their purpose. In addition, some of the changes in our current OpenSSL 1.1.x patches are fragile and easily mis-applied or mis-rebased. Here's an example of such a possibly problematic hunk: @@ -2026,9 +1945,9 @@ int speed_main(int argc, char **argv) # endif # ifndef OPENSSL_NO_EC - ecdsa_c[R_EC_P160][0] = count / 1000; - ecdsa_c[R_EC_P160][1] = count / 1000 / 2; - for (i = R_EC_P192; i <= R_EC_P521; i++) { + ecdsa_c[R_EC_P224][0] = count / 1000; + ecdsa_c[R_EC_P224][1] = count / 1000 / 2; + for (i = R_EC_P256; i <= R_EC_P521; i++) { ecdsa_c[i][0] = ecdsa_c[i - 1][0] / 2; ecdsa_c[i][1] = ecdsa_c[i - 1][1] / 2; if (ecdsa_doit[i] <= 1 && ecdsa_c[i][0] == 0) @@ -2040,7 +1959,7 @@ int speed_main(int argc, char **argv) } } } -# ifndef OPENSSL_NO_EC2M +# if 0 By not using easy macros where possible, we're making it far easier to have compile-time or even runtime errors. > > But I am open to better language. I just don't wanna sit here not knowing. > Someone out there has to have the right information to settle this. > Yep. We consult legal advice or stop using half-measures. Best, sam