DSA with keylength > 1024 no longer accepted (solved)
dalibor topic
dalibor.topic at oracle.com
Thu Jan 22 17:05:05 UTC 2015
Thanks, Peter.
cheers,
dalibor topic
On 22.01.2015 15:49, Peter Haraldson wrote:
> I just want to confirm that this applies only to RedHat:s patched version.
> In their release "java-1.7.0-openjdk-1.7.0.71-2.5.3.2.el6_6", which
> basically is OpenJDK 7, they added a patch that included this rule.
>
> I will turn to RedHat for further discussions.
> Thanks for your help!
>
> Regards
> peter
>
>
>>
>> Message: 1
>> Date: Mon, 19 Jan 2015 15:50:13 +0000
>> From: Se?n Coffey <sean.coffey at oracle.com>
>> To: Peter Haraldson <peter at certitrade.net>,
>> "jdk7u-dev at openjdk.java.net" <jdk7u-dev at openjdk.java.net>
>> Cc: "security-dev at openjdk.java.net" <security-dev at openjdk.java.net>
>> Subject: Re: DSA with keylength > 1024 no longer accepted (jdk7u-dev
>> Digest, Vol 43, Issue 8)
>> Message-ID: <54BD27B5.4030906 at oracle.com>
>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>
>> Peter,
>>
>> the issue you reference isn't a problem in jdk7u. - for the Oracle JDK
>> at least. The code snippet your refer to is from jdk8 source code. The
>> key length restriction was initially introduced as a side effect of this
>> fix in JDK 8 https://bugs.openjdk.java.net/browse/JDK-7044060
>>
>> That said, the version string you pasted makes it look like you're
>> running IcedTea from Redhat. My earlier assumptions were that you were
>> running OpenJDK binary based on the jdk7u sources
>> (http://hg.openjdk.java.net/jdk7u/jdk7u/jdk) - If IcedTea has ported
>> JDK-7044060 to their code base, you might have to contact them. Best to
>> follow up on distro-pkg-dev at openjdk.java.net
>>
>> regards,
>> Sean.
>>
>> On 19/01/15 15:21, Peter Haraldson wrote:
>>>
>>>
>>> Thanks, I have now subscribed to security-dev as well. To keep the
>>> thread intact I still reply here.
>>>
>>> Our java version would be JDK 7 I suppose - reported java version
>>> "1.7.0_65".
>>>
>>> I checked your link, and I can see this issue will be resolved in JDK
>>> 8 & 9, but I could not find anything about this issue with JDK 7.
>>> If it's not to be fixed in JDK 7 then we will need to upgrade.
>>>
>>> Kind regards
>>> Peter
>>>
>>>
>>>>
>>>> Message: 3
>>>> Date: Thu, 15 Jan 2015 10:28:46 +0000
>>>> From: Se?n Coffey <sean.coffey at oracle.com>
>>>> To: Peter Haraldson <peter at certitrade.net>
>>>> Cc: Security OpenJDK <security-dev at openjdk.java.net>
>>>> Subject: Re: DSA with keylength > 1024 no longer accepted
>>>> Message-ID: <54B7965E.8010109 at oracle.com>
>>>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>>>
>>>> Hi Peter,
>>>>
>>>> security-dev is best mailing list to discuss this issue, I'm cc'ing
>>>> that
>>>> list and bcc'ing off jdk7u-dev.
>>>>
>>>> Are you hitting this issue with JDK 8 and later ? (I'll assume so) -
>>>> You've hit https://bugs.openjdk.java.net/browse/JDK-8039921
>>>> To aid compatibility, it's been decided to relax that restriction from
>>>> 8u60 and later. See comments in bug report around use of SHA1 and SHA2
>>>> and the length of keys that should be used in each operation.
>>>>
>>>> Hope that helps.
>>>> regards,
>>>> Sean.
>>>>
>>>> On 15/01/2015 10:10, Peter Haraldson wrote:
>>>>> Hi
>>>>> First, I'm not quite sure if this is the correct list for this issue,
>>>>> please excuse & correct me if it's not.
>>>>>
>>>>> Our problem is that in latest openjdk a check is added that makes our
>>>>> certificates with DSA & Keylength 2048 unusable. In file
>>>>> "sun.security.provider.DSA" line 484-489:
>>>>> protected void checkKey(DSAParams params) throws
>>>>> InvalidKeyException {
>>>>> int valueL = params.getP().bitLength();
>>>>> if (valueL > 1024) {
>>>>> throw new InvalidKeyException("Key is too long for
>>>>> this algorithm");
>>>>> }
>>>>> }
>>>>> This is new, these certificates worked fine before. I don't know the
>>>>> reason for not accepting longer keys than 1024, not allowing too short
>>>>> keys would make sense to me but not allowing long keys?
>>>>>
>>>>> We need to find a permanent solution, as for now we can't update our
>>>>> production servers because of this. We have several certificates
>>>>> issued by MasterCard, it is a very tedious job to change them all.
>>>>> Is there a way we could bypass this, could this check be abandoned in
>>>>> next update?
>>>>>
>>>>> Our system:
>>>>> java version "1.7.0_65" (not affected)
>>>>> OpenJDK Runtime Environment (rhel-2.5.1.2.el6_5-x86_64 u65-b17)
>>>>> OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
>>>>> OS: RedHat 6.6
>>>>>
>>>>> Regards Peter
>>>>
>
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>
ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
More information about the jdk7u-dev
mailing list