> The article shows largely a series of examples where you DID have HIGHLY PAID and HIGHLY > trained professionals with plenty of experience and oversight... >...software development is very hard
You are absolutely right, it is hard. You really are making the same point I am. What they thought was enough, was not. It's not a matter of paying the same people more money. It's a matter of taking more time and using more developers, and more experienced developers. It's also a matter of more careful design (ie more time and expense), more design reviews, more code reviews, more testing, all by more experienced people. It sounds like you are throwing up your hands and saying "It's hard, so accept the bugs and get over it". OTOH I'm saying that more and better resources, properly developed and managed, can make a critical difference.
Consider how much software is written by people with five years or less of professional experience, on short schedules, with no time allocated for continuing education. If software projects weren't always rush jobs, and on relative shoestring budgets, the quality would be better. If continuing education for programmers was a priority, quality would be better. If a couple of decades of experience was properly appreciated, quality would be better.
It seems that journalists never get articles on cryptography right. They think that adding a few technical terms adds to the credibility of the story. But when they get it wrong it has the opposite effect.
Bruteforcing 3DES or AES (even 128 bit AES) is extremely infeasible with current technology. OTOH it is quite possible they get success via a dictionary attack on a password-based key, or on a password protecting a key store, or perhaps exploiting some other weakness in the key generation algorithm (ie hash of a timestamp etc), or perhaps bypassing the encryption to find unencrypted info in a swap file, etc.
Let's say I make my one authorized recording. It is now a file (ie, a sequence of bits on a disk--perhaps a CD?) I can now use a tool like K3B or PartImage to make a replica of the disk. I can FTP the file to another system. I can play it through open source software which gives me opportunity to capture the decoded material and perhaps re-encode it to remove watermarks. etc... The only thing that has changed is that commercially available tools will enforce the embedded copy controls.
Sure DRM laws might prohibit some of those things. But copyright laws prohibit unauthorized file sharing now, yet people continue to do it. I don't see how this changes anything...other than for all those people who use commercial tools only.
If ad servers were blazingly fast I'd be less likely to block the ads. Sometimes the browser pauses for many seconds waiting for a particular ad server to respond. Blocking ads using firefox & adblock plugin makes browsing some sites substantially faster.
GPL needs to make the license more user friendly, not less. Closing "loopholes" is moving in the wrong direction. That just limits the potential usefulness of the software.
Side note: Can they legally add restrictions (ie. close a loophole) in a license for existing software? Doesn't the GPL itself prevent this?
HMAC is designed to be robust even if the underlying hash function has weaknesses, within reasonable limits. SHA-1 is still within such reasonable limits (for that matter, MD5 probably is also).
The recently published attacks are not particularly useful for snooping on encrypted internet protocols such as IPSEC, SSL/TLS etc. To find a collision using the recently published attacks on MD5 and SHA-1, you must be able to control both of the colliding files. By introducing carefully chosen changes to each file you arrive at two files with the same hash. That is not very useful to a third party wishing to listen in on IPSEC, SSL/TLS, etc. However there are practical ways to exploit the new attacks. Stefan Lucks has a web site with a little story involving two PDF documents with the same hash, illustrating how this can be exploited: http://www.cits.rub.de/MD5Collisions/
> Actually, reading on, it looks like the author > really doesn't have a clue.
Indeed. He says:
> This Diffie-Hellman key exchange protocol is > used, for example, by RSA and PGP.
RSA and DH key exchange are two different animals. The formulas involved have a certain similarity but the principles are different. RSA is an asymmetric encryption scheme based on the hard problem of factoring, and provides authentication. DH key exchange is a "key exchange" protocol based on the hard problem of discrete logs, and is non-authenticating (meaning it is vulnerable to a man in the middle attack).
Also, the article states: > By the late 1990s, security researchers had been > able to break the 56-bit DES algorithms in as > little as three hours.
But the 1998 break by EFF in combination with distributed.net took over 23 hours. Details, details... see
He clearly didn't violate either when he taped the boxes together. Fed Ex put its name and logo all over those boxes...not the furniture maker.
Photographing the results and putting that on the web seems like fair use to me (not a lawyer however).
He may have violated some terms of his fed ex account. It is even possible that the domain name violates trademark. But surely there is no basis for copyright charges.
> Now, that doesn't mean this is an unchangeable > system, but it is one hell of a beast to slay.
Granted. But there is a huge economic incentive to eliminate the middle man. Both the artist and the customer will benefit.
Artists could sign with publicity agents. They could attract venture capital investments. They could purchase air time. They could prime the pump by releasing free music. They could give free concerts in major cities. They could tour the country. They could perform outrageous publicity stunts to gain notariety. Etc...
Not to mention the fact that there are already a lot of artists with well known names. These artists could opt out of their current deals at the next opportunity and adopt a new business model.
It won't be easy but I think there is enough financial incentive to overcome that.
Remember I'm talking about new works. What artist wouldn't prefer to keep the copyright on new works, if there were a viable distribution network that would collect royalties for them?
RobertRunAmock inquired: > Well, which is it, the performer or the composer?
It is not ambiguous who owns the copyright.
Eventually someone will start a P2P-based business to collect royalties and distribute to copyright owners, and will contract directly with artists. That will be to the advantage of everyone except the RIAA, whose buggy whips are not really needed any more.
It should be cheaper to buy from a peer on the network than from the central server, because the server adds no value in that case. You aren't using their disk storage and you aren't using their bandwidth. All you should have to pay is a royalty of a few pennies, to go to the coypright holder.
What is really needed is a way to take the RIAA out of the loop and have royalties go directly to the copyright holder (which eventually would be the performer or composer for new works).
The special capabilities of "traditional" quantum computers (based on quantum entanglement) do not result from small size but from complexities of quantum physics. Due to a property called superposition, each quantum bit (qubit) can be zero, one, or both at the same time (with an associated probability for each of 0 and 1). An n-bit quantum computer would simultaneously model all 2^n states, and any quantum operation occurs simultaneously on all the 2^n states. Try doing that on your Dell!
Many systems are idle for some period during the day / week etc. Someone who can gain unprivileged access during that time can "cause" the system to perform an RSA key operation while simultaneously running the spy program. That's exactly what the writer did.
For some systems this presents a new threat. For others it's not an issue. If your root password is found in a standard dictionary, you should address that first.
He describes an attack on the RSA secret key in an OpenSSL system. By knowing how OpenSSL performs modulus arithmetic, he is able to distinguish many bits of p and q in the modulus by observing L1 cache hits and misses in a simultaneously running process. Assembler code is provided...
The producer of the mpg file could use a collision attack, since he controls both the mpg file and the bogus file. He could hash the mpg file (for example, md5), saving the internal state of the md5 engine at the last iteration. He could create a bogus file of the same size, generate its hash, and save that internal state also at the last iteration. Then, proceed with the published attack (adapted to use the two internal states that were saved) to find two blocks that could be appended to each file resulting in two files with the same md5 sum. At least, if I understand correctly that should be possible.
Of course, that is no more than an inconvenience to p2p since the file could be truncated, or another byte appended etc resulting in a different hash value. It would be possible to flood the network with bogus files matching the original, but it would be trivial to create usable mpg files with unique hashes.
All we can really say is that these researchers did not demonstrate a preimage attack. However what they did demonstrate should raise serious concerns that a preimage attack might be possible. For example, I could hash the latest blockbuster movie file, saving the internal MD5 state at the last iteration. Then, proceed with their algorithm, searching for a pair of two-block extensions to add to the file which lead to MD5 collisions of the entire file. If not, why not?
Bottom line, attacks get stronger over time, never weaker. Once a crack appears, further probing generally widens the crack.
MD5 is probably ok to use in a scenario where you don't expect an active adversary, or in a keyed hash where the security is protected by a secret key. But relying on MD5 to protect data integrity against a well funded adversary is foolish at this point.
There is a simple python program which demonstrates this collision:
http://tinyurl.com/amp43
I'd post the program but slashdot lameness test commplains about junk characters.
Here are two different files with the same md5 sum. They are quite similar, but notice for example the differences at byte 20 and at byte 27. file1.dat:
00000000 d1 31 dd 02 c5 e6 ee c4 69 3d 9a 06 98 af f9 5c
00000010 2f ca b5 87 12 46 7e ab 40 04 58 3e b8 fb 7f 89
00000020 55 ad 34 06 09 f4 b3 02 83 e4 88 83 25 71 41 5a
00000030 08 51 25 e8 f7 cd c9 9f d9 1d bd f2 80 37 3c 5b
00000040 96 0b 1d d1 dc 41 7b 9c e4 d8 97 f4 5a 65 55 d5
00000050 35 73 9a c7 f0 eb fd 0c 30 29 f1 66 d1 09 b1 8f
00000060 75 27 7f 79 30 d5 5c eb 22 e8 ad ba 79 cc 15 5c
00000070 ed 74 cb dd 5f c5 d3 6d b1 9b 0a d8 35 cc a7 e3
MD5(file1.dat) = a4c0d35c95a63a805915367dcfe6b751
file2.dat:
00000000 d1 31 dd 02 c5 e6 ee c4 69 3d 9a 06 98 af f9 5c
00000010 2f ca b5 07 12 46 7e ab 40 04 58 3e b8 fb 7f 89
00000020 55 ad 34 06 09 f4 b3 02 83 e4 88 83 25 f1 41 5a
00000030 08 51 25 e8 f7 cd c9 9f d9 1d bd 72 80 37 3c 5b
00000040 96 0b 1d d1 dc 41 7b 9c e4 d8 97 f4 5a 65 55 d5
00000050 35 73 9a 47 f0 eb fd 0c 30 29 f1 66 d1 09 b1 8f
00000060 75 27 7f 79 30 d5 5c eb 22 e8 ad ba 79 4c 15 5c
00000070 ed 74 cb dd 5f c5 d3 6d b1 9b 0a 58 35 cc a7 e3
MD5(file2.dat) = a4c0d35c95a63a805915367dcfe6b751
For SHA1, you are correct. They presented an algorithm for finding collisions in full 80-round SHA1, and demonstrated the correctness of the algorithm on SHA1 reduced to 58 rounds. Here is the SHA1 announcement:
It seems that lots of people here are behind on their crypto news.
MD5 is done. Put a fork in it. SHA-1 is down for the count. These are not theoretical results but actual collisions. There is little doubt that a billion dollar industry can afford to generate these collisions, if they believe it will protect their revenue stream.
Slashdot Mirror
> The article shows largely a series of examples where you DID have HIGHLY PAID and HIGHLY ...software development is very hard
> trained professionals with plenty of experience and oversight...
>
You are absolutely right, it is hard. You really are making the same point I am. What they thought was enough, was not. It's not a matter of paying the same people more money. It's a matter of taking more time and using more developers, and more experienced developers. It's also a matter of more careful design (ie more time and expense), more design reviews, more code reviews, more testing, all by more experienced people. It sounds like you are throwing up your hands and saying "It's hard, so accept the bugs and get over it". OTOH I'm saying that more and better resources, properly developed and managed, can make a critical difference.
Consider how much software is written by people with five years or less of professional experience, on short schedules, with no time allocated for continuing education. If software projects weren't always rush jobs, and on relative shoestring budgets, the quality would be better. If continuing education for programmers was a priority, quality would be better. If a couple of decades of experience was properly appreciated, quality would be better.
It seems that journalists never get articles on cryptography right. They think that adding a few technical terms adds to the credibility of the story. But when they get it wrong it has the opposite effect.
Bruteforcing 3DES or AES (even 128 bit AES) is extremely infeasible with current technology. OTOH it is quite possible they get success via a dictionary attack on a password-based key, or on a password protecting a key store, or perhaps exploiting some other weakness in the key generation algorithm (ie hash of a timestamp etc), or perhaps bypassing the encryption to find unencrypted info in a swap file, etc.
Ok maybe I am missing something...
Let's say I make my one authorized recording. It is now a file (ie, a sequence of bits on a disk--perhaps a CD?) I can now use a tool like K3B or PartImage to make a replica of the disk. I can FTP the file to another system. I can play it through open source software which gives me opportunity to capture the decoded material and perhaps re-encode it to remove watermarks. etc... The only thing that has changed is that commercially available tools will enforce the embedded copy controls.
Sure DRM laws might prohibit some of those things. But copyright laws prohibit unauthorized file sharing now, yet people continue to do it. I don't see how this changes anything...other than for all those people who use commercial tools only.
They prefer Java as the write-once, run anywhere solution.
...the ability to synchronize music across pc, ipod, and other devices regardless of format?
If ad servers were blazingly fast I'd be less likely to block the ads. Sometimes the browser pauses for many seconds waiting for a particular ad server to respond. Blocking ads using firefox & adblock plugin makes browsing some sites substantially faster.
In the next item of business, the US proposed that the UN should take control of Buckingham Palace.
GPL needs to make the license more user friendly, not less. Closing "loopholes" is moving in the wrong direction. That just limits the potential usefulness of the software.
Side note: Can they legally add restrictions (ie. close a loophole) in a license for existing software? Doesn't the GPL itself prevent this?
They have "password" but not "PASSWORD". Much less, "pAssWOrD" or "p455w0rd" or "0qww294e" (transposed up one row on querty keyboard).
John the Ripper need not fear.
HMAC is designed to be robust even if the underlying hash function has weaknesses, within reasonable limits. SHA-1 is still within such reasonable limits (for that matter, MD5 probably is also).
The recently published attacks are not particularly useful for snooping on encrypted internet protocols such as IPSEC, SSL/TLS etc. To find a collision using the recently published attacks on MD5 and SHA-1, you must be able to control both of the colliding files. By introducing carefully chosen changes to each file you arrive at two files with the same hash. That is not very useful to a third party wishing to listen in on IPSEC, SSL/TLS, etc. However there are practical ways to exploit the new attacks. Stefan Lucks has a web site with a little story involving two PDF documents with the same hash, illustrating how this can be exploited:
http://www.cits.rub.de/MD5Collisions/
> Actually, reading on, it looks like the author
> really doesn't have a clue.
Indeed. He says:
> This Diffie-Hellman key exchange protocol is
> used, for example, by RSA and PGP.
RSA and DH key exchange are two different animals. The formulas involved have a certain similarity but the principles are different. RSA is an asymmetric encryption scheme based on the hard problem of factoring, and provides authentication. DH key exchange is a "key exchange" protocol based on the hard problem of discrete logs, and is non-authenticating (meaning it is vulnerable to a man in the middle attack).
Also, the article states:
> By the late 1990s, security researchers had been
> able to break the 56-bit DES algorithms in as
> little as three hours.
But the 1998 break by EFF in combination with distributed.net took over 23 hours. Details, details... see
http://www.distributed.net/des/
This article is an embarrasment to IBM. They have people who know better!
He clearly didn't violate either when he taped the boxes together. Fed Ex put its name and logo all over those boxes...not the furniture maker.
Photographing the results and putting that on the web seems like fair use to me (not a lawyer however).
He may have violated some terms of his fed ex account. It is even possible that the domain name violates trademark. But surely there is no basis for copyright charges.
> Now, that doesn't mean this is an unchangeable
> system, but it is one hell of a beast to slay.
Granted. But there is a huge economic incentive to eliminate the middle man. Both the artist and the customer will benefit.
Artists could sign with publicity agents. They could attract venture capital investments. They could purchase air time. They could prime the pump by releasing free music. They could give free concerts in major cities. They could tour the country. They could perform outrageous publicity stunts to gain notariety. Etc...
Not to mention the fact that there are already a lot of artists with well known names. These artists could opt out of their current deals at the next opportunity and adopt a new business model.
It won't be easy but I think there is enough financial incentive to overcome that.
If you build it, they will come.
Remember I'm talking about new works. What artist wouldn't prefer to keep the copyright on new works, if there were a viable distribution network that would collect royalties for them?
RobertRunAmock inquired:
> Well, which is it, the performer or the composer?
It is not ambiguous who owns the copyright.
Eventually someone will start a P2P-based business to collect royalties and distribute to copyright owners, and will contract directly with artists. That will be to the advantage of everyone except the RIAA, whose buggy whips are not really needed any more.
It should be cheaper to buy from a peer on the network than from the central server, because the server adds no value in that case. You aren't using their disk storage and you aren't using their bandwidth. All you should have to pay is a royalty of a few pennies, to go to the coypright holder.
What is really needed is a way to take the RIAA out of the loop and have royalties go directly to the copyright holder (which eventually would be the performer or composer for new works).
The special capabilities of "traditional" quantum computers (based on quantum entanglement) do not result from small size but from complexities of quantum physics. Due to a property called superposition, each quantum bit (qubit) can be zero, one, or both at the same time (with an associated probability for each of 0 and 1). An n-bit quantum computer would simultaneously model all 2^n states, and any quantum operation occurs simultaneously on all the 2^n states. Try doing that on your Dell!
Many systems are idle for some period during the day / week etc. Someone who can gain unprivileged access during that time can "cause" the system to perform an RSA key operation while simultaneously running the spy program. That's exactly what the writer did. For some systems this presents a new threat. For others it's not an issue. If your root password is found in a standard dictionary, you should address that first.
... see
http://www.daemonology.net/papers/htt.pdf
He describes an attack on the RSA secret key in an OpenSSL system. By knowing how OpenSSL performs modulus arithmetic, he is able to distinguish many bits of p and q in the modulus by observing L1 cache hits and misses in a simultaneously running process. Assembler code is provided...
The producer of the mpg file could use a collision attack, since he controls both the mpg file and the bogus file. He could hash the mpg file (for example, md5), saving the internal state of the md5 engine at the last iteration. He could create a bogus file of the same size, generate its hash, and save that internal state also at the last iteration. Then, proceed with the published attack (adapted to use the two internal states that were saved) to find two blocks that could be appended to each file resulting in two files with the same md5 sum. At least, if I understand correctly that should be possible.
Of course, that is no more than an inconvenience to p2p since the file could be truncated, or another byte appended etc resulting in a different hash value. It would be possible to flood the network with bogus files matching the original, but it would be trivial to create usable mpg files with unique hashes.
All we can really say is that these researchers did not demonstrate a preimage attack. However what they did demonstrate should raise serious concerns that a preimage attack might be possible. For example, I could hash the latest blockbuster movie file, saving the internal MD5 state at the last iteration. Then, proceed with their algorithm, searching for a pair of two-block extensions to add to the file which lead to MD5 collisions of the entire file. If not, why not?
Bottom line, attacks get stronger over time, never weaker. Once a crack appears, further probing generally widens the crack.
MD5 is probably ok to use in a scenario where you don't expect an active adversary, or in a keyed hash where the security is protected by a secret key. But relying on MD5 to protect data integrity against a well funded adversary is foolish at this point.
There is a simple python program which demonstrates this collision: http://tinyurl.com/amp43 I'd post the program but slashdot lameness test commplains about junk characters.
file1.dat:
00000000 d1 31 dd 02 c5 e6 ee c4 69 3d 9a 06 98 af f9 5c
00000010 2f ca b5 87 12 46 7e ab 40 04 58 3e b8 fb 7f 89
00000020 55 ad 34 06 09 f4 b3 02 83 e4 88 83 25 71 41 5a
00000030 08 51 25 e8 f7 cd c9 9f d9 1d bd f2 80 37 3c 5b
00000040 96 0b 1d d1 dc 41 7b 9c e4 d8 97 f4 5a 65 55 d5
00000050 35 73 9a c7 f0 eb fd 0c 30 29 f1 66 d1 09 b1 8f
00000060 75 27 7f 79 30 d5 5c eb 22 e8 ad ba 79 cc 15 5c
00000070 ed 74 cb dd 5f c5 d3 6d b1 9b 0a d8 35 cc a7 e3
MD5(file1.dat) = a4c0d35c95a63a805915367dcfe6b751
file2.dat:
00000000 d1 31 dd 02 c5 e6 ee c4 69 3d 9a 06 98 af f9 5c
00000010 2f ca b5 07 12 46 7e ab 40 04 58 3e b8 fb 7f 89
00000020 55 ad 34 06 09 f4 b3 02 83 e4 88 83 25 f1 41 5a
00000030 08 51 25 e8 f7 cd c9 9f d9 1d bd 72 80 37 3c 5b
00000040 96 0b 1d d1 dc 41 7b 9c e4 d8 97 f4 5a 65 55 d5
00000050 35 73 9a 47 f0 eb fd 0c 30 29 f1 66 d1 09 b1 8f
00000060 75 27 7f 79 30 d5 5c eb 22 e8 ad ba 79 4c 15 5c
00000070 ed 74 cb dd 5f c5 d3 6d b1 9b 0a 58 35 cc a7 e3
MD5(file2.dat) = a4c0d35c95a63a805915367dcfe6b751
For SHA1, you are correct. They presented an algorithm for finding collisions in full 80-round SHA1, and demonstrated the correctness of the algorithm on SHA1 reduced to 58 rounds. Here is the SHA1 announcement:
http://theory.csail.mit.edu/~yiqun/shanote.pdf
It seems that lots of people here are behind on their crypto news.
MD5 is done. Put a fork in it. SHA-1 is down for the count. These are not theoretical results but actual collisions. There is little doubt that a billion dollar industry can afford to generate these collisions, if they believe it will protect their revenue stream.