SHA-512 is indeed faster than SHA-256 on 64-bit processors. SHA-512 uses 80 rounds using 64-bit variables on block sizes of 128 bytes, and SHA-256 uses 64 rounds using 32-bit variables on block sizes of 64 bytes. Since on most 64-bit machines 64-bit operations are roughly as fast as 32-bit operations, you see a speed increase because you're processing twice as much data and doing only a little more work (80 rounds versus 64). Both algorithms are very similar internally, so a round in each algorithm generally performs the same amount of computation.
The traditional way to make a longer hash value into a shorter one is to truncate it, using the leftmost bits. This is used with DSA and is generally considered suitable for most purposes. I don't therefore really see a need for SHA-512/t; at best it seems like this is an effort to improve performance.
Technically, Texas has a use tax as well which is identical to the sales tax. Unlike other states, though, we don't have an income tax, and the state constitution makes it practically impossible to impose one. So most Texans don't end up paying the use tax because we have no paperwork to file for income tax, which is how most states collect it.
Texas sales tax is also tricky because the state collects a 6.25% sales tax, and other governmental entities (such as the City of Houston and METRO, the Houston-area transit authority) can collect up to an additional 2% total. Therefore, it's pretty difficult to tell how much sales tax a given Texan is going to pay.
There are basically four levels of security with passwords. The first one is an unencrypted password. It's obvious why this is a bad idea. The second is a hashed password. This is, however, subject to a trivial dictionary attack. The third is salted and hashed, and the last is salted, iterated, and hashed. The benefit of iteration is that it slows down the attacker a huge amount. So while salted and hashed is much better than just hashed, it's not really ideal. OpenPGP provides the last three types and strongly encourages using iteration. WPA2 uses PBKDF2, which is iterated and salted. It's clear that if you want real, cryptographic security, you should be using an iterated and salted method. But using just salt is a much, much better idea than without salt at all.
You can find some of the reasons here. Among them are ZFS, jails, and pf. I've used Debian GNU/kFreeBSD in the past and found pf significantly easier to use than iptables and tc.
Since router advertisements use unique addresses based on a 64-bit prefix and an expanded 64-bit version of the normal 48-bit Ethernet/WiFi MAC address, a/64 is generally the right size. Unless you're using something like DHCPv6, router advertisements are the normal way to get addresses on a local network.
As has been covered on Slashdot before, encrypted WiFi doesn't actually matter if the attacker is also on the same network. Encrypted WiFi prevents attacks from someone not on the network. If you and I are on the same network, I can sniff all your data, period. If you're using HTTPS (or something like SSH), then that data is not very useful to me. But if it's not, I can read it.
I believe those would be git repositories. Since the ID of every commit is based on the entire history of every file, directory, and commit before it, it would be almost impossible to rewrite the history. Sure, Google could do it, but (a) every commit would get a different ID, breaking the ability for everyone to update their repositories trivially, and (b) every individual's copy of the original repository will contain the entire history and every version of every file. There is no practical way to remove those files permanently, and anytime someone pushes their modified version to their server or to github or wherever, they'll come back again.
The reason Mozilla gave for supporting certain video formats in the browser instead of using system implementations is consistency. It avoids cases where one system has a codec installed but another doesn't, leading to hard-to-reproduce problems. It also avoids problems where different platforms' implementations are buggy or implement less than the entire spec.
The App Store imposes additional restrictions on what users can do with the apps. The GPL, which is used by VLC, prohibits additional restrictions. So it is impossible to legally distribute VLC (or any derivative work) through the App Store.
The i387 (and its successors) suck as floating-point hardware; this we know. However, this bug isn't as crippling as it might seem. This bug won't affect amd64 machines running in 64-bit mode where the compiler is GCC (since GCC uses SSE2 in that case). It also won't affect any Mac OS X machines, since they made the smart move to always use SSE2 on Intel hardware since all of the Intel chips they've ever shipped support it. And I think FreeBSD uses double precision mode by default, so this probably won't affect them either, unless PHP puts the libc into extended-precision mode.
Actually, Microsoft's EULAs disclaim liability just like FLOSS licenses do. The difference is that Microsoft has deep pockets. Your average FLOSS project does not.
Everyone does not necessarily need a distributed source control system. (Although I use one and am happy with it.) But if you're ever sending your programmers out of the office somewhere and expect them to do work, distributed source control is essential, since they may not have access to the Internet wherever they're going.
You can find the information on Intel's own site: http://www.intel.com/technology/anti-theft/ . The 3G kill switch requires the operating system to keep working, but there are other disable mechanisms, such as a watchdog, that don't.
Generally, policies end up being legally binding. Companies that have had certain non-discrimination policies (say, on the basis of sexual orientation) but ended up violating them have been successfully sued. Basically, if you end up doing anything in reliance on a company policy, it's legally binding.
That, of course, is why most privacy policies are extremely vague and one-sided.
That's true. But iteration does. For example, WPA requires 4096 iterations of PBKDF to make it prohibitively expensive to attack the passphrase. OpenPGP does something similar to generate a key from a passphrase.
Java is supposed to be cross-platform. But the Java VM and standard libraries need to be ported to whatever architecture and platform. For example, Java needs networking support, which it gets through native code to the Berkeley sockets interface. Code to handle sound is also likely to require native code.
So basically, programs written in the Java language or for the Java virtual machine are only cross-platform because people have already put work into abstracting these differences away by porting the JVM code.
Most (if not all) RIRs require some sort of demonstration of need. If you ask for a/16, you're going to need to show that you really need all those addresses. If you don't, they won't hand them out. So it's unlikely that anyone is going to be able to stockpile addresses.
Yes. Furthermore, the purpose of a trademark is to prevent confusion in a certain field of endeavor. It's completely acceptable to use a trademark to refer to the entity in question. So if I trademarked "bk2204", it's entirely within your rights to use it in pretty much any context as long as you're actually referring to me, whether or not those references are flattering.
If you use "bk2204" to say untrue and defamatory things about me, that's libel (or slander), but that's because they're untrue and defamatory. Whether I have a trademark on that name is irrelevant.
That's not my experience. When I was a kid, the joystick was always on the left side of the computer (because there wasn't any space to put it on the right side). Consequently, I always used the joystick left-handed, even though I'm right-handed. Finding an ambidextrous joystick was exceptionally difficult, let alone one specifically for left-handers.
Basically, the problem here is that ASP.NET leaks information about incorrectly decrypted data. If the attacker can get information about the failed decryption, then that's called an oracle. The secure way to handle any sort of decryption error is simply to say "decryption error", regardless of whether it's a padding error, a MAC (message authentication code) error, invalid plaintext, or whatever. You should never give the user the invalid decrypted data or any information about it.
Some SSL/TLS implementations have this problem, too, because they treat a MAC error differently than other decryption errors. Secure implementations, including OpenSSL, have the sane behavior: simply stating that the decryption failed.
A good way to make padding oracle attacks irrelevant is to design protocols to use cipher modes that don't require padding. In other words, instead of using CBC, use CFB. This does have some tradeoffs, but overall CFB is a good choice. (For example, OpenPGP uses CFB.)
I don't know about the UK, but in the US courts don't take kindly to having their time wasted. Lawyers that pursue obviously baseless and meritless cases can be the subject of an ethics complaint to the bar association. And when the person referring your case to the bar association is a sitting judge, that doesn't look so good.
The diagnostic systems that you plug in are very, very expensive. I once had to do some work on an IBM Thinkpad with an ancient version of SCO OpenServer that was running reverse-engineered BMW/Mini diagnostic software. This unit cost $600. The official unit costs $20,000. That $85 charge seems fairly small in comparison.
Even if the standard is a preponderance of the evidence, any other civil case requires an appearance in a courtroom with both sides present to argue it out in front of a judge or jury. Where red light cameras are installed, the tickets are often mailed to the alleged violator without any sort of appearance in a courtroom by the defendant.
I know in Houston the city is trying to get the county to deny vehicle registrations if the red-light tickets are unpaid. It seems that the city has forgotten about the adversarial nature of our judicial system.
Slashdot Mirror
SHA-512 is indeed faster than SHA-256 on 64-bit processors. SHA-512 uses 80 rounds using 64-bit variables on block sizes of 128 bytes, and SHA-256 uses 64 rounds using 32-bit variables on block sizes of 64 bytes. Since on most 64-bit machines 64-bit operations are roughly as fast as 32-bit operations, you see a speed increase because you're processing twice as much data and doing only a little more work (80 rounds versus 64). Both algorithms are very similar internally, so a round in each algorithm generally performs the same amount of computation.
The traditional way to make a longer hash value into a shorter one is to truncate it, using the leftmost bits. This is used with DSA and is generally considered suitable for most purposes. I don't therefore really see a need for SHA-512/t; at best it seems like this is an effort to improve performance.
Technically, Texas has a use tax as well which is identical to the sales tax. Unlike other states, though, we don't have an income tax, and the state constitution makes it practically impossible to impose one. So most Texans don't end up paying the use tax because we have no paperwork to file for income tax, which is how most states collect it.
Texas sales tax is also tricky because the state collects a 6.25% sales tax, and other governmental entities (such as the City of Houston and METRO, the Houston-area transit authority) can collect up to an additional 2% total. Therefore, it's pretty difficult to tell how much sales tax a given Texan is going to pay.
There are basically four levels of security with passwords. The first one is an unencrypted password. It's obvious why this is a bad idea. The second is a hashed password. This is, however, subject to a trivial dictionary attack. The third is salted and hashed, and the last is salted, iterated, and hashed. The benefit of iteration is that it slows down the attacker a huge amount. So while salted and hashed is much better than just hashed, it's not really ideal.
OpenPGP provides the last three types and strongly encourages using iteration. WPA2 uses PBKDF2, which is iterated and salted. It's clear that if you want real, cryptographic security, you should be using an iterated and salted method. But using just salt is a much, much better idea than without salt at all.
You can find some of the reasons here. Among them are ZFS, jails, and pf. I've used Debian GNU/kFreeBSD in the past and found pf significantly easier to use than iptables and tc.
Since router advertisements use unique addresses based on a 64-bit prefix and an expanded 64-bit version of the normal 48-bit Ethernet/WiFi MAC address, a /64 is generally the right size. Unless you're using something like DHCPv6, router advertisements are the normal way to get addresses on a local network.
As has been covered on Slashdot before, encrypted WiFi doesn't actually matter if the attacker is also on the same network. Encrypted WiFi prevents attacks from someone not on the network. If you and I are on the same network, I can sniff all your data, period. If you're using HTTPS (or something like SSH), then that data is not very useful to me. But if it's not, I can read it.
No. It makes it so that nobody can tag you in that photo again (except you).
I believe those would be git repositories. Since the ID of every commit is based on the entire history of every file, directory, and commit before it, it would be almost impossible to rewrite the history. Sure, Google could do it, but (a) every commit would get a different ID, breaking the ability for everyone to update their repositories trivially, and (b) every individual's copy of the original repository will contain the entire history and every version of every file. There is no practical way to remove those files permanently, and anytime someone pushes their modified version to their server or to github or wherever, they'll come back again.
The reason Mozilla gave for supporting certain video formats in the browser instead of using system implementations is consistency. It avoids cases where one system has a codec installed but another doesn't, leading to hard-to-reproduce problems. It also avoids problems where different platforms' implementations are buggy or implement less than the entire spec.
The App Store imposes additional restrictions on what users can do with the apps. The GPL, which is used by VLC, prohibits additional restrictions. So it is impossible to legally distribute VLC (or any derivative work) through the App Store.
The i387 (and its successors) suck as floating-point hardware; this we know. However, this bug isn't as crippling as it might seem. This bug won't affect amd64 machines running in 64-bit mode where the compiler is GCC (since GCC uses SSE2 in that case). It also won't affect any Mac OS X machines, since they made the smart move to always use SSE2 on Intel hardware since all of the Intel chips they've ever shipped support it. And I think FreeBSD uses double precision mode by default, so this probably won't affect them either, unless PHP puts the libc into extended-precision mode.
Actually, Microsoft's EULAs disclaim liability just like FLOSS licenses do. The difference is that Microsoft has deep pockets. Your average FLOSS project does not.
Everyone does not necessarily need a distributed source control system. (Although I use one and am happy with it.) But if you're ever sending your programmers out of the office somewhere and expect them to do work, distributed source control is essential, since they may not have access to the Internet wherever they're going.
You can find the information on Intel's own site: http://www.intel.com/technology/anti-theft/ . The 3G kill switch requires the operating system to keep working, but there are other disable mechanisms, such as a watchdog, that don't.
Generally, policies end up being legally binding. Companies that have had certain non-discrimination policies (say, on the basis of sexual orientation) but ended up violating them have been successfully sued. Basically, if you end up doing anything in reliance on a company policy, it's legally binding.
That, of course, is why most privacy policies are extremely vague and one-sided.
Actually, yes. They were quite pleasant and agreeable. And they were all in Canada.
That's true. But iteration does. For example, WPA requires 4096 iterations of PBKDF to make it prohibitively expensive to attack the passphrase. OpenPGP does something similar to generate a key from a passphrase.
Java is supposed to be cross-platform. But the Java VM and standard libraries need to be ported to whatever architecture and platform. For example, Java needs networking support, which it gets through native code to the Berkeley sockets interface. Code to handle sound is also likely to require native code.
So basically, programs written in the Java language or for the Java virtual machine are only cross-platform because people have already put work into abstracting these differences away by porting the JVM code.
Most (if not all) RIRs require some sort of demonstration of need. If you ask for a /16, you're going to need to show that you really need all those addresses. If you don't, they won't hand them out. So it's unlikely that anyone is going to be able to stockpile addresses.
Yes. Furthermore, the purpose of a trademark is to prevent confusion in a certain field of endeavor. It's completely acceptable to use a trademark to refer to the entity in question. So if I trademarked "bk2204", it's entirely within your rights to use it in pretty much any context as long as you're actually referring to me, whether or not those references are flattering.
If you use "bk2204" to say untrue and defamatory things about me, that's libel (or slander), but that's because they're untrue and defamatory. Whether I have a trademark on that name is irrelevant.
That's not my experience. When I was a kid, the joystick was always on the left side of the computer (because there wasn't any space to put it on the right side). Consequently, I always used the joystick left-handed, even though I'm right-handed. Finding an ambidextrous joystick was exceptionally difficult, let alone one specifically for left-handers.
Basically, the problem here is that ASP.NET leaks information about incorrectly decrypted data. If the attacker can get information about the failed decryption, then that's called an oracle. The secure way to handle any sort of decryption error is simply to say "decryption error", regardless of whether it's a padding error, a MAC (message authentication code) error, invalid plaintext, or whatever. You should never give the user the invalid decrypted data or any information about it.
Some SSL/TLS implementations have this problem, too, because they treat a MAC error differently than other decryption errors. Secure implementations, including OpenSSL, have the sane behavior: simply stating that the decryption failed.
A good way to make padding oracle attacks irrelevant is to design protocols to use cipher modes that don't require padding. In other words, instead of using CBC, use CFB. This does have some tradeoffs, but overall CFB is a good choice. (For example, OpenPGP uses CFB.)
I don't know about the UK, but in the US courts don't take kindly to having their time wasted. Lawyers that pursue obviously baseless and meritless cases can be the subject of an ethics complaint to the bar association. And when the person referring your case to the bar association is a sitting judge, that doesn't look so good.
The diagnostic systems that you plug in are very, very expensive. I once had to do some work on an IBM Thinkpad with an ancient version of SCO OpenServer that was running reverse-engineered BMW/Mini diagnostic software. This unit cost $600. The official unit costs $20,000. That $85 charge seems fairly small in comparison.
Even if the standard is a preponderance of the evidence, any other civil case requires an appearance in a courtroom with both sides present to argue it out in front of a judge or jury. Where red light cameras are installed, the tickets are often mailed to the alleged violator without any sort of appearance in a courtroom by the defendant.
I know in Houston the city is trying to get the county to deny vehicle registrations if the red-light tickets are unpaid. It seems that the city has forgotten about the adversarial nature of our judicial system.