Re: Stream ciphers
- From: Ivan Voras <ivoras@xxxxxxxxx>
- Date: Wed, 30 Dec 2009 02:19:40 +0100
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.