How did it work out when the Irish tried that? The key word is "survived". The Irish died relying on the potato.

A) this exact story was on Slashdot a couple months ago.
B) judges don't like smartasses who play word games with the law. You can only hope the judge dislikes the NSA even more.

Look up Draco sometime. You just said that slower internet for the third offense is the same as the death penalty on the first offence. Or did you mean that having your internet service turned off for a few months is equalivent to having your eye removed?

You could, you know, stop stealing after you get caught twice.

TLA says:
  "suggests some ongoing shift in user behavior, and likely some net reduction in infringement," Giblin said. However, the research noted that [when everyone e found out the NSA was watching their traffic] encrypted HTTPS increased.

They are assuming that all / most https traffic is piracy. Much more likely, as sites like Google start using https more, and people find out the NSA is watching, people have been using https for routine web traffic.

You can legitimately say that you don't like copyright. Fine. You could almost make a coherent argument that programmers, record producers, and videographers should all work two jobs, one to eat and one (for free) to give you free shit. Kinda silly, but that's at least cogent. When you start saying "it doesn't reduce infringement, and here's the evidence - our study shows that it does, but we wish it didn't, therefore it doesn't" - at that point you've just gone off the deep end and are making yourself look like a complete nutjob.

Issues originating from kernel.org can and have been seen and fixed because each of the thousands of developers has their own copy and sees all changes. An attacker would need root access to everybody's desktops, or at least they'd need to know who might be interested in that area of the kernel and root those developers machines.

You have a point, Red Hat does a LOT more development than Canonical, so maybe that's not the best example.
Offhand, I don't know what the BEST example is. I think you get the point, though. I've just been reading about the different options for caching disk devices on Flash and I noticed the three developers of different implementations, and the fans of the three implementations, assisted in pointing out weaknesses in competing implementations.

Binary blobs are bad, m'kay. No argument there. However, IO-MMUs like VT-d, which is used by Core i* processors, seem to be a pretty strong protection. The approach is simple and therefore should be robust, and it directly handles the root issue, rather than trying to band-aid the symptom as Microsoft Security Essentials and similar do.

It is my understanding that DMA address space is assigned at runtime, but it's allocated at boot time, meaning a device can't gain access to memory not allocated for DMA at boot time. Memory management isn't "my thing", though, the storage stack is, and to some extent early boot is my thing. What you're talking about is handled by the memory management people.

For the Linux kernel, that's how development is done already, for quality control and bloat reduction. Nobody can commit by themselves, it takes at least three people to get a change into mainline. Each developer has their own copy of the tree into which changes are pulled, so they can see all changes that are made, and who made them.

For each part of the kernel, there are a number of people particularly interested in that bit who watch it and work on it. For example, the people making NAS and SAN devices and services keep a close eye on the storage subsystems. Myself, I watch the cm storage stack generally, more specifically LVM, and even more specifically snapshots. There are a few dozen people around the world with special interest in that particular part of the code. No backdoors will come in without some of us spotting it. What COULD happen is that some code could come in that isn't quite as secure as it could be.

It just so happens that I'm a security professional who uses advanced Linux storage systems for a security product called Clonebox, so that's at least one security professional closely watching that part of the code. Thousands of others watch the other parts.

It's convenient that a lot of the development is done by companies like Netapp, Amazon (S3) and Google. You can bet that when Amazon submits code, Netapp and Google are looking closely at it. When RedHat submits something, Canonical will point out any reasons it shouldn't be accepted.

The reason you can boot from a raid card or network is because the BIOS loads and runs BIOS modules from those cards. You may be familiar with the Linux kernel, where most of the functionallity is in modules that become part of the kernel. BIOS is the same. One differentiator between a server motherboard and a consumer one is how much BIOS memory it has, to load modules from many different pieces of hardware. I have one machine with at least four different pieces of hardware that include BIOS. MOST of the BIOS on that machine didn't come with the motherboard.

Yep, the whole thing is stupid. My "black" wife is lighter in color than our "white" friend Kristi, also known as Krispy because she tans often. So there goes the whole black/white thing.

There is such a thing as thug culture. In Boston, you'll find plenty of pale redheads engaged in that culture. It has little to do with race or color, and for Al Sharpton to tell "black" people that they should be part of thug culture is offensive.

High crime is high crime. The areas are what they are. Fuck Jesse Jackson. He's one of the reasons that areas with high black population tend to also have high crime rates.

(This statement has been approved by both my wife and me, who are caramel colored and slightly tan.)

> No, your key is #125125215 in the queue.

In that case, at four hours per key, they'll get to mine in 58,000 years.
It's too bad we can't know for sure that it takes at least a few hours per key, and that it always will. It would be ideal if it took about a day or so per key, with US government level resources.

Which is better marketing than cryptography. To make it REALLY secure, they could add another step, hash it using this function:

function slashHash() {
  return('a');
}

You could never predict the result if they added slashHash to the sequence! :; Note that it doesn't matter if you put slashhash as the last step, the first step, or anywhere in the middle - the whole thing is broken if you have a breakable step anywhere in the procedure.

In the case of KeePass, it's not THAT bad because the thing they are hashing (your password) is probably shorter than either of the hashes, thus easy to guess. An eight character password doesn't provide much security, so not much is being lost. (8-12 characters is insufficient against offline attacks. 10-12 isn't bad for online systems that have server-side brute force /dictionary protection.)

The idea is that because most people's password is their pet's name or something equally easy to guess, KeePass might as well force the attacker to spend a second hashing each guess 500 times. That's not terrible IF you assume the users will choose short, weak passwords. However, it means the attacker does NOT have to guess the right password. They only need to guess any password which collides on any of the 500 rounds! Once the hash matches, hashing a match many more times still results in a match. In that way, it makes it 500 times easier for the attacker.

What that means is that if you did ten million rounds of SHA-256, ANY password would open your KeePass, 'dumb' would always work as an extra password because any password short enough to type will probably collide with "dumb" at one of those 10 million rounds. Of course the user and the attacker both have to sit around waiting for 10 million rounds to finish.

So in summary, more rounds means a) it's easier to guess and b) both the attacker and the user have to wait longer while the rounds run.

To be specific, a hash or signature should only be done once. A DES hash of an MD5 hash is weaker than either DES or MD5, for example.

There is a small exception to the above. Running multiple rounds of the SAME algorithm in a very specific way can sometimes make it slightly more secure against one particular type of attack - brute force. That's a narrow exception, though.

That's my point. They won't spend any money tracking me. Well, not more than about $10-$50, since I'm pretty sure I'm on a list or two. They WILL spend money tracking whoever appears to be the next bin Ladin. Cool. I'd like them to be able to track bin Laden, while it's not anywhere near worth it to track me.

If I were using "1 bit encryption" they WOULD break it. They proof of that is that they DO track people who use 0 bit (plain email, phone). That's bad. I prefer that everyone use encryption enough so NSA finds it worthwhile to track 0-100 people.

Ps - I said I'm probably on a list. I've worked in security for many years, so my footprints can be found looking at information about exploits, etc. I run a system where we teach cybersecurity to state and local government employees, so I frequent sites that a bad guy might find interesting. On top of that, I use words like "freedom" and "Constitution" and we now know the Obama administration considers those words to be red flags.