3

I'm using the TripleDESCryptoServiceProvider and need to store the encryption key.

If I call the providers GenerateKey method, is this just a base64 encoded string? If so am I safe to unencode it as such as use the resulting string as a key?

On a slightly different note, is there any problem with using this same key as a salt key when doing one-way hashes? I'm writing a simple membership provider for .net which allows the user to choose the encryption technique (plain, hash, encrypted) so wondered whether it was necessary to make the user specify both a salt key and encryption key.

poupou
  • 43,413
  • 6
  • 77
  • 174
Ben Foster
  • 34,340
  • 40
  • 176
  • 285

2 Answers2

4

Calling GenerateKey will generate a new, random, safe (i.e. not weak) key. It's length (128 or 192) will depend on how your TripleDESCryptoServiceProvider is set up.

If I call the providers GenerateKey method, is this just a base 64 encoded string?

The format itself is a byte[] array since you can only retrieve it from the Key property - so it's not base64, but can easily be encoded that way if you wish, e.g. Convert.ToBase64String(algo.Key);

If so am I safe to unencode it as such as use the resulting string as a key?

You cannot use a string as a key - not unless you convert it back to a byte[]. However you can keep the key as a string between it's uses (if that's any help to your application).

On a slightly different note, is there any problem with using this same key as a salt key when doing one-way hashes?

If you use the random data as a key or as a salt then there should be no issue. Just don't use the same data for both (and).

poupou
  • 43,413
  • 6
  • 77
  • 174
1

On a slightly different note, is there any problem with using this same key as a salt key when doing one-way hashes?

Salts are public parameters; and private and symmetric keys should be secret.

I'm writing a simple membership provider for .net which allows the user to choose the encryption technique (plain, hash, encrypted) so wondered whether it was necessary to make the user specify both a salt key and encryption key.

We would need to see more information on the scheme before answering. In general, I would not feel comfortable allowing a user to choose formats or parameters (other than a password).

jww
  • 97,681
  • 90
  • 411
  • 885
  • here the "user" is the developer. I certainly would not allow the application user to decide this. So there's nothing wrong with storing the salt alongside the hashed password? – Ben Foster Oct 11 '11 at 08:44
  • @Ben: it sounds a lot like a unix password file (a {user, salt, hash} tuple). If so, I would not have a problem with the storage format. – jww Oct 11 '11 at 18:08