I’m here to help
- Local time
- Yesterday, 23:00
- Oct 29, 2018
Hi. Please pardon me for jumping in. Out of curiosity, I downloaded the modified RC4 attachment and gave it a try. This is what I got. Is this correct, or did I do something wrong?Update:
I examined the code in your example for RC4 encryption. It was one of the many i came across while searching for a sufficient algorithm. Albeit, one of the least favorited of the bunch... The mistake the author made was 1.) not fixing his error 2.) superficially patching a function as critical as an encryption device with "On Error Resume Next"... Shameful!!! Other than that, I am a fan.
The code errors when it gets a subscript error when he assigns to the Key() array in first loop. I made some modifications to the code which handles this, as I really wasn't able to figure out how to properly solve this error. Someone else probably can with little effort.
The last thing I did was (somewhat crudely) apply a Base64 arg. When set, the output is converted to Base 64, which plays much better with Access. The principle reason full ASCII isn't ideal with Access is because there will be inevitable SQL Syntax clashes. Suppose the encryption text is outputted by the cipher and results in a leading or trailing character of any SQL operator (ex: ",',>,<), there will inevitably be a, Error 3075 syntax collision with a statement such as...
SQL = "SELECT * FROM Accounts WHERE ID = '" & EncryptedText & "';"
And I can say just in development typing random values for debugging my application, I came across way more instances of that clash than I was comfortable with... Maybe there's a SQL work-around with syntax.
Whether this Base64 conversion implements weaknesses into the algorithm, I'm not sure. I don't believe it has an impact.
Attached is a .txt of the module, which contains the cipher, as well as 2 supporting functions and 1 test function.