one time pad breakable debate

This is a discussion on one time pad breakable debate within the General Discussions forums, part of the Community Boards category; post the contents of "ciphertext.txt" here, and hopefully I can demonstrate what I'm talking about
Well i wrote a short ...

post the contents of "ciphertext.txt" here, and hopefully I can demonstrate what I'm talking about

Well i wrote a short paragraph, compiled and ran the program, here is the output of my ciphertext.txt file.
unfortunately the decrypt did not want to work, i tried several times differently, i dont know if i am missing something but every time the key length error came up so i could not test that.
Strangely the first time i ran it the decrypt executed but the out file just looked like another key, then it would not work again after that. if its my usage thats at fault go ahead with the sample cipher below, or let me know what you think i doing wrong and i will go again.

As far as I know, historically one-time pads have indeed been broken (ones used by Soviet spies). But that was only because the opponents got hold of the key-books and / or the Soviets reused keys for several messages.

As far as I know, historically one-time pads have indeed been broken (ones used by Soviet spies). But that was only because the opponents got hold of the key-books and / or the Soviets reused keys for several messages.

That is why I stated that "the main problem concerning the use of a one time pad is key management".

EDIT:
Oh, and besides problems with key distribution, usage and storage, there's also the problem of key generation: the keys really must be random.

Which, if done for computer purposes, does remove most concerns regarding key distribution and storage. The "key" can be as simple as a long integer.

You still have a key distribution problem: if you use public key encryption to establish a secure channel, then breaking the public key cryptosystem (or the protocol, or its implementation, if they are flawed) would break your scheme. Key storage is probably less of a problem for computers, yes, but if your key is a single long integer, you only can encrypt a message equivalent to a single long integer.

Which, if done for computer purposes, does remove most concerns regarding key distribution and storage. The "key" can be as simple as a long integer.

So the key would be the "random seed"? That makes the actual key much much much more predictable, since rather than 2^8000 possibilities for a 1000 byte message, you now have only LONG_INT_MAX possibilities, for a message of any length.

That would be extremely simple simple to crack. Just using rand() in a naive way to generate a key will defeat most of the purpose.

No, that would not make a one time pad. If you use a cryptographically secure PRNG it may still be rather secure, but it will not be a one time pad and thus will not have the theoretically unbreakable property of a one time pad.

No, that would not make a one time pad. If you use a cryptographically secure PRNG it may still be rather secure, but it will not be a one time pad and thus will not have the theoretically unbreakable property of a one time pad.

Okay, but that is what brewbuck's method boils down to -- it is the sequence used by your random number generator, which is not very secret. Even if you seeded it, the number of message length keys this could produce is limited to LONG_INT_MAX.

Okay, but that is what brewbuck's method boils down to -- it is the sequence used by your random number generator, which is not very secret.

I suppose you can provide your own key.txt that contains key that is properly randomly generated. Note that it is not about the secrecy of the PRNG: even if you use the NSA's best cryptographically secure PRNG that no one outside of the NSA knows, the resulting key would not constitute a one time pad simply because the seed has less information than the plaintext.

But the seed is not the key. Hence why I put it in double quotes. The key will be generated by the seed. The mechanism for said generation is an RNG. Meaning the actual key can be generated on the fly and the decryption is made right after, as long as:

a) you possess the correct seed
b) you possess the correct RNG
c) you possess the correct decryption algorithm

So the seed is just another layer of security, if you will. And a more convenient way of transporting the key.

Originally Posted by MK27

So the key would be the "random seed"? That makes the actual key much much much more predictable, since rather than 2^8000 possibilities for a 1000 byte message, you now have only LONG_INT_MAX possibilities.

Note really MK. It would be sensible to store the RNG with the decryption algorithm. There's thus no added concerns past those you had without it. And I just removed out of the equation any concerns regarding they key storage.

You may ask why I would want to do that. For no particular reason, really. Just outlying that key distribution and storage can be simplified down to a long integer without it needing be a "document" the same size or larger as the cipher.

It only uses rand() if you don't provide your own key. I did not have a portable source of randomness. In reality, you would generate your own key from a truly random source and use that. Obviously, keys generated by PRNGs are not suitable because the seed is fixed length. But that isn't the point I'm making -- regardless of what key you use, I can easily produce a key that decrypts to any plaintext of my choice. The ability to do that doesn't depend on how secure the key is. If you doubt it, go ahead and generate your own random key -- I can do it regardless.

If you guys are saying that it's not decrypting properly, then the "trick" I was going to demonstrate isn't going to work... What exactly are the commands you are using? The following should be working:

If out.txt isn't looking like plaintext.txt then something's wrong. I tested this thing pretty extensively before posting it.

The gethex() function only allows upper case hex digits. If there are spaces or other characters in your key, it will mess up the input. If that's the case, try replacing the gethex() function with this one, which is more tolerant (at least tolerant to whitespace):