http://news.bbc.co.uk/2/hi/science/nature/7661311.stm

Perfect secrecy has come a step closer with the launch of the world's first computer network protected by unbreakable quantum encryption at a scientific conference in Vienna.


These are typically based on complex mathematical procedures which are extremely hard for outsiders to crack but not impossible given sufficient computing resources or time.

But quantum systems use the laws of quantum theory, which have been shown to be inherently unbreakable.


what do you guys think?

Security vulnerabilities can generally be divided into two categories; design bugs and implementation bugs. While quantum cryptosystems may have the potential to be designed for perfect secrecy, chances are good that the implementations will be far from perfect. Example:

http://hackaday.com/2008/10/06/quantum-cryptography-in-band-attack/

No encryption is unbreakable. The point of a brute-force with present technology can merely be pushed beyond the heat-death of the universe, so that when all things die, the data will live.

No encryption is unbreakable. The point of a brute-force with present technology can merely be pushed beyond the heat-death of the universe, so that when all things die, the data will live.

That's deep. You should be a poet.

No encryption is unbreakable. The point of a brute-force with present technology can merely be pushed beyond the heat-death of the universe, so that when all things die, the data will live.

I'm going to clarify this statement (not argue it) with the following: "breaking" an encryption/cipher does not include a full brute force attack of the entire keyspace. When cryptogeeks speak of a break, it refers to any attack that results in less "tries" than brute forcing the entire key. For example, a flaw in a cipher may allow an attacker with 1000 plaintext-ciphertext combinations to find 2 bits of the key. If that cipher uses a 128 bit key, this attack reduces the number of "tries" from 2^128 down to 2^126. This is an example of breaking a cipher (making it easier than full brute-force). Even if the analyst still has to brute force the rest of the key; that cipher is still broken because it has a flaw that allows information about the key to be leaked.

By this standard (and it is the standard), there is one proven unbreakable cipher; a one-time pad. This is merely an encryption method that requires unique and random keybits for every bit of plaintext.

Also, regardless of the time we have left until the flying-spaghetti-monster slurps up the universe and the current computing power on the planet, a break is still a break. Although many many of the breaks discovered in ciphers cannot be realistically exploited in the real world because even after the flaw is leveraged there is still too much to brute force (or it requires too much plaintext-ciphertext, etc..).

I'm going to clarify this statement (not argue it) with the following: "breaking" an encryption/cipher does not include a full brute force attack of the entire keyspace. When cryptogeeks speak of a break, it refers to any attack that results in less "tries" than brute forcing the entire key. For example, a flaw in a cipher may allow an attacker with 1000 plaintext-ciphertext combinations to find 2 bits of the key. If that cipher uses a 128 bit key, this attack reduces the number of "tries" from 2^128 down to 2^126. This is an example of breaking a cipher (making it easier than full brute-force). Even if the analyst still has to brute force the rest of the key; that cipher is still broken because it has a flaw that allows information about the key to be leaked.

By this standard (and it is the standard), there is one proven unbreakable cipher; a one-time pad. This is merely an encryption method that requires unique and random keybits for every bit of plaintext.

Also, regardless of the time we have left until the flying-spaghetti-monster slurps up the universe and the current computing power on the planet, a break is still a break. Although many many of the breaks discovered in ciphers cannot be realistically exploited in the real world because even after the flaw is leveraged there is still too much to brute force (or it requires too much plaintext-ciphertext, etc..).

You're correct. But to clarify, I usually think of an algorithm (like Serpent or OTP) as a 'cipher' and something encrypted with it to be an 'encryption'. But that's likely idiosyncratic.

You're correct. But to clarify, I usually think of an algorithm (like Serpent or OTP) as a 'cipher' and something encrypted with it to be an 'encryption'. But that's likely idiosyncratic.

Gotcha, that makes sense.

No encryption is unbreakable. The point of a brute-force with present technology can merely be pushed beyond the heat-death of the universe, so that when all things die, the data will live.
Were not going to be using current technology forever. Processing power continues to grow at an explosive rate. The processors you can buy today for $99 are more powerful than million dollar computer systems of the late 80s.

Were not going to be using current technology forever. Processing power continues to grow at an explosive rate. The processors you can buy today for $99 are more powerful than million dollar computer systems of the late 80s.

Yeah, and then a new algorithm pushes it back beyond what that hardware can go. It's an arms race.

No encryption is unbreakable. The point of a brute-force with present technology can merely be pushed beyond the heat-death of the universe, so that when all things die, the data will live.


I really need to make a note to re-read this later, as that just confused the shit out of me.

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.

No encryption is unbreakable. The point of a brute-force with present technology can merely be pushed beyond the heat-death of the universe, so that when all things die, the data will live.

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.

Security vulnerabilities can generally be divided into two categories; design bugs and implementation bugs. While quantum cryptosystems may have the potential to be designed for perfect secrecy, chances are good that the implementations will be far from perfect. Example:

http://hackaday.com/2008/10/06/quantum-cryptography-in-band-attack/

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

Torture is always a viable option.

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

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.