Prev: On the classification of ciphers
Next: A C-code for permutation polynomials mod 2^n
From: Mok-Kong Shen on 23 Mar 2010 10:10
Mok-Kong Shen wrote:

> We have assumed the availability of a single PRNG (e.g. the compound
> PRNG) only. If one uses a separate PRNG for the different passes, e.g.
> associating each pass to a PRNG in the pool of the compound PRNG,
> then this problem does not arise.

If one associates a PRNGs F1(x), e.g. from the pool of my compound
PRNG, with each pass, then one could also do the following, i.e. using
it not only to generate R1 but also to transcribe h^C[i]:

h = R1;

for (i=0; i<plaintextlength; i++)
{
C[i] = P[i] ^ h;

h = F1(h ^ C[i]);
}

C[plaintextlength] = h ^ R1;

If one associates two PRNGs F1(x) and F2(x) from the compound PRNG with
each pass, one could also do the following:

h = R1;

for (i=0; i<plaintextlength; i++)
{
C[i] = F2(P[i] ^ h);

h = F1(h ^ C[i]);
}

C[plaintextlength] = h ^ R1;

In this case the decryption would need inversion of F2(x), which has
however the disadvantage of being about 32 times slower than computing
F2(x) for 32-bit words (see the function invpermpoly in the thread
"A C-code for permutation polynomials mod 2^n").

Thanks,

M. K. Shen
--------------------------------------------------------------------------

[OT, personal note:]

It is surprising that one person of the group tends to follow-up
without dealing with the stuff of mine "directly" in any sense. (I
could only guess that the cause was that once I "inadvertently" wrote
a few lines that pointed out a "mondane" error of him and that "sin"
was never forgotten by him ever since.)

I have posted quite a lot recently. My main goal has been to try to
enable any poorman to easily implement encryption software himself from
scratch (in particular for the worst case where he is deprived of
any particular crypto literatures/documents) with schemes that are
fairly simple to memorize and that he could highly "plausibly" (though
certainly not mathematically "provably") convince himself to be
sufficiently secure, if only he correspondingly sufficiently trades
computing costs/time (since the simple schemes need more rounds/passes,
or even used in cascade, to achieve security comparable to the
well-established highly optimized algorithms) for the desired security.
But in that, a poorman has, as a rule, no difficulties in doing. For
the volume of his messages is likely to be relatively small and a few
seconds or even minutes delay in dispatching isn't likely to be a
concern for him.

With my recent posts on poorman's block and poorman's stream algorithm
as well as on my compound PRNG and the publication of my C-code, which
shows that the implementation of my proposed compound PRNG is quite
simple, a good set of tools for the poorman in the worst case has
already been established in my humble view. Thus the goal can be
considered to be achieved and there is in fact no necessity of my
continuing spending time and effort in that direction. (Like everybody,
I don't get paid for posting!)

On the other hand, in the "normal" days, a poorman is certainly not
really poor, for he can well employ the well-established efficient
algorithms. But he may have a feeling of uncertainty in using them, not
only because these are more complex for him to understand but also (and
in praticular) because he knows that researchers continue to achieve
progress in attempting to attack these algorithms with linear analysis,
algebraic analysis, etc., as evidenced by the number of annual crypto
congresses. In my thread "Introducing dynamics into block encryptions"
I have clearly shown on the other hand that he needs "only" to use
dynamic keys (generated from a master-key with the same block algorithm
in counter mode) in order to be sure that no "eventual" sensational
future breakthroughs in crypto research could ever surprise him and
render his encrypted secrets suddenly open to attack. So I think I have
also served him sufficiently well in situations of the "normal" days.

BTW, I have sent a copy of my posts in the thread "Introducing
dynamics ....." to a person who evidently has very high expertise
on (among other fields) linear analysis, but (perhaps fairly
understandably) I didn't get any comments back.


From: Tom St Denis on 23 Mar 2010 11:55
On Mar 23, 10:10 am, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote:
> On the other hand, in the "normal" days, a poorman is certainly not
> really poor, for he can well employ the well-established efficient

<snip>

GPG is free.

Tom
From: J.D. on 23 Mar 2010 12:19
On Mar 23, 11:55 am, Tom St Denis <t...(a)iahu.ca> wrote:
> On Mar 23, 10:10 am, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote:
>
> > On the other hand, in the "normal" days, a poorman is certainly not
> > really poor, for he can well employ the well-established efficient
>
> <snip>
>
> GPG is free.
>
> Tom

Maybe this is for days when "the poorman" has a negative balance in
his bank account -- because, when that occurs, even if GPG costs $0 he
still couldn't afford it.
From: unruh on 23 Mar 2010 12:20
On 2010-03-23, Mok-Kong Shen <mok-kong.shen(a)t-online.de> wrote:
>
> I have posted quite a lot recently. My main goal has been to try to
> enable any poorman to easily implement encryption software himself from
> scratch (in particular for the worst case where he is deprived of
> any particular crypto literatures/documents) with schemes that are
> fairly simple to memorize and that he could highly "plausibly" (though

All of your schemes are far harder to memorize than say rc4, and are
weaker and slower. And implimenting encryption on the cheap does
absolutely no good if the other side of the communication does not have
the scheme. They are far more likely to be able to get say rc4 than you
be able to send them your scheme.

> certainly not mathematically "provably") convince himself to be
> sufficiently secure, if only he correspondingly sufficiently trades
> computing costs/time (since the simple schemes need more rounds/passes,
> or even used in cascade, to achieve security comparable to the
> well-established highly optimized algorithms) for the desired security.
> But in that, a poorman has, as a rule, no difficulties in doing. For
> the volume of his messages is likely to be relatively small and a few
> seconds or even minutes delay in dispatching isn't likely to be a
> concern for him.

>
> With my recent posts on poorman's block and poorman's stream algorithm
> as well as on my compound PRNG and the publication of my C-code, which
> shows that the implementation of my proposed compound PRNG is quite
> simple, a good set of tools for the poorman in the worst case has
> already been established in my humble view. Thus the goal can be
> considered to be achieved and there is in fact no necessity of my
> continuing spending time and effort in that direction. (Like everybody,
> I don't get paid for posting!)
>
> On the other hand, in the "normal" days, a poorman is certainly not
> really poor, for he can well employ the well-established efficient
> algorithms. But he may have a feeling of uncertainty in using them, not
> only because these are more complex for him to understand but also (and
> in praticular) because he knows that researchers continue to achieve
> progress in attempting to attack these algorithms with linear analysis,
> algebraic analysis, etc., as evidenced by the number of annual crypto
> congresses. In my thread "Introducing dynamics into block encryptions"
> I have clearly shown on the other hand that he needs "only" to use
> dynamic keys (generated from a master-key with the same block algorithm
> in counter mode) in order to be sure that no "eventual" sensational
> future breakthroughs in crypto research could ever surprise him and
> render his encrypted secrets suddenly open to attack. So I think I have
> also served him sufficiently well in situations of the "normal" days.
>
> BTW, I have sent a copy of my posts in the thread "Introducing
> dynamics ....." to a person who evidently has very high expertise
> on (among other fields) linear analysis, but (perhaps fairly
> understandably) I didn't get any comments back.
>
>
From: Mok-Kong Shen on 23 Mar 2010 16:02
unruh wrote:

> All of your schemes are far harder to memorize than say rc4, and are
> weaker and slower. And implimenting encryption on the cheap does
> absolutely no good if the other side of the communication does not have
> the scheme. They are far more likely to be able to get say rc4 than you
> be able to send them your scheme.

I think RC4 is nice, but my compound PRNG is meant to be much bigger
in general (it operates on words and is meant to use a quite large
pool). BTW, I must admit I have till now a little bit personal problem
of understanding RC4. The alphabet in it gets modified through certain
swapping. How was that particular swapping decided upon? Could you or
someone else kindly help? (Sorry for this dumb question.)

To the implementation point of yours: The schemes are not meant to be
sent. It is assumed that both partners can easily understand the
foundations underlying the kind of scheme I depicted and thus can agree
on one to be implemented by them individually. Further, it is likely to
be the case that only one partner will be a poorman (due to e.g.
unfavourable political environment etc. etc.), while the other is rich.
So, if the poorman manages to implement, there is no problem at all
on the side of his partner (in this case).

Thanks,

M. K. Shen
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: On the classification of ciphers
Next: A C-code for permutation polynomials mod 2^n