Talk:Stream cipher

Speeds

I am changing the sentence "Stream ciphers typically execute at a higher speed in hardware but a much slower speed in software than block ciphers." because it isn't generally true. RC4, for example, is one of the fastest strong ciphers available in software. --agr 18:26, 17 Nov 2004 (UTC)

Errors

The patent indicated in the link actually points to a releasable pin. I can't find the correct patent, but maybe some clever pedian can. —The preceding unsigned comment was added by 198.97.67.57 (talk) 16:58, 30 January 2007 (UTC).

Yes indeed. I took the liberty of removing reference (U.S. patent 2,405,400), because it was not valid. Whoever finds the correct patent number, feel free to insert the reference back.

Military

The sentence

Another advantage of stream ciphers in military cryptography is that the cipher stream can be generated in a separate box that is subject to strict security measures and fed to other devices, e.g. a radio set, which will perform the xor operation as part of their function. The latter device can then be designed and used in less stringent environments.

looks questionable to me--any device that sees plaintext has to be designed stringently. See Red-black separation. I'd like to remove this sentence unless someone objects. Phr 03:37, 9 April 2006 (UTC)

I see what you're saying but I read this that the "crypto box" sees the pialntext, and then feeds the ciphertext to the radio DrVxD (talk) 19:21, 15 June 2008 (UTC)

Comparison table

I wonder if a comparison table is a good idea. We found that trying to maintain one for ESTREAM was a pretty fraught business, especially when (as is the case with Py (cipher)) there's dispute about the validity of an attack. And unlike with with ESTREAM, here the table may grow without bound.

I think it should list only ciphers that are widely used: RC4, A5/1, A5/2 etc.

On a minor note, the table suggests that there are linear cryptanalytic attacks on Salsa20. I'm unaware of any published, unless you mean the papers by Li An-Ping which never made sense have been pretty thoroughly shredded. — ciphergoth 05:51, 7 September 2006 (UTC)

Pretty table. Does the color coding mean anything? There's no legend for cell color. -Kvng 16:24, 28 September 2006 (UTC)

There's still no legend. It CANNOT be expected reader's criteria will match those of the author. --201.253.138.252 (talk) 18:17, 12 September 2008 (UTC)

I removed the cite of Jean-Phillip Aumasson's distinguishing attack on ISAAC, because it doesn't work. And marked ISAAC as N/A for an initialization vector, since having already seeded ISAAC doesn't give you an easier reseeding algorithm. I doubt that RC4 really has any IV algorithm either, but didn't mark that N/A because I wasn't sure. 71.164.0.155 09:18, 4 January 2007 (UTC) Bob Jenkins

The internal state column is somewhere between misleading and wrong. Does it mean required dynamic memory? For SALSA20, the default implementation only uses 512 bit for performance reasons or code simplification, only 384 bit are real dynamic data. For RC4 on the other hand, the largest part of the state is the permutation table, which has a lot less entropy. The claimed effective key size for RC4 is wrong for the very same reason. The entropy stored in the internal state is never larger than log(256*256*256!)/log(2)~=1700. --88.74.60.166 (talk) 18:42, 13 January 2010 (UTC)

If nobody explains the weird cell coloring, I will remove it eventually.93.205.122.104 (talk) 16:16, 2 April 2010 (UTC)

Is "eventually" gt 2.75 years, or did someone explain the color scheme to you via enciphered communication to your satisfaction? — Preceding unsigned comment added by 71.83.65.241 (talk) 14:13, 1 November 2012 (UTC)

"Cycles per byte" must presumably be a ratio; so what value should be assigned to the term "Voice"? MrDemeanour (talk) 09:19, 4 July 2010 (UTC)

Grammar in second sentence

I changed "In a stream cipher the plaintext digits are encrypted one at a time, and in which the transformation of successive digits varies during the encryption." to "In a stream cipher the plaintext digits are encrypted one at a time, and the transformation of successive digits varies during the encryption." because it didn't appear to make sense. If I was wrong, can someone who knows things please fix it? Bitwiseb 20:43, 7 November 2007 (UTC)

Question

how do you create a hash function from a stream cipher? —Preceding unsigned comment added by 131.111.8.96 (talk) 22:39, 22 January 2008 (UTC)

Answer: In general: You don't. Stream ciphers are usually not specifically designed to be either compressing or collision-resistant, since this is no requirement here. —Preceding unsigned comment added by 93.205.122.104 (talk) 18:58, 2 April 2010 (UTC)

I agree with 93.205.122.104 . While a few hash functions (such as bcrypt) use encryption internally, the vast majority of hash functions are designed in a very different way in order to meet their very different requirements.

Is this a common enough question that this article could say a sentence or two about it?

Is "Can you make a hash out of a stream cipher?" close enough to a reliable source to use as a reference for that sentence? --DavidCary (talk) 05:42, 18 November 2013 (UTC)

smallest unit

..while stream ciphers eliminate this issue by naturally operating on the smallest unit that can be transmitted (usually bytes).

isn't a bit the smallest unit? stream ciphers can operate bitwise. —Preceding unsigned comment added by 147.86.212.162 (talk) 08:28, 10 June 2008 (UTC)

As stated in the article, stream ciphers just produce a pseudorandom keystream from the key and combine it with the plaintext (or ciphertext). Usually this is done using XOR which is already a bitwise operation. There is no plausible reason not to use XOR, so stream ciphers operate bitwise by the very nature of the encryption. 121.73.17.17 (talk) 02:35, 14 December 2010 (UTC)

There is a confusion between the notion of the smallest unit that can be processed. The first applies to the size of a symbol the keystream generator/stream cipher outputs. Usually, this is a byte for software-oriented stream ciphers because of the prevalence of byte-aligned memory addressing in current computer architectures, and a bit for hardware designs. Stream ciphers that implement pseudo-random functions have much larger symbol sizes (e.g., 64 bits). The second notion applies to the smallest unit of plaintext that can be processed. For additive stream ciphers, where the keystream is added with the plaintext in an exclusive-or style, this is naturally always a bit. HTH, Nageh (talk) 13:16, 14 December 2010 (UTC)

GROMARK

Would the GROMARK cipher be a stream cipher? 99.251.236.178 (talk) 03:24, 4 July 2010 (UTC)

Yes, the GROMARK cipher described at running key cipher#Gromark cipher matches the description of a stream cipher. --DavidCary (talk) 00:13, 27 March 2016 (UTC)

No. An important property of the keystream used in a stream cipher is that this keystream is secret. This is clearly not the case for the so-called running key in the GROMARK cipher. This so-called running key can be derived entirely from the primer. But the primer is part of the ciphertext and hence not secret at all. 176.127.147.245 (talk) 06:42, 28 March 2016 (UTC)

What kind of cipher is the GROMARK cipher?

I agree that an important property of the keystream in a *secure* stream cipher is that the keystream is secret, which is not the case for a traditional GROMARK ciphertext (since it includes the non-secret primer).

I admit GROMARK doesn't fit neatly into the "stream cipher" category -- but what would you call a 5th category where GROMARK would fit?

I generally categorize ciphers into 4 categories -- stream ciphers, block ciphers, transposition ciphers, and combination ciphers. I hope you agree that GROMARK is more like a stream cipher than those other categories.

Until I hear differently, I'll continue to think of GROMARK as a *insecure* stream cipher. --DavidCary (talk) 02:48, 29 April 2016 (UTC)