Not really. CPUID is an untrappable ring 3 instruction, so all callers get basically an honest answer.
You'd have to single-step the entire program, or do a speculative emulation to identify the call points then breakpoint them, or something similar, to subvert it.
Well, that's an awful lot of mud you're slinging there. Now, do you have any solid references to back you up?
http://en.wikipedia.org/wiki/Cash_cow
The above is what most people would understand "cash cow" to mean, was how the comment above used it, and is a usage that makes perfect sense.
You also mentioned a clear mistake in Word's spelling checker, that (I just checked) doesn't seem to exist, at least not in my version. (I even tried switching from UK to US English to see if it was a regional thing.)
You also drew attention to the original being posted AC, despite posting as AC yourself.
Clearly trollish behaviour, I just can't see why you picked up on something so inconsequential to troll about. Perhaps you're just a Canadian who took offense at the original's slur but then went off at half cock with the retaliation.
Re:God of the Gaps: Glass half-full or half-empty?
on
Subatomic Darwinism
·
· Score: 1
Not entirely true. If He exists, He needs to be exactly as smart as He needs to be to have achieved what He has achieved. This is a constant regardless of how much we happen to know about it.
As we learn, we are not defining God, any more than we are defining the Universe.
An MP3 player has to load, what, a 5Mb file from the disk? That can be done in a fraction (say, a tenth) of a second. That file will then play for the next 5 minutes or so during which time the disk can be powered down, reducing power consumption due to the disk by a factor of 3000 or so.
Video bandwidth is a lot higher, even compressed, and if you're recording will likely need continuous writing to the drive.
If you can expect, say, 40 hours continuous playback battery life from an MP3 player, then (using these ballpark figures I plucked from thin air, plus other assumptions such as perfectly uniform power consumption my the drive when spun up, equal battery capacity, negligible consumption from other system components etc.) that gives 48 seconds for a device that keeps the drive spinning continuously.
You don't RC. Members of the Party were trained from an early age not only to turn other people in, whether they be stranger, neighbour or close family, but to actively spy on anyone they though "suspicious".
"Search[ing] the entire hashspace" doesn't seem to make a lot of sense - a hash converts an arbitrary sized document into a (often smaller) fixed size value. So there are in theory an infinite number of documents that correspond to each hash. (So none of the following probably means very much until you clarify what you'd be searching for, in what, and how.)
There's an interesting section at the beginning of Applied Cryptography which uses basic physics principals to show that simply counting a 256-bit counter through all values would take far more energy than is available in this universe. Even a 128-bit counter is in trouble purely on energy grounds, and would in any case run out of time in most universe models. Producing all possible key values is fundamental to a brute force attack, and the above analysis said nothing about actually *using* the counted values for anything.
Of course, counting possible hash values gets you nowhere unless you can come up with some cryptanalytic attack which given a hash value, tells you something useful about the documents which could have produced it. For the currently recommended hashes we're nowhere near there yet, and indeed even old hashes were designed to defeat this as best they could, and new hashes do it better.
Now, if you want to go in reverse and see if you can find at least one document that hashes to each possible value your situation doesn't improve since current hashes are designed to defeat deliberate attempts to "work through the process" to attempt to influence the output by tweaking the input - that's how collisions occur. Even if you try to brute force the document space, you have to store the results so far to know what your progress is, which is a truly monstrous (and physically impossible in this universe) amount of storage. And with no way of carefully choosing the input your hitrate on the unexplored parts of the hashspace suffers exponential decay, causing the search to get slower and slower... (which actually doesn't change the status of the problem from impossible at all.)
But once you've finished I'm sure the manager of The Restaurant at the End of the Universe would happily buy your dinner for you.
Well, *down here* they are, maybe.
But if Mars turns out to not support life and never have support life then clearly the most common processes are different over there.
There's a lot of ammonia in inter-stellar space. Far, far more in total than on Earth. Clearly the universally most common process for producing ammonia is *not* biological.
The Microsoft results alone are quite revealing (I couln't find anything recognisable for Oracle or Sun):
Connie E. Ballmer, Homemaker George W. Bush $2,000 Steven A. Ballmer, C.E.O. Microsoft George W. Bush $2,000 Michael J Bernard, Tax Attorney Microsoft Corporation George W. Bush $2,000 William H. Gates, CEO Microsoft Corp. George W. Bush $2,000 George H Zinn, Fianance Microsoft George W. Bush $2,000 William A. Spencer, Marketing Manager Microsoft Corporation George W. Bush $2,000 George A. Spix, Engineer Microsoft George W. Bush $2,000
Jason Black, Manager Microsoft Howard Dean $1,700 Laura John, Lead Program Manager Microsoft Howard Dean $750 James Moe, Software Design Engineer Microsoft Howard Dean $600 Gerald Smith, Computer Trainer Microsoft Howard Dean $500 James Such, Editor Microsoft Howard Dean $500 Brad Merrill, Software Engineer Microsoft John Kerry $500 James R Such, Editor Microsoft Dennis Kucinich $500 David Lee, Software Engineer Microsoft Wesley Clark $500 James Moe, Software Design Engineer Microsoft Howard Dean $400 David Duhon, Software Engineer Microsoft Howard Dean $275 David Duhon, Software Engineer Microsoft Howard Dean $250 Ken Showman, Software Design Engineer Microsoft Howard Dean $250 Rod Such, Editor Microsoft Howard Dean $250 Lynn Armstrong, Programmer/Writer Microsoft Corporation John Edwards $250 Troy Starr, Software Test Engineer Microsoft Carol Moseley Braun $250 James R. Such, Editor Microsoft Corporation Dennis Kucinich $250 Laura Hamill, Org Psychologist Microsoft Wesley Clark $250 Jason Black, Manager Microsoft Howard Dean $200 Michael Kelly, Group Program Manager Microsoft Howard Dean $200 David Lomet, computer scientist Microsoft Wesley Clark $150 Ken Showman, Software Design Engineer Microsoft Howard Dean $125 Gloria Boyer, Technical Writer Microsoft Howard Dean $100 Clara Graham, Developer Microsoft Howard Dean $50 J Brian Smith, Software Design Engineer Microsoft Howard Dean $50
So if you can afford the full limit, you give it to Bush. If you can't, you give it to anyone *but* Bush.
Different sales model.
Offer a selection of complete texts by a variety of authors, and people might then have their interest piqued and go after the other (pay) stuff by those authors. The good stuff sells itself if people can find out about it easily enough.
Offer a single text a chapter at a time, and people lost patience. I'm not surprised. It slowed down people's reading, which makes it harder to keep involved with the plot, and having to keep paying chapter by chapter with no guarantee that you're going to be able to finish the story in the end, even if *you* paid, because of the authors unrealistic threshold, just turned people off to it.
When performing open heart surgery on a switched-mode PSU to replace a blown reservoir cap, remember to switch it off and discharge it before picking it up and laying the PCB flat on your hand.
The GPS signal is *very* hard to jam - it was designed to be so. And I hope the US would think twice about the risks of a large amount of satellite debris floating around in an orbit they might actually want to use themselves.
Having several other sources of GPS or GPS-style data would be of benefit to everyone, partly because no one entity could then control GPS availability or enforce a deliberately degraded signal on the world.
Actually symmetric ciphers are much more secure than the Public/Private Key (per keylength 7kbit RSA ~ 256 AES)
Symmetric and asymmetric ciphers solve completely different problems. Whether one or the other is more secure is a meaningless question. It depends not only on the key size (which could be chosen arbitrarily in either case to 'prove' whatever assertion you wanted), but also on the problem domain and how closely the ciphers in question map to it, and also the current state of the art in cryptanalysis which marches forwards every year.
In fact with PGP and I would guess SSL is the same they only use the Private Public key encryption to securely agree upon a symmetric key to encrypt the data with.
This is a performance issue. Symmetric ciphers simply don't provide the capability that is required for securing ad-hoc channels, but asymmetric ciphers are too slow for encrypting the entirety of the communication. RSA encrypting a 3DES key provides a bridge between the two.
Symmetric keys use XORs are permutations to encrypt and are generally faster.
I don't even know what you're trying to say here, but ciphers built on pure XOR tend to be pathetically weak. The stronger symmetric ciphers use some combination of arithmetic, non-arithmetic, lookup tables, permutation and other methods to build up non-linear functions which are highly resistant to analysis.
At the most fundamental level, even RSA is just a combination of ANDs and NOTs (or equivalent logic). There are slow symmetric ciphers too, though speed in hardware, software or both is generally an important consideration in their design.
Hmm, so if I write a daemon that checks passwords using strcmp, and my C library's implementation stops after the first mismatch, I might have the same hole?
This is the traditional way timing attacks are used. In fact measurement of timing to this precision is often difficult, and the canonical exploit was to place the password across a memory page boundary (first n characters at end of first page, remainder in second page) then ask ths OS to verify it. By testing to see whether a page fault had occurred you knew whether the first n character were right, thus turning an exponential search into a linear one. Same theory, different measurement method.
Assuming I understand this correctly, doesn't that mean a _lot_ of software potentially has this problem?
Not a lot, because this is a well known flaw and any serious password implementation takes steps to avoid it. (Always compare every character in the supplied password, even if you know early on that the whole thing is invalid.)
If the I/O bus specs is going to be around for decades (and it will be obsoleted by an even faster SCSI standard within that time, though it will have a significant installed base), then the system bus specs *will* catch up and exceed its capability.
Slashdot Mirror
Not really. CPUID is an untrappable ring 3 instruction, so all callers get basically an honest answer. You'd have to single-step the entire program, or do a speculative emulation to identify the call points then breakpoint them, or something similar, to subvert it.
It's the volts that jolt, but it's the mills that kill...
"Bugbot searching, Thodin..."
Two game wardens, seven hunters and a cow.
K.315a and BWV 841
Well, that's an awful lot of mud you're slinging there. Now, do you have any solid references to back you up? http://en.wikipedia.org/wiki/Cash_cow The above is what most people would understand "cash cow" to mean, was how the comment above used it, and is a usage that makes perfect sense. You also mentioned a clear mistake in Word's spelling checker, that (I just checked) doesn't seem to exist, at least not in my version. (I even tried switching from UK to US English to see if it was a regional thing.) You also drew attention to the original being posted AC, despite posting as AC yourself. Clearly trollish behaviour, I just can't see why you picked up on something so inconsequential to troll about. Perhaps you're just a Canadian who took offense at the original's slur but then went off at half cock with the retaliation.
Not entirely true. If He exists, He needs to be exactly as smart as He needs to be to have achieved what He has achieved. This is a constant regardless of how much we happen to know about it.
As we learn, we are not defining God, any more than we are defining the Universe.
Wow. Not only does it clear minefields, but it also cooks you a steak dinner while it works!
An MP3 player has to load, what, a 5Mb file from the disk? That can be done in a fraction (say, a tenth) of a second. That file will then play for the next 5 minutes or so during which time the disk can be powered down, reducing power consumption due to the disk by a factor of 3000 or so. Video bandwidth is a lot higher, even compressed, and if you're recording will likely need continuous writing to the drive. If you can expect, say, 40 hours continuous playback battery life from an MP3 player, then (using these ballpark figures I plucked from thin air, plus other assumptions such as perfectly uniform power consumption my the drive when spun up, equal battery capacity, negligible consumption from other system components etc.) that gives 48 seconds for a device that keeps the drive spinning continuously.
You don't RC. Members of the Party were trained from an early age not only to turn other people in, whether they be stranger, neighbour or close family, but to actively spy on anyone they though "suspicious".
"Search[ing] the entire hashspace" doesn't seem to make a lot of sense - a hash converts an arbitrary sized document into a (often smaller) fixed size value. So there are in theory an infinite number of documents that correspond to each hash. (So none of the following probably means very much until you clarify what you'd be searching for, in what, and how.)
There's an interesting section at the beginning of Applied Cryptography which uses basic physics principals to show that simply counting a 256-bit counter through all values would take far more energy than is available in this universe. Even a 128-bit counter is in trouble purely on energy grounds, and would in any case run out of time in most universe models. Producing all possible key values is fundamental to a brute force attack, and the above analysis said nothing about actually *using* the counted values for anything.
Of course, counting possible hash values gets you nowhere unless you can come up with some cryptanalytic attack which given a hash value, tells you something useful about the documents which could have produced it. For the currently recommended hashes we're nowhere near there yet, and indeed even old hashes were designed to defeat this as best they could, and new hashes do it better.
Now, if you want to go in reverse and see if you can find at least one document that hashes to each possible value your situation doesn't improve since current hashes are designed to defeat deliberate attempts to "work through the process" to attempt to influence the output by tweaking the input - that's how collisions occur. Even if you try to brute force the document space, you have to store the results so far to know what your progress is, which is a truly monstrous (and physically impossible in this universe) amount of storage. And with no way of carefully choosing the input your hitrate on the unexplored parts of the hashspace suffers exponential decay, causing the search to get slower and slower... (which actually doesn't change the status of the problem from impossible at all.)
But once you've finished I'm sure the manager of The Restaurant at the End of the Universe would happily buy your dinner for you.
Well, *down here* they are, maybe. But if Mars turns out to not support life and never have support life then clearly the most common processes are different over there. There's a lot of ammonia in inter-stellar space. Far, far more in total than on Earth. Clearly the universally most common process for producing ammonia is *not* biological.
Doh!
So if you can afford the full limit, you give it to Bush. If you can't, you give it to anyone *but* Bush.
Different sales model. Offer a selection of complete texts by a variety of authors, and people might then have their interest piqued and go after the other (pay) stuff by those authors. The good stuff sells itself if people can find out about it easily enough. Offer a single text a chapter at a time, and people lost patience. I'm not surprised. It slowed down people's reading, which makes it harder to keep involved with the plot, and having to keep paying chapter by chapter with no guarantee that you're going to be able to finish the story in the end, even if *you* paid, because of the authors unrealistic threshold, just turned people off to it.
When performing open heart surgery on a switched-mode PSU to replace a blown reservoir cap, remember to switch it off and discharge it before picking it up and laying the PCB flat on your hand.
su nobody -c 'perl -e stuff'?
I thought that was Zaphod Beeblebrox?
The GPS signal is *very* hard to jam - it was designed to be so. And I hope the US would think twice about the risks of a large amount of satellite debris floating around in an orbit they might actually want to use themselves.
Having several other sources of GPS or GPS-style data would be of benefit to everyone, partly because no one entity could then control GPS availability or enforce a deliberately degraded signal on the world.
Symmetric and asymmetric ciphers solve completely different problems. Whether one or the other is more secure is a meaningless question. It depends not only on the key size (which could be chosen arbitrarily in either case to 'prove' whatever assertion you wanted), but also on the problem domain and how closely the ciphers in question map to it, and also the current state of the art in cryptanalysis which marches forwards every year.
This is a performance issue. Symmetric ciphers simply don't provide the capability that is required for securing ad-hoc channels, but asymmetric ciphers are too slow for encrypting the entirety of the communication. RSA encrypting a 3DES key provides a bridge between the two.
I don't even know what you're trying to say here, but ciphers built on pure XOR tend to be pathetically weak. The stronger symmetric ciphers use some combination of arithmetic, non-arithmetic, lookup tables, permutation and other methods to build up non-linear functions which are highly resistant to analysis.
At the most fundamental level, even RSA is just a combination of ANDs and NOTs (or equivalent logic). There are slow symmetric ciphers too, though speed in hardware, software or both is generally an important consideration in their design.
This is the traditional way timing attacks are used. In fact measurement of timing to this precision is often difficult, and the canonical exploit was to place the password across a memory page boundary (first n characters at end of first page, remainder in second page) then ask ths OS to verify it. By testing to see whether a page fault had occurred you knew whether the first n character were right, thus turning an exponential search into a linear one. Same theory, different measurement method.
Not a lot, because this is a well known flaw and any serious password implementation takes steps to avoid it. (Always compare every character in the supplied password, even if you know early on that the whole thing is invalid.)
If the I/O bus specs is going to be around for decades (and it will be obsoleted by an even faster SCSI standard within that time, though it will have a significant installed base), then the system bus specs *will* catch up and exceed its capability.
Nope. They almost certainly noticed the sky before the pantheon was formalised.