SHA-0 Broken, MD5 Rumored Broken

An anonymous reader writes "Exciting advances in breaking hash functions this week at the CRYPTO conference. SHA-0 has definitely been broken (collision found in the full function). Rumors are that at the informal rump session, a researcher will announce a collision in full MD5 and RIPEMD-128. And Ed Felten is speculating about collisions in SHA-1! Many systems, especially those that use cryptography for digital signatures are most at risk here."

Okay that's it

I picked the wrong week to quit sniffing MD5 hashes.

Re:Airplane quotes

For those who don't recognize the above quote, go here [moviequotequiz.com] ... especially Joey if you haven't seen a grown man naked yet ... ;-)

BTW, it wasn't that long ago that /. reported about the Feds finally formally dropped DES. [slashdot.org]

ec7b19b60e616fb1c6013d4ada83ec32

d008960fa6b395dca1c8362165bb31be

md5 is so weak

$ echo "first post" | md5sum d008960fa6b395dca1c8362165bb31be

I didn't figured out your title tough.

Re:md5 is so weak

Okay, jokes aside, this shows how social engineering will always be among the best tools for cracking. Krunch, you da man.

Re:md5 is so weak

I give up on the title... I tried all the usual slashdot titles (varying caps and w/ and w/o punctuation)...

"md5 cracked?"

"crack this!"

"GNAA"

"In Soviet Russia, MD5 cracks you!"

"fp!"

"First Post!"

I just don't get it...

Re:md5 is so weak

I give up on the title... I tried all the usual slashdot titles (varying caps and w/ and w/o punctuation)...

You forgot the typo's...

Re:md5 is so weak

I didn't figured out your title tough.

Just wait till the end of the conference. I hear there's a rumor MD5 is broken :)

Re:ec7b19b60e616fb1c6013d4ada83ec32

d008960fa6b395dca1c8362165bb31be

You know you're a complete and utter nerd when you read this post, immediately understand it, and laugh out loud, as I just did :)

Re:Should We Fear?

Your bank will buy enron stock with your accounts, your credit card will explode, and your mind will begin to melt. Nuclear missiles will spontaneously launch and direct themselves to your house. Bush will be exposed as a witless robot when he begins to utter swahili at a press conference. The Martians will arrive from their base on the dark side of the moon, and the War of the Worlds will begin. Super-Bowl half-time will be unceremoniously interrupted when terrorists will arrive to sear off Janet Jackson's nipple with a laser in the name of Allah.

Re:Should We Fear?

Yes, but how does this affect me personally?

Re:Should We Fear?

I don't think George Bush is going to start spewing Swahili anytime soon. He has enough troubles with English.

Re:Should We Fear?

WHAT WOULD IT MEAN TO YOU IF YOU GOT A SEMI-AUTOMATIC WEAPON?

Perhaps I could shoot the first family. =P

TELL ME MORE ABOUT YOUR FAMILY

What business is it of yours?

TELL ME MORE ABOUT YOUR BUSINESS. I CAN OFFER INCENTIVES TO SMALL BUSINESS OWNERS.

Uh, how about we talk about something else...

SOMETHING ELSE...

You know, you're starting to sound like a program I wrote in introduction to programming...

WHAT RESEMBLANCE DO YOU SEE

You are not very intelligent-sounding.

WHAT MAKES YOU THINK I AM NOT VERY INTELLIGENT-SOUNDING?

You never say anything but conservative rhetoric.

WHY DO YOU THINK I NEVER SAY ANYTHING BUT CONSERVATIVE RHETORIC?

You're a mindless tool for the Right-Wing Conspiracy.

DOES IT PLEASE YOU TO BELIEVE I AM A MINDLESS TOOL FOR THE RIGHT-WING CONSPIRACY?

Damn it! I knew it! You're just a useless Eliza hack!

WHAT ELSE COMES TO YOUR MIND WHEN YOU THINK OF ELIZA?

Re:Should We Fear?

I don't think George Bush is going to start spewing Swahili anytime soon. He has enough troubles with English.

Now you know why.

Re:Should We Fear?

doesn't mean that much.

Carefully crrafted binary data can be made to have the same checksum.

This is not a generalised attack where I can create binary data to have a CHOSEN checksum.

Therefore, if you verify your downloads by checksum, I can't generate a fake download with the same checksum.

First step is MATCHING some checksums (this has been done)
The next step is CHOOSING the chekcsum (aka DEADBEEF attack)
The next step is MANIPULATING, i.e. adding junk to a given binary file to allow you to choose the cheksum. that's the scary one!

- substitute trojaned binary
- append some binary junk so the checksum matches
- profit!!!

Nothing to worry about yet, sort of like the first proof-of-concept brute force crack of DES.
Yes, it can be done under some circumstances.
Yes, eventually processing power and methods may improve to make this a valid attack
Yes, you can sleep soundly tonight.

Re:Should We Fear?

maybe I should have read this first: http://www.freedom-to-tinker.com/archives/000661.h tml "And now the rumor is that somebody has extended Joux's method to find a collision in SHA-1." "The finding of a single collision in SHA-1 would not, by itself, cause much trouble, since one arbitrary collision won't do an attacker much good in practice. But history tells us that such discoveries are usually followed by a series of bigger discoveries that widen the breach, to the point that the broken primitive becomes unusable. "

Re:Should We Fear?

First step is MATCHING some checksums (this has been done)
The next step is CHOOSING the chekcsum (aka DEADBEEF attack)
The next step is MANIPULATING, i.e. adding junk to a given binary file to allow you to choose the cheksum. that's the scary one!

Actually, you can do interesting and dangerous things with variants of your first step, not even progressing to step two. The MD5 collisions (well, almost collisions) are largely the same input data that has differences in only a few places. Now imagine that I have two messages that say something like this:

1. "Joe will send Dr. Blue $10. Confirmation number 1234567."
2. "Joe will send Dr. Blue $100000. Confirmation number 6451234."

Now lets say I can manipulate the confirmation numbers in those two messages so that they have the same hash value -- I don't care what the hash is, as long as it's the same in both cases. Then I send you the $10 message.

If you agree, you sign it. But you realize that digital signatures don't actually sign the message, right? They sign the hash of the message, so I can later produce the $100000 message, with your signature, and it will verify that you signed that message!

Re:Should We Fear?

Or say Microsoft signs the hash of Windows XP SP3 with their special key. I tweak the firewall to allow in a nasty backdoor, put data in the padding to give it the same hash as before, and put it out on a BitTorrent site for hundreds of unsuspecting geeks to download. The signature verifies fine, so it must be OK, right?

Re:Should We Fear?

This is step 3, which he mentioned:

"The next step is MANIPULATING, i.e. adding junk to a given binary file to allow you to choose the cheksum. that's the scary one!"

Fortunatly manipulating a file to have the checksum you want is a hell of a lot more difficult than finding a colision between two bits of random data which don't need to match any format or rules.

Really, really no.

If there is a fundamental flaw in the hash algorithm itself, simply using it more often will probably not solve the problem.

It absolutely is incredibly hard to make an encryption algorithm more secure. Just "doing some math with the hashes" is the type of bit-twiddling at which cryptologists both wince and sneer. "Then I'll multiply the second one by three, then add them together! Then modulo it 17! Then oohoohooh, square root the whole thing and drop the first digit! No one will _ever_ figure this out!" Crap like this does not add any new cryptographic strength, just a dependency on a secret algorithm. And any method which relies on a secret algorithm is hopelessly flawed.

There is still considerable debate in the cryptographic community about whether 3des is actually any stronger than des. Many people feel that if an attack is found to be effective against the des algorithm, the extra layers of stirring the bits around will not make the plaintext any more secure.

I'm afraid that Schneier covered this succinctly: "Anyone who creates his or her own cryptographic primitive is either a genius or a fool. Given the genius/fool ratio for our species, the odds aren't very good."

Re:Should We Fear?

But CRC32 is not a cryptographic hash, and is not designed to make it difficult to find a collision. CRC32 is in the same class as checksums, and is designed to catch errors introduced by transmission or storage. It's not just "more complex on MD5s" in the way that CRC32 is "more complex" than a checksum; it's an entirely different class of problem.

It means we all have to carry a midget around

Yep -- that's right. I'm not a crypto expert. Hell -- I'm a layman compared to most /.'ers, and my user number proves it (all 7 embarrassing digits of it). But I do know this -- if Slashdot crypto geeks are concerned about it, then we've reached the point of...

CARRYING A MIDGET AROUND.

Yes, it's true. Every person with encrypted data on Earth will soon have to carry around a Level 10 Anthromorphic Hexidecimal Midget Encryption System. Or "Midget Key" for short. The midget will become part of every computer purchase where the user requires high encryption, secured communications, etc. Families without sufficient room to accommodate and feed the midget will have to run computers with the old and vulnerable encryption technologies.

Meanwhile, those of us with a Midget Key will need to have his/her encryption midget with us at all times. The midget will encrypt data locally by locking a portable hard drive to his/her wrist and preventing anyone OTHER THAN THE OWNER of said local data from accessing it again. To facilitate this local midget encryption, each encryption midget will be equipped with:

- body armor
- handgun
- lightweight sub-machine gun
- tactical nuclear or convential explosive self destruct device

Addtionally, each encryption midget will be required to communicate with all other encryption midgets around the world using special genetically encoded phones that cannot be replicated outside of the midget gene pool. The phone will be surgically embedded in the arm of each encryption midget and require a drop of said midget's body temperature saliva to activate the phone (a.k.a. spit on the arm to make the call).

Why encryption midgets? They're:

- portable
- eat less than an encryption giant and/or an encryption obese person
- tough as nails

Why tough as nails? If you've watched The Amazing Race at all this season on CBS, you have witnessed a midget drag her whiney, lazy cousin around the world. She has become the envy of other teams featuring health nuts, ex-Marines, and super-Christians. Who wouldn't entrust their data with a badass little person that can grab a live electrified cattle fence somewhere in South America, cuss about it, and STILL manage to continue the race?

Get me THAT encryption midget, and you'll never get a hold of MY data!

IronChefMorimoto

[Note -- if the midget from the show mentioned above has been eliminated from said show, then our data is doomed. I've missed the last several episodes, so all may be lost.]

Re:It means we all have to carry a midget around

I only see 6 digits in your ID, maybe your hash was cracked.

Re:It means we all have to carry a midget around

It's better then my encryption dog. That system was broken with a raw DEADBEEF attack. Lousy mutt.

Re:Should We Fear?

Here is the significance of this story:

The proof that they have computed two values that have the same hash is significant because it proves that it is computationally feasible with today's computing resources to calculate a second different string or dataset that hashes to the same value as the original. It shows that a md5 hash can be "faked" or duplicated using current computing power. There is nothing significant about the values themselves presented in the story just that such values can now be theoretically found in a reasonable amount of time using available resources.

Why this is a bad thing:
Say I sign a program using md5. An attacker writes his own different program and appends some gibberish data in such a way that the two files are different but have the same md5 hash. There is now no way (using md5) to tell the two programs apart. (Of course the programs would have to be similar in other ways, size etc... for the spoof to work.) This same thing could be used to calculate new passwords for md5 hashes that are known to the attacker.

Why should we not panic: It took a long time to find the collision. Chances are a script kiddie wont be able calculate such hashes to crack into your site. But it show that banks or other highly confidential data stores should now look elsewhere for their hashing needs. (Which they probably already do).

Strater

Re:Don't the laws of computing make it...

And since processors are supposed to double their speed every 18 months, I guess that cracking ability will follow the same trend. Scary...

Not really...nobody expects this trend in processing performance to continue forever. There are in fact provable limitations given things such as the number of atoms available in the universe that can be harnessed for computation... ignoring little details like quantum computation and such :-). These limitations may seem "out there" but in fact they aren't nearly as unrealistic as you might think. Exponentials grow FAST.

It's trivial to continue scaling the computing requirements required to break encryption schemes by simply adding more bits. That is, assuming the encryption/hash scheme itself doesn't have some fatal flaw which may allow for a sub-exponential cracking algorithm.

Re:Don't the laws of computing make it...

Also, with using individual atoms for computing, whilst it would be nice, it's also impossible(?) - given that the more accurately you try to measure one property of an atom, the less accurately you can measure it's other properties. There's a name for this, but I can't remember.

It's the Heisenburg uncertainty principle, and it doesn't rule out computing with individual atoms. It just means that computing with individual atoms will work a lot differently than it does with normal, mostly deterministic electronics. The field of quantum computing is all about exploiting the weird quantum properties of atoms to do even more computation than would be possible if they were completely deterministic little point particles.

Re:Don't the laws of computing make it...

That's a common misconception.

In fact, advances in computer speed tend to favor people encrypting data, rather than those trying to decrypt it. For example, increasing CPU speed by a factor of four or five will generally allow you to use a key two or three times as large, and still get the same performance. However, it definitely won't let you crack a key twice as large.

Suppose your faster CPU inspires you to move from 128-bit keys to 256-bit. What happens to the guy trying to decrypt your message? He now has to work 68,056,473,384,187,692,692,674,921,486,354,000,000 times as long, even if he buys the 5x faster CPU. Ouch!

Re:Don't the laws of computing make it...

Indeed, here's [timmerca.com] another novel argument from Bruce Schneier's book....

in regards to the strength of 256-bit encryption:

now, the annual energy output of our sun is about 121 * 10^41 ergs. this is enough to power about 2.7 * 10^56 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. if we build a dyson sphere around the sun and captured all of its energy output for 32 years, without any loss, we should power a computer to count up to 2 ^ 192. of course, it wouldn't have the energy left over to perform any useful calculations with this counter.

but that's just one star, and a measly one at that. a typical supernova releases something like 10^51 ergs. (about a hundred times as much energy would be released in the form of neutrinos, but i let them go for now.) if all this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.

these numbers have nothing to do with the technology of the devices; they are the maximum that thermodynamics will allow. and they strongly imply that brute-force attracks against 256-bit keys will be infeasable until computers are built from something other than matter and occupy something other than space.

bruce schneier, applied cryptography, p 158

Re:Don't the laws of computing make it...

Phleg [slashdot.org] wrote [slashdot.org]:

Think about that. It is impossible, by our current knowledge of physics, to count up to nothing more than a 256-digit number...

Want something that will really blow your mind? Think about this: your computer monitor can display anything someone can take a picture of with a digital camera. Anything that is visible, can have its picture taken and thus can be displayed in your 1024x768 32-bit color monitor.

Now, one would normally think that there is an infinite number of possible pictures that one can take in our universe. Heck, just using a paper clip on a table could result in thousands of unique pictures considering the different angles, lighting, etc. Every situation, every person, place or thing you see during your lifetime could have its picture taken and displayed on that monitor! The near-infinite amount of photos that could be displayed on your computer monitor would encompass every visible event from the past, things going on right now, and events in the future. Some of these photos would be real, most would not be.

Above, I assume our computer monitor is 1024x768 & 32-bit color. To see all these pictures -- here & now, in the future on Mars, in a pretend past where Julius Caesar isn't murdered -- all one needs to do is program their computer to serially go through every pixel & color combination. Although it would take a very, very, very long time, eventually every pixel & color combination will be shown, thus showing everything that can ever be seen. A photograph of everything that could ever be seen, and even many situations that didn't/won't happen will be shown on that computer monitor. EVERYTHING.

Of course, many more times that in just random pixels & colors will be shown, too.

Re:Don't the laws of computing make it...

Some quick numbers on this:

First let's start with something that might return some "sensible" (i.e. not ridiculously high) numbers. On the Apple II, Basic programmers had access to an incredibly low resolution mode with 40x40 pixels and 16 colors. Assuming we only use 2 colors (say, black and white), there are:

2^(40*40) = 4.44 x 10^481 possible screen images.

Whew! Already far beyond the 2^256 limit discussed. But out of curiosity, we can look at some other numbers. Using the full 16-color support of this low-res mode:

16^(40*40) = 3.90 x 10^1926

How many possible terminal screens are there, assuming only alphanumeric (and space) characters?

(26+26+10+1)^(80*24) = 5.41 x 10^3454

And some other modes of interest:

320 x 200, 2 colors: 8.31 x 10^19265
320 x 200, 256 colors: 2.27 x 10^154127
640 x 480, 256 colors: 2.07 x 10^739811

After this, direct computation was far too slow, but we can get rough estimates:

640 x 480, 16-bit color:
640*480*log10(65536) = 10^1,479,622

800 x 600, 16-bit color:
800*600*log10(65536) = 10^2311910

1024 x 768, 16-bit color: 10^3787833

And finally...

1024 x 768, 32-bit color: 10^7575677

Yep, a 1 with 7.5 million zeroes behind it. So we may all have to wait awhile before we see a computer sequentially generate a picture of alternate post-Caesar Earth. Still, an interesting thought.

Re:Don't the laws of computing make it...

Ummm... 1024x768x32bit = 25165824 bits. Cycling through these bits is exactly equivalent to the "counting up" problem you're responding to. Since we've already established we can't count that high, there's no danger anyone is ever going to show you ever possible picture. Given the thousands of possible variations of goatse guy, this is probably a good thing.

What should make you feel small is that physicist have figured out a way to count all the possible states for a particular volume of matter (assuming an upper bound on temperature, if that makes any difference). That means the entirety of the observable universe has only a finite number of possible states.

If the unobservable universe is infinite, and if states are distributed probabilistically (and why wouldn't they be?), that means that your hypothetical world where Julius Caesar wasn't murdered actually exists, out there, somewhere, far out of reach.

Re:Don't the laws of computing make it...

but it assumes something which is impossible, that is, perfect algorithms.

No, it doesn't. Schneier is discussing the computational complexity of scanning a uniform keyspace, which depends only on key size and doesn't touch on algorithmic quality in the slightest. Now, if he were talking about the security of 256-bit ciphers against any attack, rather than just against brute force, then the quality of the algorithm would indeed be important.

Re:Don't the laws of computing make it...

Indeed, here's another novel argument from Bruce Schneier's book.... in regards to the strength of 256-bit encryption: now, the annual energy output of our sun is about 121 * 10^41 ergs. this is enough to power about 2.7 * 10^56 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. if we build a dyson sphere around the sun and captured all of its energy output for 32 years, without any loss, we should power a computer to count up to 2 ^ 192. of course, it wouldn't have the energy left over to perform any useful calculations with this counter.

That is an erroneous conclusion based upon the (incorrect) assumption that a small amount of energy (kT) must be dissipated for each elementary computational step. If the computation is carried out using a reversible (classical) computer, this is not the case. Thermodynamics does not place any such restriction on computation. On the other hand, quantum mechanics does place constraints on the speed of a classical computer.
For more fun see Ultimate physical limits to computation [arxiv.org] by Seth Lloyd

Re:Don't the laws of computing make it...

This is all true. However, you have to think about how long you need to keep something a secret. Let's say for the sake of argument that you confessed to a murder and encrypted it with single-DES in 1979. Anyone who got a hold of an intercept of it between then and now has evidence of a felony with no statute of limitations. Single-DES has been practically crackable by brute force since at least the mid-90s.

More realistically, what if the subject of the communication was a long standing bank account or evidence of a government scandal?

Advances in computing power can work for attackers who stand to profit from a long-delayed payoff. Advances in quantum computing will lower the expiration date of protection for anything you encrypted in the past even more. The further in the past the ciphertext was made, the weaker it gets. This will be generally true for any arbitrary past date and future date. No ciphertext can be considered indefinitely secure. We can only assume that reasonable protection only exists for the short-to-medium term.

Fairly long OTP messages may be one exception.

Re:Don't the laws of computing make it...

We can only assume that reasonable protection only exists for the short-to-medium term.

Fairly long OTP messages may be one exception.

Actually, all OTP messages are an exception. For every plaintext P and ciphertext C, there is a key K, such that an OTP of P with K will product C. Hence, if you try all possible keys on a ciphertext of length l, you'll find all possible plaintexts of length l. So, if you have a ciphertext of length 3, then there are keys for "bad", "moo", "can", "has", "aaa", "bbb", "ccc", etc., etc. There's no way for you to know what the original was.

Re:Don't the laws of computing make it...

Longer strings make isolating the correct original easier, as there are fewer possible correct permutations according to syntax and context (which you know or have an idea of).

But it's not enough, because you still can't tell which variation is correct. E.g. a 19 character message can be decoded as both:
"I killed John Smith"
"I did not kill John"
There is no way to tell which is the real plaintext. Since every single 19 character sequence will appear, every 19 character English sentence and every 19 character sentence in every other language that uses the same character set needs to be checked. You can eliminate as many garbage results as you like, there'll still be a huge number of non-garbage results that you have no way of choosing between. In fact, you might as well not even look at the cipher text - it can tell you nothing. Just enumerate all 19 character sentences and work from there.

Re:Don't the laws of computing make it...

You're so wrong it's funny :)

Sorry, didn't mean to mock, it's just amusing whenever these one-time pad things come up and everyone starts jumping up and down yelling "unbreakable" and others start going "no, 'cos, like, we could brute-force it.."

You can't brute-force a one-time pad. That's the point. There are many weaknesses to OTP, related to key exchange, but you can't brute force it, because you have no way of knowing if you're right, or even if you're close. The possible set of plaintexts from a properly OTP encrypted message is the complete set of possible plaintexts of that size (or smaller, plausibly).

Let us take the following ciphertext:

aaa

I have encrypted this with a one time pad. Now, it's a pretty short message. We could brute force all the possible combinations on your regular computer pretty much instantly. Anyone care to guess what the message might be?

Of course not, because it could be *any* 3 letter combination, assuming that I'm sticking to letters. Any attempt to contextually analyse it is flawed because you will never be able to prove you got it right. Let's say that we know the message is english, and we can therefore reduce the number of possibilities down to all 3 letter english words.

Woohoo. It doesn't help, it doesn't get us any closer to knowing exactly what it is, because there is no next step, the only information that can aid us in the decryption of a one time pad is information from "outside" the decryption. In this case, two items of information are available to us, the length (3 letters) and the fact that it is english, but the actual ciphertext itself is of no value whatsoever. It doesn't matter if those a's were z's or q's or anything else, we can't do anything with them unless we have the OTP.

"Decrypt candidates with "bad" and "moo" in them would definitely merit further analysis"

This is always the point where things go wrong :) there *is* no further analysis you can make. lets take the following:

abskjhsglkjlssdkglkjsfdlkgjfld

Now lets imagine that we knew it was coming from bank robbers. Sweet, so, what can we do? again, the *only* information we have is the length. It could say this:

I am going to rob a bank in WA

Or this:

I am going to rob a bank in CA

Or this:

I am going to rob a bank in NZ

And there is no way to prove what it actually says at all. It might say:

I am going to buy some flowers

Again, you'll never know unless you have the key, there's just no way to tell.

Re:Don't the laws of computing make it...

This shows a fundamental misunderstanding of OTPs. Any message of n bits could be encoded as any other message of n bits. Even your "natural language parser" doesn't help. Take an arbitrary "short" message: "A". It is equally likely that it could decode to "I" or "A" or "Z" or any other 1 character string. It doesn't matter if you know what I'm talking about.

OTPs are provably secure, as long as the key isn't compromised, e.g. by reusing it....

Here is a good link that answers the question: Why Are One-Time Pads Perfectly Secure? [std.com]

-a

Re:Don't the laws of computing make it...

No, it's the OTP key that needs to be random. The main problems with OTP are that the key needs to be as long as the message, can only be used once, and a secure channel is needed to distribute the key.

If you do OTP right, it is unbreakable* because the only possible attack is to brute force it by trying every possible key, and trying every possible key on an n character cyphertext gives you every possible n character plaintext, with no way of telling which one is right. (That is, if you had the 16 character cyphertext "bhgisngukfgxd gyt" you would get all possible 16 character strings as possible plaintexts, including "attack US friday", "shoot Osama soon" and "I like chocolate", and you would have no way to tell which was the actual plaintext.)


*except for rubber-hosing, but that affects all crypto systems, and is a weakness of the people involved, not the crypto.

Re:Don't the laws of computing make it...

When used properly, One Time Pad is impossible to break. Of course, carrying around enough truely random characters/bytes for all of your encrypting needs without getting caught is another story. And humans are notoriously good at not following directions properly....

Re:Don't the laws of computing make it...

Not really, because you could still guess what the pad is on your first shot. It's not likely, but its not "impossible".

The beauty of the OTP is that it doesn't matter if you guess what the pad is - you can't tell you've got it rigbt.

Given a cyphertext of length 9, there are keys that will decrypt it to read "Kill Bush", "Save Bush", "FuckOsama", "Bomb Iraq", "Love Boat", "qwertyuio", "!@#3fst9$-", and every other 9 character string. Since the OTP is random, all these keys have equal probability of being the correct one.

Re:Don't the laws of computing make it...

When used properly, One Time Pad is impossible to break. Of course, carrying around enough truely random characters/bytes for all of your encr