Using the Rijndael algorithm is it possible to encrypt a config file (or section(s) in a config file) and then decrypt that file in Java? Assumptions can be made such as:
Pass in IV (not Autogenerated idea :: GenerateIV(); )
Pass in Key
BlockSize is 128 (standard)
Assuming this can be done, my next question on this would be:
Can the keySize be 256? I know 128 is AES but we would like to use 256. I also don't know if Java has that provider for 256 or if I need to use BouncyCastle
What is the Padding? PKCS7?
I assume the CiperMode would be CBC
Something like this in c#? But, no clue if it can be decrypted in Java...perhaps even my c# is wrong?
public static void initCrypt()
{
byte[] keyBytes = System.Text.UTF8Encoding.UTF8.GetBytes("abcdefghijklmnop");
rijndaelCipher = new RijndaelManaged();
PasswordDeriveBytes pdb = new PasswordDeriveBytes(keyBytes, new SHA1CryptoServiceProvider().ComputeHash(keyBytes));
byte[] key = pdb.GetBytes(32);
byte[] iv = pdb.GetBytes(16);
rijndaelCipher.Mode = CipherMode.CBC;
rijndaelCipher.Padding = PaddingMode.PKCS7; //PaddingMode.PKCS7 or None or Zeros
rijndaelCipher.KeySize = 256; //192, 256
rijndaelCipher.BlockSize = 128;
rijndaelCipher.Key = keyBytes;
rijndaelCipher.IV = iv;
}
I'd check if an external library such as keyczar supports this.
As Jeff Atwood has taught us in his blog recently, 99% of developers shouldn't be concerning themselves with the low level details of encryption routines (because we will probably screw them up).
Depending on your usage of this config file, you may want to use an external program.
For example, if you want to protect the config file while it resides on disk, but you're okay with its contents being held in memory while the program is running, you could use gpg to encrypt the file, decrypt it into memory using a user-supplied password required by the program when you start it, and then clear out the memory when you shut down the program.[1]
[1] It's worthwhile to note that there's no real way to guarantee the contents won't be written to disk because of memory paging and the like. That's dependent on operating system and a lot of factors you can look up if you are interested in it.
Q1 : It have to be 128 or you will have to use BouncyCastle
Q2 : Yes PKCS7
Q3 : Yes CBC
If your question is not dead I could give you working examples c# and java
Related
I'm working on a website, where users are able to upload files. I want to encrypt these files, in case there is some kind of security breach where access is granted to them.
When the user wants to download their files, I decrypt directly to the HTTP(S) output stream.
The files are placed on disc, and a record for each is inserted in the website database with some additional data (file name, size, file path, IV and such).
I only have a basic understanding of how to use encryption and therefore have some questions.
I'm using Rfc2898DeriveBytes to generate the bytes for the encryption key. Is it okay to use this class? As far as I know it uses SHA1, which might no longer be secure?
Right now I'm using the same password and salt for each encryption, but a random IV each time. Should I also be randomizing the salt and keep it in the database along with the IV? Will this give additional security?
Should I be using a message authentication code (MAC)? The encrypted files themselves are only stored and never transferred, so I don't know if it's necessary.
I don't really know how to best store the encryption password. I don't want to include it in my website DLL, so I'll probably have it in a file on the server somewhere that isn't in my website folder. How else could I be doing this?
This is my code for encryption. Any obvious security flaws?
const int bufferSize = 1024 * 128;
Guid guid = Guid.NewGuid();
string encryptedFilePath = Path.Combine(FILE_PATH, guid.ToString());
byte[] rgbIV;
using (Rfc2898DeriveBytes deriveBytes = new Rfc2898DeriveBytes("PASSWORD HERE", Encoding.ASCII.GetBytes("SALT HERE")))
{
byte[] rgbKey = deriveBytes.GetBytes(256 / 8);
using (FileStream decryptedFileStream = File.OpenRead(decryptedFilePath))
using (FileStream encryptedFileStream = File.OpenWrite(encryptedFilePath))
using (RijndaelManaged algorithm = new RijndaelManaged() { KeySize = 256, BlockSize = 128, Mode = CipherMode.CBC, Padding = PaddingMode.ISO10126 })
{
algorithm.GenerateIV();
rgbIV = algorithm.IV;
using (ICryptoTransform encryptor = algorithm.CreateEncryptor(rgbKey, rgbIV))
using (CryptoStream cryptoStream = new CryptoStream(encryptedFileStream, encryptor, CryptoStreamMode.Write))
{
int read;
byte[] buffer = new byte[bufferSize];
while ((read = decryptedFileStream.Read(buffer, 0, bufferSize)) > 0)
cryptoStream.Write(buffer, 0, read);
cryptoStream.FlushFinalBlock();
}
}
}
I'm using Rfc2898DeriveBytes to generate the bytes for the encryption key. Is it okay to use this class? As far as I know it uses SHA1, which might no longer be secure?
The recent efficient breakage of SHA-1 really only impacts collision resistance which is not needed for PBKDF2 (the algorithm behind Rfc2898DeriveBytes). See: Is PBKDF2-HMAC-SHA1 really broken?
Right now I'm using the same password and salt for each encryption, but a random IV each time. Should I also be randomizing the salt and keep it in the database along with the IV? Will this give additional security?
Maybe it will give additional security, but it certainly won't hurt to do this except if you add a bug. Source: Need for salt with IV
Should I be using a message authentication code (MAC)? The encrypted files themselves are only stored and never transferred, so I don't know if it's necessary.
Usually, a storage system has checks and procedures to prevent and fix data corruption. If you don't have that, then a MAC is a good way to check if the data was corrupted even if this didn't happen maliciously.
If the end user is supposed to receive the data, they can check the MAC themselves and make sure that nobody altered the ciphertext.
I don't really know how to best store the encryption password. I don't want to include it in my website DLL, so I'll probably have it in a file on the server somewhere that isn't in my website folder. How else could I be doing this?
As I understand, you actually want to hold the encryption/decryption key. Anything that you can do is really obfuscation and doesn't provide any actual security. An attacker might just use the same connection to the data storage as your usual code. At best, the attacker will be slowed down a little bit. At worst, they don't even notice that the data was encrypted, because the decryption happened transparently.
It is best to make sure that an attacker cannot get in. Go through the OWASP top 10 and try to follow the advice. Then you can do some security scanning with Nikto or hire a professional penetration tester.
This is my code for encryption. Any obvious security flaws?
Using PaddingMode.ISO10126 doesn't seem like a good idea. You should go with PKCS#7 padding. Source: Why was ISO10126 Padding Withdrawn?
Rfc2898DeriveBytes is essentially PBKDF2 which is NIST recommended.
IF you randomize the salt (a good security practice) would will have top supply it for decryption. A common way is to prefix the encrypted data with the salt and IV.
Yes, you should be using a Mac over the encrypted data and any prepended information such as above.
In order to provide suggestions on securing the encryption key more information on how the the encryption will be used.
Use PKCS#7 padding, sometimes the option is named PKCS#5 for historical reasons.
I've already searched on the internet and on Stack Overflow, but I couldn't find a solution to the following question:
I want to encrypt and decrypt data with AES algorithm in CFB mode. As far as I've read, CFB mode doesn't require padding and the encrypted data has the same size as the unencrypted data. However, when I set Padding to None and keep the standard Feedback Size at 128 bits, I get an exception saying that the length of the data to write/encrypt is invalid.
When I change the Feedback Size to 8 bits, everything works fine. But this is an extremly inefficent and therefore slow encryption process. As far as I understood, CFB can use standard Feedback Size and handle data that is shorter than the full length of a block.
Init-Code:
RijndaelManaged aes_algorithm = new RijndaelManaged();
ICryptoTransform crypto_transform;
CryptoStream crypto_stream;
aes_algorithm.Mode = CipherMode.CFB;
aes_algorithm.Padding = PaddingMode.None;
aes_algorithm.FeedbackSize = 128;
aes_algorithm.KeySize = aes_key.Length * 8;
aes_algorithm.BlockSize = aes_iv.Length * 8;
crypto_transform = aes_algorithm.CreateEncryptor(aes_key, aes_iv);
Encryption
MemoryStream Memory = new MemoryStream();
crypto_stream = new CryptoStream(Memory, crypto_transform, CryptoStreamMode.Write);
crypto_stream.Write(Input, 0, Input.Length);
crypto_stream.FlushFinalBlock();
crypto_stream.Dispose();
crypto_transform.Dispose();
byte[] Output = Memory.ToArray();
Memory.Dispose();
So what am I doing wrong or is that a bug in .NET? I've just found this topic C# AES-128 CFB Error, but there was also no real solution, except for the manual shortening of the encrypted data (which is not a nice solution, but merely a workaround).
CFB mode is usually implemented as CFB-8, that is, it encrypts 8 bits at a time.
See Wikipedia: Cipher feedback
I've been reading on different cryptography algorithms and I came across the "Diffie Hellman Cryptography Next Generation". I've made a lot of searches about this algorithm and I have found that it is an Asymmetric cryptography system which is in some ways rivaling RSA. I had a look at the .Net's System.Security.Cryptography and I found it provides Diffie-Hellman cryptography as well. So I wen't to MSDN and there I found a very nice example on how to use it in C#, but this example has brought some questions into my mind. Let me copy some part of the code first: (I don't post the full code as my question is mainly about this part)
public static byte[] alicePublicKey;
public static void Main(string[] args)
{
using (ECDiffieHellmanCng alice = new ECDiffieHellmanCng())
{
alice.KeyDerivationFunction = ECDiffieHellmanKeyDerivationFunction.Hash;
alice.HashAlgorithm = CngAlgorithm.Sha256;
alicePublicKey = alice.PublicKey.ToByteArray();
Bob bob = new Bob();
CngKey k = CngKey.Import(bob.bobPublicKey, CngKeyBlobFormat.EccPublicBlob);
byte[] aliceKey = alice.DeriveKeyMaterial(CngKey.Import(bob.bobPublicKey, CngKeyBlobFormat.EccPublicBlob));
byte[] encryptedMessage = null;
byte[] iv = null;
Send(aliceKey, "Secret message", out encryptedMessage, out iv);
bob.Receive(encryptedMessage, iv);
}
}
private static void Send(byte[] key, string secretMessage, out byte[] encryptedMessage, out byte[] iv)
{
using (Aes aes = new AesCryptoServiceProvider())
{
aes.Key = key;
iv = aes.IV;
// Encrypt the message
using (MemoryStream ciphertext = new MemoryStream())
using (CryptoStream cs = new CryptoStream(ciphertext, aes.CreateEncryptor(), CryptoStreamMode.Write))
{
byte[] plaintextMessage = Encoding.UTF8.GetBytes(secretMessage);
cs.Write(plaintextMessage, 0, plaintextMessage.Length);
cs.Close();
encryptedMessage = ciphertext.ToArray();
}
}
}
}
When I look at this, I see that it is the AES that is doing everything, and the ECDiffieHellman is only responsible for providing a key for the AES algorithm. In the meanwhile it itself is based on the SHA256 hashing system.
So my question is, what exactly is this "ECDiffieHellmanCng" doing in this case? What I see is a hybrid cryptography system, one for key exchange and the other for the encryption, this has conflict with what I've read over the internet about this Diffie Hellman algorithm, most sources list it under Asymmetric encryption systems but this example is not showing the same thing. I say this because when I look the AliceKey I see that, it is made based on a Public Key that has been probably made using SHA256 and it itself is not encrypting/ decryption anything.
What you have stumbled upon is actually the "cryptographic development platform" called "Cryptography Next Generation" developed by Microsoft. From a cryptographic point of view there is nothing revolutionary or "next gen" in there, just a new library implementing or wrapping known cryptographic algorithms.
Diffie-Hellman is one of the oldest and most respected asymmetric cryptographic algorithms available to us. It allows two parties to exchange a private key in such a way that a passive eavesdropper of their communication cannot deduce the exchanged key. As such Diffie-Hellman is an important building block for many cryptographic protocols. It's not an encryption algorithm though. After the private key has been deduced by the two parties they still have to use a symmetric algorithm to encrypt their following communication.
This is not unique to Diffie-Hellman though, every asymmetric algorithm is used with many symmetric algorithms to build a working and secure protocol. RSA for example only allows you to use encrypt 256 bytes at a time with a 2048bit key. And for security purposes you should never user raw RSA to encrypt data. I've described one combination to use RSA securely to encrypt arbitrary data in this answer.
Elliptic Curve Diffie-Hellman is a variant of the classic Diffie-Hellman that uses an other mathematical structure - an elliptic curve - as a foundation together with the same fundamental idea behind Diffie-Hellman. It has gained some attention lately as it considerable faster than the classic variant while achieving the same security level.
I'm using AesCryptoServiceProvider and CryptoStream to encrypt some data and it seems to be working OK when I use the same key for decryption. However, If I try to decrypt it with the wrong key, I don't get an exception, just junk data. I can't find anything in the .Net documentation which says what is supposed to happen but according to this:
http://books.google.co.uk/books?id=_Y0rWd-Q2xkC&pg=PA631
and this:
Why does a bad password cause "Padding is invalid and cannot be removed"?
I should be getting a CryptographicException. Am I doing it wrong? my function is this:
public static byte[] Encrypt(byte[] data, string password, string salt, bool decrypt)
{
SymmetricAlgorithm aes = new AesCryptoServiceProvider();
Rfc2898DeriveBytes rfc2898 = new Rfc2898DeriveBytes(password, Encoding.UTF8.GetBytes(salt));
aes.IV = rfc2898.GetBytes(aes.BlockSize / 8);
aes.Key = rfc2898.GetBytes(256 / 8);
ICryptoTransform enc;
if (decrypt) {
enc = aes.CreateDecryptor();
} else {
enc = aes.CreateEncryptor();
}
using (enc) {
using (MemoryStream ms = new MemoryStream()) {
using (CryptoStream cs = new CryptoStream(ms, enc, CryptoStreamMode.Write)) {
cs.Write(data, 0, data.Length);
return ms.ToArray();
}
}
}
Relying on padding errors is not a good way to determine if a key is correct or not. You should really consider using Authenticated Encryption for this purpose.
I have a public domain snip-it that works in C# for this Modern Examples of Symmetric Authenticated Encryption of a string. that I try to keep up to date and reviewed.
P.S. Also it's not clear if your salt is per domain, per user, or per ciphertext from your sample, but if it's not per ciphertext in your code the IV will be predictable and the same for many ciphertexts which is not good for AES-CBC. Implementing crypto is hard.
I've also worked on a highlevel encryption library , a C# port of Google Keyczar. But that may not work very well for you, it only supports randomly generate keys and keysets, and those keysets can then be password encrypted, but only the keysets. High level encryption frameworks are the best practice for encyption.
If you have no padding set on decryption then the decryption method won't be able to recognise junk. Set padding to PKCS#7 for both encryption and encryption and the decryption method will probably be able to recognise junk.
For full assurance, you will need authentication, as jbtule says. To include authentication and encryption in the one data pass use GCM mode. For separate authentication use HMAC.
I'm going to have to put my hands up here and say False Alarm.
I have no idea what was happening on Friday but now I'm getting what I would expect - most of the time the CryptographicException happens as expected. I've no idea whether I was just hugely unlucky with my test data or whether there was a bug in my test harness which I inadvertently fixed, but it's all behaving as expected now.
Incidentally I did a quick empirical test which validates rossum's 1/256 number but that's acceptable for my purposes. In the general case I completely accept the other comments here about HMACs etc, but what I'm doing is for a test tool
I tried to encrypt a string with System.Security.Cryptography.DES but I found that every time I run The program the result of encryption changed !
I don't know how to get the same result each time I run the application ? IS there constant key or anything else to add to get the same result ?
I want when I enter "google" in this code
byte[] plaintextBytes = (new UnicodeEncoding()).GetBytes(expireddate);
SymmetricAlgorithm sa = DES.Create();
MemoryStream msEncrypt = new MemoryStream();
CryptoStream csEncrypt = new CryptoStream(msEncrypt, sa.CreateEncryptor(), CryptoStreamMode.Write);
csEncrypt.Write(plaintextBytes, 0, plaintextBytes.Length);
csEncrypt.Close();
byte[] encryptedTextBytes = msEncrypt.ToArray();
get "google" from this code when I entered the result of array of bytes in next time i opened the application ?
MemoryStream msDecrypt = new MemoryStream(decodedlistbyte.ToArray());
CryptoStream csDecrypt = new CryptoStream(msDecrypt, sa.CreateDecryptor(), CryptoStreamMode.Read);
byte[] decryptedTextBytes = new Byte[decodedlistbyte.Count];
csDecrypt.Read(decryptedTextBytes, 0, decodedlistbyte.Count);
csDecrypt.Close();
msDecrypt.Close();
string decrypteddate = (new UnicodeEncoding()).GetString(decryptedTextBytes);
You are generating a cryptographically secure IV (initialization vector) each time you re-encrypt the plain text - this is good, and the value should change each time. The IV can be kept public and should in no way relate to the encryption key.
However Des is not a very secure algorithm any more and I would recommend switching to Rijndael or tripple des.
I recommend you use a strong symmetric key algorithm such as AES (i.e. Rijndael). Have a look at the RijndaelManaged class in .NET. The same key can be used for encryption and decryption, which is why it's a symmetric algorithm. The security of the key is vital, so keep it private and store it securely.
Like #Ross said the encrypted string will be different because a new IV should be used each time.
However you current code is using a new Key and IV each time. If you want to be able to decrypt on another computer then you should set the Key and IV yourself - or keep the one automagically produced while encrypting.
E.g. when encrypting
byte[] key = sa.Key;
byte[] iv = sa.IV;
ICryptoTransform ct = sa.CreateEncryptor ();
E.g. while decrypting (on another computer)
ICryptoTransform ct = sa.CreateDecryptor (key, iv);
You can transmit the IV with the encrypted data. The secret key should, of course, be transmitted/shared out-of-band.
Your problem isn't that he cipher text is different. This is actually an important property of an encryption scheme.
Your problem is either that you are reusing the same symmetric algorithm object without reseting its state or -- more likely, but I can't tell from the snippet, -- reintegrating the symmetric algorithm with a different key and iv.
For decrypt, generate a new symmetric algorithm and then set sa.Key and sa.IV to be the values used in the one you encrypted with. Important, make sure you store the key securely and make sure your IV is random ( you will need to include it in the data you store). Don't hardcode the IV. That is completely insecure.
By the way, DES is rather insecure ( I could try all possible keys in about 3 days 10 years ago). Use AESManaged. Also, crypto is hard and I don't recommend you do it yourself. If you do want to , consider looking at this, it does most of what you want and a little more.