Re: [SECURITY] [DLA 1283-1] python-crypto security update
On 2018-03-27 07:38:43, Brian May wrote:
> Antoine Beaupré <anarcat@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
Reply to: