Hi We can simply send a DLA-1283-2 telling that it was not fixed.
// Ola On 29 March 2018 at 21:34, Antoine Beaupré <anar...@orangeseeds.org> wrote: > On 2018-03-27 07:38:43, Brian May wrote: > > Antoine Beaupré <anar...@orangeseeds.org> writes: > > > >> I'm not sure. The security team marked that as "no-dsa (minor issue)" > >> for jessie and stretch, and fixed in pycryptodome 3.4.11-1... Couldn't > >> we reuse the fixes from cryptodome to get this working properly? Or is > >> this what you say breaks API compatibility? > > > > I don't think I ever said anything about breaking API compatability. > > > > Rather the patch that was applied upstream was considered insufficient > > (by the security researcher) to fix the problem. > > > > This is same patch I used for the LTS problem. > > > > Upstream was told about the problem: > > https://github.com/Legrandin/pycryptodome/issues/90# > issuecomment-362783537 > > > > "This indicates that, with your latest modification, ElGamal encryption > > is now secure under the DDH assumption. However, this is not true. As I > > mentioned in my previous comment, you must encode plaintexts as > > quadratic residues, too (which is, I guess, what breaks compatibility)." > > > > ... but they didn't seem to care: > > https://github.com/Legrandin/pycryptodome/issues/90# > issuecomment-362907413 > > > > "Since the library itself does not support encryption officially, we > > cannot make claim an implementation using the keys generated by the > > library is secure or not." > > > > So it does look like fixing this properly might break API compatability, > > but there are no known fixes we can apply. > > Hmm... so I guess the core question here is whether we expect our users > to actually use cryptodome/pycrypto to do ElGamal-based encryption... > > I have the same problem trying to tackle the libgcrypt11 pending > security issue: > > https://security-tracker.debian.org/tracker/CVE-2018-6829 > > My understanding of this issue is that it only affects consumers of the > library that use ElGamal for encryption, a similar problem than what is > described here. > > I was tempted to mark this as no-dsa, given how little elgamal is > actually used in the wild. It was also my understanding that GnuPG > wasn't vulnerable to this specific issue, but I haven't verified this > deeply and it's been a while since I checked, so I am not exactly sure > of that specific claim. > > CVE-2018-6594 is marked as no-dsa in Jessie/Stretch, for what that's > worth... > > But the problem now is that we issued DLA-1283-1 to claim this was > fixed, so at least an update on that should be provided to our users so > we're clear this is *not* fixed. I'm not sure how to do that. > > Anyone else has suggestions here? > > A. > -- > Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, by > definition, not smart enough to debug it. > - Brian W. Kernighan > > -- --- Inguza Technology AB --- MSc in Information Technology ---- / o...@inguza.com Folkebogatan 26 \ | o...@debian.org 654 68 KARLSTAD | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---------------------------------------------------------------
