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: <82040E68-99C0-459B-9AC3-E82B4C9F1984@mikemccandless.com>
From: Michael McCandless <lucene@mikemccandless.com>
To: java-dev@lucene.apache.org
In-Reply-To: <004001c9a1b3$f3c5bc50$db5134f0$@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: Tue, 10 Mar 2009 16:43:17 -0400
References: <004001c9a1b3$f3c5bc50$db5134f0$@com>


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.mbox/%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