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: Ivan Voras on 29 Dec 2009 16:17 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)?
From: unruh on 29 Dec 2009 16:40 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. Remember that a one time pad-- xoring a true random stream with the message ( which has the same xor operation) is the only provably secure cryptosystem. the purpose of the stream cypher is to mimic the one time pad with a stream which, while not a random stream, is indistiguishable from a random stream to anyone who does not have the key. > > 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)? > Remember that the operation must be reversible, other wise it is not a cypher. stream cyphers should be as simple as possible. Thus the problem with yours is reversibility and speed.
From: amzoti on 29 Dec 2009 16:52 On Dec 29, 1: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)? Perhaps you can have at look at: 1. Stream Ciphers: http://en.wikipedia.org/wiki/Stream_cipher 2. eStream Competition: http://en.wikipedia.org/wiki/ESTREAM (the competition to design new ones)
From: Thomas Pornin on 29 Dec 2009 17:00 According to Ivan Voras <ivoras(a)gmail.com>: > 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)? It has been done. The stream cipher which was incorporated in the ZIP archive format was such a system; that specific cipher turned out to be quite weak, but not because of its state-machine structure. However, stream ciphers which produce a pseudo-random stream, to be XORed with the data to encrypt, are easier to build and analyze: there is much less need for reversibility, and the analysis can be performed without needing to model the input data itself. From an implementation point of view, it may also help a bit, since much of the computation can be performed by chunks, outside of the main data processing path. For these reasons, stream cipher designers tend to favour the PRNG+XOR model. The XOR itself is not a downside. XORing allows an active attacker to flip bits at will; but the mistake would be to believe that a non XOR-based cipher would be immune against an active attacker. The XOR merely illustrates that against an active attacker you need an appropriate response, i.e. a MAC. --Thomas Pornin
From: Ivan Voras on 29 Dec 2009 17:42
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 big flipping and key / keystream reuse. |