# 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.

-

## migrated from security.stackexchange.comOct 2 '13 at 22:24

This question came from our site for Information security professionals.

This is a security specific topic certainly, but code golf type questions or questions about breaking specific systems or working with a specific ciphertext are indeed off topic here. It might be a better fit at the Programming Puzzles site. –  Xander Oct 2 '13 at 21:37
@Xander I'll post it there. Would the best practice be to delete this post? –  user31478 Oct 2 '13 at 21:53
@Xander This isn't a brain teaser, it's a serious crypto question. It would be on-topic on Cryptography. Please don't repost, I've flagged for migration. –  Gilles Oct 2 '13 at 22:19
I remember - I think from stackoverflow - that this was a misinterpretation of the question. Can you confirm that and possibly delete this question if it has been solved? –  owlstead Nov 3 '13 at 21:21
7 such lines would be 287 bytes. If there are, as you say, only 6 newlines, not 7, that would be 286 bytes. In either case, if the ciphertext is 288 bytes there must be some padding. What padding was used? How sure are you that it's not 7 40-byte lines without newlines, followed by 1 newline that's been padded out to 8 bytes? –  Brock Hansen Feb 14 at 23:15

Well, DES is weak and since you can guess a plaintext you can use a rainbow table to crack the key and then of course decrypt and re-encrypt the message.

Apart from that I don't think you can re-order the blocks to change the first and last line, if you really want to do this specific operation.

-
A rainbow table to crack DES encryption, really? If you maintain that assertion, give us details!! Absent these, I consider this is a serious confusion. –  fgrieu Jul 23 at 4:47
If you wanted to crack a single message for a single DES key then yes, it wouldn't help. If you could predict a specific plaintext which could be a name or something like that then a rainbow table could be built to help even if the DES key was changing for every message or if you had limited amount of time to attack the message. No? –  Antikithira Jul 24 at 3:53
Yes, with the assumption of a known plaintext block common to enough instances of the problem to make a precomputation worthwile, what you are describing is feasible. However that does not apply in the situation of the question: there is no indication of multiple instances, and I see no hope to find an existing rainbow table that applies, for we need a different table for each known plaintext block. –  fgrieu Jul 24 at 5:25

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 — 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.

-