Welcome to Community Server Sign in | Join | Help

C# SHA1 String Hashing

Sam's C# version could be marginally abbreviated (and much less legible). Which is virtually useless, although I would hope no one is writing one-time string hashing routines.

I'm sure it could probably be compressed further, but you have to give it to everything other than Java for providing more convenient abstractions. To my way of thinking, string -> hashed string is probably one of the more common uses of the hashing service providers.

using System;
using System.Security.Cryptography;
using System.Text;

public class ConsoleOutput 
{
 static void Main(string[] args)
 {
  Console.Write(HashUtils.GetSHA("It's just data"));
 }
}

public class HashUtils
{
 protected HashUtils() {}
 public static string GetSHA(string source)
 {
  return BitConverter.ToString(new SHA1CryptoServiceProvider().ComputeHash(
   Encoding.Default.GetBytes(source))).Replace("-", String.Empty);
 }
}
Published Tuesday, August 05, 2003 6:50 PM by grant

Comments

Tuesday, August 05, 2003 8:06 PM by grant

# re: C# SHA1 String Hashing

If you are hashing passwords, something like what you describe is the right abstraction.

If you are hashing content, an object that allows you to update the hash block by block as you obtain the text is also useful. I presume that this is what the TransformBlock and TransformFinalBlock are for, but I was not able to decipher how they are to be used given the information available in the online MSDN.

If somebody knows, I would appreciate it if a sample (or a pointer to a sample) is placed here for others to find.
Tuesday, August 05, 2003 10:01 PM by grant

# re: C# SHA1 String Hashing

Yeah I've didn't have any luck getting that to actually compute coherent hashes.

I had thought they were basically the underlying methods for ComputeHash(stream) but that's not the case. ComputeHash reads the stream and hashes to its own local buffer before performing HashFinal.

For larger content, I've just hashed against a stream, but I've never really had a need for the intermediate results.
Thursday, October 16, 2003 11:22 AM by grant

# re: C# SHA1 String Hashing

Here's another approach:

public struct HashString {
private static string hstring;

private HashString(string s) {
hstring = s;
}

public static implicit operator HashString(string s) {
return new HashString(s);
}

public override string ToString() {
return hstring;
}

public string ToString(SHA1CryptoServiceProvider provider) {
byte[] b = provider.ComputeHash(Encoding.Default.GetBytes(hstring));
string s = BitConverter.ToString(b);
return s.Replace("-", string.Empty);
}
}

/* ... */

static void Main(string[] args) {
HashString s = "It's just data";
Console.WriteLine(s.ToString(new SHA1CryptoServiceProvider()));
Console.ReadLine();
}

I think this is a bit cleaner, but it's really just another side of the same pie.
Thursday, October 23, 2003 1:51 PM by grant

# re: C# SHA1 String Hashing

What about hashing file streams?
Tuesday, December 23, 2003 3:30 PM by grant

# re: C# SHA1 String Hashing

Hey guys, be careful there with BitConverter - this doesn't look like the intended use for this class. You *might* get away with it here, but I've bumped into data corruption problems when abusing the analogous class in Java, and in a very similar situation.

The thing to remember is that not every byte sequence is a valid sequence according to whatever character encoding BitConverter might happen to be using, and its behavior on those byte sequences is probably undefined, and thus subject to change or subject to blowing up. This class is intended for restoring character data - not for representing arbitrary binary data. (For those who care, you can be fairly certain BitConverter.ToString is not an injection, aka multiple inputs could yield same output, thus leading to loss of data, or in this case to increased odds of collision.)

A better strategy is to use a string function whose behavior is well-defined for the entire input space, e.g. Convert.ToBase64String(). Perhaps the output will be slightly less compact, but it is safer, better defined, and more fuure-proof.

(Another advantage: it is easier to answer important questions like "exactly what encoding spec are you using?" if this data is to be used by code written in another language or environment, or if you're documenting your format.)

Ben
Anonymous comments are disabled