Re: Stream ciphers

On 30.12.2009 0:42, Greg Rose wrote:
In article <hhe0nk$g75$1@xxxxxxxxxxxxxx>, Ivan Voras <ivoras@xxxxxxxxx> wrote:
On 29.12.2009 22:40, unruh wrote:
On 2009-12-29, Ivan Voras <ivoras@xxxxxxxxx> wrote:

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

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.

[*] Though it isn't necessarily fast (at least my attempts aren't):
around 2 MB/s for MD5-based stream cipher and 33 MB/s for adler32-based,
on a 2.4 GHz Core2 CPU.