It may do a good job as long as the adversary does not get access to more than one copy of the ciphertext. But if the adversary is able to get copies of the same sector from two different points in time, CTR provides no security. In this respect I think CTR is worse than CBC with fixed key and deterministic IV.
The goal of this is to waste as much upstream bandwidth as possible so that others suffer.
I agree that seems to be the weakest point of a torrent. I have another twist to this attack, though I don't know, if it is going to work or not. While downloading from a peer, you could use a modified TCP implementation, that acknowledges lost TCP packets, even if a few are lost. Assuming you receive packet number 10, 13, and 15, you could acknowledge the full range from 10-15. That way you could trick the TCP layer on the sender to believe, there is much more bandwidth available, than there really is. If this works, they will essentially DoS their own upstream to the extent where even downloads will suffer because of lost acks. Of course a correctly configured ratelimit would solve that problem.
The problem with peers uploading fake data could be made even smaller than it currently is. Why does a full piece have to be transfered before it can be verified? Rather than just hashing the full sequence of bytes, a hash tree could be used. Then you could show correctness of units as small as 56 bytes at little extra cost. Of course this should only be used in the beginning. Once two peers starts having trust in each other they only show correctness of larger units. It also could be used in the end when two peers are nearly finished and fear the other peer would drop the connection as soon as he finishes.
but it depends on your attack model.
Very much indeed.
If your attack model is simply that the encrypted disk falls into the hands of the bad guys who try to get the data from it, the problem is easy.
It is easier, but not as easy as you might guess. Assuming the disk is stolen, and assuming that cannot happen without the owner noticing, then I think we can ignore the data integrity questions. That still leaves us with some worries though.
First of all you have to worry about birthday attacks. Which is why 64 bit cipher blocks should be avoided. AFAIR a 500GB disk encrypted with a single key and a 64 bit cipher block would result in approximately 100 collisions assuming there were no weaknesses in the cipher.
What you also have to worry about is change of passwords. Most disk encryptions doesn't really do that safely. Assume the media was preencrypted using some default password, and the first thing you do is to change the password. This is not safe since if you can recover the old encrypted key the new data can be recovered using the old password. The old password is not secret, and can imagine three ways to recover the old encrypted key. First of all it might be that it is the same on all medias sold by this manufacturer, so the attacker could just buy another media of the same model. The second way would be if the manufacturer used different keys for each media, but kept a copy. The third way would be if the old key could actually be recovered from the actual media. Maybe it wasn't securely erased.
If you always reencrypt the entire media when changing password, you don't have to worry about the attacks I just described. But many products will let you change password without reencryption. I have not yet seen any implementation of safe and efficient password change.
But there are more possible attacks, assuming an adversary that does just steal your disk is a bit too simplistic. The adversary may be in a position to perform a chosen plaintext attack. Do you put emails on your encrypted media? Do you think an adversary would never be able to send something that you would eventually put on your encrypted media? If the adversary can perform chosen plaintext attacks, then some products are vulnurable to watermarking attacks.
Some of these attacks only leaks minor amounts of data. But how much data do you want to leak? Do you want to use an encryption, where you know some small amounts of data will easilly be leaked to the adversary?
If the model is that they have access to the disk inbetween times that you're using it, that's when things get interesting.
Yes, that is interesting. I have a chapter about it in my dissertation:-)
I'm not aware of any interesting current work on full-disk encryption apart from Rogaway et al's interesting large-tweaked-blockcipher mode CMC - if you know any please enlighten me, thanks!
I only reacently heard about tweaked cihpers. I have not yet had time to read about it, but I will find some time soon. I have a few references which may be of interest, I have not yet read all of them. I think one of them is the one you mentioned as well. And notice that I'm one of the authors on the last paper:
K.Gjøsteen: Security Notions for Disk Encryption, the Eprint archive,
no. 2005-88, www.iacr.org
P.H.Kamp: GBDE-GEOM Based Disk Encryption. Proc. of BSDCon 2003:
57-68, www.usenix.org.
S.Halevi and P.Rogaway: A Tweakable Enciphering Mode. Proc. of
Crypto 2003: 482-499
Markku-Juhani O. Saarinen,
"Encrypted Watermarks and Linux Laptop Security".
In C. H. Lim and M. Yung (Eds.) Information Security Applications,
5th International Workshop, WISA2004, Jeju Island, Republic of
Korea, August 23-25, 2004. Lecture Notes in Computer Science 3325,
Springer Verlag 2004. pp. 30-41.
Ivan Damgård and Kasper Dupont: Universally Composable Disk Encryption Schemes, the Eprint archive, no. 2005-333, www.iacr.org.
As far as I can see in the README file, it uses deterministic IVs. That makes it vulnurable to the same kinds of attacks as most other disk encryptions. The v3 format may be some of the best which could be achieved with a deterministic encryption, but a probabilistic encryption should have been used instead. GBDE is the only disk encryption I know about which uses probabilistic encryption. But I'm not so sure about the cherrypicker.
As far as encryption goes, for god's sake don't rely on anything the manufacturers ship.
I agree. And don't rely on full disc encryption products. We are just starting to understand the security issues of full disc encryptions, it will be a few years before I'd expect manufacturers to start understand it as well and be able to implement something secure. For now GBDE is probably the most secure, but even that isn't perfect. gpg --symmetric --cipher AES256 would probably beat any full disc encryption when it comes to security.
Use Blowfish or Twofish for proper 2 way encryption.
Uhm, what is a two way encryption? And I'd advice against blowfish as it only uses 64 bit cipher blocks. Go for something with at least 128 bit cipher blocks and even more if you have many GB of data. AES256 have 256 bit keys and 128 bit blocks, which I think should be sufficient as long as you don't need to encrypt more than 64GB of data in the key's lifetime.
Flash memory is usually designed to rotate through the available empty space
The flash doesn't know which sectors are empty, only the file system knows that, which is a different layer. So what you describe would require the flash to be larger than advertised and use this extra space for the purpose. Assuming it actually works that way, then were does it keep information about correspondance between logical and physical sectors, and how does it avoid overwriting this all the time? No doubt it is possible, but do they actually put such complicated stuff in the flash? And does it mean, that we no longer have any need for the file systems able to handle this?
First of all the way it is stated is a bit too general. It is not enough for x and y to cause a collision in the final hash, they must cause a collision in the internal state of the hashing algorithm. But all the hash collisions which have been found so far worked by finding a collision in the internal state, in which case the statement is true for any hash algorithm.
You may find algorithms claimed not to be vulnurable to this kind of attack. The reality just is, that their internal state is larger than the final hash. So you can generate a hash collision without generating a collision of the internal state. Is that a strength? That really depends on how you define the strength of a hash function.
Assume we have two hash functions that work the same except that one produce a hash value which is shorter than the internal state where the other use the entire internal state as hash. Which of the two is the strongest? You'd expect the one with the longest hash output to be the safest, and the way I described it there is no way you could find a collision for the long hash without also finding a collision for the short hash. However the long hash is not as much safer as you would expect from the length.
Typically the internal state of a hash algorithm is of constant size. And it is clearly not practical to let the internal state grow as large as the input. For that reason there exist collisions in the internal state of any hash algorithm, and when one is found, all bets are off. So it is really a tradeoff between size of internal state, size of hash value, performance and security.
And no - raid-5 doesn't match raid-0 for speed even on reads, at least not in my linux software raid setup.
What measurements do you have to back up that claim? Unless you are careful about it, you are going to end up doing both reads and writes, and it doesn't take many writes to reduce the performance of a raid5. I know sequential reads can be slightly faster on raid0 than raid5, but only as long as the disks are the bottleneck. If the PCI bus becomes the bottleneck, it will not matter anymore. And three disks are more than enough to saturate a 33MHz 32bit bus. For random access you shouldn't expect much of a difference between raid0 and raid5. Each logical sector exist only in one physical sector, so you can expect the same number of seeks on the same drives. And if you can sometimes save a seek because the head was already on the right chunk, it will be so on raid0 as well as raid5. In a few rare occasions raid5 may even be able to chose between reading the data and the parity because all the other sectors are cached, in this case performance could be improved by sending the read to the least busy disk or the one that would need the shortest seek. On raid1 random access reads can be even faster as the raid can always chose between multiple disks. If performance is the main priority I'd test a raid 1+0 with those four disks.
I keep my games installed on a 4-stripe raid-0 volume, since it helps considerably with level load times
You could probably match the read performance or at least get close if you were using raid-5 rather than raid-0, and it would give you much more data security. It is on write performance you see the significant difference between raid-0 and raid-5.
Moreover, having a second core doesn't make interrupt handling latency decrease
In fact it may even increase the interrupt latency. The fact that a single CPU system could process a network interrupt faster than a dual CPU system was one of the reasons the Horseshoe cluster was build using single CPU systems.
you can't just throw the topic because you can think of a method to protect.
I gave not one, but two ways to protect against this. One was the user picking a good password, the other was a sensible software design. That means you will need to combine a stupid developer with a stupid user if you want to be vulnurable.
I inserted a number of hashes for common first names and dictionary words, and none of them returned a hit.
You wouldn't by any chance be using the md5sum command line utility and typing a newline after the word? I just tried my own name, which turned out to be in the database. Could you give just a few examples of the hash values you submitted, and the word you expected it to return?
Any system using plain md5 to hash passwords is broken anyway. Include a salt - and any database over hashes will become useless. Besides if people choose good passwords, they are most likely not in the database. That is already two reasons why people should be protected, do we need anymore?
For many other uses of cryptographic hashes the input is much more than a single word, and typically you don't really worry about keeping the input a secret anyway.
Though the parent post is moderated troll, there still is one good point, namely the question in the subject.
What value is a graphics card comparison to me, if it doesn't tell me which of them will work with my system? Two additional pieces of information would make the comparison very valuable.
Don't worry, they can't pronounce your name either. (I have actually heard one of these Chinese try to speak English. I didn't understand a word of what she was saying... except from MD5 a few times.)
how would the web services proposal of GPL v3 affect google's web service's?
I don't know how the license is going to end up looking, and I don't know if copyright even can be used to impose additional restrictions. Copyright limits the copying of a work, using the work is something different. Even if they manage to come up with a way to impose such restrictions in GPL version 3, Google could keep using the same software as they do today which will still be covered by GPL version 2.
If GPL version 3 impose restrictions not imposed by GPL version 2, then merging the two would be a violation of the GPL version 2 license unless the software includes the "or (at your option) any later version" statement. Most projects do, but Linux does not, so for Linux it will always be GPL version 2 that applies. It would be kind of weird if GPL version 2 is going to be incompatible with GPL version 3.
My understanding is that it is easy to generate multiple messages that have the same MD5 hash, but only if you get to choose both messages. It's still very hard (i.e., an infeasibly large number of CPU cycles for most of us) to generate data that yields the same MD5 hash as some other, arbitrary document.
That is basically correct. Easy might be an exaggeration, but at least it has been done using lots of CPU power. And though you have to be able to choose parts of each message, you don't have to be able to choose all of it. So it might be possible, that if you gave me two different pictures A and B, I could produce two new pictures A' and B' with same MD5 hash such that A and A' looks exactly the same, and B and B' also looks the same. But since I had to match the MD5 sum of A, this wouldn't help me. The reason I say it might be possible is, that so far this have only been demonstrated with postscript files. It is a bit more difficult to do in a format which does not contain some kind of programming language.
Sounds like a good idea, let's hope they have figured out a license, that will work well. Maybe an overall principle in such a license could be, that anybody can use the patented technology in open source products, and you can only use it in closed source products if you make all your own patents available for everybody to use under the same license.
Putting Stallman on the stand is about the only way to fuck the case up.
Don't send a hacker to do a lawyers job. Even if FSF were to get involved, it doesn't have to involve RMS. Send Eben Moglen, he'd probably do a good job.
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.54 [en]
The interesting part is, that if read the HTTP specification, and then interpret accordingly, this string contains three product tokens and one comment. The product tokens are "Mozilla/4.0", "Opera", and "7.54". So actually it does not identify itself as MSIE, neither does IE. The [en] part is syntactically wrong, and really should have been part of a comment. Another mistake is that "Opera" and "7.54" are given as two different product names. Adjusting according to the specification, the user agent string should have been "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera/7.54 (en)"
I'm sure if you count what browsers really identify themselves as, Mozilla will be a clear winner. Mozilla, IE, and FireFox all identify themselves as Mozilla.
If the article had been named "Opera to Stop Spoofing User Agent as Mozilla", it would have been technically correct.
Not to mention if you have an array of 15 disks in a RAID-5, there's a higher chance of two failures happening simultaneously, than if you have only 5.
Then use RAID-6 with a hotspare. You still have 12 disks for data which means 50% more storage than you would get from 5 of the larger disks in a RAID-5. And I do believe RAID-6 with hotspare is more secure than RAID-5, even when the RAID-6 have single failures more often.
Slashdot Mirror
A block cipher in CTR mode does a good job
It may do a good job as long as the adversary does not get access to more than one copy of the ciphertext. But if the adversary is able to get copies of the same sector from two different points in time, CTR provides no security. In this respect I think CTR is worse than CBC with fixed key and deterministic IV.
The goal of this is to waste as much upstream bandwidth as possible so that others suffer.
I agree that seems to be the weakest point of a torrent. I have another twist to this attack, though I don't know, if it is going to work or not. While downloading from a peer, you could use a modified TCP implementation, that acknowledges lost TCP packets, even if a few are lost. Assuming you receive packet number 10, 13, and 15, you could acknowledge the full range from 10-15. That way you could trick the TCP layer on the sender to believe, there is much more bandwidth available, than there really is. If this works, they will essentially DoS their own upstream to the extent where even downloads will suffer because of lost acks. Of course a correctly configured ratelimit would solve that problem.
The problem with peers uploading fake data could be made even smaller than it currently is. Why does a full piece have to be transfered before it can be verified? Rather than just hashing the full sequence of bytes, a hash tree could be used. Then you could show correctness of units as small as 56 bytes at little extra cost. Of course this should only be used in the beginning. Once two peers starts having trust in each other they only show correctness of larger units. It also could be used in the end when two peers are nearly finished and fear the other peer would drop the connection as soon as he finishes.
Very much indeed.
If your attack model is simply that the encrypted disk falls into the hands of the bad guys who try to get the data from it, the problem is easy.
It is easier, but not as easy as you might guess. Assuming the disk is stolen, and assuming that cannot happen without the owner noticing, then I think we can ignore the data integrity questions. That still leaves us with some worries though.
First of all you have to worry about birthday attacks. Which is why 64 bit cipher blocks should be avoided. AFAIR a 500GB disk encrypted with a single key and a 64 bit cipher block would result in approximately 100 collisions assuming there were no weaknesses in the cipher.
What you also have to worry about is change of passwords. Most disk encryptions doesn't really do that safely. Assume the media was preencrypted using some default password, and the first thing you do is to change the password. This is not safe since if you can recover the old encrypted key the new data can be recovered using the old password. The old password is not secret, and can imagine three ways to recover the old encrypted key. First of all it might be that it is the same on all medias sold by this manufacturer, so the attacker could just buy another media of the same model. The second way would be if the manufacturer used different keys for each media, but kept a copy. The third way would be if the old key could actually be recovered from the actual media. Maybe it wasn't securely erased.
If you always reencrypt the entire media when changing password, you don't have to worry about the attacks I just described. But many products will let you change password without reencryption. I have not yet seen any implementation of safe and efficient password change.
But there are more possible attacks, assuming an adversary that does just steal your disk is a bit too simplistic. The adversary may be in a position to perform a chosen plaintext attack. Do you put emails on your encrypted media? Do you think an adversary would never be able to send something that you would eventually put on your encrypted media? If the adversary can perform chosen plaintext attacks, then some products are vulnurable to watermarking attacks.
Some of these attacks only leaks minor amounts of data. But how much data do you want to leak? Do you want to use an encryption, where you know some small amounts of data will easilly be leaked to the adversary?
If the model is that they have access to the disk inbetween times that you're using it, that's when things get interesting.
Yes, that is interesting. I have a chapter about it in my dissertation
I'm not aware of any interesting current work on full-disk encryption apart from Rogaway et al's interesting large-tweaked-blockcipher mode CMC - if you know any please enlighten me, thanks!
I only reacently heard about tweaked cihpers. I have not yet had time to read about it, but I will find some time soon. I have a few references which may be of interest, I have not yet read all of them. I think one of them is the one you mentioned as well. And notice that I'm one of the authors on the last paper:
What about loop aes?
As far as I can see in the README file, it uses deterministic IVs. That makes it vulnurable to the same kinds of attacks as most other disk encryptions. The v3 format may be some of the best which could be achieved with a deterministic encryption, but a probabilistic encryption should have been used instead. GBDE is the only disk encryption I know about which uses probabilistic encryption. But I'm not so sure about the cherrypicker.
As far as encryption goes, for god's sake don't rely on anything the manufacturers ship.
I agree. And don't rely on full disc encryption products. We are just starting to understand the security issues of full disc encryptions, it will be a few years before I'd expect manufacturers to start understand it as well and be able to implement something secure. For now GBDE is probably the most secure, but even that isn't perfect. gpg --symmetric --cipher AES256 would probably beat any full disc encryption when it comes to security.
Use Blowfish or Twofish for proper 2 way encryption.
Uhm, what is a two way encryption? And I'd advice against blowfish as it only uses 64 bit cipher blocks. Go for something with at least 128 bit cipher blocks and even more if you have many GB of data. AES256 have 256 bit keys and 128 bit blocks, which I think should be sufficient as long as you don't need to encrypt more than 64GB of data in the key's lifetime.
Flash memory is usually designed to rotate through the available empty space
The flash doesn't know which sectors are empty, only the file system knows that, which is a different layer. So what you describe would require the flash to be larger than advertised and use this extra space for the purpose. Assuming it actually works that way, then were does it keep information about correspondance between logical and physical sectors, and how does it avoid overwriting this all the time? No doubt it is possible, but do they actually put such complicated stuff in the flash? And does it mean, that we no longer have any need for the file systems able to handle this?
Is this true for other popular hash functions?
First of all the way it is stated is a bit too general. It is not enough for x and y to cause a collision in the final hash, they must cause a collision in the internal state of the hashing algorithm. But all the hash collisions which have been found so far worked by finding a collision in the internal state, in which case the statement is true for any hash algorithm.
You may find algorithms claimed not to be vulnurable to this kind of attack. The reality just is, that their internal state is larger than the final hash. So you can generate a hash collision without generating a collision of the internal state. Is that a strength? That really depends on how you define the strength of a hash function.
Assume we have two hash functions that work the same except that one produce a hash value which is shorter than the internal state where the other use the entire internal state as hash. Which of the two is the strongest? You'd expect the one with the longest hash output to be the safest, and the way I described it there is no way you could find a collision for the long hash without also finding a collision for the short hash. However the long hash is not as much safer as you would expect from the length.
Typically the internal state of a hash algorithm is of constant size. And it is clearly not practical to let the internal state grow as large as the input. For that reason there exist collisions in the internal state of any hash algorithm, and when one is found, all bets are off. So it is really a tradeoff between size of internal state, size of hash value, performance and security.
And no - raid-5 doesn't match raid-0 for speed even on reads, at least not in my linux software raid setup.
What measurements do you have to back up that claim? Unless you are careful about it, you are going to end up doing both reads and writes, and it doesn't take many writes to reduce the performance of a raid5. I know sequential reads can be slightly faster on raid0 than raid5, but only as long as the disks are the bottleneck. If the PCI bus becomes the bottleneck, it will not matter anymore. And three disks are more than enough to saturate a 33MHz 32bit bus. For random access you shouldn't expect much of a difference between raid0 and raid5. Each logical sector exist only in one physical sector, so you can expect the same number of seeks on the same drives. And if you can sometimes save a seek because the head was already on the right chunk, it will be so on raid0 as well as raid5. In a few rare occasions raid5 may even be able to chose between reading the data and the parity because all the other sectors are cached, in this case performance could be improved by sending the read to the least busy disk or the one that would need the shortest seek. On raid1 random access reads can be even faster as the raid can always chose between multiple disks. If performance is the main priority I'd test a raid 1+0 with those four disks.
I keep my games installed on a 4-stripe raid-0 volume, since it helps considerably with level load times
You could probably match the read performance or at least get close if you were using raid-5 rather than raid-0, and it would give you much more data security. It is on write performance you see the significant difference between raid-0 and raid-5.
Moreover, having a second core doesn't make interrupt handling latency decrease
In fact it may even increase the interrupt latency. The fact that a single CPU system could process a network interrupt faster than a dual CPU system was one of the reasons the Horseshoe cluster was build using single CPU systems.
you can't just throw the topic because you can think of a method to protect.
I gave not one, but two ways to protect against this. One was the user picking a good password, the other was a sensible software design. That means you will need to combine a stupid developer with a stupid user if you want to be vulnurable.
I inserted a number of hashes for common first names and dictionary words, and none of them returned a hit.
You wouldn't by any chance be using the md5sum command line utility and typing a newline after the word? I just tried my own name, which turned out to be in the database. Could you give just a few examples of the hash values you submitted, and the word you expected it to return?
Any system using plain md5 to hash passwords is broken anyway. Include a salt - and any database over hashes will become useless. Besides if people choose good passwords, they are most likely not in the database. That is already two reasons why people should be protected, do we need anymore?
For many other uses of cryptographic hashes the input is much more than a single word, and typically you don't really worry about keeping the input a secret anyway.
What value is a graphics card comparison to me, if it doesn't tell me which of them will work with my system? Two additional pieces of information would make the comparison very valuable.
Even if they are unpronouncable
Don't worry, they can't pronounce your name either. (I have actually heard one of these Chinese try to speak English. I didn't understand a word of what she was saying... except from MD5 a few times.)
The did a minor change to the algorithm, but didn't tell anyone why they changed it, and what attack that change was meant to fix.
I have heard something like that before, except last time I heard it, it was about DES. Did the same thing happen with both DES and SHA?
Although it may cause one of those universe destroying events.
No, it will just give you a very slow system. Oh, maybe in your world those two are the same?
how would the web services proposal of GPL v3 affect google's web service's?
I don't know how the license is going to end up looking, and I don't know if copyright even can be used to impose additional restrictions. Copyright limits the copying of a work, using the work is something different. Even if they manage to come up with a way to impose such restrictions in GPL version 3, Google could keep using the same software as they do today which will still be covered by GPL version 2.
If GPL version 3 impose restrictions not imposed by GPL version 2, then merging the two would be a violation of the GPL version 2 license unless the software includes the "or (at your option) any later version" statement. Most projects do, but Linux does not, so for Linux it will always be GPL version 2 that applies. It would be kind of weird if GPL version 2 is going to be incompatible with GPL version 3.
My understanding is that it is easy to generate multiple messages that have the same MD5 hash, but only if you get to choose both messages. It's still very hard (i.e., an infeasibly large number of CPU cycles for most of us) to generate data that yields the same MD5 hash as some other, arbitrary document.
That is basically correct. Easy might be an exaggeration, but at least it has been done using lots of CPU power. And though you have to be able to choose parts of each message, you don't have to be able to choose all of it. So it might be possible, that if you gave me two different pictures A and B, I could produce two new pictures A' and B' with same MD5 hash such that A and A' looks exactly the same, and B and B' also looks the same. But since I had to match the MD5 sum of A, this wouldn't help me. The reason I say it might be possible is, that so far this have only been demonstrated with postscript files. It is a bit more difficult to do in a format which does not contain some kind of programming language.
announced a patent acquisition campaign for OSS.
Sounds like a good idea, let's hope they have figured out a license, that will work well. Maybe an overall principle in such a license could be, that anybody can use the patented technology in open source products, and you can only use it in closed source products if you make all your own patents available for everybody to use under the same license.
Putting Stallman on the stand is about the only way to fuck the case up.
Don't send a hacker to do a lawyers job. Even if FSF were to get involved, it doesn't have to involve RMS. Send Eben Moglen, he'd probably do a good job.
So in reality, it's Opera spoofing Mozilla 4.0 spoofing MSIE 6.0 spoofing Opera...
Not exactly, but close. In reality it is Opera spoofing MSIE/6.0 spoofing Mozilla/4.0.
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.54 [en]
The interesting part is, that if read the HTTP specification, and then interpret accordingly, this string contains three product tokens and one comment. The product tokens are "Mozilla/4.0", "Opera", and "7.54". So actually it does not identify itself as MSIE, neither does IE. The [en] part is syntactically wrong, and really should have been part of a comment. Another mistake is that "Opera" and "7.54" are given as two different product names. Adjusting according to the specification, the user agent string should have been "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera/7.54 (en)"
I'm sure if you count what browsers really identify themselves as, Mozilla will be a clear winner. Mozilla, IE, and FireFox all identify themselves as Mozilla.
If the article had been named "Opera to Stop Spoofing User Agent as Mozilla", it would have been technically correct.
I didn't even notice that mistake. I did however notice how wrong they spelt "development model".
Not to mention if you have an array of 15 disks in a RAID-5, there's a higher chance of two failures happening simultaneously, than if you have only 5.
Then use RAID-6 with a hotspare. You still have 12 disks for data which means 50% more storage than you would get from 5 of the larger disks in a RAID-5. And I do believe RAID-6 with hotspare is more secure than RAID-5, even when the RAID-6 have single failures more often.