Re: New unbreakable encryption method

jlb@xxxxxxxxxxxxx writes:

Hi! I developed an unbreakable encryption method that will replace the
One Time Pad. I know that sounds unlikely, as so many people have
attempted this and failed. I have shown this to DoD architects, and
they agreed with my conclusions. I have a Ph.D. in computer science
and a strong background in math. My name is Jack Bosworth. If you wish
to contact me, I have a web site at

I call the method "Perpetual One Time Pad", or POTP for short. I
considered calling it Perpetual One Use Pad, but I thought POUP wasn't
a good nickname for it:).

The Basic Idea
Take a small number of One Time Pads. These are of course shared
between two computers. Add an array of random numbers that can be used

What is this "array of random numbers"? How is it generated? How is it
shared between the computers? Is it itself just a OTP.

as indexes in those One Time Pads. Now, every time you use a code from
one of the pads, use the next value in the array to determine another
code in that same pad with which to swap values. That's basically it.
Now you have a small set of perpetual One Time Pads.

More Detail
Consider each of these One Time Pads to be a dictionary. You provide a
symbol, e.g. a word or a binary value, and it provides a code for that
symbol. One of the easiest ways to understand and implement this
method is using 16-bit codes. 16-bits is a "short integer" in computer-
ease. A 16-bit integer can hold 64K values, i.e. values ranging from 0
to 65,535. Create 10 64K arrays of short integers with random numbers

Uh, how do you create them?

such that each array contains each number only once. I.e. each array

It they occur only once then they are NOT random numbers. It may be a
random permutation.

represents a 2-way translation. E.g. if the value at index 5 of an
array is 3492, then 3492 does not appear at any other index in that
array. There are several ways to populate such arrays, so I won't go
into that. We'll call these arrays dictionaries 0, 1, . . . 9.

Add another 64K array of short integers. This is the "replacement
array". Populate this array as you would one of the dictionaries, with
each value represented exactly once.

Let's call one side the "sender" and the other the "receiver". The
sender sends a message to the receiver saying, "Hi, I'm <whoever it
is>. Wanna talk?" The details of this message are not important except
to minimize the potential effect of a DOS attack. I'll let you choose
the details that are most appropriate to your application of the
method, but keep in mind that the <whoever it is> can be encrypted.

The receiver responds with an encrypted message containing an integer

Sorry, how is this encrypted since the two sides have not synchronized
their stuff yet?

sequence number. This message may contain other info, if you like. The
sequence number determines the starting dictionary. E.g. if the
sequence number is 3502917, the first dictionary to use is dictionary
7 (mod 10 arithmetic). (NOTE: The point of using the fake sequence
number is to obfuscate which dictionary is being used to translate any
given value in a message. Other schemes could be used to accomplish

??? It is encrypted. Why the obfuscation?

Now the sender encrypts a message. Let's say the message is
"aaaaaaaaaa". (The sender is trying to decide what to say:)) Let's say
the value of the letter 'a' is decimal 97. So take the value in
dictionary 7 at index 97. That's the encoding for the first 'a'. Look
in the replacement array at index 3502917 modulo 65536. Let's name the
value at that index n. Now swap the values in dictionary 7 at index 97
and index n. Do the same thing for the second 'a', using dictionary 8.
Since this is the next encoding in the message, use the next index in
the replacement array. And so on. You see that the resulting encoding
probably has all different codes, but if two or more of the codes are
the same, it has not significance.

Notice that the shared data changes based on the actual data
encrypted. As such, a listening hacker never has enough information to
decrypt any part of any message. If you are concerned that someone
might at some point collect enough to hack in, add pseudo-random non-

Sorry, in a provably secure scheme the attacker never has enough
information. That is what provably secure means. Your scheme is not
probably secure.

transmitted messages to the mix. Combine this method with the fact
that One Time Pad is the only "proven" unbreakable encryption method
to date. QED

Sorry, no QED here. You might as well have said "the sky is blue QED"
You have not shown that, no matter how much information the attacker has,
and no matter how much plain text->encrypted text the attacker has, he
cannot discover anything about any other parts of the message. That is what
"provably secure" means. It does not mean "my scheme is complicated enough
that you probably cannot find a way of attacking it".
Ie, assume that the attacker has an infinite amount of plain text to
encrypted text (ie has botht he plain text and the encrypted text) You now
send a message. Can the attacker use that infinite amount of plain to
encrypted text to determine anything about your message. For the OTP the
answer is no, because there is nothing in that infinite amount of material
that could be used to determine anything about the key used for the next
material, by the definition of the key (each bit of the key is by
assumption completely independent of the rest of the key). Yours does NOT
have that feature. Yours only 2^170 bits of key material. Your job is to
demonstrate that despite that limited amount of key material, the attacker
cannot get any information. Make your character length 1 bit rather than
16. Use just one dictionary and one random table (of two elements). See if you can break that. If
you can, then the fact that you have made yours much more complicated does
not help. It just makes it harder to break, not impossible.

Clearly, one issue is maintaining consistency between the data shared
by the sender and receiver, since they become out of sync as soon as
the sender begins to encrypt a message. There are several approaches
to handle this, depending on the application. I've described a little
of this on the web site.

See my web site for more details or to contact me. There are many
variations on this method. It is strong enough to use for DoD or
financial transactions. (Actually, I don't think there is a stronger
encryption anywhere today.) I developed a prototype, but I assume that
you can understand this method without a sample implementation.

It is a horrible method in that it requires the exchange of over half a
million bytes of key to exchange a message (all your tables) and then one
needs to keep things synchronized, with no recovery if things become
unsynchronized except a further exchange of tables.

It is not probably secure although it is probably reasonably secure. It is unwieldy.
Exactly why should anyone use it?

My intention is to make this encryption method available to everyone
in the country who needs it, and the only way I know to do that is to
make it available to everyone, so here it is.