CryptoEx - I'm missing something here :(

[LineCutter]

I'm still trying to get my head around the encryption potential of B4PPC. I just can't get the hang of it.

I've slimmed down the code, which is attached. The password is sent to the sub, where it is converted to an MD5 hash & then the first 64 bits are used as the key for DES object. This encrypts the string & saves it.

The decrypt routine then attempts to reverse the process.

Taking the encryption out leaves me with a spare character at the end of the string, but otherwise works as planned. (The string terminator I guess)

The table is of no significance here (it's never used).

Can anyone see what I've done wrong??

 

[agraham]

The attached code works. As I am using the next beta an sbp file may not load on your system so it is in text form to copy and paste into the IDE. The main thing for simple use is to use Mode 2 which avoids using inialisation vctors (IVs) for block chaining. Your problem was that the IV on encryption was not the same as the IV on decryption as Crypto.New1 creats a new random IV each time (The help incorrectly states that the default IV is all zeroes :signOops: it appeared like that on testing but is apparently not true :sign0013

I don't' understand "Taking the encryption leaves ..." but after decryption of a string there are spare bytes that have been used to pack the string to a muliple of 8 bytes. I've tried to explain this in the comments in DesDemo.sbp. The output from DecryptString should strip them off. Bad data complaints on DecryptString arise because when decrypted these packing bytes are not within the valid range - they have specific values to tell DecryptString how many bytes were added as packing.

You also had an unneeded extra parameter in DecryptString.

 

[LineCutter]

Thanks! :sign0188:

Hopefully this will help more people than me.

(The "taking out the encryption" refers to bf.writebytes() when applied to the array of bytes returned from the string with bit.stringtobytes(). I've attached the sbp in case that's not clear enough. I'm more than happy with the working code as a skeleton for the routine I need, which strangely enough uses the table on the form.)

 

[agraham]

The extra byte is because when you open a file in cRandom mode it is never truncated so because you already had an 8 byte long file from when you were trying to encrypt it stays at 8 bytes even when you store fewer bytes in it. Look at the beginning of the code I just posted. I aded a test and delete of test.enc to pre-empt this very problem.

 

[LineCutter]

Thanks again! I suspect that you've just saved me a rather irritating debugging session trying to track this down. Hopefully, if I keep reading the forum & learning this sort of thing I'll be able to stop asking similar questions.