Stream ciphers
in [Cryptography]
|
Prev: Nothing is Hid – All will be revealed-2
Next: Cryptography Researcher: Increase Your Research Productivity with the Leading Web 2.0 Research Portal
From: WTShaw on 30 Dec 2009 07:51 On Dec 29, 3:17 pm, Ivan Voras <ivo...(a)gmail.com> wrote: > Hi, > > I'm not an expert but it looks like the canonical description of a > stream cipher boils down to "a PRNG which generates a keystream, which > is XOR-ed with plaintext to produce the ciphertext". This has some > obvious downsides mostly caused by the XOR step. > > Is there some fundamental problem that prohibits designing some other > classes of stream ciphers, for example in which incoming data would be > mixed with/permutated by key data and internal state byte by byte and > then some result of this mixing is outputted byte by byte (modifying the > internal state while passing through)? There are endless ways to do stream ciphers, many much better than XOR. Endless complexity does not make it good if adequate primitives are used wisely in the first place.
From: Thomas Pornin on 30 Dec 2009 09:04 According to Ivan Voras <ivoras(a)gmail.com>: > I'd guess they would be no more complicated to analyze than block > ciphers (and probably similarly complex to create), or would they? Precisely. A block cipher can be converted into a stream generator by encrypting successive values of a counter; this is called "CTR" mode. The whole point of designing a _stream cipher_ is that we hope, by restraining the ways the cipher may be used (when compared with a generic block cipher), we can achieve some better performance, stronger security analysis, smaller implementation, or any other such gain. --Thomas Pornin
From: Maarten Bodewes on 10 Jan 2010 18:28 Ivan Voras wrote: > On 30.12.2009 0:42, Greg Rose wrote: >> In article <hhe0nk$g75$1(a)sunce.iskon.hr>, Ivan Voras <ivoras(a)gmail.com> wrote: >>> On 29.12.2009 22:40, unruh wrote: >>>> On 2009-12-29, Ivan Voras <ivoras(a)gmail.com> wrote: >>>>> Hi, >>>>> >>>>> I'm not an expert but it looks like the canonical description of a >>>>> stream cipher boils down to "a PRNG which generates a keystream, which >>>>> is XOR-ed with plaintext to produce the ciphertext". This has some >>>>> obvious downsides mostly caused by the XOR step. >>>> This has an obvious downside why? The xor step has no downside. >>> I am thinking about bit flipping and key / keystream reuse. >> Bit flipping is an attack against message >> integrity and must be defeated by a message > > I would guess it could also be useful if the basic structure of the > message is known (e.g. a data file contains 32-bit integers in known > places) so it can get serious. > >> integrity check of some kind. There are also > > But I agree with you in general :) > >> So, since you already need non-repeating nonces >> and message integrity, the simplicity of a stream >> cipher with XOR combiner is pretty compelling to >> me... > > OTOH I have been experimenting a little and it is very easy - > practically trivial - to construct a stream cipher described in my > original post (e.g. not keystream-xor-plaintext based) from a generic > hash function[*] - so this answers my question. > Secure hash functions are inherently more difficult to construct - some people even think they are impossible to construct - than block ciphers which is reflected in their speed. Using a (safe) PRNG to create a stream cipher is fine, but if both are in software, I'd use a standardized block cipher in a standardized CTR mode. Regards, Maarten
From: WTShaw on 12 Jan 2010 04:22
On Jan 10, 5:28 pm, Maarten Bodewes <maarten.bode...(a)gmail.com> wrote: > Ivan Voras wrote: > > On 30.12.2009 0:42, Greg Rose wrote: > >> In article <hhe0nk$g7...(a)sunce.iskon.hr>, Ivan Voras <ivo...(a)gmail.com> wrote: > >>> On 29.12.2009 22:40, unruh wrote: > >>>> On 2009-12-29, Ivan Voras <ivo...(a)gmail.com> wrote: > >>>>> Hi, > > >>>>> I'm not an expert but it looks like the canonical description of a > >>>>> stream cipher boils down to "a PRNG which generates a keystream, which > >>>>> is XOR-ed with plaintext to produce the ciphertext". This has some > >>>>> obvious downsides mostly caused by the XOR step. > >>>> This has an obvious downside why? The xor step has no downside. > >>> I am thinking about bit flipping and key / keystream reuse. > >> Bit flipping is an attack against message > >> integrity and must be defeated by a message > > > I would guess it could also be useful if the basic structure of the > > message is known (e.g. a data file contains 32-bit integers in known > > places) so it can get serious. > > >> integrity check of some kind. There are also > > > But I agree with you in general :) > > >> So, since you already need non-repeating nonces > >> and message integrity, the simplicity of a stream > >> cipher with XOR combiner is pretty compelling to > >> me... > > > OTOH I have been experimenting a little and it is very easy - > > practically trivial - to construct a stream cipher described in my > > original post (e.g. not keystream-xor-plaintext based) from a generic > > hash function[*] - so this answers my question. > > Secure hash functions are inherently more difficult to construct - some > people even think they are impossible to construct - than block ciphers > which is reflected in their speed. Using a (safe) PRNG to create a > stream cipher is fine, but if both are in software, I'd use a > standardized block cipher in a standardized CTR mode. > > Regards, > Maarten Such is the hype. However, this not true. If I explained a most simple hash process to you, and gave you some output to play with, there is no chance that you could solve it. But, so many like to live in la la land and hold there head in there hands when there are better ways. Defeating prejudice is threatening and the prejudice is that there are no simple answers for any critical problems. As happened in London, the cesspool workers fought the introduction of sewers because it threatened their way of life...it didn't but blocking public health would have. |