-3

The attack consists in finding two keys for 2-DES. I know the plaintext and the ciphertext(both in hex) and I have to find the keys. Keys are represented in bits of strings and there are 2^56 possible keys because a key has the lenght equals to 56. For every key I have to encrypt the plaintext and make pairs (plaintext, key). I should memorize the hex value for key and plaintext. Then I have to decrypt the ciphertext using every possible key ( again 2^56) and see if one of the result is equal with one of the pair (plaintext, key). I know how I should implement it but I do not know how to store such large values.

Martha
  • 5
  • 3
  • 2
    It takes petabytes of storage to do a meet-in-the-middle attack. Do you have that much storage on-hand? – Mike Borkland Mar 11 '19 at 19:34
  • 2
    Using a straightforward approach you'd need 8 * 2^56 bytes of storage at a minimum, or 2^59 bytes. You probably don't have that much. You can decrease memory requirements by doing more computation. The first step is figuring out how much memory you have. – President James K. Polk Mar 11 '19 at 20:45
  • @JamesKPolk I guess you would need memory mapping for this (?) – Maarten Bodewes Mar 12 '19 at 09:01
  • @MaartenBodewes you have to have the storage somewhere to map the memory to. This is .5 exabytes. Just for a ballpark, the storage alone would cost more than $10M USD from Amazon Web Services. – President James K. Polk Mar 12 '19 at 14:31

1 Answers1

0

Prior to std::unordered_*, I used std::map to hold large numbers of objects for an object cache and though there are faster random access containers, it scaled well enough for our uses. The newer unordered_map has O(1) access time so it is a hashed structure and should give you the near best access times.

BLAKE
  • 149
  • 1
  • 15
  • I'm thinking the user needs to use as few bytes as possible; I'd rather suggest disk storage using memory mapping with a minimum (probably no) amount of overhead. – Maarten Bodewes Mar 12 '19 at 09:00