I\'m working on a cryptosystem which uses IDEA. The designer made the mistake of
ID: 651469 • Letter: I
Question
I'm working on a cryptosystem which uses IDEA. The designer made the mistake of including a CRC-32B hash of the password unencrypted in the header, so that the system can quickly reject bad passwords. Of course, that opens it up to the obvious attack of brute forcing CRC32 over potential passwords until the right one is found. Which is what I'm trying to do.
Questions:
1.Is the best way to do this simply to do an exhaustive search of the password space? It would seem to me that since CRC32(x) is related to x in manifest ways (eg XOR is preserved), it might be possible to do a construction where we actively direct the search in the right direction. I don't know enough about CRC32, but it would seem to me something like this is possible.
Of course, it's not enough to find a string with the same CRC32. It has to be the real password used, otherwise the IDEA decrypt will be gibberish. So this might throw some water on this method. But, regardless, I'd like to know more about it. What do you say?
2.Failing that, I'll need fast code to brute force the CRC32B. What is the fastest code? My plan is to brute force candidates via CRC32, then try to decrypt via IDEA and measure the entropy to filter out all of the false positives (1 in 4 billion) that will still match CRC.
Explanation / Answer
Assuming the n-bit CRC of an unknown bit string b is known, one can constructively rebuild any consecutive n bits of b from the rest of the bit string (and the definition of the CRC). Indeed, in the case described, that speeds up password search considerably. One can compute the last 32 bits of the password (likely, 4 characters) from the beginning of the password. If the password is constrained to characters in [20h..7Fh], that will further remove 49/50 of the candidates.
Many CRCs found in practice (including 32-bit CRC CCITT) are not "XOR-preserving" in the sense CRC(x?y)=CRC(x)?CRC(y).
However it allways holds that CRC(x?y?z)=CRC(x)?CRC(y)?CRC(z) for any x, y, z of identical length (including with z all-zero); that (and a little linear algebra) is enough to organize the computation. At the end of the day, with n=32, one can compute the last 4 bytes by XOR-ing the values found in precomputed tables (one table for each preceding byte, with each table 256?32 bits).