Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <22008EEB-B5D6-4647-A519-4DA7415ECC92@mikemccandless.com>
From: Michael McCandless <lucene@mikemccandless.com>
To: java-dev@lucene.apache.org
In-Reply-To: <002b01c9a305$097a1710$1c6e4530$@com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: FIPS compliance?
Date: Thu, 12 Mar 2009 08:44:47 -0400
References: <004001c9a1b3$f3c5bc50$db5134f0$@com>
 <82040E68-99C0-459B-9AC3-E82B4C9F1984@mikemccandless.com>
 <004801c9a1c5$f72dc150$e58943f0$@org>
 <346A7E20-87F5-4A4A-8C05-32B86F8BB0D3@mikemccandless.com>
 <002b01c9a305$097a1710$1c6e4530$@com>


That'd work too.

In which, I think we should simply leave Lucene using the builtin MD5  
(since JREs don't seem to reject it as insecure).

Mike

Digy wrote:

> Or a "home made" md5 (without using
> System.Security.Cryptography.MD5/java.security.MessageDigest) ?
>
> DIGY
>
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Wednesday, March 11, 2009 11:08 PM
> To: java-dev@lucene.apache.org
> Subject: Re: FIPS compliance?
>
>
> So... I think this is a .NET specific issue at this point?
>
> Or.. if we could find some common digest that is *not* used for crypto
> (so .NET won't reject it as "insecure"), but still has low risk of
> collision, that seems best.  Maybe just CRC32?
>
> Mike
>
> DIGY wrote:
>
>> Thanks Mike.
>>
>> DIGY
>>
>> -----Original Message-----
>> From: Michael McCandless [mailto:lucene@mikemccandless.com]
>> Sent: Tuesday, March 10, 2009 10:43 PM
>> To: java-dev@lucene.apache.org
>> Subject: Re: FIPS compliance?
>>
>>
>> Interesting... I wonder if in any java runtime there's ever a
>> "rejection" of a
>> known-insecure crypto digest alg.  I don't think that's come up on
>> java-user/dev that I've seen.
>>
>> But it's certainly possible, but it should be rare because we now
>> simply
>> default to "write.lock" in the index directory (getLockID is only  
>> used
>> if
>> you override the LockFactory).
>>
>> Really we want a digest that doesn't not need to be secure, here, but
>> I don't
>> think Java APIs differentiate.  (We don't care if someone can reverse
>> the
>> mapping of lock ID --> directory name; we simply want low risk of
>> collision).
>>
>> Do .NET APIs offer a "give me a digest and it doesn't have to be
>> secure"?
>> If so that's probably the best solution.
>>
>> That said... we could change this to SHA-1, to be safe, but then in
>> another
>> few years we'd probably be having this discussion again when SHA-1 is
>> fully cracked ;)
>>
>> I don't think there's a back-compat issue since it's use only for the
>> naming of the lock file, which is transient.
>>
>> Mike
>>
>> Deniz@ttnet wrote:
>>
>>> Hi All,
>>>
>>> There is a discussion about FIPS compliance(using MD5 Hash algorithm
>>> in FSDirectory) in Lucene.Net.
>>>
>>>
>>
> http://mail-archives.apache.org/mod_mbox/incubator-lucene-net-user/200903.mb
>> ox/%3c006101c99f4e$7bdd3590$7397a0b0$@rendelmann@gmx.net%3e
>>> https://issues.apache.org/jira/browse/LUCENENET-175
>>>
>>> In fact, if the system wide policy (HKLM\System\CurrentControlSet
>>> \Control\Lsa\FIPSAlgorithmPolicy) is set, then trying to use MD5
>>> (which is not FIPS compliant) to compute the hash causes exception.
>>>
>>> So, Is a change in Lucene possible to use SHA1 in computing hash for
>>> FIPS compliance (I can see the backward compatibility problems)
>>> Or
>>> is this problem specific to Lucene.Net?
>>>
>>> What do you think?
>>>
>>> DIGY
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org