While using asymmetric algorithm, which is best place to store private key
in client system in client-server applications.
- Prasad.
--- More Realistic approach (but not really good security practice) ------
Have CryptoAPI securely generate the keys for you by using appropriate .NET
RSA overloaded constructor. This does not protect your private key access very
well (no password required to accessing your private key and any app. can export
your keys!).
You should export the private key blob immediately, and reimport it as nonexportable
and with strong (pswd) protection, using other CryptoAPI utilities.
If your computer is secure, at least this means that applications running as you
won't automatically be able to do things like sign on your behalf
etc..
- Mitch Gallant
MVP Secuity
"Prasad" <pai...@vertexcs.com> wrote in message news:u9Wo1oO4...@TK2MSFTNGP09.phx.gbl...
A common technique is to encrypt private keys using a symmetric algorithm.
Typically the symmetric key is derived from some sort of a passphrase.
-Derek
I thought it was common to encrypt private keys using an asymmetric
algorithm, i.e. public key encryption?
What do you mean by the "symmetric key is derived from some sort of a
passphrase"?
-dh
"Derek Slager" <de...@activate.net> wrote in message
news:pan.2004.01.22....@activate.net...
It is common to encrypt a symmetric secret (session) key with an asymmetric
public key encryption (e.g. this is used in most S/MIME encryption approaches).
The op was asking about protection of the asymmetric (e.g. RSA/DSA) private
key itself.
My first response showed the best way to let the OS protect it for you (which really
uses underlying symmetric key encryption based on user principal credentials.
For more portability, you can export your RSA public/private keypair and encrypt
it with a password derived symmetric key. In .NET you use PasswordDeriveBytes
class to generate cryptographically strong byte sequence for symmetric key generation.
Password derived symmetric keys basically just take the hash of the password and
the actual secret symmetric key is typically the first bytes of that hash (more complicated
procedure is 3DES is the derived key).
See also the paragraph "Key Maintenance | Protecting Exported Private Keys" here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh07.asp
- Michel Gallant
MVP Security
http://www.jensign.com
I want to store some data encrypted in an SQL Server database. So that only
my applications can get the real data (unencrypted). I am using the managed
Rijndael class to encrypt the data. My problem is how do I store the key
(and I suppose the IV, I am using the same for both) so that my .NET Form
applications (2) will be able to get the data but nobody else.
If I use PasswordDeriveBytes as the article suggests, see the following
code, it seems to me that I know have the same problem except that instead
of securely storing my Rijndael key I know have to store my "strong
password" securely. What have I gained? I don't need absolute security. I
just want to make it quite difficult to use the data I am storing in SQL
Server. What am I missing? Are there some techniques where I can
'actually' store the key or password in my .NET code but do so in a way that
disassemblers can not easily show the storage?
PasswordDeriveBytes deriver = new PasswordDeriveBytes("strong password",
null);
byte[] ivZeros = new byte[8];//This is not actually used but is currently
required.
//Derive key from the password
byte[] pbeKey = deriver.CryptDeriveKey("TripleDES", "SHA1", 192, ivZeros);
Thanks for any help you can provide...
-dh
"Michel Gallant" <neu...@NOSPAMistar.ca> wrote in message
news:%23Fgxcwy%23DHA...@TK2MSFTNGP12.phx.gbl...
You generate a good random encryption credential using PasswordDeriveBYtes
and DON'T store any information at all about your password in that database.
Ultimately this boils down to how easy you want to make it to decrypt versus
how paranoid you are about anyone else getting access to credentials that specify your encryption
key.
It will of course depend on how important the information is that you are protecting
in your database.
There is no magic here. You will always need to protect access to SOME credentials.
Even if you use a hardware token, you need to protect it ... and usually with an extra
password layer there too!
- Mitch Gallant
"David Hoffer" <dhoffer...@xrite.remove.com> wrote in message
news:exWbNY8%23DHA...@TK2MSFTNGP10.phx.gbl...
As Michael said, it is a fundamentally difficult problem to solve, so there
is no silver bullet. There are, however, some known techniques which are
better than others. If you are new to security, check the "Safeguard
Database Connection Strings and Other Sensitive Settings in Your Code"
article at
http://msdn.microsoft.com/msdnmag/issues/03/11/ProtectYourData/default.aspx.
It will not give you the direct answer (i.e. this is what you need to do),
because it very much depends on the type of application, environment, etc,
but at the least, it will give you some pointers and may help you pick a
reasonable option (and avoid obviously bad decisions).
Alek
"David Hoffer" <dhoffer...@xrite.remove.com> wrote in message
news:exWbNY8%23DHA...@TK2MSFTNGP10.phx.gbl...
"Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
news:uDCtTA9%23DHA...@TK2MSFTNGP11.phx.gbl...
"Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
news:uDCtTA9%23DHA...@TK2MSFTNGP11.phx.gbl...
I will check out the link you suggested.
-dh
"Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
news:u40cDN9%23DHA...@TK2MSFTNGP10.phx.gbl...