Re: C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: Maaartin <grajcar1@xxxxxxxxx>
 Date: Fri, 20 Aug 2010 10:49:39 0700 (PDT)
On Aug 20, 6:34 pm, "Tran Ngoc Duong" <tranngocdu...@xxxxxxxxx> wrote:
"Maaartin" <grajc...@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 semisecure PRNG according to you definition. I don't
think, semisecure PRNGs occur in reality.
Yes. I think it could be considered semisecure. I don't think it is
practically usable since it is constructed from a secure PRNG.
Agreed, I'm not sure what I could use it for. It's not secure and it
needs a secure PRNG, that's a clear loss. It's just faster, that's
all.
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.
With the decimated sequence there can't be any attacks, since each
it's member depends bijectively on a member of the secure sequence
which doesn't get used anywhere else. There are attacks distinguishing
it from random, which IMHO need the whole sequence.
But this isn't what I meant. I was speaking about partlysecure PRNGs
like RC4. There are attacks against RC4, which can be prevented be
dropping the beginning of the sequence.
On Aug 20, 6:44 pm, MokKong Shen <mokkong.s...@xxxxxxxxxxx> wrote:
It is well known that a system of linear equations doesn't have a
determined solution, if the determinant is zero. I am making use
essentially of an akin argument. If one thus can't even find a "path"
to the generation process of a PRNG, how could one start to break it
at all?
There's no established cryptosystem build on a zerodeterminant matrix
and I'd say, there can't be any. Given enough input/output pairs you
always get enough equations. When the determinant is zero, it means
there are equivalent keys, and this is a weakness. The attacker can't
determine the key uniquely, but they don't need to; each one of them
suffices.
On Aug 20, 7:20 pm, MokKong Shen <mokkong.s...@xxxxxxxxxxx> wrote:
BTW, a historical remark: Actually the idea of exploiting
"indeterminancy" was present in a thread months ago, where I argued
with Maaatin whether a simple scheme of mine could be cracked. Maaartin
wrote a program which he reported to be capable of very speedily
breaking that in some 10 of test cases. There should however be in fact
nonetheless some errors in his work. For there was a negotiation of a
challenge prize between him and me and my challlenge offer was later
not taken up by him.
There were no errors in my program, it just took too long in some
cases. Most instances were solved much faster than you'd imagine. To
my surprise, the hard instances were the ones NOT having the maximum
period.
I never cared about the challlenge, but I'll publish the program some
day.
.
 FollowUps:
 Re: C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: MokKong Shen
 Re: C code of PEARL1, a block encryption algorithm emphasising simplicity
 References:
 [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: MokKong Shen
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: Tran Ngoc Duong
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: MokKong Shen
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: Tran Ngoc Duong
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: MokKong Shen
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: Tran Ngoc Duong
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: MokKong Shen
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: Tran Ngoc Duong
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: MokKong Shen
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: Tran Ngoc Duong
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: MokKong Shen
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: Tran Ngoc Duong
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: MokKong Shen
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: Tran Ngoc Duong
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: MokKong Shen
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: Tran Ngoc Duong
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: MokKong Shen
 Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 From: MokKong Shen
 [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 Prev by Date: Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 Next by Date: Re: C code of PEARL1, a block encryption algorithm emphasising simplicity
 Previous by thread: Re: [long] C code of PEARL1, a block encryption algorithm emphasising simplicity
 Next by thread: Re: C code of PEARL1, a block encryption algorithm emphasising simplicity
 Index(es):
Relevant Pages
