lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: FIPS compliance?
Date Tue, 10 Mar 2009 20:43:17 GMT

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  
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  
mapping of lock ID --> directory name; we simply want low risk of  

Do .NET APIs offer a "give me a digest and it doesn't have to be  
If so that's probably the best solution.

That said... we could change this to SHA-1, to be safe, but then in  
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.


Deniz@ttnet wrote:

> Hi All,
> There is a discussion about FIPS compliance(using MD5 Hash algorithm  
> in FSDirectory) in Lucene.Net.
> 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?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message