Unbreakable encyrption

**c2141** · Apr20-09, 11:27 PM

I have developed a methodology to implement a one-time pad in the field (by hand), without all the issues regarding Key Management or PAD security etc.

This is a 100 character text (in English) encrypted using my method. I do not want to give any more clues about this until A.) it is cracked really fast or B.) has been tested by quite a few people and still found to be unbreakable.

Encrypted Message:

fogcjevggclhccccsdufinphrkqqsbolsdddunzkfrstvkuabk ctertdxvhhoqfdwvoazgyglhnazdetytfrzcrwytchobnismpr

**junglebeast** · Apr20-09, 11:34 PM

Originally Posted by c2141

I have developed a methodology to implement a one-time pad in the field (by hand), without all the issues regarding Key Management or PAD security etc.

This is a 100 character text (in English) encrypted using my method. I do not want to give any more clues about this until A.) it is cracked really fast or B.) has been tested by quite a few people and still found to be unbreakable.

Encrypted Message:

fogcjevggclhccccsdufinphrkqqsbolsdddunzkfrstvkuabk ctertdxvhhoqfdwvoazgyglhnazdetytfrzcrwytchobnismpr

A message encrypted with a one time pad is impossible to decrypt without the pad. Fundamentally. Impossible. Period. So why did you bother to post a message which it is impossible to decode? Unless...you don't actually understand the concept of what a one time pad is.

Secondly, generating a one time pad in the field is trivial. All you have to do is randomly generate bits. The problem is that in order for someone else to decode the message, you need to give them the pad first.

If there's some kind of "rule" or "trick" or "pattern" that can be used to decode the message, then it is not a one time pad.

**c2141** · Apr21-09, 12:20 AM

Yes, I know a one-time pad is considered unbreakable - I posted this because the operative words are "to randomly generate bits" - In this methodology, you don't need to generate random bits, and you don't need to give anyone the pad.

I admit, this is a form of super-encryption because a small random key was used to encrypt on top of the already encrypted text.

One time pads require a random key, the same size as the message - used once.

My goal was to have people do their thing, so I can determine if my methodology truly produced a random PAD. I guess I wanted people to try a bunch of frequency analysis tools, code breaking software, etc. (which I don't have) on this code to test it.

I guess, I am challenging the industry standard statement which you quoted:
"If there's some kind of "rule" or "trick" or "pattern" that can be used to decode the message, then it is not a one time pad."

-- this is kind of true, barring one point ... and that is unless the rule, trick or pattern truly produces randomness.

**junglebeast** · Apr21-09, 12:49 AM

My goal was to have people do their thing, so I can determine if my methodology truly produced a random PAD. I guess I wanted people to try a bunch of frequency analysis tools, code breaking software, etc. (which I don't have) on this code to test it.

I guess, I am challenging the industry standard statement which you quoted:
"If there's some kind of "rule" or "trick" or "pattern" that can be used to decode the message, then it is not a one time pad."

-- this is kind of true, barring one point ... and that is unless the rule, trick or pattern truly produces randomness.

It sounds like you are claiming to have generated a new pseudo-random number generator. These are useful in cryptography for generating keys. However, it is highly improbable that you managed to discover an algorithm that is more random than any of the ones developed by mathematicians who have extensively studied this problem over the past century, and who do have access to advanced statistical techniques for assessing randomness.

Some of the most basic tests for randomness are the chi squared test and the runs test. However as I recall these are just primitive tests which are more suitable for regular random number generation such as linear congruential generators, Mersenne twister, etc. An example of a cryptographically secure random number generator is Blum Blum Shub.

There is a big difference between appearing to be random and actually being cryptographically secure. It's very easy to construct a cipher that baffles smart people for a very long time...but the field of cryptography has really moved beyond simple gimmicks. At this point, to be considered secure, they assume that you have been able to gain full information about how your system works (either by stealing the apparatus, or by espionage, or because its public knowledge), and also having access to the most powerful computers in the world, and with all that if it takes more than a million years to decipher the code, then it's secure. This is the level of security that is now taken for granted and used in every day devices such as cell phones and web browsers...so unless you can beat that...

**c2141** · Apr21-09, 11:01 AM

I don't know if I can beat that. I have tried all the software I could find on the web to crack it. Nothing so far - even if I supply the initial 8 character key.

So if anyone has a way to bang on this and confirm. Then the ability to implement an OTP in the field without the need for a notebook full of stuff, key managment, or anything to steal etc. -- could be valuable?

**junglebeast** · Apr21-09, 12:51 PM

Originally Posted by c2141

So if anyone has a way to bang on this and confirm. Then the ability to implement an OTP in the field without the need for a notebook full of stuff, key managment, or anything to steal etc. -- could be valuable?

No, for three reasons..

(1) We already have excellent procedures for generating a one time pad in the field without a "notebook of stuff" if one wanted it. An example is Blum Blum Shub.

(2) A one time pad generated on the fly is not useful for secure communication because a method for communicating the one time pad to the other party is the same as the original problem of wanting to communicate a message to the unknown party securely.

(3) The whole existence of public key cryptography solves the problem in (2), which is why one time pads are not used as the basis for secure communication.

**c2141** · Apr23-09, 04:45 PM

Would you know the answer to this?

I wanted to know: If you took a string of random characters, lets say 50 for example, and then applied a small 8 or 12 character random key to it.
(assume random = cryptographically random by all NIST standards)

Would that be decipherable? I mean could some determine the key or key length?

I ask because, if the letters are random, then I would think there would be nothing available to wedge in on?

**junglebeast** · Apr23-09, 05:05 PM

Originally Posted by c2141

Would you know the answer to this?

I wanted to know: If you took a string of random characters, lets say 50 for example, and then applied a small 8 or 12 character random key to it.
(assume random = cryptographically random by all NIST standards)

Would that be decipherable? I mean could some determine the key or key length?

I ask because, if the letters are random, then I would think there would be nothing available to wedge in on?

It's easy to crack...you just brute force check all possible keys. Usually in cryptographic analysis you assume that if they can generate a set of decrypted messages containing the true message, then it's completely insecure (even though in reality, choosing the correct one would also be difficult or impossible, especially for a short message).

**jamesb-uk** · Apr29-09, 01:35 PM

If you have used a random key which is the same length as the message, then it is impossible to break- it has been mathematically proven. Do you mean you have created a method of creating random keys, or would you just use the same key for all messages. In that case, it would be possible to decrypt if you give us another sample of similar size.

**c2141** · May4-09, 09:10 AM

Thanks for all your guidance - I had to learn the hard way. I finally approached my algorithm from de-cryption perspective and found its flaw.

You all were right. No matter what I do - I have to assume that the algorithm is public, therefore just a brute force on the key is all that is needed.

There really is nothing you can do to make an unbreakable code. You either need to keep the algorithm secret (fat chance) or make the key so long it is computationally infeasable.. or OTP and share a huge random key.. again infeasable.

I'll go back to the drawing board -