asked on
VB.NET AES Encryption
Sorry, encryption newbie here. Can someone provide some feedback on this AES encryption algorithm?
1) Is it possible to determine if this AES-128, 256 or 512?
2) Does the fact the encryptor.Key and encryptor.IV are the same make this less secure?
Thanks.
Public Shared Function SampleEncryptAES2Base64(ByVal dataToEncrypt As String, ByVal Password As String) As String
Dim keyBytes As Byte() = UTF8Encoding.UTF8.GetBytes(Password)
Dim rfc As New Rfc2898DeriveBytes(Password, keyBytes, 1000)
' Use the AES managed encryption provider
Dim encryptor As New AesManaged()
encryptor.Key = rfc.GetBytes(16)
encryptor.IV = rfc.GetBytes(16)
Using ms As New MemoryStream()
Using encrypt As New CryptoStream(ms, encryptor.CreateEncryptor(), CryptoStreamMode.Write)
Dim dataBytes As Byte() = New UTF8Encoding(False).GetBytes(dataToEncrypt)
encrypt.Write(dataBytes, 0, dataBytes.Length)
encrypt.FlushFinalBlock()
encrypt.Close()
Return Convert.ToBase64String(ms.ToArray())
End Using
End Using
End Function
1) Is it possible to determine if this AES-128, 256 or 512?
2) Does the fact the encryptor.Key and encryptor.IV are the same make this less secure?
Thanks.
EncryptionVisual Basic.NET
Last Comment
btan
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
The IV is designed to get different output for the same key and plaintext. So that an attacker cannot count symbols or words or patterns. Thus it should be different for each message.
But when it is different for each message, how do I know it to decrypt a cipher? Cause you send the IV with message. That's also the reason, why the key should be never the calculation base of the IV, cause maybe there is inverse operation, which would reveal the key.
But when it is different for each message, how do I know it to decrypt a cipher? Cause you send the IV with message. That's also the reason, why the key should be never the calculation base of the IV, cause maybe there is inverse operation, which would reveal the key.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Thanks for the explanation, ste5an. This makes sense for sending a series of messages. However, if this is being used inside a desktop application to save and retrieve passwords, etc. from a handful (let's say 3) of local files (as private documents, not to be sent elsewhere through internet, etc.), would it make sense to just hard code a random IVs for the file? As the file continues to be updated, would it be OK to continue to use the same IV or should I keep changing the IV with each file update and track the IV as well?
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
As long as the IV remain unique to the each file, it is alright for "hardcode". The random would be generated from RNG. Reencryption of the same updated file does not need to change the existing IV.
ASKER
Thanks to all. For any other newbies reading this later on, I figured out that the IV (Initiation Vector):
1) should be uniquely generated, preferably every time a new message needs to be encrypted. This is mainly used to prevent someone from trying to look for patterns to crack the encrypted message. Re-using the same IV makes it easier to crack. Worse, don't generate the IV based off the password. Even worse, don't make it the same as the password.
2) while the password can remain the same, the IV should be changed with every new message
3) can be manually generated or created through one of many cryptoservices
4) does not need to be "encrypted"
5) can be pre-pended to the beginning of a final encrypted stream.
6) during decryption, the unencrypted IV at the beginning of a stream can then be used with the password to decrypt the rest of the message stream (the encrypted payload)
7) therefore, no need to track or save the IV anywhere except in the message stream itself
More reference info:
AesCryptoServiceProvider Class
Good AES Initialization Vector practice
1) should be uniquely generated, preferably every time a new message needs to be encrypted. This is mainly used to prevent someone from trying to look for patterns to crack the encrypted message. Re-using the same IV makes it easier to crack. Worse, don't generate the IV based off the password. Even worse, don't make it the same as the password.
2) while the password can remain the same, the IV should be changed with every new message
3) can be manually generated or created through one of many cryptoservices
4) does not need to be "encrypted"
5) can be pre-pended to the beginning of a final encrypted stream.
6) during decryption, the unencrypted IV at the beginning of a stream can then be used with the password to decrypt the rest of the message stream (the encrypted payload)
7) therefore, no need to track or save the IV anywhere except in the message stream itself
More reference info:
AesCryptoServiceProvider Class
Good AES Initialization Vector practice
Just a minor add on, the mode of symmetric operation determines the size of the IV. This is usually the same as the block size but it doesn't have to be. For instance, for (AES-)GCM the default IV size is 12 bytes
As for the key-IV issue: if I created a new variable as "rfcIV" as below with a different number of iterations as below, would this be more secure/random as the IV?
Open in new window