1
$\begingroup$

Since a single hardware pass of an XOR with a 64-bit key is speedy, would Triple DES-X with seven 64-bit keys used in the following manner be virtually identical in terms of code size, memory consumption, and execution speed to 3DES?

  • You have four 128-bit keys and three 64-bit keys.

  • You take a 128-bit block of plaintext.

  • You break it into two 64-bit block halves in the following columnar transposition-based fashion.

The bits at even indexes go into one half, and the bits at odd indexes go into the other half, so the halves are intermingled.

  • You take the first 128-bit key and XOR the entire 128-bit block.

  • You take the first 64-bit key and encrypt each 64-bit half-block with DES independently of each other.

You treat the result as that round's 128 bits of ciphertext and repeat the 128-bit columnar transposition, importantly inter-mixing both half-blocks again based on odd-even indexing.

  • You take the second 128-bit key and XOR the entire block as one.
  • You then take the second 64-bit key and DES both 64-bit half-blocks independently.
  • You then repeat the columnar transposition-XOR-DES process for the third time.
  • Finally, you XOR the entire 128-bit block with the 7th 128-bit key.

Would it be significantly stronger? Would it still suffer from the same block size-based vulnerability of DES-X?

Improve this question
$\endgroup$
5
  • $\begingroup$ I hardly understand your question. Do you process the message? XOR (Key 7) DES (K8,( XOR (Key 4) DES (K5, (XOR (K1) DES (K1,M) XOR (Key 3)) ), XOR (Key 6)) XOR (Key 9). Why do you need 3DES or DES-X? 64 - block ciphers are vulnerable, see sweet32. Why do you need DES at all. Use AES that is faster than 3DES. $\endgroup$
    – kelalaka
    Commented Feb 15, 2020 at 16:25
  • $\begingroup$ Sorry, I incorrectly explained. You Xor with Key 1, DES with Key 2, XOR with Key 3, DES with key 4, XOR with Key 5, DES with Key 6, and XOR with Key 7. $\endgroup$
    – user227162
    Commented Feb 18, 2020 at 5:30
  • 1
    $\begingroup$ This is really unclear. However they answer to "Would it still suffer from the same block size based vulnerability of DES-X?" is a definite "yes". Don't use an encryption algorithm with a 64-bit block size. $\endgroup$
    – Future Security
    Commented Feb 18, 2020 at 20:11
  • 1
    $\begingroup$ This feels like a fairly standard SPN with DES as the (keyed) S-Box and this "columnar transposition" as the permutation. Chances are this will be covered by some theoretical SPN results. $\endgroup$
    – SEJPM
    Commented Feb 19, 2020 at 10:59
  • $\begingroup$ This recent paper has a bunch of references on the topic of provable security for SPNs (including ones with secret s-boxes) which will probably greatly help in answering this question. $\endgroup$
    – SEJPM
    Commented Feb 19, 2020 at 12:53

1 Answer 1

Reset to default
2
$\begingroup$

Well, there's a fairly obvious CPA attack that uses circa $2^{34}$ or so chosen plaintexts, and about $2^{120}$ trial DES operations. Because of that, the cryptographical strength is not significantly higher than standard 3DES.

As for code size and memory size, it'd certainly be larger than standard 3DES (you do more, and have more keying material lying around) - but it's hard to make a guess as to how much.

The scheme would likely be somewhat slower than 3DES. For 3DES, you can omit the intermediate IP/FP permutations between DES operations. In the scheme you've defined you would have to have them in there, and you would have to perform the columnar transposition as well. Now, it looks plausible that you could combine the FP/transpose/IP between DES operations into a single operation, which would reduce the cost somewhat, but it still wouldn't be as cheap as omitting them entirely.

On the plus side, this is effectively a 128 bit block cipher, so you do avoid the vulnerabilities that come with a 64 bit block size.

Improve this answer
$\endgroup$
8
  • $\begingroup$ It doesn't sound like it would be worth the increase in execution time, significant increase in memory requirements, and very significant increase in implementation complexity, unless eliminating the block size vulnerability itself while sticking with 3DES was enough since the other cryptographic gains would be small. In short, my idea is probably not a good idea. $\endgroup$
    – Abercrombie Dorfen
    Commented Feb 20, 2020 at 7:22
  • 1
    $\begingroup$ @AbercrombieDorfen: and, of course, AES-128 is still better... $\endgroup$
    – poncho
    Commented Feb 20, 2020 at 13:28
  • $\begingroup$ Basically the scheme in the question could be a good idea if 1. the 64 bit block size is an issue, 2. you're stuck with DES / TDES and 3. the required extended key size and loss of efficiency doesn't make the scheme impractical. That seems a bit of a niche to say the least. $\endgroup$
    – Maarten Bodewes ♦
    Commented Jul 19, 2020 at 15:25
  • 1
    $\begingroup$ @MaartenBodewes: I believe it could be improved; if we replace the bit-shuffling with an MDS matrix, that'd address the CPA attack without increasing cost that much... $\endgroup$
    – poncho
    Commented Jul 19, 2020 at 15:47
  • $\begingroup$ Trying to get my head around that statement. You would remove the encryption requirements for the columnar transposition and use the MDS matrix instead. You would need some small sized multiplication (shift + XOR) instead of full DES + keys. And then you would still have the same security... hmm, sounds 2 fishy to me :) $\endgroup$
    – Maarten Bodewes ♦
    Commented Jul 19, 2020 at 16:02

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.