|WikiProject Cryptography / Computer science||(Rated Start-class, Top-importance)|
|It is intended that this article be included in WikiReader Cryptography, a WikiReader on the topic of cryptography. Help and comments for improving this article would be especially welcome. A tool for coordinating the editing and review of these articles is the daily article box.|
|To-do list for Stream cipher:|
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)
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 188.8.131.52 (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.
- 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)
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)
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. 184.108.40.206 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. --220.127.116.11 (talk) 18:42, 13 January 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)
- 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 18.104.22.168 (talk) 18:58, 2 April 2010 (UTC)
- I agree with 22.214.171.124 . 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)
..while stream ciphers eliminate this issue by naturally operating on the smallest unit that can be transmitted (usually bytes).
- 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. 126.96.36.199 (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)