sha

On the 2nd of October NIST decided that SHA-3 is the new standard hashing algorithm. Should MD5 users start migrating to SHA-3? To something else (see below why SHA-3 is not recommended)? bcrypt? Why Not {MD5, SHA1, SHA256, SHA512, SHA-3, etc}? And, is this really critical? Even if your password is salted? The main reason not to use MD5 for hashing passwords is not the fact that MD5 is severely compromised or even considered broken. It’s true, MD5 has known vulnerabilities . But none of them do pose a serious threat to your use of MD5. Because in your case the only threat would be a preimage

What is the best way to create a SHA-1 for a very large file in pure Java6? How to implement this method: public abstract String createSha1(java.io.File file); Jeff Foster Use the MessageDigest class and supply data piece by piece. The example below ignores details like turning byte[] into string and closing the file, but should give you the general idea. public byte[] createSha1(File file) throws Exception { MessageDigest digest = MessageDigest.getInstance("SHA-1"); InputStream fis = new FileInputStream(file); int n = 0; byte[] buffer = new byte[8192]; while (n != -1) { n = fis.read(buffer);

In my database I have a computed column that contains a SHA1 hash of a column called URLString which holds URLs (e.g. "http://xxxx.com/index.html"). I often need to query the table to find a specific URL based on the URLString column. The table contains 100K's and these queries take several seconds (using SQL Azure). Since URLs can be quite long, I cannot create an index on this column (above 450 bytes). To speed things up I want to calculate the equivalent of SQL Server hashbytes('SHA1',[URLString]) from C# and query based on this value. I tried the below code, but the value I get is

For the sake of an experiment, lets say your git log identifies the following commits commit 16bc8486fb34cf9a6faf0f7df606ae72ad9ea438 // added 2nd file commit 9188f9a25b045f130b08888bc3f638099fa7f212 // initial commit After committing, .git/refs/heads/master points to 16bc8486fb34cf9a6faf0f7df606ae72ad9ea438. Let's say, after this, i manually edit the .git/refs/heads/master file to point to 9188f9a25b045f130b08888bc3f638099fa7f212 At this point, git status recognizes that a new uncommitted file is in need of some attention. This is the same file my second commit took care of before. If i do

I've seen a few questions and answers on SO suggesting that MD5 is less secure than something like SHA. My question is, Is this worth worrying about in my situation? Here's an example of how I'm using it: On the client side, I'm providing a "secure" checksum for a message by appending the current time and a password and then hashing it using MD5. So: MD5(message+time+password) . On the server side, I'm checking this hash against the message that's sent using my knowledge of the time it was sent and the client's password. In this example, am I really better off using SHA instead of MD5? In what

I read about that Git uses SHA-1 digest as an ID for a revision. Why does it not use a more modern version of SHA? Why does it not use a more modern version of SHA? Dec. 2017: It will. And Git 2.16 (Q1 2018) is the first release to illustrate and implement that intent. Note: see Git 2.19 below: it will be SHA-256 . Git 2.16 will propose an infrastructure to define what hash function is used in Git, and will start an effort to plumb that throughout various codepaths. See commit c250e02 (28 Nov 2017) by Ramsay Jones (``) . See commit eb0ccfd , commit 78a6766 , commit f50e766 , commit abade65 (12

I know that when you add a submodule to a git repository it tracks a particular commit of that submodule referenced by its sha1. I'm trying to find where this sha1 value is stored. The .gitmodules and .git/config files only show the paths for the submodule, but not the sha1 of the commit. The git-submodule(1) reference only speaks of a gitlink entry and the gitmodules(5) reference doesn't say anything about this either. It is stored in Git's object database directly. The tree object for the directory where the submodule lives will have an entry for the submodule's commit (this is the so-called