Prev: Any recommendations for frequency analysis software?
Next: Linear Equivalence and Involutions
From: Mok-Kong Shen on 11 Mar 2010 11:26

Consider the admittedly rather rare but not totally unrealistic
scenario where two partners agree on a secret key for block encryption
under the circumstance that one of them has to implement the algorithm
from scratch without the kind of very difficult to memorize algorithm
descriptions commonly found with the well-known block algorithms. That
is, the logic of the algorithm used should be simple enough to be kept
in one's head and comparatively easy to be programmed on a computer.

In my humber view, one practically viable approach is to use a class of
nonlinear functions F_K(X) as the E(K,X) in the (revised) code [1]
given in the thread "Composing large block cipher from smaller ones"
initiated by me. Since, for efficiency reasons, on 32-bit computers
it is advantageous to work with 32-bit unsigned integers, F_K(X) can be
a polynomial of X of degree n (n>=2) mod 2^32, with its coefficients
constituting the K. (Personaly I would prefer to use a permutation
polynomial with full cycle in [0, 2^32-1] for F_K(X)). These
coefficients can be generated from the given (master) secret key by
using it (together with some time-varying data specific to the session)
as the coefficients (and starting value) of a polynomial of X mod 2^32
(i.e. used as a PRNG). Evidently, the requirements depicted above are
fairly well met.

Of course, a sufficiently large number of rounds would be needed for
security. (High computing efficiency isn't likely to be required
in our context.) One may also advantageously employ dynamics to render
analysis hard. (See the thread "Introducing dynamics into block
encryptions". For authentication see also the thread "Using a kind of
running accumulation of ciphertext as chaining value of encryption".)

I should be grateful for critiques and comments and for ideas of better
alternatives.

Thanks,

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

[1]

for (i=0; i<numberofrounds, i++)
{
Cn = IVMK + i;
k0i = E(MK0,Cn); k1i = E(MK1,Cn); K2i = E(MK2,Cn); K3i = E(MK3,Cn);
}

for (i=0; i<numberofrounds, i++)
{
B_0 ^= E(K1i,B_1); B1 ^= E(K0i,B0); B_2 ^= E(K3i,B_3); B3 ^= E(K2i,B2);
B_0 ^= E(K2i,B_2); B2 ^= E(K0i,B0); B_1 ^= E(K3i,B_3); B3 ^= E(K1i,B1);
}

-------------------------------------------------------------------------------------------

[OT, personal note:] I am unfortunately forced by recurrent personal
insults to use kill-file. That is, I would not read, not to say answer,
posts of some who have the mean habit of frequently abuse this
sci-group that way. Anyone who doesn't like my posts for whatever
reasons is strongly advised to put me in his kill-files as well.
From: Maaartin on 11 Mar 2010 14:18
Mok-Kong Shen wrote:
> Consider the admittedly rather rare but not totally unrealistic
> scenario where two partners agree on a secret key for block encryption
> under the circumstance that one of them has to implement the algorithm
> from scratch without the kind of very difficult to memorize algorithm
> descriptions commonly found with the well-known block algorithms. That
> is, the logic of the algorithm used should be simple enough to be kept
> in one's head and comparatively easy to be programmed on a computer.
>
> In my humber view, one practically viable approach is to use a class of
> nonlinear functions F_K(X) as the E(K,X) in the (revised) code [1]
> given in the thread "Composing large block cipher from smaller ones"
> initiated by me. Since, for efficiency reasons, on 32-bit computers
> it is advantageous to work with 32-bit unsigned integers, F_K(X) can be
> a polynomial of X of degree n (n>=2) mod 2^32, with its coefficients
> constituting the K. (Personaly I would prefer to use a permutation
> polynomial with full cycle in [0, 2^32-1] for F_K(X)). These
> coefficients can be generated from the given (master) secret key by
> using it (together with some time-varying data specific to the session)
> as the coefficients (and starting value) of a polynomial of X mod 2^32
> (i.e. used as a PRNG). Evidently, the requirements depicted above are
> fairly well met.

There's a problem with polynomials you was already told about: They
propagate only towards higher bits (unless you use non-power of two
modulus which is slow). So you can be sure, that a couple of least
significant bits can be found out easily, no matter how many rounds
you do. Starting from them, higher bit can be found, etc. I already
recomennded a remedy, so use it or find another.

> Of course, a sufficiently large number of rounds would be needed for
> security. (High computing efficiency isn't likely to be required
> in our context.) One may also advantageously employ dynamics to render
> analysis hard. (See the thread "Introducing dynamics into block
> encryptions". For authentication see also the thread "Using a kind of
> running accumulation of ciphertext as chaining value of encryption".)
>
> I should be grateful for critiques and comments and for ideas of better
> alternatives.
>
> Thanks,
>
> M. K. Shen
> -------------------------------------------------------------------------------------------
>
> [1]
>
> for (i=0; i<numberofrounds, i++)
> {
> Cn = IVMK + i;
> k0i = E(MK0,Cn); k1i = E(MK1,Cn); K2i = E(MK2,Cn); K3i = E(MK3,Cn);
> }
>
> for (i=0; i<numberofrounds, i++)
> {
> B_0 ^= E(K1i,B_1); B1 ^= E(K0i,B0); B_2 ^= E(K3i,B_3); B3 ^= E(K2i,B2);
> B_0 ^= E(K2i,B_2); B2 ^= E(K0i,B0); B_1 ^= E(K3i,B_3); B3 ^= E(K1i,B1);
> }
>
> -------------------------------------------------------------------------------------------
>
> [OT, personal note:] I am unfortunately forced by recurrent personal
> insults to use kill-file. That is, I would not read, not to say answer,
> posts of some who have the mean habit of frequently abuse this
> sci-group that way. Anyone who doesn't like my posts for whatever
> reasons is strongly advised to put me in his kill-files as well.

I wouldn't describe it as an insult. You was mainly told to try harder
(learn, read papers, think more before you ask) which is a good
advice, isn't it?
From: Phoenix on 11 Mar 2010 15:46

Maaartin wrote

>There's a problem with polynomials you was already told about: They
>propagate only towards higher bits (unless you use non-power of two
>modulus which is slow)....

Slow??

Try:

FRACTIONAL_PART_OFF(x(x+b)+c) This is polynomial non-power of two
modulus, in this case is (MOD 1.0)

And then tell me about speed.

From: rossum on 11 Mar 2010 16:34
On Thu, 11 Mar 2010 17:26:33 +0100, Mok-Kong Shen
<mok-kong.shen(a)t-online.de> wrote:

>Consider the admittedly rather rare but not totally unrealistic
>scenario where two partners agree on a secret key for block encryption
>under the circumstance that one of them has to implement the algorithm
>from scratch without the kind of very difficult to memorize algorithm
>descriptions commonly found with the well-known block algorithms. That
>is, the logic of the algorithm used should be simple enough to be kept
>in one's head and comparatively easy to be programmed on a computer.
If you are prepared to move away from block cyphers to a stream cypher
then RC4 is easily memorisable and programmable from memory. It is
not perfectly secure but is certainly easily memorized.

rossum

From: unruh on 11 Mar 2010 16:40
On 2010-03-11, Phoenix <ribeiroalvo(a)gmail.com> wrote:
>
> Maaartin wrote
>
>>There's a problem with polynomials you was already told about: They
>>propagate only towards higher bits (unless you use non-power of two
>>modulus which is slow)....
>
> Slow??
>
> Try:
>
> FRACTIONAL_PART_OFF(x(x+b)+c) This is polynomial non-power of two
> modulus, in this case is (MOD 1.0)

The answer is also always 0 which may not be too useful, since x b c are
integers (as far as the conversation here is concerned).
If you are using some encoding of reals by integers, then this is power
of 2 modulus arithmetic.

>
> And then tell me about speed.
>
 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Any recommendations for frequency analysis software?
Next: Linear Equivalence and Involutions