Does it make sense to run a encryption key (2048 bit) generated with the RNGCryptoServiceProvider through Rfc2898DeriveBytes.GetBytes() or is Rfc2898DeriveBytes more geared toward generating encryption keys from shorter keys like passphrases?
Rfc2898DeriveBytes.GetBytes() is mainly used for getting a key of the right size with your encryption chipper size. If you're sure that your key is secure this is not needed (and of course if the key sizes match). If it's a user input (i.e. a passkey), than definitely use Rfc2898DeriveBytes class to derive a proper key (or use hashing with salt).
If you already have something suitable for a key, which it appears you have, why would you use it to generate another key? Personally I don't see any benefit putting it through derived bytes as you already have a cryptographically secure random number.
Related
I have an encoding application written in C# where users can optionally encrypt messages. I had been using the class in this answer, and it turns out I'm in good company because I found several places online that use the exact same code (one of which is Netflix's Open Source Platform).
However, comments to that answer (as well as later edits to that answer) led me to believe that this method was insecure. I opted to use the class in this answer to the same question instead.
How secure is AES encryption if you use a constant salt? How easily can this method be broken? I admit that I have very little experience in this area.
AES is a block cipher. A block cipher's input is a key and a block of plaintext. A block cipher is usually used in a block cipher mode of operation. All secure modes of operation use an Initialization Vector or IV. Otherwise identical plaintext would encrypt to identical ciphertext (for the same key), and this is leaking information.
Salt is not used by AES or modes of operation. It's usually used as input for Key Derivation Functions (KDFs), especially Password Based Key Derivation Functions (PBKDFs). Dot NET's Rfc2898DeriveBytes implements the PBKDF2 function as defined in - you'd guess it - RFC 2898: "PKCS #5: Password-Based Cryptography Specification Version 2.0".
If you use a static salt in a PBKDF2 then you would get the same key as output (for the same number of iterations). Now if you would ever leak the resulting key then all your ciphertext would be vulnerable. And if you would use multiple passwords then an attacker would be able to build a rainbow table; the PBKDF2 work factor would become less important; the attacker can simply build one table and then try all the resulting keys on all possible ciphertexts.
So, as the salt is not actually used for AES it doesn't make much of a difference for the security. It is however still a horrible sin, even worse than using the default iteration count for PBKDF2 / Rfc2898DeriveBytes.
Note that horrible security sins are committed by a large number of people on a daily basis. That there are many many many persons that get it wrong doesn't tell you that you are in "good company". That there are 289 upvotes just tells you that SO answers about cryptography should not be trusted based on vote count.
Salt is there for a reason.
This enables same input to be encrypted differently.
If an attacker would really insist, he can find some patterns that repeat themselves in encryption without salt, and eventually can get to your key more easily.
Still the attcker would have to work very hard.
Using constant salt equals to not using salt at all.
And it is highly recommended to use it, as it has no effect on the decryption process.
What is considered "best practice" for encrypting certain sensitive or personally identifiable data in a SQL database (under PCI, HIPAA, or other applicable compliance standards)?
There are many questions here regarding individual aspects of a solution, but I have not seen any that discuss the approach at a high level.
After looking around for quite some time, I came up with the following:
Use CryptoAPI and Rijndael
Generate IV and store it with the encrypted data
Use DPAPI (Machine scope) to "protect" the symmetric key
Store the symmetric key in the registry or a file or the database, split the key and store parts in multiple places for added protection
do not decrypt the data unless it is really needed, i.e. not upon read from the database. Instead, hold cipher text in memory.
Is this adequate? Outdated? Audit-safe? Reckless?
Your approach is good, with a few adjustments in my eyes (I code for PCI compliance generally):
Use CryptoAPI and Rijndael
Use Rijndael/AES256 at a minimum, regardless of other APIs
Generate IV and store it with the encrypted data
Good
Use DPAPI (Machine scope) to "protect" the symmetric key
Not sure if it matters. I'd just keep the IV next to the data that's encrypted, or if you're really paranoid on some other medium. Ensure that the IV is not accessible to the public.
Store the symmetric key in the registry or a file or the database, split the key and store parts in multiple places for added protection
Storing in multiple places will not help you if someone steals your media. It's a bit overkill to split the key up all over heck, but definitely do NOT store it with your IV and/or ciphertext. That'd be bad.
do not decrypt the data unless it is really needed, i.e. not upon read from the database. Instead, hold cipher text in memory.
Definitely. Holding cipher text in memory in fine, but don't pass it around anywhere, and don't decrypt except when you absolutely must, and even then don't EXPOSE the entire unencrypted dataset - only what is needed from it at the minimum. Also, do not hold the key in memory if possible - a memory dump could expose it.
Additions:
Whatever database you store your cipher text in, restrict read access entirely to the proc(s) that select for a given identifier. Do not allow read access to the tables that store this data to ANYONE, even the SA account. This way, a person who breaks into your system will have a hard time pulling down your cipher texts without knowing what IDs to look for. Do the same for any table(s) referencing the identifier on the ciphertext table. DO NOT ALLOW BLANKET READS OF THESE TABLES!
Restrict database access by IP
Never persist any unencrypted plaintext in memory over state. Allow it to be dereferenced/garbage collected as soon as the request is completed.
Restrict the server(s) running this code to as few users as possible.
Possibly combine encryption methods for a stronger ciphertext (AES + Blowfish for example)
Hope these help. Some of them are my personal opinions but remain PCI compliant to the best of my knowledge.
I saw that one of the previous comments mentioned that it doesn't matter if you use CryptoAPI. I just wanted to point out that CryptoAPI is FIPS 140-2 compliant, while Bouncy Castle and the built-in managed classes (all the ones with "Managed" at the end of their names in the System.Security.Cryptography namespace) are not. If you have a requirement for FIPS compliance, it's probably easiest to for you to use CryptoAPI.
I would add:
Keeping the IV hidden is not important. It's OK if the IV is public. Just use good IVs, which means, use a cryptographic-strong random number generator so that your IVs are indistinguishable from random.
Storing the encryption key separate from the data that it encrypts.
Add authentication to your encryption. For example, add an HMAC keyed with a second symmetric encryption key, covering the ciphertext. If you don't use some form of authenticated encryption, then your ciphertext could be modified, and you have no way of knowing (AES will decrypt garbage just fine.) You want any tampering of the ciphertext to be noticed.
Taken more generic list of best practices, from OWASP (Cryptographic Storage Cheat Sheet):
Use strong approved cryptographic algorithms
Do not implement an existing cryptographic algorithm on your own
Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing
Do not use weak algorithms, such as MD5 or SHA1
Avoid hashing for password storage, instead use Argon2, PBKDF2, bcrypt or scrypt
Use approved cryptographic modes
In general, you should not use AES, DES or other symmetric cipher primitives directly. NIST approved modes should be used instead. Quote from Nist: "The approved algorithms for encryption/decryption are symmetric key algorithms: AES and TDEA."
Use strong random numbers
Ensure that any secret key is protected from unauthorized access
Also, according to this Cisco article:
DES is to be avoided and so is RSA-768, -1024
RSA-2048 and RSA-3072 are acceptable
AES-CBC mode is acceptable, while
AES-GCM mode is part of the Next Generation Encription.
I have now learnt that PasswordDeriveBytes is deprecated in favor of Rfc2898DeriveBytes.
Looking up Rfc2898DeriveBytes on MSDN. There is a code example that uses TripleDES.
But TripleDes is older and weaker than AES. Why have they seemingly taken one step forward and one step back?
Can one just replace the TripleDes with AES or is Rfc2898DeriveBytes intrinsically linked to TripleDes?
A password based KDF simply turns a password+salt into a sequence of bytes which you can use as key, or store as password hash.
It's in no way linked to your choice of cipher, you can use PBKDF2 together with AES. One minor issue is how much data you read from PBKDF2-HMAC-SHA-1. I recommend only reading 20 bytes, and using a separate hash to increase their size when that's needed.
There is no reason to follow MSDN examples. They often do not follow good coding practices. Just because they use 3DES doesn't mean you should.
PBKDF2 (Rfc2898DeriveBytes) is used to derive a key from a password (Key Derivation Function), the key length it generates and what you do subsequently are your choice, so use PBKDF2 to generate they key and use which ever symmetric cipher you like. To answer your question, there is no intrinsic link.
I'm generating an encryption key to encrypt some sensitive data with the Rijndael (AES) encryption algoritm. I'm using a guid as key generator. Are these keys "strong" enough?
Note: it is only sensitive for 20 minutes.
No. The GUID keys can be predicted, at least those generated by .NET / WinAPI. Also keep in mind that the GUID does not even have a true 128bit randomness, because the version number is fixed. This gives you a very weak key in the first place.
To make matters worse, several versions of the GUID algorithm suffer from predictability. The point is that GUIDs are not created at random, but they follow certain rules to make it practically impossible for GUIDs to collide.
As discussed in the comments, GUID V1 suffered from privacy issues (or, the other way around, weaker keys) because the MAC address was used to generate them. With GUID V4, there are still ways to predict the sequence according to the (russian) source below.
Fortunately, .NET has cryptographically strong random generators on board. The RNGCryptoServiceProvider is your friend:
RNGCryptoServiceProvider _cryptoProvider = new RNGCryptoServiceProvider();
int fileLength = 8 * 1024;
var randomBytes = new byte[fileLength];
_cryptoProvider.GetBytes(randomBytes);
You might want to refer to:
How can I generate a cryptographically secure pseudorandom number in C#? -- shows alternatives and in a comment, the link to Wikipedia is given:
http://en.wikipedia.org/wiki/Globally_Unique_Identifier
In there, it is claimed (according to wikipedia, the page is in Russian)that one can predict previous and future numbers generated:
http://www.gotdotnet.ru/blogs/denish/1965/
No, GUIDs are not cryptographically secure. They follow an extremely predictable and well-documented pattern, and they're fairly short as far as truly secure keys go. But more to the point, you're misusing GUIDs by doing this. This is not what they were designed for. They're globally unique identifiers. The only guarantee you get is that each of them is unique. A sophisticated hacker will make child's play of reverse engineering a GUID.
Use the functions provided by the System.Security.Cryptography namespace, instead. That's what they're designed for. Read up on cryptographically secure pseudo-random number generators.
I would not use a GUID for the key to encrypt data. Look at some of the implementations of the UUID protocol: UUID they can be predicted as they're computed to be unique, not random. I'd look into the using System.Security.Cryptography namespace for objects like "TripleDESCryptoServiceProvider" for sensitive data personally.
Consider using this, or an equivalent random string generator: http://msdn.microsoft.com/en-us/library/aa379942%28VS.85%29.aspx
I'm no crypto expert, but as I understand it, 3DES is a symmetric encryption algorithm, which means it doesnt use public/private keys.
Nevertheless, I have been tasked with encrypting data using a public key, (specifically, a .CER file).
If you ignore the whole symmetric/asymmetric thang, I should just be able to use the key data from the public key as the TripleDES key.
However, I'm having difficulty extracting the key bytes from the .CER file.
This is the code as it stands..
TripleDESCryptoServiceProvider cryptoProvider = new TripleDESCryptoServiceProvider();
X509Certificate2 cert = new X509Certificate2(#"c:\temp\whatever.cer");
cryptoProvider.Key = cert.PublicKey.Key.
The simplest method I can find to extract the raw key bytes from the certificate is ToXmlString(bool), and then doing some hacky substringing upon the returned string.
However, this seems so hackish I feel I must be missing a simpler, more obvious way to do it.
Am I missing a simpler way to use a .cer file to provide the key data to the C# 3DES crypto class, or is hacking it out of the certificate xml string really the best way to go about this?
It's not a good idea to use keys generated for asymmetric cryptography for symmetric cryptography. There's nothing preventing you from coming up with a way of using a public key as an encryption key for 3DES, but the end result will be that anyone having access to the public key (and this means everyone!) will be able to decrypt your ciphertext.
cryptoProvider.Key = cert.GetPublicKey()?
Encrypting large amounts of data with asymmetric cryptography is not the way to go. Instead, encrypt the data with a symmetric algorithm and encrypt the symmetric key (and IV) with your public key.
This page from MSDN really helped me get going with .Net symmetric cryptography.
The real problem here is that the public key is, well, public. Meaning freely available, meaning it's providing zero security of encryption.
Heck, anyone on this thread has all the information they need to decrypt everything. So do googlers.
Please try to encourage your users not to use public key data like that. At the very least, get them to give a password or some other slightly-more-secure chunk you can use to generate a consistent key.
One more thing. Certificate keys vary in size. It can probably handle throwing away extra bytes in the key, but you'll probably get an Array Index / Out Of Bounds exception if the key happens to be shorter than the 3DES key needs. I doubt that'll happen, 3DES only needs 56bits, and cert keys are almost always 256bits or larger.
I think what you are missing is converting the bytes from the string containing the key-bytes.
Hope the method FromBase64String will help you:
byte[] keyBytes = Convert.FromBase64String(sourceString);