laffer1 wrote: "This helps if there is a crazy background process eating up CPU and it might even help control flash crushing system performance a bit."
Well, sort of, but not really. A competent video player is fine running along with CPU intensive background processes. The problem is competing for attention with new-born babies.
A parallel 'make' will fork() and exec() short-running processes at the rate of dozens per second. The scheduler will find that each new-born processes has used up zero CPU so far, and therefor put them ahead of the video player and browser, which have already sucked major CPU without completing their work.
A task group for each TTY fixes that particular problem. Each child process has to wait and share the CPU time allocated to its group. Immoral as charging children with debts of their parents may seem, in this case it smooth out our video and web browsing so that's that.
Slashdot isn't about religious dogma. The teachings of the Catholic Church, whether about extraterrestrials or how the Sun orbits the Earth, are of no relevance to the scientific search for life elsewhere in the universe.
Whether intelligent societies elsewhere in the universe developed religions comparably to how we did is perhaps an interesting question. Trying to apply some of our historical myths to beings who evolved completely independently from ourselves is just nonsense.
Data has an "intelligence life": the period in which its exposure is harmful. The NSA ended its Venona project not because they could recover no more plaintext, but because the information was too dated to be of value. U.S. Census data on individuals is seeled for 72 years; then it is public record.
Right now 72 bits is at the outer edge of what we can break exhaustively. If we accept Moore's law as indicating that each 18 months we can take on another bit, then 128 bits is good for 84 years.
The systems here have problems that vastly dominate the difference between 128-bit AES and 256-bit AES. Moreover, we really don't have any systems where direct attack of 128-bit AES is the week link. 128 vs 256 Bit AES is so far down the list of security issues that it should not occupy one second of our attention. Doh! Too late.
I second the "so what". Let's not encourage more companies to make more stupid rules placing more restrictions on what their employees do away from work.
"Nondeterministic finite automata" is well defined in comp-sci and Friedl has it wrong. The set of languages accepted by NFA's is exactly the same as the set accepted by DFA's.
Perl's engine and its brethren use search-and-backtrack. They accept a lot things that are not regular expressions. Such engines don't have much theory behind them, and it's hard to reason generally about what they do and how fast they do it.
The right tools for data integrity are things like reliable transports, error correction codes, RAID, off-site backups, and digital signatures. Modern systems are too complex to tolerate wrong data. Refusing to compress so that we might live with errors in some formats via manual partical data recovery is naive. Engineer the system so it works: compress then add ECC.
>> And considering that a large majority of viruses and malware >> is due to 5cr1p7 k1dd135, and not real hackers, this helps.
> No, because all it takes is one real hacker to reimplement raw > sockets and we've done nothing but punish the good guys.
Exactly. The very term "script kiddy" means one who doesn't really understand how things work, but simply executes someone else's script. One good script is all it takes.
To be clear: The security problem is that the net routs any packets it can, and some TCP/IP stacks will choke upon *receiving* (a flood of) bad packets. Trying to make it difficult to *send* those packets from Windows is essentially useless.
Removing raw socket support from an operation system is a trivial, bogus attempt to hide the problem without fixing it. A root-compromised system can send raw packets no matter what the vendor implements.
There are two reasonable places at which to resist these denial- of-service attack: At the hosts, we can tolerate bogus-packet- floods with things like SYN-cookies or random-early-drop; in the routing infrastructure, we could halt floods of hostile messages from reaching their destinations.
Microsoft's approach here is nonsense. If an attacker takes control of a system, he can send from it any packets he wants.
> use 'Mastering Regular Expressions . It's a good book on the topic as well.
I'm one of the few people who doesn't like Friedl's/Mastering Regular Expressions/. (I have the first edition.)
First, he says that extended regexp engines, such as Perl's, use nondeterministic finite automata (NFA). Not true; NFA's can accept exactly the same languages as DFA's (deterministic finite automata). The extended regexps use search-and-backtrack engines.
Friedl gives some examples of (extended) regexps that have catastrophic worst-case behavior, but doesn't present a systematic method for recognizing or avoiding them. The naive use of extended regexps, mostly by people who think they have mastered them, is setting us up for denial-of-service attacks based on the worst-case complexity of regular expressions.
Formal regular expressions are exactly the languages DFA's and NFA's can accept. A DFA can parse any string in time proportional to the length of the string. Compiling the DFA may be exponential time, and space, but at least we find out at compile time, not when some attacker figures out a case we missed.
Does anyone else find it strange that "the greatest made for TV movies of all time" compares so atrociously to the average episode of 'The Simpsons' or 'NYPD Blue'?
Moreover, track buffers allow the disk to de-couple reading and writing the magnetic media, from transferring data over the bus. The disk should always be able to read one track in one spin (after the seek), then transfer it at whatever bus bandwidth is available.
> For example, there's no law that stacks have to stupidly grow > downwards in memory so that an overflow ends up overwriting > older stuff on the stack space, instead of overwriting in the > direction where the unallocated space is.
That doesn't help much, because the assumption of unallocated space isn't usually true. More often than not, the buffer is allocated then passed to another routine (for example, sprinf). It's actually the called routine that writes the data that overflows the buffer. With a stack that grows upward in memory, the attack simply overwrites sprinf's return address rather than the return address of the function that allocates the buffer.
One PC using the Quadratic Sieve can out-factor all the computer power in the world using the NEO trial-divide method. (The current best factoring algorithm for large composites is the General Number Field Sieve.)
That's nothing compared to the real folly: they were trying to factor a 2048-bit RSA modulus by trial division.
Even using the best algorithms known (which are super-polynomial but sub-exponential), that key size will be out of range for a number of decades. The stupid Neo approach was to find primes and try to divide.
It was not a serious project. Just distributed cluelessness.
> If MS really used "proper" RSA, noone has yet found an > algorithm that is better than brute force.
False. There's Pollard's Rho, the Elliptic Curve algorithm, the quadratic sieve and the number-field sieve. All the successfully factored RSA challenges used sub-exponential algorithms (and large distributed networks).
The NEO project guys are clueless. They're using trial division. Numbers that one Wall-Mart class computer could factor in seconds are far, far out of their grasp.
For reasonable info on how long it should take, see
Arjen K. Lenstra and Eric R. Verheul, Selecting Cryptographic Key Sizes,/Journal of Cryptography/ volume 14 number 4, 2001.
Available on-line from
http://citeseer.nj.nec.com/287428.html
The expected time it should take with the current algorithms, is not definitively known. Nevertheless, we can say the world's X- Boxes are not up to the task.
The story is no more accurate on the technical matters than
the typical press releases about DVD.
D-VHS has been around for a couple years. It stores a digital
data stream on an S-VHS tape. Whether the data is compressed
is irrelevant. The four hours of HD video per tape is for the
MPEG-2 compressed stream.
D-VHS was pulled from the market about a year ago, pending
completion of a copy-protection system similar in spirit to
CSS. The reason for pulling it was not that the old decks
would copy anything, but rather that they would not be able to
play future pre-recorded tapes, since they lack the decryption
system.
The talk about uncompressed data probably refers to picking up
the decoded stream on the way to the display unit.
Slashdot Mirror
laffer1 wrote: "This helps if there is a crazy background process eating up CPU and it might even help control flash crushing system performance a bit."
Well, sort of, but not really. A competent video player is fine running along with CPU intensive background processes. The problem is competing for attention with new-born babies.
A parallel 'make' will fork() and exec() short-running processes at the rate of dozens per second. The scheduler will find that each new-born processes has used up zero CPU so far, and therefor put them ahead of the video player and browser, which have already sucked major CPU without completing their work.
A task group for each TTY fixes that particular problem. Each child process has to wait and share the CPU time allocated to its group. Immoral as charging children with debts of their parents may seem, in this case it smooth out our video and web browsing so that's that.
Slashdot isn't about religious dogma. The teachings of the Catholic Church, whether about extraterrestrials or how the Sun orbits the Earth, are of no relevance to the scientific search for life elsewhere in the universe.
Whether intelligent societies elsewhere in the universe developed religions comparably to how we did is perhaps an interesting question. Trying to apply some of our historical myths to beings who evolved completely independently from ourselves is just nonsense.
Data has an "intelligence life": the period in which its exposure is harmful.
The NSA ended its Venona project not because they could recover no more
plaintext, but because the information was too dated to be of value. U.S.
Census data on individuals is seeled for 72 years; then it is public record.
Right now 72 bits is at the outer edge of what we can break exhaustively. If
we accept Moore's law as indicating that each 18 months we can take on another
bit, then 128 bits is good for 84 years.
The systems here have problems that vastly dominate the difference between
128-bit AES and 256-bit AES. Moreover, we really don't have any systems
where direct attack of 128-bit AES is the week link. 128 vs 256 Bit AES
is so far down the list of security issues that it should not occupy one
second of our attention. Doh! Too late.
I second the "so what". Let's not encourage more companies to make
more stupid rules placing more restrictions on what their employees
do away from work.
Not news, not for nerds, does not matter.
"Nondeterministic finite automata" is well defined in comp-sci
and Friedl has it wrong. The set of languages accepted by NFA's
is exactly the same as the set accepted by DFA's.
Perl's engine and its brethren use search-and-backtrack. They
accept a lot things that are not regular expressions. Such
engines don't have much theory behind them, and it's hard to
reason generally about what they do and how fast they do it.
The right tools for data integrity are things like reliable transports, error correction codes, RAID, off-site backups, and digital signatures. Modern systems are too complex to tolerate wrong data. Refusing to compress so that we might live with errors in some formats via manual partical data recovery is naive. Engineer the system so it works: compress then add ECC.
Or -- let me see if I can get the order right:
compress
encypher
sign
error-control code
--Bryan
>> And considering that a large majority of viruses and malware
>> is due to 5cr1p7 k1dd135, and not real hackers, this helps.
> No, because all it takes is one real hacker to reimplement raw
> sockets and we've done nothing but punish the good guys.
Exactly. The very term "script kiddy" means one who doesn't
really understand how things work, but simply executes someone
else's script. One good script is all it takes.
--
--Bryan
And he is wrong.
To be clear: The security problem is that the net routs any
packets it can, and some TCP/IP stacks will choke upon
*receiving* (a flood of) bad packets. Trying to make it
difficult to *send* those packets from Windows is essentially
useless.
Removing raw socket support from an operation system is a
trivial, bogus attempt to hide the problem without fixing it. A
root-compromised system can send raw packets no matter what the
vendor implements.
There are two reasonable places at which to resist these denial-
of-service attack: At the hosts, we can tolerate bogus-packet-
floods with things like SYN-cookies or random-early-drop; in
the routing infrastructure, we could halt floods of hostile
messages from reaching their destinations.
Microsoft's approach here is nonsense. If an attacker takes
control of a system, he can send from it any packets he wants.
--
--Bryan
> use 'Mastering Regular Expressions . It's a good book on the topic as well.
/Mastering
I'm one of the few people who doesn't like Friedl's
Regular Expressions/. (I have the first edition.)
First, he says that extended regexp engines, such as Perl's, use
nondeterministic finite automata (NFA). Not true; NFA's can
accept exactly the same languages as DFA's (deterministic finite
automata). The extended regexps use search-and-backtrack
engines.
Friedl gives some examples of (extended) regexps that have
catastrophic worst-case behavior, but doesn't present a
systematic method for recognizing or avoiding them. The naive
use of extended regexps, mostly by people who think they have
mastered them, is setting us up for denial-of-service attacks
based on the worst-case complexity of regular expressions.
Formal regular expressions are exactly the languages DFA's and
NFA's can accept. A DFA can parse any string in time
proportional to the length of the string. Compiling the DFA may
be exponential time, and space, but at least we find out at
compile time, not when some attacker figures out a case we
missed.
Does anyone else find it strange that "the greatest made for TV
movies of all time" compares so atrociously to the average
episode of 'The Simpsons' or 'NYPD Blue'?
Moreover, track buffers allow the disk to de-couple reading
and writing the magnetic media, from transferring data over the
bus. The disk should always be able to read one track in one
spin (after the seek), then transfer it at whatever bus
bandwidth is available.
> For example, there's no law that stacks have to stupidly grow
> downwards in memory so that an overflow ends up overwriting
> older stuff on the stack space, instead of overwriting in the
> direction where the unallocated space is.
That doesn't help much, because the assumption of unallocated
space isn't usually true. More often than not, the buffer is
allocated then passed to another routine (for example, sprinf).
It's actually the called routine that writes the data that
overflows the buffer. With a stack that grows upward in memory,
the attack simply overwrites sprinf's return address rather than
the return address of the function that allocates the buffer.
The NEO client is a piece of garbage.
One PC using the Quadratic Sieve can out-factor all the computer
power in the world using the NEO trial-divide method. (The
current best factoring algorithm for large composites is the
General Number Field Sieve.)
That's nothing compared to the real folly: they were trying to
factor a 2048-bit RSA modulus by trial division.
Even using the best algorithms known (which are super-polynomial
but sub-exponential), that key size will be out of range for a
number of decades. The stupid Neo approach was to find primes
and try to divide.
It was not a serious project. Just distributed cluelessness.
> If MS really used "proper" RSA, noone has yet found an
> algorithm that is better than brute force.
False. There's Pollard's Rho, the Elliptic Curve algorithm, the
quadratic sieve and the number-field sieve. All the
successfully factored RSA challenges used sub-exponential
algorithms (and large distributed networks).
The NEO project guys are clueless. They're using trial
division. Numbers that one Wall-Mart class computer could
factor in seconds are far, far out of their grasp.
--
--Bryan
For reasonable info on how long it should take, see
Arjen K. Lenstra and Eric R. Verheul, Selecting Cryptographic Key Sizes,
Available on-line from
http://citeseer.nj.nec.com/287428.html
The expected time it should take with the current algorithms, is
not definitively known. Nevertheless, we can say the world's X-
Boxes are not up to the task.
--Bryan Olson
Freelance Cryptographer
The story is no more accurate on the technical matters than
the typical press releases about DVD.
D-VHS has been around for a couple years. It stores a digital
data stream on an S-VHS tape. Whether the data is compressed
is irrelevant. The four hours of HD video per tape is for the
MPEG-2 compressed stream.
D-VHS was pulled from the market about a year ago, pending
completion of a copy-protection system similar in spirit to
CSS. The reason for pulling it was not that the old decks
would copy anything, but rather that they would not be able to
play future pre-recorded tapes, since they lack the decryption
system.
The talk about uncompressed data probably refers to picking up
the decoded stream on the way to the display unit.