Re: (newbie) question on modification of polyalphabetic substitution cipher

From: Gary Shannon (gary_at_fiziwig.com)
Date: 03/30/04 

Date: Tue, 30 Mar 2004 02:25:56 GMT

<vedaal@hush.com> wrote in message
news:52a1833e.0403290551.1d6cfae6@posting.google.com...
> Joe Peschel <jpeschel@no.spam.org> wrote in message
news:<Xns94BB930DDE73fa0khgj7ji8i8jo9@216.168.3.44>...
> > vedaal@hush.com (vedaal@hush.com) wrote in
> > news:52a1833e.0403280826.6e0f2efe@posting.google.com:
>
> > Then you would have a plaintext autokey cipher.
>
> yes,
> but somewhat different than the ones i've read about,
> in that there is no repetition of the key anywhere, no matter how long
> the plaintext

Not so. Try any function you wish. As long as you take it mod 256 the
function will have a repeating period of at most 256, possibly after some
aperiodic part of less than 256 steps in length. Most of the time the
period will much shorter than 256.

Trying your function f(n) = [a[(b)^(n+c)] + d[(k)^(n+g)] + r]mod(256)

with randomly choosen constants:

a = 2
b = 793
c = 14
d = 243
k = 91
g = 44

Here is the result starting with n = 1:
 3 187 91 219 219 219 219 219 219 219 219 ...

The aperiodic part is 3 values in length and the repeating period is only 1
value so after the first three letters it becomes a monoalphabetic cipher.

Changing a to 3 instead of 2 yeilds:

 110 190 126 126 126 126 ...

and the cipher becomes monoalphabetic after only two letters.

Maybe bigger numbers would help? Changing c to 9999 gives me:

 110 190 126 126 126 126 ...

So you see, the notion that the stream of values never repeats is way off
base.

BTW: I just noticed that I left out the "+r" when I wrote the little
program to demonstrate this, but obviously adding any constant to a series
of unchanging numbers won't make them be different from each other.

--gary

Quantcast