Re: C code of PEARL1, a block encryption algorithm emphasising simplicity

In article <i4maqi$1cip$1@xxxxxxxxxxxxxxxxxxxx>,
Tran Ngoc Duong <tranngocduong@xxxxxxxxx> wrote:

"Maaartin" <grajcar1@xxxxxxxxx> wrote in message

What about the following PRNG repeating these steps:
- Generate x using a secure PRNG.
- Generate y using a trivial PRNG.
- Output 2*x+y where the computation gets performed in GF.
- Output x+2*y where the computation gets performed in GF.

Instead of (x, y) -> (2*x+y, x+2*y) you can take any other MDS
function.

Given all outputs you can invert the output transform and get to the
values generated by the trivial PRNG. Given only each second output
you can do nothing at all.

I think, it is a semi-secure PRNG according to you definition. I don't
think, semi-secure PRNGs occur in reality.

Yes. I think it could be considered semi-secure. I don't think it is
practically usable since it is constructed from a secure PRNG. If I have
a truly secure PRNG, I would surely find a better way to use it. No MDSs
or other such jokes.

But maybe they do? Aren't there attacks which can be stopped by
decimating the sequence?

If one actually uses the sequence I'm sure there are easy attacks (not
much more complicated than attacking a XOR stream cipher that uses the
same key stream twice). I see no such attacks with the decimated
sequence.

True, but I also don't see any advantages over
just outputting the sequence of x's. What does the
extra work of generating the y's, combining, and
then decimating, add? Assuming the existence of
the secure PRNG sort of begs the question.

That, to me, is the point. Schneier once said "anyone
can make a secure cipher; the hard part is making
it fast enough to be interesting." Or something like
that anyway.

Greg.
--
.

Relevant Pages