Slashdot Mirror
Slashback: Flashmob, Currency, Verification
Reminder of your scheduled spontaneous appointment. Zero_K writes "As previously posted on Slashdot and the NY Times, the University of San Francisco's, Computer Science department is building a 'flash mob' supercomputer on April 3rd. On their newly updated official web-site (Main Site, ISO's) the team has now posted the ISO image of their custom morphix that will be used to boot all the computers into the cluster, documentation is on the website (under 'downloads') and on the CD (index.html). I personally plan on downloading and testing this ISO tonight. And after the cluster is taken off line, there will be a massive LAN PARTY (Possibly one of the biggest in San Francisco...) On a 10-Gigabit LAN...Oh sweetness ... So if you are in or around the SF Bay Area on April 3rd, be sure to sign up and bring your laptop or desktop to campus and help make history."
Whaddya mean, "no pun intended"? Rudiger writes "After the dust (no pun intended) has settled around the whole Operation Dust Bunny thing, McAfee updates their signature database classifying Dust Bunny as an application. To be more specific: 'This program is detected as a "potentially unwanted application."' They also say 'This is not a virus or trojan.' Should we leave it to the experts this time?"
Would you read Atlas Shrugged on this screen? An anonymous reader writes "The so-called 'electronic paper,' being a high-clarity monochrome display to become a foundation for comfortable and inexpensive 'electronic papers,' has finally shown its face. The new electronic paper, which looks a bit like an iPod, has 10MB memory, keyboard, Memory Stick PRO slot, voice recorder, speaker, and headphones output, and USB2.0 interface."
(We mentioned the device yesterday, but this link provides better images of it.)
Now they're Pragmatic Publishers as well -- much success! AndyHunt writes "As you may have heard, the Pragmatic Programmers have started their own publishing company (see Slashdot reviews here and here). We've just signed our first outside author: Mike Clark, editor of the JUnit FAQ and developer of JUnitPerf and JDepend. He'll be writing the eagerly-anticipated Pragmatic Project Automation book, the third volume in our Jolt Productivity award-winning series."
Exactly how many bits, Ma'am? And in what order, did you say? jlcooke writes "Two months (almost to the day) after getting slashdotted for an innocent post to sci.crypt - the MD5CRK project has launched. The aim is to get the thousands of applications and websites to drop MD5 for SHA-1 or SHA-256 by finding a counter-example of a security requirement in MD5. Press Release is here."
How to take criticism, by example. slashdot_commentator writes "Eric S. Raymond has recently written a wonderful piece explaining to the Linux zealot why it may not be the operating system of choice of all users. (Or what user aspects open source developers need to focus on to further Linux World Domination.) The op-ed specifically focuses on the CUPS printing system. (But it would be a mistake to dismiss it as a screed against CUPS.) The CUPS authors surprisingly acknowledged ESR's points, and he wrote a followup to the article."
Hitting them where it figuratively hurts. Ian Wilson writes with a followup to the Slashdot post earlier this month on "website thieves stealing content and designs from others, taken from silicon.com. Well, now silicon.com is reporting that it has contacted the offending site's advertisers and forced them to stop paying ad revenues - thus effectively crippling the illegal site - after all, no revenue, no reason to the run the site."
Express your appreciation with PizzaPal. Chuck writes "After you guys published the article on $20 bills exploding when microwaved, a co-worker of mine went to put his soup in the microwave and found a $20 bill in it. Too bad it was an older one, but someone around the office must have left it in there after reading your article. The co-worker then took me out to lunch. Thanks, Slashdot!"
SHA-1 isn't really "their" message digest algorithm, they're just recommending it as a replacement for MD5, which they're trying to crack.
You have three different "MD5 sum" utilities that all give different checksums for the same data? If so, then at least two of them aren't actually MD5 utilities, in the sense that they don't compute MD5 sums. *cough*
Too bad nobody agrees on how MD5 should be calculated.
Wow, really, you know, someone should like, write an RFC for it or something, then maybe they could all agree!
You're trolling. It is a relatively simple algorithm and an old standard.
Or grab the nifty new (v1.1 released today) md5deep. Computes MD5, works recursively and most any platform too.
AVGd =1028 312263
i d=103256665 3
http://fileforum.betanews.com/detail.php3?fi
Antivir
http://www.fileforum.com/detail.php3?f
Just use a throw-away mail account to register.
Be extraordinarily careful when trying to take a MD5 sum of a text file. Most operating systems will give you different file contents for a text file, depending on how you ask to open and read the file. If you have MD5 utils that aren't explicity requesting all files in binary mode, then they are being sloppy.
You also have to be careful with text files that they aren't being modified on the fly when being transferred between machines.
SHA1, which you can use via the sha1sum command in the GNU core utilities, probably already installed on most Linux systems.
from the bit torrent web site faq:
...
Does BitTorrent contain spyware or adware?
Some warez sites are distributing spyware-wrapped versions of the BitTorrent installer. Please only download the BitTorrent installer from this site. I'm considering legal action against sites which misrepresent their hacked installers as the official one.
I frequently use MD5 in my code, for verifying a file's integrity. I do not use SHA-1 or SHA256, because they run a lot slower than MD5, without providing a realistically better guarantee that a file contains what it did at the time of its creation (if 128 bits leaves a significant chance of collision, you have bigger problems than choice of hashing algorithms... Such as how to store over a trillion yottabytes, which corresponds to one bit per 10 picograms assuming you used the entire Earth as a storage device).
Now, cryptographically, MD5 does not have the same "strength" as the SHA256. If you want to prevent tampering, you should most certainly switch to an SHA. But to just check the validity of a large block of data (such that a mere CRC doesn't suffice), MD5 works beautifully.
Additionally, I would point out to those who seem to believe finding a single MD5 collision would invalidate the whole algorithm - BS. For SHA256, going though every possible 257 bit block, you can guarantee a collision. For any hashing algorithm, that will hold true. I don't care if someone came up with a quantum hash (pulled from my posterior, since quantum-blah seems like the word of the day for magical guarantees of computational perfection), you'll still have at least one collision in N+1 bits, where the hash generates N bits.
So can we drop the SHA elitism that seems to have infected people lately? If you want to waste time in your code, go right ahead. But don't fault those of us who actually understand that, outside the realm of hard cryptography, MD5 more than suffices as an all around good hashing algorithm.
MD5 is standardized and portable.
Perhaps some of the utilities you are using consider file metadata when generating the checksum?
Also beware of implicit conversions being done to your data by your I/O libraries, as other posters have noted.
DNA just wants to be free...
That is an incorrect assumption. The fundamental requirement is: It is hard (next to impossible) to find two inputs which produce the same digest (and still make sense
The message digest is usually shorter than the message, so this means that the digest contains less "information" that the message. Which means there will be more than one message for the same digest. This loss of "information" means also that you cant reverse a hash to get the original message and be 100% certain you have the right message. There is an infinite number of messages that produce that hash.
Almost forgot your comment about speed. SHA-1 is slightly slower then MD5. SHA-256 is slightly slower then SHA-1. SHA-384/512 use 64 bit operations so it is much slower on 32bit systems. In short, you concerns about speed are unfounded. Read on.
...
Run this command:
openssl speed md5 sha1
I get:
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md5 13426.71k 46361.18k 124663.83k 222340.64k 286203.62k
sha1 11175.12k 30058.96k 69783.42k 104107.06k 121809.96k
I also ran "time md5sum file94mb" and "time sha1sum file94mb" file 3 times in succession. The performance is much closer.
a959b7de4f11fe89ba57ecc6fe2f6a07 file94mb
real 0m1.070s
user 0m0.860s
sys 0m0.060s
a959b7de4f11fe89ba57ecc6fe2f6a07 file94mb
real 0m1.070s
user 0m0.850s
sys 0m0.070s
a959b7de4f11fe89ba57ecc6fe2f6a07 file94mb
real 0m1.071s
user 0m0.810s
sys 0m0.110s
5d926755ef975a8900b89b514feac9ded29c4477 file94mb
real 0m1.538s
user 0m1.260s
sys 0m0.060s
5d926755ef975a8900b89b514feac9ded29c4477 file94mb
real 0m1.524s
user 0m1.270s
sys 0m0.040s
5d926755ef975a8900b89b514feac9ded29c4477 file94mb
real 0m1.520s
user 0m1.280s
sys 0m0.030s
Are the MD5CRK folks trolling, smoking crack, or just not explaining themselves very well?
They "aim to disprove one of the fundamental requirements of a secure message digest: No two inputs can be found which produce the same digest - this is also known as a collision."
MD5 gives a 128-bit digest. There are more than 2^128 possible messages. Of course there are collisions. What MD5 claims is that the difficulty of coming up with two messages having the same message digest is on the order of 2^64 operations, and that the difficulty of coming up with any message having a given message digest is on the order of 2^128 operations.
No digest algorithm can claim to be free of collisions; they are many-to-one mappings.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Peachy. Where were you going to put the lookup table for that? 2^81920 is on the order of 10^25000. If you could store one of those documents on an atom (attach it with a little dab of glue, okay?) you'd have enough plaintext documents for every atom in this universe...and for every atom to have its own universe of attached atoms...and still have enough documents to be short several orders of magnitude of storage space. Generating the table is left as an exercise for the reader. Cheers.
~Idarubicin
I like the idea of my computer auto-detecting any network printers. I don't have my printer linked up to the network as I don't have time to try and figure out how to do it.
I do to. But I also want the ability to say "you're wrong...do it this way" to the computer.
I think you are in the minority. If the printer is currently down then you can't use it so configure it later when you CAN use it.
For home users, this may not be an issue. For an office environment, it may be. There have been a few times dealing with printers where part of the support group is out unboxing them, putting them in place, assigning an IP to it, while the network group is setting the servers up to have that print queue. It'd suck if there were 20 of these and we had to wait until they were all unboxed and setup to add the queue, or get interrupted to do each one as it's setup.
Sure...have the ability to say "I don't think this is the option you are looking for" but at the same time, allow people to override any auto-detection with the caveat that this may no work if you don't know what you're doing. Just don't force them to be at the mercy of the wizard programmer as to what should happen in the real world.
How will it just work if it cannot connect to the network interface?
The point was, I believe, that the wizard may not be smart enough to recognize every type of connection. For instance, if the wizard was written by someone who never say anything but Linux, there may be code that looks for ethx. But on HPUX it's lanx, or whatever Solaris calls its interfaces. Or what if my only connection is a ppp connection (dialup or VPN) and it isn't connected at the time I'm setting it up. Again, it's about saying "this is what it looks like to the wizard, but if you wanna igore those assumptions, go ahead at your own risk."
They user doesn't care about how difficult it is behind. If it's badly designed then it will be system dependant and a support nightmare. It will need a bit of thought in the design, that's all.
Amen brother.
And it isn't just Linux - printers on any Unix system (or any system at all) are ridiculous.