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:luc...@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:luc...@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
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.mb
ox/%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
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
