Re: Chosen plaintext attacks
- From: JT <jonas.thornvall@xxxxxxxxxxx>
- Date: Wed, 15 Sep 2010 02:08:50 -0700 (PDT)
On 15 Sep, 01:23, rossum <rossu...@xxxxxxxxxxxx> wrote:
On Tue, 14 Sep 2010 10:24:15 -0700 (PDT), JT
On 14 Sep, 15:31, rossum <rossu...@xxxxxxxxxxxx> wrote:
On Tue, 14 Sep 2010 02:45:43 -0700 (PDT), JT
Someone here suggested a chosen plaintext attack on CSPRNG which
baffeled me a bit and made me tell him he was crazy.
When you make a CSPRNG which is just a random number generator with a
small period like a hash,
A hash is not a CSPRNG. A hash may be a component of a CSPRNG but not
on its own.
or a long period like PRP pseudo random
permutation. And then you have the LFSR who i guess can have both
longer and shorter periods.
Alll CSPRNG rely on that the algorithm do not leak information about
the internal states so you want to prevent the attacker from being
able to calculate next bit, byte or block of output from the CSPRNG.
A good CSPRNG should not leak any information about either the next
state or the previous state. If the attacker captures part of the
keystream then she should not be able to read either new messages sent
after or old messages sent before the known keystream.
So if i give the attacker 1 gigabyte of output from the CSPRNG, he
should not be able to calculate next, bit byte or block. So that
someone who suggested a chosen plaintext attack on CSPRNG what did he
really mean was he just confused or was there any idea within that OT
So when is known plaintext attacks applicable? To me it seems they are
mainly applicable on blockciphers with fixed S-boxes?
A chosen plaintext allows the attacker to easily extract the keystream
from the cyphertext. Having the keystream allows the attacker to
attack the underlying CSPRNG directly.
There is some vaguely retarded to suggest a chosen plaintext attack
on a cipher who relies on a simple XOR of plaintext, of course the
[keystream] will be revealed.
An OTP cipher relies on that the keystream comes from a random source
can not be recreated.
Similarly an PRP cipher relies on the fact that the internal keystream
not can be recreated without the key.
Not necessarily so. If you can completely determine the internal
state of the PRNG at any time then you can run it forwards (and
possibly backwards as well) regardless of whether you have the key or
And this is what i beleive is regarded in the argument you suggest to
find the internal states, which have a keyspace of 2^6044 pretending
that would be easier then finding the original key which have a
keyspace of 256!.
So i am not sure what you suggesting here, also note there is a many
to one relationship between internal state to CSPRNG output. Many
combinations of internal stream can make up same CSPRNG stream.
Your suggestions is either just distractions or you are wondering in
It is afterall 6044 bits that should be guessed so a bruteforce of
the key is far easier.
That depends on there being no other weaknesses in the PRNG. A weak
PRNG will leak information about its internal state and/or its key in
the keystream. See
Ok i understand that, i do not beleive there to be any weakness in the
CSPRNG, it will not leak internal bitstates***small potatoes*** to the
for an example, the Fluhrer, Mantin and Shamir attack on RC4.
So there is something vaguely retarded over suggesting a plaintext
attack when the keystream is free for inspection.
How? I presume you are not giving away the secret key for free? The
first step in attacking a stream cypher is often to recover the
underlying keystream and a chosen plaintext atttack is one way to do
Well that would work for an OTP also you will have the OTP key, but it
is still not an attack, just vaguely retarded.
I called some of my ciphers POTP for a reason, you did not like it so
now i say PRP cihpers, but they have many of the trades of OTP.
Well that is just my thoughts about the subject and the chosen way to
attack it, what have gone wrong?
- Re: Chosen plaintext attacks
- From: rossum
- Re: Chosen plaintext attacks
- Prev by Date: Re: Chosen plaintext attacks
- Next by Date: Re: Bi-directional certificate authentication [vs. passwords]
- Previous by thread: Re: Chosen plaintext attacks
- Next by thread: Re: Chosen plaintext attacks