Prev: Patented HOTP One-Time Password Algorithm?
Next: Complexity Theoretic Cryptography
From: Mok-Kong Shen on 18 Mar 2010 14:57
Maaartin:
>> P.S. Maaartin questioned in a follow-up to the original version of this
>> post whether our scheme (with n=2) could be considered as (real) digram
>> substitution. Answer: Our scheme could be considered as a digram
>> substitution in the same sense that Playfair could. (For our scheme
>> works in ways analogous to Playfair. See also the limitation of Playfair
>> described above.)
>
> You missed my point. Sure, Playfair is not a general digram
> substitution cipher, but - unlike yours - it produces pairs of
> ciphertext letters where both members depends on both members of the
> plaintext letter pair.

I am not sure whether I was wrong or there was instead a
misunderstanding between us. So let me first reproduce the Playfair
example:

c u l p e
r a b d f
g h i k m
n o q s t
v w x y z

Consider some pairs from the first and the second column:

(c,a)->(r,u) (c,h)->(g,u) (c,o)->(n,u) (c,w)->(v,u)

Now suppose in my scheme the two vectors "happen" to be
as follows (. means other elements of the alphabet):

c u
r a
g h
n o
v w
. .
. .
. .

Wouldn't I have the same transcription result as that of Playfair?
If yes, I don't yet quite understand why there is a fundamental
difference in the "nature" of the dependency of ciphertext letters from
plaintext letters in the two cases.

Thanks,

M. K. Shen
From: Maaartin on 18 Mar 2010 15:56
On Mar 18, 7:57 pm, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote:
> Maaartin:
>
> > You missed my point. Sure, Playfair is not a general digram
> > substitution cipher, but - unlike yours - it produces pairs of
> > ciphertext letters where both members depends on both members of the
> > plaintext letter pair.
>
> I am not sure whether I was wrong or there was instead a
> misunderstanding between us. So let me first reproduce the Playfair
> example:
>
>     c u l p e
>     r a b d f
>     g h i k m
>     n o q s t
>     v w x y z
>
> Consider some pairs from the first and the second column:
>
> (c,a)->(r,u)  (c,h)->(g,u)  (c,o)->(n,u)  (c,w)->(v,u)

That's right. (c, anythingFromTheSecondColumn) maps to (something, u).
But (c, f) maps to (r, e), so the first member of the ciphertext
depends (not only in exceptional cases) on both plaintext letters.
Sure, there are not many possibilities for the outcome if one
plaintext letter is fixed, but it's more than in your cipher.

> Now suppose in my scheme the two vectors "happen" to be
> as follows (. means other elements of the alphabet):
>
>     c  u
>     r  a
>     g  h
>     n  o
>     v  w
>     .  .
>     .  .
>     .  .
>
> Wouldn't I have the same transcription result as that of Playfair?

Yes, but only because you stopped just before it started to get
interesting.

> If yes, I don't yet quite understand why there is a fundamental
> difference in the "nature" of the dependency of ciphertext letters from
> plaintext letters in the two cases.

Just continue your example and you'll see.
From: Mok-Kong Shen on 18 Mar 2010 16:17
Maaartin wrote:
> Mok-Kong Shen wrote:
>> Maaartin:
>>
>>> You missed my point. Sure, Playfair is not a general digram
>>> substitution cipher, but - unlike yours - it produces pairs of
>>> ciphertext letters where both members depends on both members of the
>>> plaintext letter pair.
>>
>> I am not sure whether I was wrong or there was instead a
>> misunderstanding between us. So let me first reproduce the Playfair
>> example:
>>
>> c u l p e
>> r a b d f
>> g h i k m
>> n o q s t
>> v w x y z
>>
>> Consider some pairs from the first and the second column:
>>
>> (c,a)->(r,u) (c,h)->(g,u) (c,o)->(n,u) (c,w)->(v,u)
>
> That's right. (c, anythingFromTheSecondColumn) maps to (something, u).
> But (c, f) maps to (r, e), so the first member of the ciphertext
> depends (not only in exceptional cases) on both plaintext letters.
> Sure, there are not many possibilities for the outcome if one
> plaintext letter is fixed, but it's more than in your cipher.
>
>> Now suppose in my scheme the two vectors "happen" to be
>> as follows (. means other elements of the alphabet):
>>
>> c u
>> r a
>> g h
>> n o
>> v w
>> . .
>> . .
>> . .
>>
>> Wouldn't I have the same transcription result as that of Playfair?
>
> Yes, but only because you stopped just before it started to get
> interesting.
>
>> If yes, I don't yet quite understand why there is a fundamental
>> difference in the "nature" of the dependency of ciphertext letters from
>> plaintext letters in the two cases.
>
> Just continue your example and you'll see.

O.K. Let me choose as follows:

c u
r a
g h
n o
v w
a l
d b
f i
i q
l x
o p
q d
s k
u s
x y
z e
h f
b m
w t
y z
e c
k r
m g
p n
t v

I don't yet see what's interesting that will come out.

Thanks,

M. K. Shen

From: Mok-Kong Shen on 19 Mar 2010 05:51
Mok-Kong Shen wrote:
> Maaartin wrote:
[snip]

> I don't yet see what's interesting that will come out.

Thank you tremendously for causing me to review the described scheme,
which in fact needs a repairment. I have to strongly blame myself,
because the required repairment measure was already contained in a
previous post of mine in the thread "The classical sliding alphabets"
(initiated by myself on 26.10.2009), where I wrote:

It may be mentioned that the device can be conveneintly used also
for digram substitution (analogous to playfair, see a recent thread
of mine: "Diagram substitution using a polyalphabetic substitution
table"), since sliding alphabet is in fact a special case of
polyalphabetic substitution.

That means, after encryption of a plaintext pair (in the case n=2),
one has to do a sliding of one alphabet relative to the other before
processing the next plaintext pair.

Now, incorporating the repairment, I like to formulate the revised
version of the scheme for the general case of n-gram substitutions as
follows:

Let M[m,n] be a matrix with each column being a random permutation
of the alphabet of size m and S[n] be a vector to contain the
sliding-values, initialized at encryption processing setup time with:

for (i=0; i<n; i++) S[i]=0;

and cc be an arbitrary non-zero constant. Given a current plaintext
n-gram P[*], we transcribe it to the ciphertext n-gram C[*] as follows
(the letters are denoted by numerals in [0,m-1]):

for (i=0; i<n; i++)
{ ii = (i+1)%m;
C[i] = M[(P[ii]+S[ii]+cc)%m, i];
}

for (i=0; i<n; i++) S[i]=(S[i]+i)%m;

The scheme has admittedly the disadvantage of being rather error-prone
for manual work, but isn't evidently a problem, if one has a computer
to do the work.

We repeat that cc could be dynamically varied (from n-gram to n-gram)
and that, if there are N (N>n) vectors (random permutations of the
alphabet) available, one could use a keystream to determine different
sets of n vectors out of the total N vectors to process the individual
n-grams of the given plaintext stream.

Thanks,

M. K. Shen

From: Mok-Kong Shen on 19 Mar 2010 06:21
Mok-Kong Shen wrote:

> for (i=0; i<n; i++)
> { ii = (i+1)%m;
> C[i] = M[(P[ii]+S[ii]+cc)%m, i];
> }

Sorry, typo: Please read: ii = (i+1)%n;

M. K. Shen

First  |  Prev  | 
Pages: 1 2
Prev: Patented HOTP One-Time Password Algorithm?
Next: Complexity Theoretic Cryptography