That's deep. You should be a poet.

Alternatively, he could just shut the fuck up.

Alternatively, he could just shut the fuck up.

Sir,

that was uncalled for.

Actually, there is such thing as unbreakable encryption.
Google "one time pad".

Actually, there is such thing as unbreakable encryption.
Google "one time pad".

That can still be brute-forced. The question is, will that every be feasible. The qualifications for OTP as "unbreakable" encryption depends on your definition of broken.

My answer: Probably.

That can still be brute-forced. The question is, will that every be feasible. The qualifications for OTP as "unbreakable" encryption depends on your definition of broken.

My answer: Probably.

You can't brute force a one-time pad. Once you xor data with a random one-time pad, the data is literally indistinguishable from random bits.

Any "breaking" of a one-time pad would be exactly the same as just completely generating the data from scratch. A brute force method will never let you know when you've stumbled upon the right data and you just have to try every possible piece of data until you get it.

That can still be brute-forced. The question is, will that every be feasible. The qualifications for OTP as "unbreakable" encryption depends on your definition of broken.

My answer: Probably.

I believe!

You can't brute force a one-time pad. Once you xor data with a random one-time pad, the data is literally indistinguishable from random bits.

Any "breaking" of a one-time pad would be exactly the same as just completely generating the data from scratch. A brute force method will never let you know when you've stumbled upon the right data and you just have to try every possible piece of data until you get it.

A feature of any working cipher is that the ciphertext is indistinguishable from entropy. That isn't the issue. The fact is, unless you're encrypting your entropy store (I do this on a regular basis for fun and profit), your cleartext is not random.

This means that you could brute-force a piece of OTP-ciphered data by generating equivalent random data and then attempting a XOR. Alternatively, you could guess any part of the plaintext, as XOR ciphers are 100% vulnerable to a known-plaintext attack.

A feature of any working cipher is that the ciphertext is indistinguishable from entropy. That isn't the issue. The fact is, unless you're encrypting your entropy store (I do this on a regular basis for fun and profit), your cleartext is not random.

This means that you could brute-force a piece of OTP-ciphered data by generating equivalent random data and then attempting a XOR. Alternatively, you could guess any part of the plaintext, as XOR ciphers are 100% vulnerable to a known-plaintext attack.

I think we're probably misunderstanding each other. Say my cleartext happens to be 111000111 (string A). This is assumed to be meaningful and generated by completely non-random means.

Let's say I xor it with 110100001 (string B). String B is "random," which I'll get back to. The result of xoring the two strings is 001100110 (string C).

Sure, you could deduce string A if you were given string C (which you are) and if you could reasonably guess the method by which string B was constructed. But say string B is based on something like radio interference. You'd have no luck ever figuring out what string B is.

So then you're stuck with just string C. The only way know what string A is (assuming you don't already know string A, which would defeat the purpose) is to know string B is (obviously). In addition, the only way to know what string B is is to know what string A is (because string B is "random").

What if, as you said, you can guess part of the plaintext? Say you know that the beginning of String A is 111. Then, given this and string C, you can deduce that the beginning of string B is 110. But, beyond that, you can't learn anything else about string B, and, as such, you can't learn anything else about String A.

I think we're probably misunderstanding each other. Say my cleartext happens to be 111000111 (string A). This is assumed to be meaningful and generated by completely non-random means.

Let's say I xor it with 110100001 (string B). String B is "random," which I'll get back to. The result of xoring the two strings is 001100110 (string C).

Sure, you could deduce string A if you were given string C (which you are) and if you could reasonably guess the method by which string B was constructed. But say string B is based on something like radio interference. You'd have no luck ever figuring out what string B is.

So then you're stuck with just string C. The only way know what string A is (assuming you don't already know string A, which would defeat the purpose) is to know string B is (obviously). In addition, the only way to know what string B is is to know what string A is (because string B is "random").

What if, as you said, you can guess part of the plaintext? Say you know that the beginning of String A is 111. Then, given this and string C, you can deduce that the beginning of string B is 110. But, beyond that, you can't learn anything else about string B, and, as such, you can't learn anything else about String A.

Yes, which makes OTP a relatively strong cryptosystem practically. However, I don't need to guess the method by which the key was constructed. If I have sufficient resources, I can just brute force it. This will be easier the shorter the message is.

Yes, which makes OTP a relatively strong cryptosystem practically. However, I don't need to guess the method by which the key was constructed. If I have sufficient resources, I can just brute force it. This will be easier the shorter the message is.

The downfall of this is, there are as many possible random strings as 2^n (for n being the number of bits and ^ being the exponentiation operation). The same is the number of possible messages.

For any given cryptext (the technical name for an encrypted message), you have 2^n different plaintexts (the technical term for an unencrypted message, or one that has been decrypted) -- one for each possible key. Unless you have additional knowledge of what the original message was (perhaps from context), brute forcing it was just a waste of time.

Note that it's only secure under the condition that the key is truly random and never reused for a second message. Also note that radio noise isn't sufficient for cryptographic randomness -- anyone in the immediate vicinity may be able to capture the same noise and thus derive the same key. Reverse-polarized diodes and atomic decay are two better sources of entropy.

The downfall of this is, there are as many possible random strings as 2^n (for n being the number of bits and ^ being the exponentiation operation). The same is the number of possible messages.

For any given cryptext (the technical name for an encrypted message), you have 2^n different plaintexts (the technical term for an unencrypted message, or one that has been decrypted) -- one for each possible key. Unless you have additional knowledge of what the original message was (perhaps from context), brute forcing it was just a waste of time.

Thank you. Also noteworthy is the fact that there is an incorrect key that generates every incorrect message, so you even if you go through all 2^n keys, you'll get all 2^n possible plaintexts, but you'll have no idea which one is the right one.

Note that it's only secure under the condition that the key is truly random and never reused for a second message. Also note that radio noise isn't sufficient for cryptographic randomness -- anyone in the immediate vicinity may be able to capture the same noise and thus derive the same key. Reverse-polarized diodes and atomic decay are two better sources of entropy.

This is also true, but the person would need to be reasonably confident that radio noise was actually the method used, the exact method by which bits were chosen with respect the radio noise signal, and, of course, the actual sample period for the noise (which could almost be searched linearly were it not for the fact that a string of length n doesn't necessarily correspond to radio noise of any particular duration).

Anyway, you're right, radio noise is not a particularly strong example.

The downfall of this is, there are as many possible random strings as 2^n (for n being the number of bits and ^ being the exponentiation operation). The same is the number of possible messages.

For any given cryptext (the technical name for an encrypted message), you have 2^n different plaintexts (the technical term for an unencrypted message, or one that has been decrypted) -- one for each possible key. Unless you have additional knowledge of what the original message was (perhaps from context), brute forcing it was just a waste of time.

Note that it's only secure under the condition that the key is truly random and never reused for a second message. Also note that radio noise isn't sufficient for cryptographic randomness -- anyone in the immediate vicinity may be able to capture the same noise and thus derive the same key. Reverse-polarized diodes and atomic decay are two better sources of entropy.

And for the time being, I would presume OTP to be secure, as long as the source of entropy is truly secure (it isn't hard to make RNG's from atomic decay). However, if any significant effort were turned to brute-forcing some relatively small ciphertext, it would break easily, if not now, than with later equipment. Padding the message would be good, but ultimately futile.

However, if any significant effort were turned to brute-forcing some relatively small ciphertext, it would break easily, if not now, than with later equipment.

That's true, but you still have the problem of distinguishing the true plaintext from all the alternates, assuming a true-random key. Without contextual information (for example, in war, knowing placements of enemy troops so you can distinguish it by the locations referenced in the plaintext), you're still left with nothing to tell you which plaintext is which.

That's true, but you still have the problem of distinguishing the true plaintext from all the alternates, assuming a true-random key. Without contextual information (for example, in war, knowing placements of enemy troops so you can distinguish it by the locations referenced in the plaintext), you're still left with nothing to tell you which plaintext is which.

Like I said earlier, even if you did have that information, you'd still generate every possible incorrect plain text that has that information (and is the right length, of course). So you would learn absolutely nothing that you didn't already know.

That's true, but you still have the problem of distinguishing the true plaintext from all the alternates, assuming a true-random key. Without contextual information (for example, in war, knowing placements of enemy troops so you can distinguish it by the locations referenced in the plaintext), you're still left with nothing to tell you which plaintext is which.

This goes back to "are you encrypting your entropy store".

This goes back to "are you encrypting your entropy store".

In that case, I don't know what you mean and why it's relevant.

In that case, I don't know what you mean and why it's relevant.

What I'm saying is, when you find the plaintext, you'll know it's the plaintext, because the plaintext is not the entropy that you'd get by using arbitrary keys.

What I'm saying is, when you find the plaintext, you'll know it's the plaintext, because the plaintext is not the entropy that you'd get by using arbitrary keys.

I'm telling you, this is not true. The reason is that, by trying every possible key, you will generate every possible plaintext.

So if the plaintext is "The soldiers are being sent at 12:30," your brute force search will result in things like:

"The soldiers are being sent at 12:31"
"The soldiers are being sent at 10:00"
"The soldiers are being sent at death"
"dssikduersxjfhhdjklkjhfjdkslkshlfbxu"

and "We have called off the attack today."

(in addition to every single other possibility that is the right length)

Given this, there is absolutely no theoretical way you could ever deduce which plaintext is correct.

Torture is always a viable option.

Just find someone who has/knows the key and torture til he/she reveals it.

wait a year or two and there will be rainbow tables for it.

I'm telling you, this is not true. The reason is that, by trying every possible key, you will generate every possible plaintext.

So if the plaintext is "The soldiers are being sent at 12:30," your brute force search will result in things like:

"The soldiers are being sent at 12:31"
"The soldiers are being sent at 10:00"
"The soldiers are being sent at death"
"dssikduersxjfhhdjklkjhfjdkslkshlfbxu"

and "We have called off the attack today."

(in addition to every single other possibility that is the right length)

Given this, there is absolutely no theoretical way you could ever deduce which plaintext is correct.

You're right in theory, but what's the likelihood of getting just one of those?

I'm telling you, this is not true. The reason is that, by trying every possible key, you will generate every possible plaintext.

So if the plaintext is "The soldiers are being sent at 12:30," your brute force search will result in things like:

"The soldiers are being sent at 12:31"
"The soldiers are being sent at 10:00"
"The soldiers are being sent at death"
"dssikduersxjfhhdjklkjhfjdkslkshlfbxu"

and "We have called off the attack today."

(in addition to every single other possibility that is the right length)

Given this, there is absolutely no theoretical way you could ever deduce which plaintext is correct.

Hey man, bet you aren't good enough at your crypto-fu to write a new NS&H crypto challenge :p

Actually, you could reveal a *wrong key* which is the same lenght as the original message but *decrypts* to something entirely different.
Read the posts above, you'll understand.

That's deep. You should be a poet.

And you're a faggot.


OT: Nothing is unbreakable-- probably a human error won't help.

did any of you READ how quantum encryption works?

Cause if you did, you'd know it has nothing to do with encryption keys wich indeed can be broken. So all the blablabla, talking bout pc's getting faster is utterly useless, since it's not a fast pc you need to break this code

It's like trying to open a lock with a liquorice key

Nothing is uncrackable.

Nothing is uncrackable.

My sentiments exactly.