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
