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
