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

The scheme to be described processes the plaintext P[*] (in units of
computer words) in a user-chosen number of rounds. Each round consists
of two passes, one going in the forward and the other in the backward
direction, increasing the length of the result by one word in each pass.
We assume the availability of a PRNG, whose "current" outputs are
denoted by R below, i.e. different occurences of R are not of identical
values. (For a proposed PRNG of mine, see the thread "Update of my old
idea on random number generation" of 20.03.2010). We explain only the
encryption of a forward pass of a round (input="plaintext",
output="ciphertext"), for the backward pass is quite similar. The
function NLC(x,y) denotes a nonlinear combination of x and y. (For a
proposed NLC of mine, see the thread "Nonlinear combination of streams"
of 13.03.2010, for it's result plausibly contains more "entropy" than
either x or y.)

h = R;

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

C[plaintextlength] = h ^ R;

C[plaintextlength], the additional element created, can serve the
purpose of authentication. A viable variant is using h = NLC(h, P[i]);
Of course, one could choose, if one likes, to employ only one single
(forward) pass and do nothing no more.

Note that there is unfortunately a little inconvenience in decryption.
For all the R's that will be needed have to be computed and stored
before the decryption process begins (an exception is the case with one
single pass only, mentioned above).

Thanks,

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

PS: I personally consider classification of ciphers to be no more than
of secondary importance. Please don't blame me, if you deem the scheme
should properly belong to block, instead of stream, algorithms.
From: Mok-Kong Shen on 21 Mar 2010 10:39
Mok-Kong Shen wrote:

> h = R;
>
> for (i=0; i<plaintextlength; i++)
> {
> C[i] = P[i] ^ h ^ R;
> h = NLC(h, C[i]);
> }
>
> C[plaintextlength] = h ^ R;

The following is more favourable in my view:

h = R;

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

C[plaintextlength] = h ^ R;

M. K. Shen

From: Mok-Kong Shen on 22 Mar 2010 08:38
Mok-Kong Shen wrote:
>[snip]
> Note that there is unfortunately a little inconvenience in decryption.
> For all the R's that will be needed have to be computed and stored
> before the decryption process begins (an exception is the case with one
> single pass only, mentioned above).

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.

M. K. Shen
From: Greg Rose on 22 Mar 2010 17:23
In article <ho7oca$3i7$03$1(a)news.t-online.com>,
Mok-Kong Shen <mok-kong.shen(a)t-online.de> wrote:
>Mok-Kong Shen wrote:
>>[snip]
>> Note that there is unfortunately a little inconvenience in decryption.
>> For all the R's that will be needed have to be computed and stored
>> before the decryption process begins (an exception is the case with one
>> single pass only, mentioned above).
>
>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.

Mok-Kong is talking to himself again. The end is
soon...

Greg.


--
From: Tom St Denis on 23 Mar 2010 06:56
On Mar 22, 5:23 pm, g...(a)nope.ucsd.edu (Greg Rose) wrote:
> In article <ho7oca$3i7$0...(a)news.t-online.com>,
> Mok-Kong Shen  <mok-kong.s...(a)t-online.de> wrote:
>
> >Mok-Kong Shen wrote:
> >>[snip]
> >> Note that there is unfortunately a little inconvenience in decryption.
> >> For all the R's that will be needed have to be computed and stored
> >> before the decryption process begins (an exception is the case with one
> >> single pass only, mentioned above).
>
> >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.
>
> Mok-Kong is talking to himself again. The end is
> soon...

MKS isn't that good of a listener, I doubt he even listens to himself.

Tom
 |  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