# Re: New unbreakable encryption method

*From*: Unruh <unruh-spam@xxxxxxxxxxxxxx>*Date*: Sun, 24 Aug 2008 15:43:14 GMT

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 http://bosworths.net.

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.

Communication

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

this.)

??? 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.

.

**Follow-Ups**:**Re: New unbreakable encryption method***From:*biject

**References**:**New unbreakable encryption method***From:*jlb

- Prev by Date:
**Need details on NTFS-EFS internals** - Next by Date:
**Re: New unbreakable encryption method** - Previous by thread:
**Re: New unbreakable encryption method** - Next by thread:
**Re: New unbreakable encryption method** - Index(es):