|
|
|
In the interest of providing an completely open forum for cryptoanalyzing CPK, we will present the current results here. If you have any results, please send them to us with the details on the attack. One clear advantage of CPK, is it's simplicity. Instead of using snake oil terms to make a algorithm appear secure, CPK is much easier to understand and cryptoanalyze. This is a important factor, and is used in selecting the next AES candidate. Previous cryptoanalysis on the one stage 3x3 and 8x8 matrix revealed that "CPK is a kind of knapsack problem". As such, they can typically be broken using LLL techniques. To guard against this, a simple modification to CPK (32 Bit-ECB example) will allow two matrices to be used together instead of just one. This will render LLL techniques useless against CPK since no parity information is leaked from the plaintext to the ciphertext. Other modifications have also been made to CPK to further reduce information leakage in our research versions (not published yet). These changes effectively increase the lattice problem to dimensions greater than 300. Current LLL techniques are completely incapable of dealing with lattice problems of this size. CPK is easily expanded to use any size matrix, and can be designed as the product of matrices like the 32 Bit-ECB example where two 4x4 matrices are used. This effectively increases the size of the lattice while still maintaining reasonable key sizes. Since the basic implementation of CPK is based on linear algebra, many powerful techniques can be used to randomly convolute the steps CPK takes to generate keys and ciphertext. This was done in the 32-Bit ECB example and has the effect of increasing the apparent lattice size. This example has never been broken. Other techniques based on variations of the number theory behind CPK can also increase the apparent lattice size. These variations of CPK can take many forms and as new attacks are discovered, modified versions of CPK can be deployed. For example, we could "also try to merge CPK and Merkle-Hellman, using your 'knapsacks' rather than superdecodable ones hidden in Merkle-Hellman. I think it will be more constructive than finding an empirical security limit for CPK."
|
|
|