4 ms·
One of the necessary conditions for a secure cipher is security under chosen plaintext attacks, as specified by the following game: I give you two plaintexts o
by fhars 13y ago
One of the necessary conditions for a secure cipher is security under chosen plaintext attacks, as specified by the following game:
I give you two plaintexts of the same length of my choice, you select one of them and encrypt it with a key of your choice and give me the resulting ciphertext. If I can determine with probability p>50% which of the two plaintexts you have encrypted, the cipher is considered broken at level p.
I chose the following two plaintexts relative to the C source liked to elsewhere in this thread, with
#define DATA_SIZE (1024 * 1024 * 128)
Plaintext 1:
for(i = 0; i < DATA_SIZE; i++)
decrypted[i] = i;
Plaintext 2:
for(i = 0; i < DATA_SIZE; i++)
decrypted[i] = 0;
and claim that your algorithm is broken at a level of at least 95%. (I actually think it is 100% if I make the plaintext long enough, but I'm hedging my bets by conceeding 5%).
I don't need the full ciphertext, the output of the following code fragment is sufficient:
for(i = 0; i < DATA_SIZE; i++) {
count[encrypted[i] & 0xFF] += 1;
count[(encrypted[i] >> 8) & 0xFF] += 1;
count[(encrypted[i] >> 16) & 0xFF] += 1;
count[(encrypted[i] >> 24) & 0xFF] += 1;
}
for(i = 0; i < 256; i+=1) {
printf(" %8d", count[i]);
if (count[i] > 2400000) {
printf("*");
} else {
printf(" ");
}
if (i%16 == 15) {
printf("\n");
}
}
- quelsolaar 13y agoI have not considered this kind of game, and therefor not designed the cypher to withstand it. I need to run your code and do some tests to look in to it further. BUT: I currently think that the line: key[pos_a] ^= key[pos_c] ^ i ^ output[i]; Is a problem as "output" can counteract "i". I would probably replace it with: key[pos_a] ^= key[pos_c] ^ output[i]; key[pos_c] ^= i; I'm also thinking about ways that "i" could influence in a less regular way and if that is useful.
- tveita 13y agoMost stream ciphers just output a pseudorandom stream to be xored with the plaintext. Treating it as a PRG simplifies the security analysis. Letting the plaintext affect the state is more likely to hurt than help if you assume that the attacker knows or can influence parts of the plaintext.
- quelsolaar 13y agoThis to me is the challenge. If done the wrong way you would allow an attacker to influence the algorithm, done the right way it could remove any patterns created by the key. It seams all attacks proposed in this thread try to attack this problem, while the rest seams harder to attack.
- gknoy 13y ago> I have not considered this kind of game, and therefor not designed the cypher to withstand it. This seems to be the central summation of why most of us should not be rolling our own, and why peer review and cryptanalysis is so important to determine if something really is secure. :)
- tsahyt 13y agoIn fact I think everybody who's interested in the subject should try to roll their own crypto for the experience and fun in it. They shouldn't use it in the real world though.
- mathgladiator 13y agoIs there a club for this sort of activity?
- joshAg 13y agoyes. they meet at Fort Meade.