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:
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.
[*] 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.
.
- References:
- Stream ciphers
- From: Ivan Voras
- Re: Stream ciphers
- From: unruh
- Re: Stream ciphers
- From: Ivan Voras
- Stream ciphers
- Prev by Date: Re: Stream ciphers
- Next by Date: Cryptography Researcher: Increase Your Research Productivity with the Leading Web 2.0 Research Portal
- Previous by thread: Re: Stream ciphers
- Next by thread: Re: Stream ciphers
- Index(es):
Relevant Pages
|