Slashdot Mirror

Or, get it for free from the IACR.

Yes, the Linux random number generator was vulnerable in the past too. See e.g. http://eprint.iacr.org/2006/086.pdf

This article refers to this summary of this paper

I fail to see why you would need administative privelidges however. You would only need to run in the userspace of the process that did run the random number generator before. Having administrative privs would be nice to inject code into that userspace, but is not needed i think.

It can get even worse if from a public key part the random number that was used to generate it can be extracted, what was done in early ssl implementation attacks.

"This situation shows one of the strongest arguments for open source."

But everyone should also bear in mind that that argument also has limits. In TFA, you see a reference to Linux having problems with it's PRNG. That was a semi-big deal a couple of years ago. From that reference (http://eprint.iacr.org/2006/086.pdf, for your convenience)"

"Why reverse-engineering the LRNG is not easy. The LRNG is part of an open source project and therefore one might assume that its source code is available for public scrutiny and that its security can be easily analyzed (or at least, is not based on security by obscurity). However, the LRNG is not well documented and there is no clear description of the implemented algorithm. The LRNG is composed of about 2500 lines of code, and in addition, hundreds of code patches were applied to the code during the last ve years (and consequently, the available documentation does not always reect the current code). One example of the complexity of the LRNG code is the fact that for 17 months the LRNG code included a bug in which entropy addition used a vector of size 4 × n instead of n. We also note that throughout our analysis we were not helped by any of the LRNG authors."

That last sentence was overly harsh. The LKML thread is at: http://marc.info/?l=linux-kernel&m=114772953214912&w=2
Posts from Ted T'so in that thread cover his design thoughts, etc. Interesting read. I remember looking at that code, back when, and thinking, WTF? So yes, it's Open Source. OTOH, it was very much a WTF moment.

Then early this month, another PRNG flaw was found on kernels before 6.2.22. I guess I should drag the code back out, have another look, and hope that it's now been cleaned up. A *lot*.

So, I'm right there with you on your "Trust no one" comment. I wouldn't personally run, or professionally deploy, anything but Open Source, except firmware that I can't avoid, and a couple of binary blob drivers I have installed on a home workstation. And I don't like even that.

But I hope there aren't newbies out there thinking this Open Source thing is a panacea. It's a lot better than binaries-only, as witness the huge problem with Win2k's PRNG also published (by almost the same crowd as the paper above) back around the beginning of the month, and which has quite possibly been around since the release of the OS. http://eprint.iacr.org/2007/419.pdf But it's not a panacea.

Jeez, what is it with PRNGs this month?

In my final year in CS, I wrote a lengthy paper researching various DRBGs. To my surprise, there were very few good candidates for cryptographic DRBGs, but of the 7 I looked at, Dual_EC_DRBG rated the worst. I was unable to find any theoretic proofs for Dual_EC_DRBG, but I did find a few papers exposing serious flaws in Dual_EC_DRBG including this one which describes a tractable distinguisher so efficient it can run on a modest desktop.

The other three DRBGs recommended by NIST were all reliant on the security of various other cryptographic primitives such as SHA (Hash_DRBG), HMAC (HMAC_DRBG - which is often based on SHA) and AES or 3DES (CRT_DRBG). They were all reasonably obvious, and only really tried to set out some sort of standard for jumbling the output of their respective primitives enough that they would be resilient to any unknown vulnerabilities in said primitives (though certain paths also failed to do this). This was mostly accomplished by calling the primitives several times (HMAC_DRBG with the NIST HMAC implementation called for 6 SHA hashes per SHA sized output) which isn't very efficient.

I suspect they only included Dual_EC_DRBG because it wouldn't have looked too good if they were unable to come up with a single number theoretic or otherwise novel DRBG. They shouldn't be too disappointed, however, as the only one I was able to find was Blum Blum Shub which is terribly inefficient. CryptMT (Cryptanalysis) also deserves a mention as it looks like a promising pseudo-number theoretic DRBG, at least a better candidate than Dual_EC_DRBG.

In my final year in CS, I wrote a lengthy paper researching various DRBGs. To my surprise, there were very few good candidates for cryptographic DRBGs, but of the 7 I looked at, Dual_EC_DRBG rated the worst. I was unable to find any theoretic proofs for Dual_EC_DRBG, but I did find a few papers exposing serious flaws in Dual_EC_DRBG including this one which describes a tractable distinguisher so efficient it can run on a modest desktop.

The other three DRBGs recommended by NIST were all reliant on the security of various other cryptographic primitives such as SHA (Hash_DRBG), HMAC (HMAC_DRBG - which is often based on SHA) and AES or 3DES (CRT_DRBG). They were all reasonably obvious, and only really tried to set out some sort of standard for jumbling the output of their respective primitives enough that they would be resilient to any unknown vulnerabilities in said primitives (though certain paths also failed to do this). This was mostly accomplished by calling the primitives several times (HMAC_DRBG with the NIST HMAC implementation called for 6 SHA hashes per SHA sized output) which isn't very efficient.

I suspect they only included Dual_EC_DRBG because it wouldn't have looked too good if they were unable to come up with a single number theoretic or otherwise novel DRBG. They shouldn't be too disappointed, however, as the only one I was able to find was Blum Blum Shub which is terribly inefficient. CryptMT (Cryptanalysis) also deserves a mention as it looks like a promising pseudo-number theoretic DRBG, at least a better candidate than Dual_EC_DRBG.

Speaking of security, Office does have a nice feature where you can encrypt sensitive files before sending them out of the office to prevent your data being read by nefarious third-parties.

Does OpenOffice have anything of the sort?

I can guarantee if you go to a professional writer and ask:

Which would you rather have?
A) An outline view where you can instantly re-order your work, including notes and references?
B) A slightly more open document format?

There isn't a single one who's going to answer B.

Quickly, before Cringely ruins it with bad math, I need to point out some very obvious weaknesses in making this work correctly:

• SHA-1 has been (somewhat) broken. Not highly repeatable yet, but they're getting there.
• Encryption does not hide a message forever. Most of us picked up on that in one form or another. It just hides it long enough to make the information useless. If I can only break a single machine 6 years after it was written, the video isn't going to be very useful to me.
• Good encryption methods assume two things. One is the attacker does not have the key. Smart card attacks have shown (PDF) that even though an attacker has to guess the key, a poor implementation may provide useful hints during the guessing phase.
• The second assumption is that the message is not highly predicatable. Disk drives are known for having highly-predicable components on them which makes finding the plaintext all that easier.
• These folks are so cocky about SHA-1's entropy space, they claim "there is no need to abort the authentication process from a specific host. For example, there is no need to abort the authentication process if a specific host generates three wrong passwords. " Zeroization is the only way to do this right. You can also vary this so that after three failures, an automatic delay is introduced to slow down the guessing.
• Reading the patent text indicates that new "commands" will be added. No mention of a bus protocol (ATA or SCSI) is mentioned. Presumably, they won't make the drives themselves, so it will need standardized. The hard drive community is open to using patents, but only if the terms are reasonable or a cross-licensing deal is in the works. If this is a forced attempt, it will fail miserably or cost so much that the drives will be considered custom, low-volume, high-cost components.
• The likelihood of them screwing the implementation up are so high, they should pursue FIPS 140-1 certification for every hard drive made. Then, the patent can apply outside the domain of Tivo.
• This scheme works better as a general hard drive protection measure than for a Tivo. People who own a Tivo might probe the memory chips for the crypographic module to sweep for the drive or system keys. AACS recent events ought to make it obvious that people are motivated to do this. The general case may prevent a lost hard drive from being very useful.
• It would appear that the cryptographic module does NOT actually encrypt data on the platters. It seems to only cover communication between the host and the disk controller. If an attacker were to replace the circuit board with one whose path was trusted, they could read the platters without issue. They do this all the time in the hard drive repair business; no clean room required.

Okay, you all can go back to your regularly scheduled cheap shots.

Can anyone confirm any of this? I find it interesting that while the paper was published today, it was received on April 1st.

See: http://eprint.iacr.org/2007/120

This paper
http://eprint.iacr.org/2006/086.pdf
includes a section on openwrt and basically claims that you shouldn't trust it to provide good random numbers (and hence good network crypto security) because it doesn't have any of the standard sources of entropy (keyboard, mouse, harddrive) that linux servers have. Of course, it will likely be no worse than the standard firmware but that isn't really the point here.

There are researches directed toward post quantum cryptography, to find asymmetric cryptography resistent to quantum computer, you can google for post quantum cryptography or look here:

http://postquantum.cr.yp.to/

or here:

http://eprint.iacr.org/2004/297.pdf

Perhaps, yes. However, "perhaps", someone will just guess the correct key after brute-forcing only 25% of the full keyspace (there's a 1 in 4 chance of it). "Perhaps" someone will figure out how to quickly perform prime factorization. "Perhaps" someone will build a quantum computer.

You don't really know what capabilities an attacker is going to have. You can't know absolutely, because you're designing a system today that needs to be secure against tomorrow's attacks. As the saying goes, "attacks only get better; they never get worse".

What you do know is that the more complex a system is, the more likely it is to be vulnerable to attack. Perhaps your rot13 function will be nicely exploitable by some side-channel attack. Take a look at a recent result, Simple Branch Prediction Analysis. If your nifty new rot13 function had been written and deployed 2 years ago, before this attack had been published, would your implementation have been secure against it? If not, would you at least be able to say that the added complexity was worth the added risk?

My opinion is that the negligible increase in security (between 0 and 1 bits of added security) isn't worth the risk that the added complexity brings. There are better-understood ways of adding one bit of security to a system. Furthermore, if you think you need one more bit of security, you should probably add a much larger safety margin, like 50% or 100% or 200% more bits of security.

Crypto experts routinely have their own systems broken. How do you honestly think you will fare?

If it's non-acedemic (sic) to crack an MD5 hash, please tell me the plaintext for this: f6540dee6b248c863bb90fcaa784fef9

The term "plaintext" has no meaning for cryptographic hashes. The point of the attack is, if you had some text that hashed to say, f6540dee6b248c863bb90fcaa784fef9, I could, with even less work than I initially gathered, generate another set of data, saying something completely different, which also hashes to the same value. This has severe implications in the field of digital signatures, as the way most digital signature algorithms work is as follows:

1. Generate the hash of the document to be signed.
2. Encrypt the hash using the signer's private key.
3. The encrypted hash is the document's digital signature.

Now, if I wanted to verify the signed document:

1. Generate the hash of the document to be signed.
2. Decrypt the digital signature using the signer's public key.
3. Compare the computed hash with the hash recovered by decrypting the digital signature. If they match, the document is supposed to be authentic.

See the central role that hash functions play in this scheme? Now, if I'm able to generate collisions for the hash with a feasible amount of work, then given any digital signature you make using MD5 as the base hash I can create another document that might say something quite different, and attach the digital signature of the initial document to it, and it will look to anyone who cares as though you signed it. Of course, the document might look slightly strange to a person looking at it, but if the signature were used as part of a more complex cryptographic protocol, where only a computer ever really sees it, or if it's a document in a complicated file format (e.g. PostScript) that provides some leeway to add arbitrary data that is ignored by the viewer, then we might be in a spot of serious trouble. These collisions for MD5 are not just harmless, theoretical curiosities as you seem to think, as the page on X.509 certs and the PostScript examples illustrate.

The fact that collisions can be computed also destroys the non-repudiation characteristic of digital signatures. If this is important for your application, continued use of a weak hash function like MD5 is certainly out of the question, as the ability to generate collisions gives the alleged sender of a signed document a valid excuse to plausibly deny that she ever sent it. This of course makes MD5 digital signatures worthless from a legal standpoint.

Fortunately most people and began phasing out the use of MD5 for these and similar applications over the past several years, as it was already long suspected to harbor significant weaknesses. Now, we're hearing similar news about SHA-1 as what we heard about MD5 since roughly 1996, when cryptographers began recommending that alternative algorithms be used. Now, we're hearing the same thing again about SHA-1, and I think it would be wise to heed the advice again and start migrating to better hash functions as soon as possible.

I just happen to have been doing some research in a closely related subject, the new passports.

If you want information from the industry side, go look at: Smart Card Alliance. They provide a wealth of information on the subject.
There is also a paper on "contactless" smartcard security.

From the other side, you can read the paper on "Relay Attacks" by Kfir and Wool.
There is also a piece in the New York Times.

Most credit card companies are going to be coming out with these cards. This is what the MasterCard PayPass commercials are about. The main issues will be with the way the individual banks implement security. They aren't supposed to transmit your name, or provide the number from your card. What you are hearing about are the situations where the security wasn't implemented. I'm not saying there aren't concerns.

My question is what is going to happen when we have three of these cards in our wallet and we go to pay. Do we get prompted for which one to use? On a further note. It looks like they want to put the chip in your cell phone and you would be able to select your method of payment from your phone.

Also a spy process is executed simultaneously with the
cipher and it continuously does the following:

1. continuously executes a number of branches, and
   
2. easures the overall execution time of all its branches
   

in such a way that all of these branches map to the same BTB set which also stores the
specific conditional branch determined by the secret key bits of the crypto process. This
requires that the number of branches in the spy process needs to be equal to the associativity
of the underlying BTB, i.e., to its number of ways. Recall that it is easy to understand the
properties of the BTB using simple benchmarks as explained in [MMK].
Let's analyze what's happening if the adversary starts the spy process before the cipher.
It simply means that when the cipher starts the encryption (= signing), the CPU cannot find
the target address of the target branch in the BTB and the prediction must be not-taken, cf.
[She]. Furthermore, we can distinguish two cases depending on the currently processed secret
key bit:

• If the branch turns out to be taken, then a misprediction will occur and the target address
  of the branch needs to be stored in BTB. Then, one of the spy branches has to be evicted
  from the BTB so that the new target address can be stored in. When the spy-process
  re-executes its branches, it will encounter a misprediction on the branch that has just
  been evicted. As the spy-process also measures the execution time of all its branches, it
  can simply detect whenever the cipher modified the BTB, meaning that the execution
  time of these spy branches takes a little longer than usual.
  
• If the branch turns out to be not taken, then no misprediction will occur and the BTB
  does not need to be updated. When the spy-process re-executes its branches, measures
  the execution time of all its branches, it can simply infer that the cipher had not modified
  the BTB, and the target branch was not taken by the crypto process.
  

Thus, the adversary can simply determine the complete execution flow of the cipher
process by continuously performing the above very simple spy strategy, i.e., just executing
spy branches and measuring their overall execution time. Therefore, the spy process will see
the complete prediction/misprediction trace of the target branch, and is able to infer the
secret key. Following [OST06], this kind of attack was named an asynchronous attack, as the
adversary-process needs no synchronization at all with the simultaneous crypto process --
it is just following his own paradigm: continuously execute spy branches and measure their
overall execution time.

This would be quite surprising to me. It is true that you can copy any personal detail you want into these cards.

But besides some personal details passports are also supposed to have a secret in them that gets proved without revealing it. The article makes no mention of it. Its called "active authentication", RSA labs has been writing about it for years. The US and many others are supposed to require it. IIRC it is done by having the passport sign a challenge with a secret key or something like that.

The only way to get to a secret in the chip would be to really mess with the chip, acids, electron microscopes, side channels, the article mention just "reading" it.

The RFID tag is supposed to tamper resistant. That is, it is supposed to forget whatever secrets it holds if it detects any attempt to tamper with the chip. One manufacturer advertises with voltage, frequency, temperature and light sensors.

Philips also appears quite serious about preventing side channel analysis attacks as well.

Now I have the impression that the whole point of standardizing on complex contactless cards was to keep little players out of the market. (RFID is covered by several patents and hard to implement power efficiently without serious fabrication facilities) The only excuse I heard for requiring contactless cards was that it somehow saved time standardizing the readers....

This is why I would expect other big manufacturers to have done their homework as well.

Is there a chance this attack only clones the parts that are supposed to be readily accessible? Fooling a reader without the "active authentication" is easy. And since a reader would need a government public key I guess getting a reader with it would be a little harder than just buying one.

(Also the Basic Access Control feature sucks. With moderate computing power you can understand the communication between passport and reader at an airport without seeing the passport.)

Snap! Ok, here are a few.

RFID Door
RFID board
Instructions on building an extended range reader

[Please mod my previous reply down. It's botched.]

There is some information about the algorithms they're using here. That page says that they're using 1024-bit DH to negotiate a 128-bit AES key, then they XOR the output of the AES algorithm with the voice data.

Frankly, I don't trust it.

First of all, neither 1024-bit DH nor 128-bit AES actually give you 128-bit security (i.e. 2^128 complexity). For AES, you need at least 256 bits of key material to get 128 bits of security. I don't know specifically about Diffie-Hellman, but it's similar in structure to RSA, and experts have been recommending at least 2048-bit keys for new designs using RSA for years, and that's not even to get a 128-bit security level. For a true 128-bit security level, you need something like 6100 bits (if I remember correctly), which most people don't use because it's very slow to do in software.

The "XOR" part of the description, while somewhat scary-sounding, might actually be counter mode, which is considered secure for AES and is actually recommended by Bruce Schneier in his book, Practical Cryptography. Or, it might just be XORing the output of a single repeating AES ciphertext block with the entire plaintext datastream, which would be trivially insecure. We really have no way of knowing.

As for authentication, which is often more important than confidentiality (and which may be required for confidentiality)? This is all I could find:

Additional security and integrity is ensured by a calculated HASH checksum that is indicated on the display.

There is no mention of what hash function is being used, nor of what is being hashed. Furthermore, people who talk about "HASH" -- in all-caps, as if HASH is an algorithm itself -- clearly don't know what they're doing. It might just be Vecrotel's marketing department messing things up. Or, it could be a more fundamental lack of expertise within the company. Who knows?

Have a look at the Vecrotel FAQ:

VECTROTEL IS BASED ON WHICH SW PLATFORM? IS THERE A SECURITY RISK?
The software is proprietary. There is no security risk.

...

KNOWING AND CHECKING THE SOURCE CODE IS VERY IMPORTANT. IS EVERYBODY ABLE TO REVIEW THIS SOURCE CODE?
No, we do not release the source code. Too much know-how would be at stake.

Totally unacceptable.

If those really are "frequently-asked questions", those responses are simply arrogant. The company has clearly adopted a "trust us" mentality. If I was willing to blindly trust other companies, I wouldn't be looking for a secure phone!

Crypto products are like voting machines. If their operation is not independently verifiable, then they simply cannot be trusted.

As an interesting side note, I don't see any FIPS certifications.

I smell snake oil.

I doubt it. I think the dozen or so Mac users I know are more typical than these supposed IT-experts the poster mentioned.

Have you been to many conferences or universities lately?
Hell, last year at Crypto, nearly half the laptops in the audience were Apples (as was the machine that they used to record and stream the rump session talks). And I know that a good portion (about 60% last time I noticed) of this group use Apples as their standard machines.

Methinks you need to get out more.

How often do Apple market at the technologically savvy?

All the time?. Well, not on TV, but they have touted its unixesque abilities in a number of print ads.

This is just the perfect story for me to plug my latest research, a couple of crypto protocols to help ensure P2P users behave honestly when uploading and storage rewards of some kind are involved, and there exists the incentive to cheat. Hope someone puts them to good use.

That's why I'm reading the paper these guy published. Scholar.google.com provided listed it first; The IACR's e-print archive is kind enough to supply the full postscript document...

What about this?
hash = MD5(secretstring.input)

This doesn't work. Because the MD5 attack is basically what we call a "free-start collision". In other words, whatever is your "secretstring", it will not prevent attackers from finding collisions. See the researchers' paper for more info http://eprint.iacr.org/2004/199.pdf.

Your first paragraph shows your complete lack of understanding.

First off ... I DO develop algorithms and perform research.

Second ... There is more to a secure cryptosystem than just "coding". Cryptographers are responsible to glue the entire system together.

By your logic a bridge engineer must develop new design concepts before he's an engineer. Otherwise he's a lowly construction grunt. I'd like to think the person who designs a bridge to withstand nature, loads, etc is more than a tool swinging grunt.

Third ... There is more to developing than just "coding". You have to know what algorithms to use and when/why. You have to be able to work with them with the utmost flexibility [e.g. you don't always get ideal situations, etc].

As to the whole FPGA vs. ASIC vs. whatever.

I may have mispoken but I know of designs that use FPGAs in fielded products, for example this is one. In things like gameboys and what not they use ASICs but they also produce MILLIONS of gameboys.

In short runs it's actually cheaper to plug in a small FPGA then get real ASICs made. If you think otherwise it's because you're a fucking moron and you have no clue whatsoever.

Tom

The passports have several protections to prevent unauthrized transmittal of data. These include a cover that blocks radio waves and Basic Access Control. These measures are not perfect and a /. debate over them would be useful. You can learn more about the shortcomings at:
http://eprint.iacr.org/2005/095.pdf

I am going to repeat myself here. Let's have a debate about the technology that is going into these passports and not the RFID boogeyman that isn't going into them.

If you add a man-in-the-middle to this, you get a nice way of proving SOMEBODY is standing next to the tag, even though the tag is nowhere near the door. This means I can stalk you in the supermarket while my accomplice breaks into your house.

http://eprint.iacr.org/2005/052

In the paper 'picking virtual pockets using relay attacks on contactless smartcard systems' by Avishai Wool and Ziv Kfir, it has been shown that a simple relay attack on RFIDs is feasible, and the range of those cards can be maliciously extended.

Here's a link to the paper:
http://eprint.iacr.org/2005/052.pdf

and from http://www.uncoveror.com/rfid2.htm

...
The manufacturers of these devices insist that they have a limited range, but hackers have always been able to build antennas to extend the range of any wireless device. Sometimes a simple Pringles can, a coax connector and a soldering iron are all they need to rig one up. A similar home-brewed contraption was how they got Paris Hilton's address book. Also, if a hacker, mugger or terrorist's RFID reader is too far away from a chipped passport, it can always piggyback data from a legitimate reader, and no one will ever know. ...

One of the most important rules of stream ciphers is to never use the same keystream to encrypt two different documents. If someone does, you can break the encryption by XORing the two ciphertext streams together. The keystream drops out, and you end up with plaintext XORed with plaintext -- and you can easily recover the two plaintexts using letter frequency analysis and other basic techniques.
...
Microsoft uses the RC4 stream cipher in both Word and Excel. And they make this mistake. ...

Lenstra and others came up with a way to generate syntactically-correct X509 certificates that collide under MD5.

Here's a link to the paper: Lenstra et al.

Here's a head start for you if you are looking to hack:
http://eprint.iacr.org/2005/095.pdf

Heh, thanks :)

As long as we're discussing the MD5 stuff:

Slashdot
E-Print of the original paper
Vlastimil Kilma's research on the topic
The finally released paper by Xiaoyun Wang, the original discoverer of this attack

Enjoy!

--Dan

Heh, thanks :)

As long as we're discussing the MD5 stuff:

Slashdot
E-Print of the original paper
Vlastimil Kilma's research on the topic
The finally released paper by Xiaoyun Wang, the original discoverer of this attack

Enjoy!

--Dan

To see the potiential down fall of this in future applications checkout the Isreali study.
http://eprint.iacr.org/2005/052.pdf

Right. And who would care to use shoddy Whitenoise? It's been broken already.

Look here: http://eprint.iacr.org/2003/250

tsk...tsk...tsk..

Two words: Branch Number.

Also the fact the round function is complete (say unlike AES) "integration style" attacks are not applicable.

Keep in mind this is based on the research of the CS-Cipher (Vaudenay) and this.

put in the public last year...

What this much-publicised break offers is a faster-than-brute-force way to create 2 messages whose hash is identical, but not to construct a message with a predetermined hash (which is what you'd need to do if you wanted to alter the content of an existing PGP-signed document).
The best such attack against SHA1 known to date, Kelsey & Schneier (Nov 2004, cf. http://eprint.iacr.org/2004/304), requires 2**106 operations; way beyond our reach today.

Your last question is the interesting one. Encryption has been described as transfering a credit card in an heavily armored truck to a guy living in a cardboard box. Oftentimes, the easiest way to circumvent the encryption is not to break it, but to look for flaws in the implementation of the algorithm, or to social engineer your way to a password.

This is the same team who broken MD4, MD5, HAVAL-128 and RIPEMD six months ago, so I'd rather believe this is true that calling them liars.

• Overview of an argument that concatenation of common hash functions won't produce a more secure hash functions (page 3)
  
• Applying a similar argument to a broader class of hash functions (I haven't read this yet, but the abstract sound neat...)
  
• Discussion about working around Joux's attack
  

You realize that all of the RIPEMD versions have been broken?
Collision Paper
"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD"
Found by the same team that reportedly just broke SHA1 are the same people who broke MD5 and the 'similar' algorithms some months ago.

• (R04) V. Rijmen, "Update on SHA-1", accepted for CT-RSA'2005
  
• P. Hawkes, M. Paddon, G. G. Rose, "On Corrective Patterns for the SHA-2 Family", Cryptology ePrint Archive, Report 2004/207
  

If this definite break is confirmed, I think we will need to conclude that the entire family is suspect for any genuinely important purpose.

There are a bunch of hashing algorithms on the Hashing Function Lounge that are listed as having no known attacks. At present, the most widespread is Whirlpool. I think it likely that one of these will replace SHA as the hashing function of choice in major cryptographic areas.

Same group of people that found the MD5 Hash Collision. Self references and the MD5 paper.

Every file that is written to an encrypted folder by User A has a private encryption key generated for it. That private encryption key is then encrypted with User A's public key and every designed Encrypted Data Recovery Agent's public key. Then either User A or any such recovery agent's private key can then decrypt the file. Of course, MS just lets lay users assume their "encrypted" files are private.

They (and they employers) also probably assume that when their key is lost then all of their work is not lost forever. You are right that Microsoft's encryption is a joke, but this is not a good example. What you have described is not a flaw per se, but a design decision. In fact, that is the only way to restore the encrypted data when the user's key is lost. On the other hand, the RC4 flaw is about reusing the same keystream in stream ciphers, which is an inexcusable amateur mistake and shows a level of incompetence just plainly laughable in the case of the largest software giant on the planet. Let me quote Bruce Schneier on Microsoft RC4 Flaw:

One of the most important rules of stream ciphers is to never use the same keystream to encrypt two different documents. If someone does, you can break the encryption by XORing the two ciphertext streams together. The keystream drops out, and you end up with plaintext XORed with plaintext -- and you can easily recover the two plaintexts using letter frequency analysis and other basic techniques.

It's an amateur crypto mistake. The easy way to prevent this attack is to use a unique initialization vector (IV) in addition to the key whenever you encrypt a document.

Microsoft uses the RC4 stream cipher in both Word and Excel. And they make this mistake. Hongjun Wu has details (link is a PDF).

In this report, we point out a serious security flaw in Microsoft Word and Excel. The stream cipher RC4 [9] with key length up to 128 bits is used in Microsoft Word and Excel to protect the documents. But when an encrypted document gets modified and saved, the initialization vector remains the same and thus the same keystream generated from RC4 is applied to encrypt the different versions of that document. The consequence is disastrous since a lot of information of the document could be recovered easily.

This isn't new. Microsoft made the same mistake in 1999 with RC4 in WinNT Syskey. Five years later, Microsoft has the same flaw in other products.

As you can see, Microsoft's crypto is a joke indeed. It is an old, unfunny joke that they keep repeating ad nauseam. But it is about a much more important incompetence than what you have noticed. As some people say: "When it comes to security, it's always Amateur Hour in Redmond." Sadly, this has been true forever. When people invest in Microsoft's security they always say "maybe this time they got it right, I'm sure." This is not without a reason.

Here is another paper that examines the implications of the Wang paper as well as some analysis of the collision.

No, but I believe this one is:

XiaoyunWang, Dengguo Feng, Xuejia Lai, and Hongbo Yu
"Collisions for hash functions md4, md5,haval-128 and ripemd"

That is not encryption, your cypher can 'decode' to more than one plaintext. It's not encryption, because you can't decrypt it. It's a hash. It's really trivial to find MD5 collisions.

http://eprint.iacr.org/2004/199.pdf

In general the timestamping problem is clearly an insoluble one, because the server has no way to tell if the human took only as much time to think as the client software claims. Obfuscation is a stopgap solution that deters the casual attacker, but there is no cryptographic solution apart from "trusted" hardware (yikes).

The way the music/movie industry has tackled the problem is to go on the offensive and call everyone a criminal. Let's see what the ICC does.

This PDF explains the MD5 Collision: http://eprint.iacr.org/2004/199link

No, what they've shown is that it's possible to find two binary strings that hash to the same value. This is different from being given a hash (e.g. your signed program example) and finding another binary string that produces the same hash.

Here's a paper that talks about this in greater detail.

Eventually I gave up trying to reproduce the hashes, and went to looking online. I found a good summary explaining the mistake the authors made (endianness problems, mostly) at this website.

The end result is that they didn't break MD5 -- yet. But their result can probably be modified to break the real MD5. Looks like we have a few more days till the world ends. ;)