the key, no, but log(10) of the key, you might well be able to have a fare guess at, and that already eliminates one hell of a lot of the factorization troubles...
Who modded you insightful? and more to the point, what was the last version of the kernel you used? 2.0?
What http.sys does is exactly the same as the khttpd you find in the 2.4 kernels. Hint, there's a reason it isn't in 2.6: it's not needed and is a walking security hole by definition.
Kernels don't run anything which can be done just as well in user space.
And before you get chatty, Linux is a layered kernel, not a monolithic one...
Anywhere near 1 amp is enough to fry you. 500mA will put your heart to rest in an instant, and in case of prolonged exposure (ie 0.5 seconds and up) 100-200mA will do the same.
Back here in the Real World, gas tanks are hardened, so that only the most violent shock would produce a rupture, and are also positioned at the opposite end of the vehicle from the major source of ignition (ie the engine).
You really have to try really hard/be very (un)lucky to get a car to explode.
I think we also have to remember that firefox/bird and thunderbird are just working names, when this stuff goes gold, it will just be called mozilla browser and mozilla mail.
OTOH I did like being able to refer to 'the birds', and would appreciate 'the foxes' (or is that foxen?), but I can also understand mozilla.org's reluctance to play name changes any more
God I'm glad I got my secondary education in France....
Seriously, I redid 6th year equiv when coming here, and it felt like I'd jumped 2 years.
And that was 12 years ago...
We're talking about a country here that spends "billions" every year working out better ways to kill people.
Personally I think space exploration would be a much better way to spend this money.
The point is that Windows is not Unix, unix has a layered kernel, windows has a micro kernel, which means that damn near everything runs in user mode (disk access, the lot) and you have different 'levels' of dlls, so in this sense, IE could well be running in what we call the 'kernel'...
While there is still fighting, the war isn't over.
It'll be over the day that not one person/being even thinks of using a product different from the 'standard'. And be that standard OOo, MS Word or Lyx, I hope that day never comes.
You have just pointed out the #1 reason why sysadmins who compile from source on production servers need a beating with a clue stick.
I'm not going to get all superior, because I know that at one time, I did the same thing.
The point is, to put something new on a production machine (like samba with acl support for debian) you:
-Compile it on a development box with prefix=/tmp/what_you_want
-Make a package of it
-test the package on a second test box to make sure it works
-install the package on your server
This provides several advantages besides the one you stated:
Firstly, you never have to have dev tools on your production server (and a lot of rootkits depend on these being present).
Secondly, you are sure that when you deploy, it's quick and painless, and you won't brake your server with a botched compile.
Thirdly, you can deploy then on multiple servers quickly and efficiently.
In short, what the grandparent is saying is that we will soon be able to encrypt so strongly that even with the entire universe as a computer, you wouldn't be able to get through it in a reasonable timeframe. Also, by then quantum crypto should be fairly commonplace, which solves the problem.
I'll take that, providing that you can prove that the processor speed is the limiting factor using today's hardware, which considering that harddisk encryption is (relatively) commonplace, and (processor speed)/(network bandwidth) has gone up by an order of magnitude or 2 in recent years, I somehow doubt.
Along with jsac's comment (more processor power exponentially benefits encryptors, only linearly benefits crackers, on the whole more power means a win for encryptors), I'd like point out this is only a set-back for encryption in-as-much as encryptors claim that their encryption will keep your data safe for all time. Which is to say, at least for the reputable encryptors, this isn't a set back at all.
Forgive my ignorance, but in this case isn't this going to play ageinst encryptors, since encrypting/decrypting is already fairly straight forward, so added optimizations will only provide a marginal gain, whereas for crackers, who have to do extremally heavy computation over a large range of numbers, the possible speed ups are enormous.
IIRC this technique has been used before, in a proof of concept case, where they found that the easiest solution was just to through an EE at the problem, and use specialized hardware for the crack.
Apple meet orange, the whole discussion is about processor speed, and you bring network bandwidth of all things into the equation.
It's already been pointed out that network intensive applications are among those that will benefit the least, since the processor isn't the limiting factor.
Try running your SSL server with double sized keys, same number of users, you'll get a completely different experience.
So? the only reason crypto works at the moment is because cracking is several hundred orders of magnitude slower than encrypting/decrypting.
Taking more time to encrypt/decrypt isn't a problem (does anyone here notice the differance between 2.5ms and 5ms?) but reducing the crack time by the same proportions means that codes that were built to last years might only last months, or even mere weeks, which is a real problem.
Slashdot Mirror
Ehh, since when did a security patch change the dependency tree? That ones new on me.
And for the record, most desktop Linux users have one click updating now (and debianers even have 0 click updating) so your point is pretty moot.
OTOH, for the case of fairness, every OS has it's security problems, we should judge them on how they handle them.
the key, no, but log(10) of the key, you might well be able to have a fare guess at, and that already eliminates one hell of a lot of the factorization troubles...
Thanks, I've got my 8 now...
Hand grenade, don't know, but a nuclear bazooka does (or, at least I hope, did) existe: the Davy Crockett.
Some info on what this hideous piece of equipement was capable of is here.
Additional info can be found here
forgot, some more ideas:
Bad spelling
Grammar nazi
Cowboy Neal posted!!!
This would be great for a /. pol:
Favorite new mod option:
Karma Whore (neg)
Sarcasm (pos)
Stupid (neg)
.
.
.
You get the idea, I'm sure we could think up some better ones than that, if I get many (any?) replys, I might submit a poll suggestion afterwoods...
Who modded you insightful? and more to the point, what was the last version of the kernel you used? 2.0?
What http.sys does is exactly the same as the khttpd you find in the 2.4 kernels. Hint, there's a reason it isn't in 2.6: it's not needed and is a walking security hole by definition.
Kernels don't run anything which can be done just as well in user space.
And before you get chatty, Linux is a layered kernel, not a monolithic one...
Anywhere near 1 amp is enough to fry you. 500mA will put your heart to rest in an instant, and in case of prolonged exposure (ie 0.5 seconds and up) 100-200mA will do the same.
You, my friend, watch way too many movies.
Back here in the Real World, gas tanks are hardened, so that only the most violent shock would produce a rupture, and are also positioned at the opposite end of the vehicle from the major source of ignition (ie the engine).
You really have to try really hard/be very (un)lucky to get a car to explode.
Well in that case, it should be renamed thunderfox to keep the ties between mail and browser apparent.
But mabey that's not what they want anymore?
I think we also have to remember that firefox/bird and thunderbird are just working names, when this stuff goes gold, it will just be called mozilla browser and mozilla mail. OTOH I did like being able to refer to 'the birds', and would appreciate 'the foxes' (or is that foxen?), but I can also understand mozilla.org's reluctance to play name changes any more
God I'm glad I got my secondary education in France.... Seriously, I redid 6th year equiv when coming here, and it felt like I'd jumped 2 years. And that was 12 years ago...
We're talking about a country here that spends "billions" every year working out better ways to kill people. Personally I think space exploration would be a much better way to spend this money.
The point is that Windows is not Unix, unix has a layered kernel, windows has a micro kernel, which means that damn near everything runs in user mode (disk access, the lot) and you have different 'levels' of dlls, so in this sense, IE could well be running in what we call the 'kernel'...
The problem being, as soon as you're trained up, you'd be on the hit list.
Hell, with the descriptions you can find on the web, even I could through something together (2 years of CS).
What about the Windows zealots. (cue flame throwers)
Or freedom fighters, it all depends on your point of view
While there is still fighting, the war isn't over.
It'll be over the day that not one person/being even thinks of using a product different from the 'standard'. And be that standard OOo, MS Word or Lyx, I hope that day never comes.
You have just pointed out the #1 reason why sysadmins who compile from source on production servers need a beating with a clue stick. I'm not going to get all superior, because I know that at one time, I did the same thing. The point is, to put something new on a production machine (like samba with acl support for debian) you: -Compile it on a development box with prefix=/tmp/what_you_want -Make a package of it -test the package on a second test box to make sure it works -install the package on your server This provides several advantages besides the one you stated: Firstly, you never have to have dev tools on your production server (and a lot of rootkits depend on these being present). Secondly, you are sure that when you deploy, it's quick and painless, and you won't brake your server with a botched compile. Thirdly, you can deploy then on multiple servers quickly and efficiently.
You still have the same problem, Ars Technica has an article on this called The ultimate limits of computers
In short, what the grandparent is saying is that we will soon be able to encrypt so strongly that even with the entire universe as a computer, you wouldn't be able to get through it in a reasonable timeframe. Also, by then quantum crypto should be fairly commonplace, which solves the problem.
I'll take that, providing that you can prove that the processor speed is the limiting factor using today's hardware, which considering that harddisk encryption is (relatively) commonplace, and (processor speed)/(network bandwidth) has gone up by an order of magnitude or 2 in recent years, I somehow doubt.
Along with jsac's comment (more processor power exponentially benefits encryptors, only linearly benefits crackers, on the whole more power means a win for encryptors), I'd like point out this is only a set-back for encryption in-as-much as encryptors claim that their encryption will keep your data safe for all time. Which is to say, at least for the reputable encryptors, this isn't a set back at all.
Forgive my ignorance, but in this case isn't this going to play ageinst encryptors, since encrypting/decrypting is already fairly straight forward, so added optimizations will only provide a marginal gain, whereas for crackers, who have to do extremally heavy computation over a large range of numbers, the possible speed ups are enormous.
IIRC this technique has been used before, in a proof of concept case, where they found that the easiest solution was just to through an EE at the problem, and use specialized hardware for the crack.
Apple meet orange, the whole discussion is about processor speed, and you bring network bandwidth of all things into the equation. It's already been pointed out that network intensive applications are among those that will benefit the least, since the processor isn't the limiting factor. Try running your SSL server with double sized keys, same number of users, you'll get a completely different experience.
So? the only reason crypto works at the moment is because cracking is several hundred orders of magnitude slower than encrypting/decrypting.
Taking more time to encrypt/decrypt isn't a problem (does anyone here notice the differance between 2.5ms and 5ms?) but reducing the crack time by the same proportions means that codes that were built to last years might only last months, or even mere weeks, which is a real problem.
so since the us invaded, people have stopped dieing of hunger.....
that should be 1000 vs 1200, things seemslightly different don't they