Talk:CipherSaber

From Wikipedia, the free encyclopedia

Contents 1 Removed CipherSaber text from article RC4 2 Relies on random number generator 3 Attacker changing message content 4 Key Length

[edit] Removed CipherSaber text from article RC4

Removed this text from RC4. It belongs on this page if anywhere, but it looks like it's already covered.

"The CipherSaber cryptosystem, which is based on RC-4, addresses the security problems mentioned above by preceding each message with a random ten byte initialization vector (IV). CipherSaber-2, an improvement over the original system, addresses the 2001 attack by repeating the key-scheduling algorithm a set number of times (usually 20)."

[edit] Relies on random number generator

This sentence, "CipherSabre relies on a decent random number generator for IV, but most programming environments provide only very weak PRNGs," doesn't seem to make much sense. Does it have a good random number generator or not? It seems that the paragraph should be rewritten to make more sense.

FuzzyOnion 19:35, 18 September 2005 (UTC)

CipherSaber doesn't specify a PRNG, and it wouldn't be appropriate for it to do so. If CipherSaber needed a strong PRNG, that could be a problem because most people implementing it won't have one handy. But it doesn't, it just needs non-repeating IVs, so that's not an issue. — ciphergoth 22:18, 18 September 2005 (UTC)

The sentence complained about above makes perfect sense to me. It says that it relies on a decent random number generator, not that it has one. -- Tzadik 18:19, 20 December 2005 (UTC)

But it doesn't rely on one, as I just explained. — ciphergoth 08:19, 18 February 2006 (UTC)

OK, Now I'm jumping into old discussion. The described algorithm does not require random numbers, but the description on the CipherSaber home page omitted that fact. - Joshua

[edit] Attacker changing message content

I propose removing the following claim: an attacker who knows that the message contains "ls -ld ." at a particular point can replace that content with "rm -rf /" without knowing the encryption key. That is false. The attacker may be able to corrupt the message in that place, assuming they have the specified knowledge, but they can't replace it with a string of their own choosing. -- Tzadik 18:19, 20 December 2005 (UTC)

No, the sentence is corrent. If the attacker knows (can guess) that the message contains "ls -ld ." at a certain position in the message he can XOR that onto the ciphertext. He then has the cipher stream bytes for that section and then can XOR that with his own data "rm -rf /". Thus producing a new "block" of ciphertext that fits in that position. When the receiver decrypts the message he will get the cleartext "rm -rf /" for that section. This attack works for all stream ciphers that XORs the keystream onto the cleartext to get the ciphertext. Even for block ciphers if you run them in for instance CTR mode. (Which really turns the block cipher into a stream cipher.)

To prevent this kind of attacks "real" cipher systems should use message authentication codes (MACs) such as HMAC to provide message integrity.

But note, CipherSaber still is pretty nice and do provide pretty strong privacy when used right but as you see it does not guarantee message integrity.

--David Göthberg 17:23, 4 February 2006 (UTC)

[edit] Key Length

A careful reading of the algorithm reveals that the largest key that could work is 246 bytes or 1968 bits. Does this belong in the article?