That's nice, but not very relevant to this part of the thread. I was addressing the parent poster's reason for having a BIOS password. Of course, an encrypted filesystem will give you confidentiality and integrity guarantees, but they are not impacted by crappy authorization performed in the BIOS.
Why would they want to if they could take out the hard drive, stick it into a USB/IDE case, connect it to their laptop, install a trojan, then replace the drive?
They'd be insane to put the key into executables (again...). As to trying to remove the key from hardware, Google for "tamper resistant" and browse Ross Anderson's papers. From the MPAA's point of view, tamper resistance is a hard property to achieve. From the basement hacker's point of view, tamper resistant hardware is pretty hard to crack. Have a look through Andrew Huang's "Hacking the XBox" to get a feel for the difficulty.
Oh come on, you can't say there are problems with homegrown protocols without pointing people towards Peter Gutmann's comment on penis-shaped sound waves.:-)
I agree with you for the most part, but I think it is worth stating that using SSL/TLS or SSH does not free you from all problems. Secure (integrity not confidentiality) distribution of public keys is still a significant challenge (to be read as "something that's easy to screw up").
I don't see why different security managers would be necessary. What's needed is to give different rights to each thread, and JAAS allows you to do that.
The parent post is the best so far. Windows has perfectly reasonable authorization mechanisms, and if folk don't use them, they deserve what they get. I would add that it would be worth using a group policy to prevent all but a white-listed set of executables from running (for the proletariat at least).
I'm not sure whether you intended to suggest that OpenBSD led the way on marked pages, but even if you did not someone else might read it that way. This kind of feature is much older. One of the comp.risks posts sums it up:
Buffer overflows and Multics?
Tom Van Vleck
Mon, 23 Feb 2004 16:23:45 -0500
To make a big deal out of providing the 40-year-old feature of marking a
region of memory non executable is kind of sad. Multicians look at each
other and make the rubbing-sticks-together gesture.
It seems to me that the marketing guys and the popular press writers don't
understand the feature, the need for the feature, or what the feature will
and won't accomplish.
It's not magic. It fixes some common problems, leaving other problems
untouched. It's not a substitute for defensive coding and proper management
of storage; all it means is that if there is a mistake, it is more work for
an attacker to exploit it.
As Paul Karger points out, when attackers are frustrated by one measure,
they don't abandon their attacks. They keep looking for other holes. A fix
like this, applied by itself, will lead to a new equilibrium between
attackers and defenders, maybe favoring one or the other, but the game will
remain the same.
Closing one open barn door is good, but it needs to be complemented by a
systematic approach to enumeration of openings, and a method of closing the
openings by architectural design that applies to all openings. So I was
taught by my leaders on the Multics project, including Corby, Bob Morris,
Jerry Saltzer, Ted Glaser, PGN, and many more.
A passive attack is one in which the attacker (the NSA in this case) is unable to insert or modify the message stream. If the NSA have the private keys of the top-level CAs but are unable to take over the server's role in Joe User's SSL connection then they cannot read the plaintext.
I believe SSL certificates issued from the common authorities are registered with the NSA so, no doubt, agree that asking an ISP to log is redundant as the NSA can log all net traffic itself as it can decrypt all web input.
I assume that you mean the private keys of the top-level CAs are held by the NSA. If so, I don't see how that would help them to perform a passive attack on Joe User's SSL connections. Having the private keys of the top-level CAs would allow them to perform an active attack by creating fake certificates, which could then be used to convince Joe User to use SSL to connect to an NSA machine, but that's much more complicated to set up than a passive attack.
That's interesting. Do you have a sense for whether the PATRIOT act includes such a requirement explicitly or whether your legal department is simply asking for something that they might want in the future? I ask because it is not clear why the same requirement would not also apply to IRC, Slashdot forums, etc.
That's incorrect. If you encrypted some uncompressed data (using any well-regarded cipher), then the ciphertext is unlikely to compress. It does not matter whether or the original plaintext is compressed.
After looking at that usage, I should have said: avoid inappropriate, fucked-up terminology. "least common multiple of denominators" is more informative than "least common denominator" and does not clash with "greatest common denominator". I cannot find any reference to "least common denominator" in number theory books, which leads me to suspect that the term is a recent 'innovation' for the elementary school market. I would be interested to hear otherwise.
Also, the meaning of "least common denominator" to which you linked is a poor analogy for the concept you originally wanted. "greatest common denominator" is much more appropriate.
You're addressing the problem of an attacker (the RIAA or their agents) finding you by looking at your network traffic. That's not what they're doing. They are finding nodes that offer files. The problem for the non-lame P2Per is that their node must tell good guys that they have lots of files and must tell bad guys that they have no files. The difficulty is that you can't tell the good guys from the bad guys on the network. One solution is to use private overlay networks, although the recent Finnish case demonstrates that it's hard to keep the "bad guys" (law enforcement in that case) out of the overlay network. Another solution would be use to use recommender systems, perhaps in a PGP style, but I haven't seen a P2P filesharing system that does that yet. Finally, Freenet attempts to give a sending node plausible deniability by hiding the true contents of a file from the sending node.
Oh, in case you meant that you were trying to hide network traffic from your network administrators (also "bad guys" from your point of view), then it would be simpler to use encryption (perhaps layering P2P communication over HTTP/SSL or SSH to avoid arousing suspicion).
You're addressing the problem of an attacker (the RIAA or their agents) finding you by looking at your network traffic. That's not what they're doing. They are finding nodes that offer files. The problem for the non-lame P2Per is that their node must tell good guys that they have lots of files and must tell bad guys that they have no files. The difficulty is that you can't tell the good guys from the bad guys on the network. One solution is to use private overlay networks, although the recent Finnish case demonstrates that it's hard to keep the "bad guys" (law enforcement in that case) out of the overlay network. Another solution would be use to use recommender systems, perhaps in a PGP style, but I haven't seen a P2P filesharing system that does that yet. Finally, Freenet attempts to give a sending node plausible deniability by hiding the true contents of a file from the sending node.
Oh, in case you meant that you were trying to hide network traffic from your network administrators (also "bad guys" from your point of view), then it would be simpler to use encryption (perhaps layering P2P communication over HTTP/SSL or SSH to avoid arousing suspicion).
Slashdot Mirror
RTFA. The teacher didn't notice. The kid confessed when they found him selling the exams.
Phew, OK. It's so hard to tell with some people around here... :-)
That's nice, but not very relevant to this part of the thread. I was addressing the parent poster's reason for having a BIOS password. Of course, an encrypted filesystem will give you confidentiality and integrity guarantees, but they are not impacted by crappy authorization performed in the BIOS.
Why would they want to if they could take out the hard drive, stick it into a USB/IDE case, connect it to their laptop, install a trojan, then replace the drive?
It is if it causes you to be incapable of preventing yourself from taking an action that harms others.
They'd be insane to put the key into executables (again...). As to trying to remove the key from hardware, Google for "tamper resistant" and browse Ross Anderson's papers. From the MPAA's point of view, tamper resistance is a hard property to achieve. From the basement hacker's point of view, tamper resistant hardware is pretty hard to crack. Have a look through Andrew Huang's "Hacking the XBox" to get a feel for the difficulty.
Oh come on, you can't say there are problems with homegrown protocols without pointing people towards Peter Gutmann's comment on penis-shaped sound waves. :-)
I agree with you for the most part, but I think it is worth stating that using SSL/TLS or SSH does not free you from all problems. Secure (integrity not confidentiality) distribution of public keys is still a significant challenge (to be read as "something that's easy to screw up").
I don't see why different security managers would be necessary. What's needed is to give different rights to each thread, and JAAS allows you to do that.
And in the sidenotes the predictions often said something about linking computers and being able to communicate across continents more easily... :-)
The parent post is the best so far. Windows has perfectly reasonable authorization mechanisms, and if folk don't use them, they deserve what they get. I would add that it would be worth using a group policy to prevent all but a white-listed set of executables from running (for the proletariat at least).
I'm not sure whether you intended to suggest that OpenBSD led the way on marked pages, but even if you did not someone else might read it that way. This kind of feature is much older. One of the comp.risks posts sums it up:
A passive attack is one in which the attacker (the NSA in this case) is unable to insert or modify the message stream. If the NSA have the private keys of the top-level CAs but are unable to take over the server's role in Joe User's SSL connection then they cannot read the plaintext.
Don't worry. They're recording all the static too, just in case some sod is using it for one-time pads. :-)
Of course, if two different groups of people happened to use the same static, then there would be an opportunity for some analysis!
I assume that you mean the private keys of the top-level CAs are held by the NSA. If so, I don't see how that would help them to perform a passive attack on Joe User's SSL connections. Having the private keys of the top-level CAs would allow them to perform an active attack by creating fake certificates, which could then be used to convince Joe User to use SSL to connect to an NSA machine, but that's much more complicated to set up than a passive attack.
That's interesting. Do you have a sense for whether the PATRIOT act includes such a requirement explicitly or whether your legal department is simply asking for something that they might want in the future? I ask because it is not clear why the same requirement would not also apply to IRC, Slashdot forums, etc.
I have. I stand by my statement.
Do you want me to call your parents to tell them to stop you reading Slashdot?
That's incorrect. If you encrypted some uncompressed data (using any well-regarded cipher), then the ciphertext is unlikely to compress. It does not matter whether or the original plaintext is compressed.
I stand somewhat corrected.
After looking at that usage, I should have said: avoid inappropriate, fucked-up terminology. "least common multiple of denominators" is more informative than "least common denominator" and does not clash with "greatest common denominator". I cannot find any reference to "least common denominator" in number theory books, which leads me to suspect that the term is a recent 'innovation' for the elementary school market. I would be interested to hear otherwise.
Also, the meaning of "least common denominator" to which you linked is a poor analogy for the concept you originally wanted. "greatest common denominator" is much more appropriate.
"poring"
Least common multiple or greatest common denominator. Pick one. Don't mix and match.
You're addressing the problem of an attacker (the RIAA or their agents) finding you by looking at your network traffic. That's not what they're doing. They are finding nodes that offer files. The problem for the non-lame P2Per is that their node must tell good guys that they have lots of files and must tell bad guys that they have no files. The difficulty is that you can't tell the good guys from the bad guys on the network. One solution is to use private overlay networks, although the recent Finnish case demonstrates that it's hard to keep the "bad guys" (law enforcement in that case) out of the overlay network. Another solution would be use to use recommender systems, perhaps in a PGP style, but I haven't seen a P2P filesharing system that does that yet. Finally, Freenet attempts to give a sending node plausible deniability by hiding the true contents of a file from the sending node.
Oh, in case you meant that you were trying to hide network traffic from your network administrators (also "bad guys" from your point of view), then it would be simpler to use encryption (perhaps layering P2P communication over HTTP/SSL or SSH to avoid arousing suspicion).
Fortunately, religious != ethical. Inclusions between the two sides are left as an exercise.
Well it could be that you are ignoring the criminals that don't get caught because they have watched the TV shows... :-)
You're addressing the problem of an attacker (the RIAA or their agents) finding you by looking at your network traffic. That's not what they're doing. They are finding nodes that offer files. The problem for the non-lame P2Per is that their node must tell good guys that they have lots of files and must tell bad guys that they have no files. The difficulty is that you can't tell the good guys from the bad guys on the network. One solution is to use private overlay networks, although the recent Finnish case demonstrates that it's hard to keep the "bad guys" (law enforcement in that case) out of the overlay network. Another solution would be use to use recommender systems, perhaps in a PGP style, but I haven't seen a P2P filesharing system that does that yet. Finally, Freenet attempts to give a sending node plausible deniability by hiding the true contents of a file from the sending node.
Oh, in case you meant that you were trying to hide network traffic from your network administrators (also "bad guys" from your point of view), then it would be simpler to use encryption (perhaps layering P2P communication over HTTP/SSL or SSH to avoid arousing suspicion).