2
$\begingroup$

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.

Improve this question
$\endgroup$
8
  • 1
    $\begingroup$ 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. $\endgroup$
    – Xander
    Commented Oct 2, 2013 at 21:37
  • $\begingroup$ @Xander I'll post it there. Would the best practice be to delete this post? $\endgroup$
    – user31478
    Commented Oct 2, 2013 at 21:53
  • 1
    $\begingroup$ Can you tell me the context where you ran into this? What makes you think it is possible to exchange the first line with the last? Why are you so set on that specific goal? That seems awfully specific (as opposed to, say, swapping some pair of entries of the attacker's choice). I assume you know that you can swap any pair of ciphertext blocks, and the corresponding plaintext blocks will be swapped? So if you can find a pair of blocks that, when swapped, leaves the format of the plaintext undisturbed (and such that the exchange is favorable to the attacker), that's a valid attack. $\endgroup$
    – D.W.
    Commented Oct 3, 2013 at 5:14
  • 1
    $\begingroup$ 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? $\endgroup$
    – Maarten Bodewes ♦
    Commented Nov 3, 2013 at 21:21
  • 3
    $\begingroup$ 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? $\endgroup$
    – Brock Hansen
    Commented Feb 14, 2014 at 23:15

2 Answers 2

Reset to default
3
$\begingroup$

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.

Improve this answer
$\endgroup$
-4
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • 2
    $\begingroup$ 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. $\endgroup$
    – fgrieu ♦
    Commented Jul 23, 2014 at 4:47
  • 1
    $\begingroup$ 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? $\endgroup$
    – Antikithira
    Commented Jul 24, 2014 at 3:53
  • $\begingroup$ 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. $\endgroup$
    – fgrieu ♦
    Commented Jul 24, 2014 at 5:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.