Hi Rick,
I am trying out the option to use AES encryption. I have figured out some of the new parameters by doing some reading (e.g. cipher mode using CBC better than ECB).
was using TripleDES before: my key was about 50-55 characters long; in your example, you pad a key to 24 chars; do I have to truncate my current key to 24 chars? It seems to me the hash parameters are used to hash the key anyhow which should shorten the length
or do I just have to provide a 16 or 24 byte key if using AES?
it seems the icIVKey is always required with AES; in reading, it seems this is used to set up the first block to be encrypted when using AES-CBC encoding; does this need to be of a particular length and/or is it required?
Thanks, Albert
I don't remember either - there are so many combinations. You need to see what the protocol requires and adjust as necessary.
I've looked at this and figured this out at some point but promptly forgot because it's all so bloody confusing. Encryption is a nightmare, and not because of the tools but of the nature of the algorithms unfortunately and poor naming of the pieces (IV? Salt?).
The examples I've posted in the docs cover some of the most common scenarios.
+++ Rick ---
I don't remember either - there are so many combinations. You need to see what the protocol requires and adjust as necessary.
I've looked at this and figured this out at some point but promptly forgot because it's all so bloody confusing. Encryption is a nightmare, and not because of the tools but of the nature of the algorithms unfortunately and poor naming of the pieces (IV? Salt?).
The examples I've posted in the docs cover some of the most common scenarios.
From what I remember ECB is an auto-filling algorithm so if you provide a key that isn't the right size it'll auto-fill to the nearest bit requirement. CBC requires exact bit counts and IV to match.
What I usually do is find an example somewhere and then match the settings. There are a number of online encryption 'calculators' that let you experiment with various algos.
+++ Rick ---
Hi Rick,
I assume passing "AES" means AES256 encryption?
Albert
Hi Rick,
I've got the AES encryption working as I need. I made some notes of what did or did not work - there might be something in these to add to your help notes (if you like). Also, there are a couple suggested code changes needed to .EncryptString/.DecryptString at the bottom.
Albert
optional parameters: for my wrapper functions that call EncryptString/.DecryptString, I prefer to pass all the parameters with each call (regardless if using default TripleDES or AES) i.e. I don't want one call for TripleDES and another for AES; findings: need to pass the optional ones as .F. or null (not "") because even if using the default TripleDES mode (where one might assume that lcIvKey will be ignored) an error is thrown if "" is passed for lcIVKey
when encrypting with AES and lcCipherMode = ECB, one would think that lcIvKey is not needed (see wikipedia article https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation) as the "IV" (initialization vector) is used with the encryption on the first block; findings: it is needed or the error "You have to pass an IV Key with AES encryption" is thrown
could not get hash mode of SHA1 to work regardless of any combination of key or lcIVKey lengths (16/20/24/32 bytes); could not find example online for guidance
but was able to get hash mode of SHA256 to work; key length did not matter (lcIVKey still had to be 16 byes though)
Possible Code changes:
if error is thrown in .EncrytString(), a second error occurs because lcReturn is never initialized and therefore cannot be RETURNed; declared all 3 local vars (lcError, lcReturn, loException) and initialized lcReturn to blank character
.DecryptString(): added loException to LOCALs list as missing and initialized lcResult to blank char
if error is thrown in .EncrytString(), a second error occurs because lcReturn is never initialized and therefore cannot be RETURNed; declared all 3 local vars (lcError, lcReturn, loException) and initialized lcReturn to blank character
But the lcError
is set and so the ERROR
will fire and cause an Exception which is the expected result in this case. The exception is the failure scenario. The RETURN
is never hit in that scenario (unless the error message is empty which it shouldn't be).
f error is thrown in .EncrytString(), a second error occurs because lcReturn is never initialized and therefore cannot be RETURNed; declared all 3 local vars (lcError, lcReturn, loException) and initialized lcReturn to blank character
I remember when I was setting this up, I think the .NET lib requires the IV even with ECB. This is shady because it's hard to tell whether the IV is used or not as ECB will backfill to the specified bit width. It'll work but the values may just be wrong. This is why I mentioned it's crucial you have some sample data with unencrypted and encrypted values so you can ensure the right data is produced.
could not get hash mode of SHA1 to work regardless of any combination of key or lcIVKey lengths (16/20/24/32 bytes); could not find example online for guidance
I think SHA1 keys are too short and shouldn't be used anyway. MD5 is common for some algos, or SHA256. Again it depends on the application and which hash (if any) is used for secondary encryption. The encoding for SHA1
hashes (via ComputeHash()
works fine though, so that's not it).
+++ Rick ---
Just to confirm as you must have missed it, AES here means that AES256 is being used? Thanks
Not sure. The algo is AES. Not sure if there's a specific AES256.
+++ Rick ---
My guess it is AES256 as it is the "standard" now (in a way). I could not find anywhere a property on the AES class to read what it is implementing. I will ask on Level Extreme. Thanks.
It think AES256 refers to the key size used. Depending on the key variation algo used (ECB, CDB etc.) the key may be auto-filled or require a fixed length block of bytes.
Notice WikiPidia doesn't mention specific number variants of AES. AES is simply the algorithm that works off key plus IV that re-encodes the key multiple times to produce output. The key size can vary though and I think that's what the name is about I think because I can't find any specific reference to AES256
as a standard.
+++ Rick ---