Talk:CipherSaber

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)."

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

On the CipherSaber home page, Arnold Reinhold states that random initialization vectors (IVs) are strongly recommended in order to make the encrypted files indistinguishable from random noise (presumably so that you don't get busted for using cryptography where it is not allowed). Pseudo-random is fine, and he does not consider it necessary to use a particularly strong pseudo-random algorithm to generate the IVs. (That may be true, because the short length of an IV relative to the length of a typical message provides attackers with less data to analyze. And because figuring out that the messages aren't truly random noise and that they may instead be secret message could be considered less of a security breach than actually decrypting those secret messages.) For security against decryption of the encrypted messages, he says simply that each IV must be unique (among messages that are encrypted with the same CipherSaber key). (If two or more messages are encrypted with the same CipherSaber key and the same IV, then they are encrypted with exactly the same keystream, making it possible for attackers to recover the plaintext of each message through frequency analysis.)

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)

I too was wondering how the attack could work, so I edited the main page to make the process more clear.Kirbysdl (talk) 18:06, 12 August 2008 (UTC)

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?

Sure. Sounds good to me. - Jatoo (talk) 10:03, 6 November 2008 (UTC)