Forum

Challenge "CMEA 1"  

  By: admin on Dec. 6, 2010, 8:17 p.m.

CMEA is a block cipher and was one of the 4 cryptographic primitives of the mobile communications network in the US. It is your challenge to perform a known-plaintext attack on CMEA with 100 known plaintext blocks given.
Read more...

 Last edited by: admin on Oct. 31, 2021, 2:54 a.m., edited 1 time in total.

Re: Challenge "CMEA 1"  

  By: wowmyst on March 15, 2011, 12:28 a.m.

there are 4 different keys, which differs in a few bits only, but they all do decode the cipher into identical cleartext.

Is this an additional design-flaw of CMEA?

Re: Challenge "CMEA 1"  

  By: pedromtorres on Nov. 9, 2011, 12:53 a.m.

I'm having some trouble understandting the known plaintext attack,
i am also following a paper and slides.

in the first part of the attack, when we have :

(p0,p1,p2) = (1 − x0, 1 − x0, 0) , and

c0 = ( 1 ^(x0 | 1 )) -x0

that c0 is the first ciphertext byte or the cypher text correspondent to the p0 we're checking in the moment?

Re: Challenge "CMEA 1"  

  By: fretty on Nov. 9, 2011, 11:51 a.m.

You are following the chosen plaintext attack.

Re: Challenge "CMEA 1"  

  By: h3po on Feb. 15, 2012, 3:55 a.m.

i have a problem replicating the behaviour of the given c program, which i assume was used to create the ciphertext.

my implementation encodes a block with a windows line ending 0x0d0a00 to 0x2ee630 (with the hardcoded key). applying cmea again correctly yields 0x0d0a00.
when i encrypt the same file with the given program, 0x0d0a00 is encoded to 0x0f1951 and using the program again, i get 0x0d0a0000.

why does this happen? other strings like "abcdef" encode/decode fine and with the same ciphertext in both my implementation and the supplied program.
i suspect the different behaviour can be a problem if the challenge plaintext was created with windows notepad, which always includes cr-lf at the end of a file.

Re: Challenge "CMEA 1"  

  By: stamp on Feb. 16, 2012, 9:50 p.m.

h3po,

When I use the CMEA program and the default key, I find that 0x0d0a00 encrypts to 0x2ee630, and 0x2ee630 decrypts to 0x0d0a00. However, I'm not able to duplicate the problem you seem to be having. To be honest, I'm not really understanding the issue, but it looks like a bug of some sort in your code. In any case, the challenge files were not created on a Windows machine, so that would not be an issue for this challenge.

Mark Stamp

Re: Challenge "CMEA 1"  

  By: DarkFibre on Feb. 20, 2012, 5:58 a.m.

This challenge is to me extremely complicated, and the literature very vague, but I think I am finally making progress after looking at it off and on for about 4 months. I was wondering if someone could answer a minor question for me as a test if I'm going in the right direction:

How many potential T(0)s should I have after the first step?

Re: Challenge "CMEA 1"  

  By: jomandi on Feb. 20, 2012, 4:38 p.m.

after the first phase there "survives" only 1 possible candidate for T(0).

best regards,
jomandi

Re: Challenge "CMEA 1"  

  By: DarkFibre on March 15, 2012, 4:29 p.m.

i have a problem replicating the behaviour of the given c program, which i assume was used to create the ciphertext.

my implementation encodes a block with a windows line ending 0x0d0a00 to 0x2ee630 (with the hardcoded key). applying cmea again correctly yields 0x0d0a00.
when i encrypt the same file with the given program, 0x0d0a00 is encoded to 0x0f1951 and using the program again, i get 0x0d0a0000.

why does this happen? other strings like "abcdef" encode/decode fine and with the same ciphertext in both my implementation and the supplied program.
i suspect the different behaviour can be a problem if the challenge plaintext was created with windows notepad, which always includes cr-lf at the end of a file.

The example program treats files as ascii (with "w" and "r"). Change this to binary ("wb" and "rb") and your ciphertexts will be the same length as your plaintexts. Otherwise certain characters are written on Windows machines with 2 characters and your ciphertext grows a byte here and there, and then if you read it in as "wb" the plain and cipher text are out of alignment.

I got hung up for most of a week debugging a non-issue revolving around this. It's probably fine if your cracking program also use "r" instead of "rb", but I used "rb" in my program and nothing would decrypt.

Re: Challenge "CMEA 1"  

  By: DarkFibre on March 15, 2012, 4:37 p.m.

This was the most absurdly complicated problem I have ever worked on, and that is probably the most convoluted example of Schneier's normally great writing I have ever read. I've been poking at this thing off and on for 5 or 6 months and came at it from every single possible wrong direction possible.

But at long last I have a working program, which I estimate will take around 7 hours running on my laptop to test all keys. I was just wondering how long other people's programs take?

Re: Challenge "CMEA 1"  

  By: jomandi on March 16, 2012, 8:45 a.m.

I was just wondering how long other people's programs take?

my program takes less than 2 seconds to find T(0) and less than 4 minutes to find the solutiontext and the key on an approximately 8 year old single core notebook.

best regards,
jomandi

Re: Challenge "CMEA 1"  

  By: Akshay.kapoor on Oct. 10, 2012, 12:03 p.m.

After getting initial 92 zeros and 164 one's for the A table. How do i insert more zeros in the A table to get a putative T(0).

I tried eliminating but unlike what the algorithm states i am unable to get a row of all zeros. How do i get over this ?
If anyone could help me out?

Thanks.


Currently 16 guests and 0 members are online.
Powered by the CrypTool project
Contact | Privacy | Imprint
© 2009-2024 MysteryTwister team