0

I'm trying to implement impossible differential cryptanalysis on IDEA cipher based on the Miss in the middle attack on IDEA and Khufu paper.

I'm trying to implement the attack on 3.5-Round IDEA and I stummpled with the initial pair generation step because they suggest generating $2^{32}$ pairs, which would normally be executed on a mainframe but I'm trying to implement it on my laptop(8GB RAM).

I'm confused with the generation part so are there any papers talking about the pairs and if they are indeed normally executed on a Mainframe or not, and in what mode they are ciphered(EBC, CBC, or any other mode), and when dealing with a large number of pairs like these are they generally stored in txt files or in a database and if there is a preferred initial key to encrypt with if you're trying the attack for the first time?

siba36
  • 301
  • 1
  • 11

2 Answers2

1

Here is a paper talking about implementing impossible differential cryptanalysis in a parallel fashion.

https://link.springer.com/chapter/10.1007/978-3-030-35869-3_9

enter image description here

Differential and linear cryptanalysis are normally defined on ECB mode, with the cipher specified as a pseudorandom permutation under a fixed unknown key, but given they're known-plaintext attacks they do work on some other modes.

kelalaka
  • 48,443
  • 11
  • 116
  • 196
kodlu
  • 22,423
  • 2
  • 27
  • 57
  • No I was asking for execution specifics other than the characteristic input difference that we need the pairs to have. Can you point me to the reference for the usage of ECB mode? – siba36 Jun 13 '22 at 13:32
  • what do you mean execution specifics? – kodlu Jun 13 '22 at 14:27
  • @siba36 Why does someone need a mainframe? $2^{32}$ ECB mode is quite achievable with modern CPUs. Did you benchmark your platform? – kelalaka Jun 13 '22 at 14:50
  • @siba36 my computer can reach 2^35 AES encryption in one day using software – kelalaka Jun 13 '22 at 19:54
  • by execution specifics I meant like what the common way to store the pair is it in text fle or in a database because I've tried adding the pairs to a text file and when I reached 700 million pair in that file I couldn't open it anymore in normal text editors and my java program took forever to read it and didn't finish , so is it better to store it in a database? – siba36 Jun 19 '22 at 18:59
  • And can you direct me to the common way of representing bits when you're attacking a cipher and you need to have the flexibility of changing a specific bits , I'm representing it in byte arrays and I wonder if that contributes to why my code taking forever to generate the pairs ? – siba36 Jun 19 '22 at 19:02
  • your comment is more on the implementation side, which is not my specialty. you may want to carefully formulate a question on this. – kodlu Jun 19 '22 at 19:04
0

I'm trying to implement the attack on 3.5-Round IDEA and I stumbled with the initial pair generation step because they suggest generating $2^{32}$ pairs, which would normally be executed on a mainframe but I'm trying to implement it on my laptop (8GB RAM).

We know out of the top of our head that $2^{32}$ is 4 billion (32 bit computers can directly address 4 GiB, although usually only 2 GiB is available per application). That means you'll have to store things on disk, or more preferably a very fast SSD. If you want to address that then I would recommend binary tables and memory mapping, not streaming. Of course, the time it takes to perform lookups may still be too large. You might be able to add a smaller table in memory to perform a "pre-lookup" e.g. using a smaller hash over values or initial bytes.

I'm confused with the generation part so are there any papers talking about the pairs and if they are indeed normally executed on a Mainframe or not

Well, mainframe, generally you'd assume fast memory access for an attack to be practical (or at least closer to practical). So the memory needs to be there.

and in what mode they are ciphered

Attacks on the block cipher themselves are not using any mode, they use the block cipher directly. You'd use the most performant code possible, i.e. without all kinds of wrapping to implement modes and whatnot. If you just want to try stuff out then you can use a single ECB block without padding or even a single CBC block without padding and an all-zero IV (as the IV is XOR'ed with the first plaintext block in CBC mode, so you would just get the block encrypt again).

are they generally stored in txt files or in a database

No, you'd use a map in memory (RAM) or possibly on SSD, preferably one with fast access. Laptops would not be perfect for this as the SSD's are generally not that fast w.r.t random access, and they generally don't have any posiblity to store a second SSD.

and if there is a preferred initial key to encrypt with if you're trying the attack for the first time?

No, not unless you already know that the key structure has influence on the attack of course.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313