View Single Post
Old 19 February 2015, 00:45   #12
modrobert
old bearded fool
 
modrobert's Avatar
 
Join Date: Jan 2010
Location: Bangkok
Age: 56
Posts: 775
Quote:
Originally Posted by Thorham View Post
You shouldn't have to. When encryption algorithms are used properly and contain no bugs, you can use any file, encrypt it and get output that looks completely random.
The algorithm is doing what it is supposed to. If you test with 'openssl enc -aes-256-ecb -in plaintext -out ciphertext' you get similar results regarding the "raw image weakness" (as in reduced larger than block size entropy). The differences being how openssl uses the first 16 bytes as a header, which I personally think is less secure since it pretty much acknowledges cipher is being used by just looking at the unecrypted first part in the header of ciphertext, and that openssl salts the password/key.

This is how openssl does it in the header of "encrypted data" (ciphertext).
Code:
00000000   53 61 6C 74  65 64 5F 5F  B8 4F 35 94  87 EC 8A B7  Salted__.O5.....
I don't use a header at all, instead the padding is done by encrypting one byte in the "empty" part at the end of file when "filesize % 16 != 0" including plaintext offset, when matching size it just adds one zero byte to the end of file as a marker making file size odd. Simple, yet less revealing. Too bad I mentioned it here, because tried pretty hard to obfuscate what is going on in the source code.

You can question using ECB for the purpose, but I have my doubts about using CBC as an alternative after reading about a weakness regarding XOR chaining all blocks, where sub sequent block plaintext bits can be derived from changing bits in the adjacent one without having the key by bruteforce decrypting the file. Sure, CBC gives you nice random looking entropy when viewing the file, but you have weakened the system by chaining it with XOR, and in effect created an unintended "Turing machine" of sorts to aid clever attackers. You can avoid the weakness if the "server" (program) is running in your control and has additional layers of session security by adding and verifying HMAC, but not when the whole flat file (ciphertext) is available to the attacker using a custom designed program completely in his/her control where the HMAC validation can be bypassed.

Last edited by modrobert; 19 February 2015 at 02:34.
modrobert is offline  
 
Page generated in 0.09647 seconds with 11 queries