www.rtfm.com/movabletype -> www.rtfm.com/movabletype/
article about attempts to extend European music copyright. It seems that European copyright on recorded music extends 50 years, so the copyright on a fair amount of music is starting to expire. Unsurprisingly, the British Phonographic Industry (BPI) is lobbying for a Sonny Bono-style copyright extension: Unlike Europe, copyright protection exists in the US for 95 years after the recording was made. Australia and Brazil have 70-year terms, and India 60 years. Peter Jamieson, the BPI's executive chairman, said less favourable copyright terms could put the UK's record industry at a commercial disadvantage to the US. He said it was unfair to performers and investors to fail to get a return for a "free-for-all" in Europe - often within the artist's lifetime. Record labels argue that their ability to invest in new talent often depends on money generated by their back catalogue. Someone proposes to tax everyone in England $10 and give the proceeds to British music companies. Well, they could then use the money to produce new music. And you might ask why the record companies would be particularly deserving. Why not, say, the movie companies, book publishers, or plumbers? If you think this subsidy is a bad idea, then you should think that extending copyright on recorded music is an even worse idea. Just like the subsidy, it takes money out of your pocket and puts it in the hands of the record companies without giving them any actual new incentive to produce more content. Unfortunately, it's even worse than that: if the copyright expires, then the cost of the music goes down to the marginal price of production, maybe a dollar or two--and it's probably available for free on the Internet. If the price is say $10, then people who value copies at $5 won't buy any--that pesky deadweight loss again. Bottom line: subsidizing more music production is a terrible rationale for extending copyright.
report): * Joux has found a single collision in SHA-0--an algorithm that nobody uses but that is very similar to SHA-1. However, SHA-0 was changed to fix a flaw (later found by Joux), thus becoming SHA-1, so we can hope that this attack can't be extended to SHA-1. The attack was fairly expensive, requiring about 2^51 operations (the brute force attack would take about 2^80). It's hard to know whether this can be extended to full SHA-1 or not. NSA (who designed SHA-1) seems to be generally pretty good at tuning their algorithms so that they're just complicated enough to be secure. The good news is that people have sort of assuming that something like this would happen ever since Dobbertin published his papers back in 1996 and so we've been mostly phasing out MD5 in contexts where this attack would be a problem. The SHA-0 and SHA-1 stuff is more serious since it now looks like there's a possibility that someone will get full SHA-1 and we need to look for alternatives.
There are three significant Rump session papers on hash collisions that will be presented, including an update on this one (and about 40 ther short papers on other aspects of cryptography).
html Barring technical or other difficulties, if you want to hear this from the horses mouth, the CRYPTO2004 Rump Session will be webcast at 7pm pacific Tuesday Aug 17 for as long as it takes. You may join us virtually using the following links (depending on the readers).
I know that my MacOSX machine with Windows Media Player can use the mms: link. I welcome feedback from anyone using other readers on other platforms like Linux. The server is currently up and running and is broadcasting a dark, empty, and silent hall. This should be more interesting after sunup Tuesday Santa Barbara time. This is our the conferences first webcast, and I hope that it works for you. Thanks jim Should be pretty interesting and, unlike the Olympics, you can watch it live in the US.
TrackBack August 16, 2004 Almost a collision in MD5 I've now successfully reproduced the MD5 collision result. They're given as hex words, but MD5 is defined in terms of bitstrings. Because MD5 is little-endian, you need to reverse the written byte order to generate the input data. A related problem is that some of the words are given as only 7 hex digits. Assuming that they have a leading zero fixes that problem. Unfortunately, this still doesn't give you the right hash value.
Voltage Security, is that they authors aren't really computing MD5 The algorithm is initialized with a certain internal state, called an Initialization Vector (IV).
MD5 RFC as: word A: 01 23 45 67 word B: 89 ab cd ef word C: fe dc ba 98 word D: 76 54 32 10 but this is little-endian format. So, the actual initialization values should be 0x67452301, etc... The authors use the values directly, so they use: 0x01234567, etc... though strangely with a different hash value than the authors provide. Steve and I have independently gotten the same result, though of course we could have made mistakes... So, this looks like it isn't actually a collision in MD5, but rather in some other algorithm, MD5'.
paper on ePrint that claims to contain collisions in MD5, MD5, HAVAL, and full RIPEMD I haven't verified that they really contain collisions, but it's hard to believe that the authors would get something that simple wrong. They claim that the MD5 collision took about an hour of compute time and then 15 seconds to five minutes for subsequent collisions with the same initial 512 bits. UPDATE: Both I and a colleague have attempted to verify the vectors in the paper with no success. Of course, we could both have made programming errors, or misinterpreted the (rather terse) paper.
posted an interesting rumor that someone is going to announce a break in SHA-1 in the near future. Ed writes: SHA-1 is the most popular cryptographic hashfunction (CHF). A CHF is a mathematical operation which, roughly speaking, takes a pile of data and computes a fixed size "digest" of that data. To be cryptographically sound, a CHF should have two main properties. Given a digest, it must be essentially impossible to figure out what data generated that digest. It must be essentially impossible to find find a "collision", that is, to find two different data values that have the same digest. They're used in most popular cryptographic protocols, including the ones used to secure email and secure web connections. They appear in digital signature protocols that are used in e-commerce applications. Since SHA-1 is the most popular CHF, and the other popular ones are weaker cousins of SHA-1, a break of SHA-1 would be pretty troublesome. For example, it would cast doubt on digital signatures, since it might allow an adversary to cut somebody's signature off one document and paste it (undetectably) onto another document. At the Crypto conference, Biham and Chen have a paper showing how to find near-collisions in SHA-0, a slightly less secure variant of SHA-1. On Thursday, Antoine Joux announced an actual collision for SHA-0. And now the rumor is that somebody has extended Joux's method to find a collision in SHA-1. If true, this would mean that the SHA-1 function, which is widely used, does not have the cryptographic properties that it is supposed to have. 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. A collision in SHA-1 would cast doubt over the future viability of any system that relies on SHA-1; If SHA-1 is completely broken, the result would be significant confusion, reengineering of many systems, and incompatibility between new (patched) systems and old. It's definitely true that the ability to find collisions in SHA-1 would be a big deal from a cryptographic perspective, but I'm not sure it would be that big a deal from a security perspective.
annulled all the same sex marriages that San Francisco had performed. We agree with petitioners that local officials in San Francisco exceeded their authority by taking official action in violation o...
|
http://csua.com/feed/