Re: The crazy encryption madmans codebook

On 2 Mar, 10:54, "Joseph Ashwood" <ashw...@xxxxxxx> wrote:
<j...@xxxxxxxx> wrote in message


On 2 Mar, 00:32, "Joseph Ashwood" <ashw...@xxxxxxx> wrote:
I do not see how *telephone* always encodes to anything particular
the actual identifier in the database '12288. telephone=a bad smell'
Just note that if offset multiplies to 0 then 0+12288=12288 it is the
only time telephone encodes to 'a bad smell' i hope you can see that
for any other ouput of letter function in the earlier decoded
plaintext sentence you will get another offset.

All you're doing is attempting to build a not very good chaining mode.
Proper chaining modes have proofs of security around them. Your chaining
mode is k*i where k is the phrase number in the message. So observing the
message it is trivially possible to identify two matching phases ph_1 and
ph_2 in a message or between messages, from there it is known that
k_1*i_1=k_2*i_2 mod N, and since k_* is known the possible space for i_* is
reduced. With each such collision more of the message becomes clear, and
more interrelations become clear, guessing a single correct i_x reveals
exponentially more information as the number of colliding pairs rises. From
there it becomes a matter of strong the permutation in the database actually
is between ph and i, considering that english has < 20 000 words, and
phrases are <= 3 words long that leaves about 40 bits of security maximum,
far from the level of cryptographic security.

And since entry zero do not exist telephone can actually never be
encoded to a bad smell.

See Enigma on why this is a very bad idea.

But maybe you say that it is vulnerable to known chosen plaintext
attacks, yes of course and to known plaintext to.
But in practise those attacs are not useful on codebooks because the
adversary immediatly sees it is a fake nonsense message from man in
the middle.

Actually in practice those attacks are extremely easy. Perform a binary
compare of two word documents on your hard drive, or a binary compare of two
newsnet posts, or a binary compare of two MP3s, you'll see there is a
significant amount of known plaintext available. Each of these known
plaintexts represents a known ph from above, and a strong possibility to
leverage a i_1, i_2 pair leaking enormous information.

In your earlier answer you did talk over my head Joe i am not skilled
in crypto terminology and schemes.
This was just an idea i did get due to the many strange messages
floating around at newsgroups, maybe they are not nonsense but a new
form of databased codebook programs based on some unknown offset

If the chaining mode (f(i,v) from my previous post) they choose is secure
their results will be secure, if it is not the result will not be secure.

Regarding your additional post while I was writing this one, no I do not
agree. To quote myself:

it will be necessary to have a database with a prime number of entries
simply in order to make your proposal as difficult as possible to break
(still trivial though), so your proposed modification (in the other
actually lowers the security further because it is trivially provable
that k
and k+1 cannot be prime for k>2.

If the database is not prime in length then your multiply chaining mode will
reach only a subset of possible outputs for each input, take for example i=2
in a database of size 10, the output would loop between 2,4,8, and 6
skipping all others. Worse take 9 in 81, k=1 out=9, k=2 out=0, k=3 out=0,
k=4 out=0 you get the idea. Even though you don't have one labelled 0, you
have a 0. So the database size has to be prime in order to avoid short and
degenerate loops.

The only thing i do not follow is why the word *telephone* can not be
encoded to any word in the database.
Why would it not be possible, the offset number is just an integer
dependent on former decoded text,
used to find the right value.

This is an assymetric crypto. So off course the actual offset would
have to be
ENCODING plaintextphrase+'textdependent offset/index number'=madman
DECODING madman ouput-'textdependent offset/index

And for how to actually create the offset number i just throw forward
a fast idea, of course much more could be found using and oneway
encoding algorithm or hash over some chosen letter from the earlier
decoded plaintext.

Maybe you did agree about telephone would be possible to encode to any
madman valure in the database and did disagree about something else,
or i just missunderstod you.