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
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.
Does the hashing algorithm of the MD5CryptoServiceProvider use some sort of key? If I have a webfarm (or multiple web roles in Windows Azure) will the result of a hash always be the same given the same input on different servers? Or do I have to set some sort of key on the web.config across all servers?
Cryptographic hash functions will always give the same result. They don't take a key.
But I would avoid MD5 in favor of SHA-2 for most applications. MD5 has been broken, in particular finding collisions is easy. And neither MD5 nor plain SHA-2 is fit for password hashing, if that's what you're doing.
There is a related concept: Message-Authentication-Codes (MAC). One of the most popular forms, HMAC is based on hashing the message and the key in a certain way.
To prevent tampering with parameters, I recommend using HMAC-SHA-256, with Base64 encoding. You can truncate it if it's too long. What you should NOT DO is using Hash(key + message), that's trivially vulnerable to a length extension attack.
According to this, Retrieve ASP.Net AutoGenerated MachineKey , the answer sounds like no (keys are not needed and things will work fine on a webfarm)
I'm trying to understand some C#-code, I have been handed, which deals with cryptography, and specifically uses PasswordDeriveBytes from System.Security.Cryptography.
In the .NET docs , it says that PasswordDeriveBytes uses "an extension of the PBKDF1 algorithm" which is later in the document specified as "the PKCS#5 v2.0 standard", which is PBKDF2 (as far as I can tell). Everywhere on the net I've found (including here on Stack Exchange), though, everyone says "use Rfc2898DeriveBytes, cause Password* is deprecated and uses PBKDF1". But the only difference in the docs at msdn.microsoft.com seems to be that the Rfc*-version specifically mentions PBKDF2, where Password* says "extension of PBKDF1" and "PKCS#5 v 2.0".
So, can anyone tell me what the difference is between the two classes (if any) and why I should use one rather than the other for PBKDF2 password key derivation?
Now, other code, that deals with the same data, explicitly uses PBKDF2, and works, so that would suggest that indeed PasswordDeriveBytes also uses PBKDF2, or that PBKDF2 is simply compatible with PBKDF1 under certain circumstances, but I want to know for sure that it's not some side effect of some random thing, and that things just magically works (and eventually probably will magically and spectacularly break) without anyone really understanding why.
If you instantiate PasswordDeriveBytes and make a single call to the GetBytes method passing a value which is smaller than the output size of the underlying digest algorithm then you get back a value from the PBKDF1 algorithm.
If you make two calls to GetBytes for the same object you may encounter a counting bug in the implementation.
PBKDF1 is only described to output up to the size of the hash algorithm (e.g. 20 bytes for SHA-1), but the PasswordDeriveBytes class has made up a formula to support up to 1000 times the hash output size. So a large value produced by this class may not be easily attainable in another platform.
If you instantiate Rfc2898DeriveBytes you get a streaming implementation of the PBKDF2 algorithm. The most obvious difference of PBKDF2 over PBKDF1 is that PBKDF2 allows the generation of an arbitrary amount of data (the limit is (2^32-1)*hashOutputSize; or for SHA-1 85,899,345,900 bytes). PBKDF2 also uses a more complex construction (in particular, HMAC over direct digest) to make recovering the input password from an output value more difficult.
The "streaming" in the implementation is that the concatenation of GetBytes(5) and GetBytes(3) is the same as GetBytes(8). Unlike in PasswordDeriveBytes, this works correctly in Rfc2898DeriveBytes.
PBKDF1 was originally created to generate DES keys, published in PKCS #5 v1.5 in 1993.
PBKDF2 was published in PKCS #5 v2.0 (which was republished as RFC2898) in 1999. A slide deck which should be found at ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2-0.pdf (but seems to be having issues so ftp://ftp.dfn-cert.de/pub/pca/docs/PKCS/ftp.rsa.com/99workshop/pkcs5_v2.0.ppt may hve to do) further summarizes differences. (The slide deck was written by RSA Security, the creators of PBKDF1 and PBKDF2, and they are the people who recommend PBKDF2 over PBKDF1).
I think a great answer to this would be found here:
C# PasswordDeriveBytes Confusion
But to sumup:
Microsoft's implementation of original PKCS#5 (aka PBKDF1) include insecure extensions to provide more bytes than the hash function can provide (see bug reports here and here).
Even if it was not buggy you should avoid undocumented, proprietary extensions to standards (or you might never be able to decrypt your data in the future - at least not outside Windows.)
I strongly suggest you to use the newer Rfc2898DeriveBytes which implements PBKDF2 (PKCS#5 v2) which is available since .NET 2.0.
Here's a blog post detailing the differences:
http://blogs.msdn.com/b/shawnfa/archive/2004/04/14/generating-a-key-from-a-password.aspx
PBKDF2 can be used to generate keys of any length, which is very useful for password-based encryption (it can generate any key length as required by the symmetric cipher) but means less for secure password storage. It also applies the salt using HMAC instead of concatenation like PBKDF1, which has better security properties in cases of weak salts.
PKCS#5 v2.0 defines both PBKDF1 and PBKDF2, the former for reasons of backwards compatibility and also recommends you use PBKDF2 for new applications. I've no idea why the latter is better than the former, but the two .NET classes do seem to use different but interoperable algorithms. (Possibly because only the resulting key is being exchanged, not the inputs + KDF.)
After reading this post regarding the use ECC to implement the hashing using aa private key I set about trying to find an implementation of ECDH and came across BoucyCastle.
Unfortunately documentation is minimal (as in zerow!) and I'm unsure what I'm about to accomplish is completely correct/valid.
We want to simply hash 4 strings which will be the users registration information (Name, Company, their company ID and their account ID which are both 12 characters long) which will then compute a serial they can use to activate our software.
I have generated a key pair using PUTTYGEN.exe but I cannot workout how to apply this with BouncyCastle, which class can I use to get started? Are there any examples out there?
So far I've concatenated the information and computed a MD5 hash of it (using the .NET classes) I cannot use the new VISTA enhanced API functions as we target XP still - .NET 3.5.
Anyone have any ideas?
I think .NET has the RSACryptoServiceProvider class which is a full RSA implementation.
There's sample code for your particular application here:
http://www.codeproject.com/KB/security/xmldsiglic.aspx
In this example they use MS's sn.exe tool to create the key.
So far I've concatenated the information and computed a MD5 hash of it (using the .NET classes).....
That statement in itself worries me. MD5 is seriously crackable - not just theoretically but practically. Please, please don't use MD5 for secure hashing. Use SHA-256 or SHA-512 and here's why
Also the post you linked is not quite true - yes symmetric algorithms use the same key to encrypt/decrypt but public/private key is not a magic bullet.
1) Public/private key is slow
2) Most publicc/private algorithms just encrypt the symmetric key and then use symmetric encryption for the data because it's much faster
The point is that a good hashing algorithm is non-reversible and hence very difficult to crack so is perfectly fine for your purposes. However, I'd suggest using a SALT, which is a cryptographically random number to add to your user data then hash that data as it makes your data much safer against dictionary attacks ( where hackers use well know terms and variants to crack passwords )