What is the algorithm used to derive the key to a TMyEncryptor ?

[dormky 2]

Okay, so according to my understanding CBC xors the plain data with the previous block (encrypted) before applying encryption. And here instead, the plain data is encrypted directly and then xor'd with the last block.

In this case, if I were to truncate my data to 8-bytes blocks, then encrypt the bytes that were removed by themselves with an IV of all 0 I could then xor the result with the last block myself, thus landing on the same result as MyDAC ? Since the last few bytes would be xor'd with the zeroed IV they wouldn't be changed before encryption, just like MyDAC is doing here.

[Kas Ob. 121]

51 minutes ago, dormky said:

And here instead, the plain data is encrypted directly and then xor'd with the last block.

In this case, if I were to truncate my data to 8-bytes blocks, then encrypt the bytes that were removed by themselves with an IV of all 0 I could then xor the result with the last block myself, thus landing on the same result as MyDAC ? Since the last few bytes would be xor'd with the zeroed IV they wouldn't be changed before encryption, just like MyDAC is doing here.

If only it was this simple.

 

and NO, that will not work, you are miss understanding how encryption work, and don't be offended, this is not for everyone.

First you have to read a little how encryption modes work, https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

Second, you must understand and never forget one essential element in encryption, the internal state (the context) does advance with every encryption process performed, meaning .... well this will get a little complicated here...

 

1) If the Data length (in whole) less than one block, this the output is similar to CTR with IV=0, CTR doesn't have IV (to be exact) but have counter|nonce works as IV, but as it is 0 for the first block then it does work for this case with DevArt broken implementation.

2) If the Data length multiple is longer than 8 bytes, then for all full blocks (n*8) then it is pure CBC, and it is correct.

3) here comes the rest if there is more fewer bytes than 8 meaning [1..7] bytes when the length of Data (the original length ) was more than 8, in this case there is nothing out of the box can help you or able to decrypt it,

Why?

Because the internal state of the this last block is already unknown and depends on the last one, and this can't be fixed by using key or IV !!, from the wikipedia link you see these boxes indicating encryption, but the state is changed and can't be injected or altered, this is way more complicated then follow the wrong doing.

 

As i said, you need an implementation and it need to be corrupted to be compatible, just to make sure you do understand what i am saying, it is CTR for less than 8 bytes CBC for all the 8*n, if there is remaining bytes then it is more like CFB mode, and in all cases the state is one !, meaning you can't switch or reinitialize cryptor/decryptor, you need the state to be chained as usual. 

 

You also didn't answer my question, about is it essential to be decrypted using different language/package/library, as you can use DevArt Encryptor to decrypt anything encrypted with it, it is wrong but consistent.

 

Also look at this clean and simple implementation in C# (no extensive OOP or forced padding),  https://gist.github.com/vbe0201/af16e522562b2122953206d8bbd1eb50#file-alefcrypto-cs-L368

at that line i marked, comes the adjustment to handle full blocks or xor after encryption for less than full block and this in theory should solve your problem, in case you want to go with this way, then build project and test cases for multiple values with multiple length and come back if you can't do it, and i will try to help.

 

An you know what CTR that you found returning same result for less than 8 bytes is identical to CFB with IV=0, so it is CBC for all 8 bytes then the rest is handled as CFB and to be accurate CFB8 (as 8 bits) happen on bit level in case you faced this discriminations searching the web.