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
de...@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$7397a0...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
