Link to home
Create AccountLog in
Avatar of eeyo
eeyo

asked on

VB.NET AES Encryption

Sorry, encryption newbie here.  Can someone provide some feedback on this AES encryption algorithm?
        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

Open in new window

Specifically:
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.
ASKER CERTIFIED SOLUTION
Avatar of ste5an
ste5an
Flag of Germany image

Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Avatar of eeyo
eeyo

ASKER

Thanks.  Too bad it is limited to 256.
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?
Dim rfc As New Rfc2898DeriveBytes(Password keyBytes, 1000)
Dim rfcIV As New Rfc2898DeriveBytes(Password, keyBytes, 1001)

Open in new window

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.
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Avatar of eeyo

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
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
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.
Avatar of eeyo

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
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