Reordering non-block-aligned parts with DES in ECB mode I was given a ciphertext file which was encrypted using DES in ECB mode. It is known that the plainttext that was encrypted has the following form:


Each line of text consists of a payroll followed by a name (no spaces):

32 characters for the name;
8 characters for the pay amount;
1 newline.



An example plaintext file would be: 

abcdefghikabcdefghikabcdefghikab00000000
abcdefghikabcdefghikabcdefghikab10010010
abcdefghikabcdefghikabcdefghikab10010010
abcdefghikabcdefghikabcdefghikab10010010
abcdefghikabcdefghikabcdefghikab10010010
abcdefghikabcdefghikabcdefghikab10010010
abcdefghikabcdefghikabcdefghikab11111111


and it was encrypted using this command (of course the key was not given, for obvious reasons):

openssl enc -e -des-ecb -nosalt -in plaintext.txt -out ciphertext.enc


The ciphertext file is of size 288 bytes since there are 6 newline ('\n') characters and DES encrypts in 64 bit blocks it's easy to tell that there are 7 entries in this payroll list.

The Objective: exchange the first line with the last.

If all the entries were on one line with no spaces this would be an easy task as DES in ECB mode you can move around the 64 bit blocks without being detected. All I would do is take the first 40 bytes and exchange them with the last 40 bytes. However since there is a '\n' character at the end of every line this approach does not work. I feel a bit stuck. All I'm looking for is a point in the right direction.
If the plaintext format is indeed as you describe, then you're out of luck: the insertion of the newlines and the consequent shifting of the plaintext records is enough to disrupt any structure in the ciphertext.  If the plaintext were longer, say, 8 records, then it could work, but with just 7 records there's no way to switch the first and last record simply by shuffling ciphertext blocks.

However, I suspect you're mistaken about the presence of newlines in the plaintext.  Specifically, since the encryption command you were given does not include the -nopad option, the openssl enc command applies PKCS #5/7 padding to the plaintext before encrypting it.  In order to be unambiguously reversible, this padding scheme always increases the length of the plaintext by at least one byte &mdash; in particular, it causes any plaintext length between 280 and 287 bytes inclusive to produce a ciphertext of 288 bytes.

Thus, I suspect that your data actually has no newlines, and simply consists of seven 40-byte fixed length records, plus 8 bytes of padding.  Keeping the last 8 bytes of the ciphertext in place, and switching the first and last 40-byte chunk of the ciphertext preceding it, should do the trick.