It's not as backed up by law as you think it might be, or there wouldn't continue to be fights about Right of First Sale that the industry kept losing (i.e. sales of used CDs and DVDs.)
The industry can think what they want; the moment they put their product in a retail outlet, apply sales tax appropriate for a consumer good, and advertise using slogans like "Buy it today!" (Blockbuster), they sold it.
Imagine if every purchase you made came with a list of conditions. Imagine how often you'd ignore that list.
"I say to you that the VCR is to the American film producer and the American public as the Boston strangler is to the woman home alone." --Jack Valenti, head of the MPAA, in congressional testimony.
Who's burglarizing who? I buy a car, I get the keys. Ford doesn't have the right to tell me where I can drive; I bought the car, and I bought its keys. If they come in and take the keys away from me, am I not the victim of burlary?
Too much intellectual property handwaving. Sellers don't have authority over buyer's uses, as some rather racist folks in whitebred towns discovered as their old homes were bought up by upwardly mobile *gasp* minorities.
Again, we're just pinging at a higher level. We were already pinging the IP address through TCP, but people were abusing open relays and BGP hacks so IP became insufficient -- tons of fake email addresses were still being attached to spam. So we test the email address instead of the IP address, because that's where to spoofing is coming from.
That's not novel. That's taking the old solution and applying it to where the new problem lies. The left hand has the finger in the dike over there; a new sprig pops out on the right...whatever is the little dutch boy going to do? I'll give you a hint, his right hand is still free...
Just because an email address is managed by a person and not a stack doesn't mean it needs to be (and indeed, we'll almost certainly see email clients, both genuine and malicious, that autorespond to email pings). Since at the end of the day bits are bits, you never really know that a response came from a human and not a machine. There are systems out there that try to do human identification based on patterns that are difficult to parse without human senses -- text on noise, certain shapes, etc -- but they're just making reference to present state of the art in computer aided response. (They also can't really be deployed en masse, since they're inherently illegal under ADA.)
I never said it was a very good security system -- but you can't deny:
1) You can't reset(RST) a connection without knowing the port pair and position along the sequence continuum, 2) When Mitnick (actually an associate of his) cracked Shimomura's machine using a blind spoofing attack, people were quite surprised.
Going from insecure challenge-response to secure challenge-response (due to deploying an actual RNG) to secure challenge-response at a higher level than TCP fails to add anything new -- we're talking about obvious moves on a clear continuum in direct response to exposed threats.
The moment people started attacking the 64K clock, people stopped using it. You can't say it was a novel idea to replace it; the attack exposed the defense. It's the same with SPAM: The moment you're receiving email from large numbers of false email addresses, it's obvious to test those email addresses before allowing a connection to get through. That's what you're already doing at the TCP layer -- no data generally passes until the handshake is complete; you're refusing to accept data until some level of authentication has occurred. But TCP isn't enough, because IP doesn't map well enough to identity. The IP can be true but the email is false. So we test email instead.
"If you are who you say you are, repeat what I tell you."
It's a pretty thin line between pinging the TCP stack and pinging the email box. Indeed, the only reason why the latter exhibits any more security than the former is the moderate dependancy upon getting into DNS (which is mandatory for email, and non-existent at the level of TCP).
You're doing the exact same thing though -- providing some information to a remote party, and trusting them because they're able to reflect it back to you. You're providing that information to them based not on who they are, but on their ability to respond to you. You hand them data, they hand it back. The only difference is that it's at a slightly higher protocol layer -- the user is involved. I'm sorry, that's dead obvious -- this happens _all_ the time, once a protocol fails some critical requirement.
SMTP has been using challenge-response since before it was SMTP. The idea that it's some brilliant idea to patch challenge-response into higher layers -- when it was failing at a lower layer quite visibly -- can't be called obvious.
A simpler analogy? Fine. It's like you've gone twenty years with the blender on medium, but now circumstances demand something more intense.
So you put the blender on high.
Look at the definition: New _and_ useful. This ain't new. It's just the same old challenge-response kicked up a notch.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Yeah, but since SMTP runs over TCP, the core technique being claimed has been part of Internet E-Mail since the beginning. The only thing interesting is that the pre-established technique was tweaked to use e-mail addresses instead of IP addresses and some kind of unique value in the email instead of a sequence number. It's a one to one mapping -- they just moved something to a higher layer.
It's like claiming a patent on, well, raising the steering wheel because people keep knocking their knees on it. If something's too low, you raise it up.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Challenge-Response is the fundamental security mechanism for TCP, the reliable communication protocol used for everything from the web to SMTP itself. During the three way handshake between client and server, each sends the other a randomly generated 32 bit number, and each refuses to communicate unless that number is successfully returned intact. If either the client or the server fakes its identity, it will fail to receive the required value -- one of four billion -- and will thus be unable to complete the handshake.
At least, that's the thinking. Perfect security this ain't, but please -- the spec for TCP came out in 1981. TCP's security technique entirely encapsulates challenge-response systems for SMTP -- the same mitigation of false addresses through an inability to respond, the same caching of credentials once a response is received (you can think of a "trusted address" as a permanently open socket, with all the management headaches that implies!), etc.
In short, this is nothing new. But of course, we already knew that:-)
Yours Truly,
Dan "I Do Way Too Much Stuff With TCP" Kaminsky
DoxPara Research
http://www.doxpara.com
The threat model that the voting machine manufacturers want to work with is: "Given a particular system, how likely is it that it will get hacked?".
The real threat model is substantially different: "Given a particular system, how likely is it that it will be accused of having been hacked, and how damaging will that accusation be?" Much different scenario. Accusations, and the credibility they carry, are directly rebutted by evidence to the contrary. The simple availability of an irrevocable audit trail prevents challenges -- "they might be able to prove us wrong, so we better not challenge the results of the election."
No evidence, no risk of accusation, no credibility for the election.
None deserved, too.
Disclaimer: I _am_ a security engineer. This isn't a technical problem, it's a sociological one. Counting is easy.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Reality By Consensus: Humans as Ontology Engines
on
Review: Matrix: Reloaded
·
· Score: 3, Insightful
Spoilers, etc.
William Gibson referred to cyberspace as a "consensual hallucination" -- millions of minds agreeing to see that which wasn't there. The Matrix has taken this to another level -- not only is the Matrix a hallucination, but the contents of the hallucination occur under the surface -- a summarization, agglomeration, and representation of the shared expectations of each observer. Can a spoon bend? Of course not, no spoon can bend. But if there is no spoon, then no spoon may bend -- the pathway is opened.
If we are shot, we die. If we attempt to jump a chasm, we will fall. If we fight the superhuman, we shall fall, for we are "Only Human". But it's beyond that. If we walk into a room, and somebody is in the room, we shall see them. If they drop a glass, it will break. If they start talking, we will hear them. The words they say will match the words we hear.
If we die in the Matrix, we die in the "real" world. If we die in the "real" world, we die in the Matrix. If you can't die, because somebody loves you, then there will be a way. There will be...hope.
How did Tank come back just in time to save Neo? All Cypher wanted to know was...did Trinity believe?
And she Did. (It's pretty clear the real world is another Matrix, a la the 13th floor. Sweet!)
The millions of rules, assertions, and consequences of Cyc become not merely descriptive, but prescriptive -- things happen because we have been convinced they already have, not the other way around.
Nowhere is this more clear than the experience of Persephone, the wife of a philandering man who wishes to experience one moment of true belief. The act is insufficient; the belief is key. "Kiss me as if I were her, expose me to a genuine truth rather than an intentionally manufactured lie." (As an interesting side note, much of love's courtship process can be thought of as a demonstration of addiction -- I _can't_ leave you, it would hurt me too much, I shall be forced to stay even through those times when others would offer something better in the short term.)
It is a peculiar testament to the power of Neo, to control his beliefs so powerfully, that's he's able to expose even that aspect of his self to sheer force of will -- because he believes it's necessary, and that if he does this deed, he will receive assistance. And so it is willed.
Science has, to some extent, been defined as the study of the observable. We may hold opinions, but we may only know what we could possibly see. But this is not the limit of human imagination...we envision realities that are implausible, fantastic, astonishing...
In the Matrix, if we believe hard enough, it becomes so. Vampires are simply another belief, made flesh by a shared architecture that only acts as people believe it must.
I have little respect for those who see the Matrix as little more than a slide show of explosions interspersed with mere yammering without a point. The most important aspect of the Matrix design is that no question is rhetorical; no answers already exist. The machines lie -- they're more than happy to imply that a decision has already been made, because once that belief takes hold, it is made real. The Oracle is astonishing -- she uses the trivialities of candy and a broken jar to to establish her power in the mind of Neo. She has no need to portray herself as a kindly old woman -- but this is precisely the form that Neo might believe to be trustworthy.
And, ironically enough, if he thinks hard enough that she'll tell him the truth, she may cease to have sufficient choice in the matter. Note all the times people tell Neo he doesn't truly understand, he's fast, but they're faster, the machine can peer into his soul and hear the thoughts he considers private. In a very interesting way, we were never given an incomplete view of the way the world worked; we were always given an incomplete view of the way the worl
Things are a bit different now. With 100MB/sec to 1GB/sec of bandwidth available from GigE/10GigE, the high speed bus itself is going commodity. But the speeds are so high that you wouldn't necessarily want to pump that through your CPU for serving purposes.
Enter RDMA -- which uses raw Ethernet messages, not IP.
Others have rebutted your assertion on RAM availability.
Clearly you haven't used XP much. I've got an XP Video Server hooked up to a TV; it has uptime of around four months right now. Good luck getting a Win9x machine to do that -- 95 literally could never stay up more than 47 days, due to a clock related overflow. They've done ALOT to fix stability, and it's nothing but ignorance to claim otherwise.
It's nice to be able to finally change your IP address without rebooting, too.:-)
95->98 was a huge jump. ME was an ummitigated disaster, but 2000 and XP have been herculean tasks that really have paid off well.
I'm a hardcore Linux/FreeBSD/OpenBSD user and programmer, but credibility demands honesty.
Linux would have many, many more viruses if it was even remotely as popular as a client platform. Since it's a popular server, it actually has more out-of-the-box remote roots (IIS notwithstanding).
Disks aren't necessarily simpler; the amount of work you need to do to keep really slow data on disk efficiently cached in RAM is monstrous. What you want to do is batch all sorts of operations together in RAM, then blast it onto the disks in an atomic operation, but do it such that if the disks crash during a blast, the data is still accurate...it's messy; disks introduce major latency within which failures can occur. RAM is so low latency that this is much, much less a problem -- the moment a batch is ready to be checkpointed, it's already practically there. So RAM approaches, beyond being faster, become simpler.
Very, very insightful post. (Mods, do your thing.)
You are quite correct that enterprise scale databases have increased at a similarly astounding pace; however, one rarely taps OS resources to manage that space. Oracle is more than happy to access raw volumes, and any efficient memory management system at even the Terabyte scale _is_ _not_ going to resemble the average desktop or server's requirements. It's just a completely different layout.
I don't think "Virtual Memory" is the appropriate term for large database; the nature of the backing store is just so different. Among other things, the "swap file" is actually relevant upon reboot! So I stand by my original assertion -- VM is dying.
I had thought of RDMA as a more efficient model for cluster communication, i.e. shared memory models actually worked transparently across hosts, and MOSIX processes could simply migrate where required. Stability-wise, it seems _all_ cluster operations can involve hosts simply failing to respond; this just seems a more efficient way to exchange data (since DMA massively reduces the CPU involvement in data transfers).
IRAM doesn't seem to be what I'm thinking. Neomagic put out a GPU with integrated DRAM for laptops; logic and storage on the same die isn't so unique. But simple, non-branching math, massively distributed, could eventually grant order-of-magnitude speed improvements for a select group of operations by avoiding the Von Neumann bottleneck. I know that Don Becker had some work in this area, and I _know_ there are problems bringing it to market. My point is that RAM can't get much bigger, and soon enough it won't be able to get faster, so the only thing left is to make it smarter.
RAM-resident Database? Yes, that would be Google -- a massive, massive cluster of x86 boxen with a couple gigs of RAM apiece. Each gets a portion of the hashspace, leading to near-O(1) searchability. I'm pretty sure all the big search engines work this way, at this point -- the DB is checkpointed into RAM, but is never actually run from it.
Recent discussions about disks vs. CPU's have ignored the massive decreases in the cost of RAM. For a very long time, the secret bottleneck in PC's (in that it wasn't advertised heavily) was RAM. That's starting to disappear -- there's a gig in my laptop, and there's no discernable improvement in all but the most intense applications if I were to go beyond that.
Virtual Memory is already on the chopping block; any time it's imaginable that a system might need another gig of storage, it's probably worth going to the store and spending the hundred dollars.
But what if more RAM is indeed needed? One of the most interesting developments in this department has involved RDMA: Remote DMA over Ethernet. Effectively, with RAM several orders of magnitude faster than disk, and with Ethernet achieving disk-interface speeds of 120MB/s, we can either a) use other machines as our "VM" failover, or more interestingly, b) Directly treat remote RAM as a local resource -- a whole new class of zero copy networking. This Is Cool, though there are security issues as internal system architectures get exposed to the rough and tumble world outside the box. It'll be interesting to see how they're addressed (firewalls don't count).
What next, for the RAM itself? I don't think there's much that value in further doublings...either of capacity, or soon, of speed. What I'm convinced we're going to start seeing is some capacity for distributed computation in the RAM logic itself -- load in a couple hundred meg in one bank, a couple hundred meg in another, and XOR them together _in RAM_. It'd just be another type of read -- a "computational read". Some work's been done on this, though apparently there's massive issues integrating logic into what's some very dumb, very dense circuitry. But the logic's already done to some degree; ECC verifiers need to include adders for parity checking.
My guess...we'll probably see it in a 3D Accelerator first.
*yawns* Anyway, just some thoughts to spur discussion. I go sleep now:-)
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
While LibraNet is certainly impressive, I must mention that Knoppix provides the "cutting edge" traits mentioned -- KDE 3.1, Linux-2.4.20-xfs, etc. -- with the bonus of the most mature automatic hardware detection algorithms in the x86 space.
And once you run knx-hdinstall, apt-get is more than happy to function normally.
Knoppix is very fun to see spread through schools; it's exponential growth at its finest:-)
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
If I have to choose between completely unauditable electronic voting and the present paper punching mess that can still be audited after the fact, I'll go with paper voting every time.
If I can get a touch-screen system that generates auditable, _human readable_ sheets of paper or some other voter-and-auditor readable medium, then I'm very interested in electronic systems -- they're faster, cheaper, and potentially much more accurate.
The purpose of a democratic election is not to determine a winner. Every conflict, democratic or not, peaceful or not, ends up generating
winners. No, the purpose of an election is to make everyone agree who lost, and to generate (through a future election) a preplanned battlefield
for a future engagement.
Only through this process can the costs of conflict -- which are often substantial, sometimes far greater than the value of what's being fought
over -- itself be minimized.
Some engineers with no knowledge of politics imagine voting is a counting problem. Given hundreds, thousands, maybe hundreds of thousands of
individual polling sites, how can the numbers be collated and reported accurately? How can the top scoring candidate be identified and informed
of his or her success? In short: Who won?
They miss the point entirely: The problem is never the winner. The winner is not the one to doubt or challenge the system. The winner is always
happy to win -- it's never the party in the lead that calls for a recount. No. The problem is with those to whom power has been denied. They
are the ones that the entire system exists for; they are the ones who the process is designed to satisfy. We hold out a carrot -- you will have
your chance again in some time -- and ultimately, a stick: You failed to convince enough people that your cause was worthy, that your message was
true. We brought your message to the people, and they turned away.
That doesn't say "You won." That proves "You lost." This is why it is so critical to have a genuine paper trail for voting systems: Any
idiot can tell you who won, but once the facts disappear -- once the finger rises from the touch screen -- there is no mark, no evidence, no proof
at all. That doesn't mean the election won't have an outcome: Courts can quite easily, by fiat, declare that the voting system may not be
challenged. By fiat, then, they decide who won.
Fiat -- legalese for "Because I said so" -- does not a proof make. Fiat declares a winner; it cannot prove a loser. Thus it fails, utterly and
completely, to serve the purpose of the election system itself. Open and unambiguous access to the voting architecture is critical if we are to
provide an election system that defies the sour grapes of a failed candidate. Anything less makes a farce of the election process -- why go
through the rigamarole if people have no reason to believe the results?
The sad part is, most engineers have settled on the most obvious solution: Touch screen voting, with a human readable (but easily
computer-auditable, through the use of the standard OCR fonts that have been on checks for decades) printout that is stored for recount purposes.
(The printout is on difficult to forge official paper, and contains some piece of data that did not exist before the election, akin to POW's
holding a newspaper.) At that point, there are a few choices -- have the touch screens also communicate to a central office, which collates votes
and designates 5% of precincts randomly for immediate on-site audit, or perhaps skip the touch screen link and have each site read the votes from
the printouts and only the printouts. Given a challenge, the computers speak the same language we do, and possess logs in the same physical
format we can analyze. A challenged result can be answered with evidence -- and thus the challenge is not likely to be made at all, for that
would be yet another failure for the candidate.
Elections without evidence see their legitimacy drain away like blood from a sliced jugular. Without evidence, it's not that the victor cannot be
shown, it's that the challenger cannot be refuted. Shaking ones shoulders, saying "I'm not going to prove a negative", is insufficient. Blind
touch-screeners leave elections vapid and useless, an exercise in futility that doesn't raise an eyebrow when precisely 100% of the (remaining?)
population votes for Saddam.
The author of UPX is nigh-obsessed with CPU performance; LZO's indeed pretty insanely fast and he's got another algo that decompresses almost entirely in-place. So I wouldn't be surprised to see launch times decrease.
Strange how meaningful that meaningless square root is.
The point isn't that it's just close; it's that the integer value to the left of the decimal point will _always_ equal the lesser of the two primes. Thus the relevance of the limit.
This is, interestingly enough, essentially numerical error -- the actual square root appears to approach but never quite reach p. sqrt((p-1)(p+1)) is the kind of operation that math professors tend to kindly point out has undefined output, since addition and multiplication don't generally play nice together, but this is a curious exception -- there's a very small range within which the resulting value can lie:
Here, lemme pull out Acme Software's BIC (basically, bc with prime functionality). 18409199 is the 100,000th twin prime.
For those not proficient in bc, I've taken the liberty of illustrating when I type and when the computer responds. I'm basically setting variables; when there is no equality specified, the output is redirected to the screen. My typing is in bold.
=== a=18409199 b=a+2 c=a*b c 338898644639999 d=sqrt(c) d 18409199 c/d 18409201
===
I tried this for a couple twin primes -- it seems to always work. I've had a nagging suspicion that sums of square roots will eventually do something interesting for factorization, but I highly doubt the above process is at all novel.
Slashdot Mirror
It's not as backed up by law as you think it might be, or there wouldn't continue to be fights about Right of First Sale that the industry kept losing (i.e. sales of used CDs and DVDs.)
The industry can think what they want; the moment they put their product in a retail outlet, apply sales tax appropriate for a consumer good, and advertise using slogans like "Buy it today!" (Blockbuster), they sold it.
Imagine if every purchase you made came with a list of conditions. Imagine how often you'd ignore that list.
--Dan
"I say to you that the VCR is to the American film producer and the American public as the Boston strangler is to the woman home alone."
--Jack Valenti, head of the MPAA, in congressional testimony.
Who's burglarizing who? I buy a car, I get the keys. Ford doesn't have the right to tell me where I can drive; I bought the car, and I bought its keys. If they come in and take the keys away from me, am I not the victim of burlary?
Too much intellectual property handwaving. Sellers don't have authority over buyer's uses, as some rather racist folks in whitebred towns discovered as their old homes were bought up by upwardly mobile *gasp* minorities.
--Dan
Again, we're just pinging at a higher level. We were already pinging the IP address through TCP, but people were abusing open relays and BGP hacks so IP became insufficient -- tons of fake email addresses were still being attached to spam. So we test the email address instead of the IP address, because that's where to spoofing is coming from.
That's not novel. That's taking the old solution and applying it to where the new problem lies. The left hand has the finger in the dike over there; a new sprig pops out on the right...whatever is the little dutch boy going to do? I'll give you a hint, his right hand is still free...
Just because an email address is managed by a person and not a stack doesn't mean it needs to be (and indeed, we'll almost certainly see email clients, both genuine and malicious, that autorespond to email pings). Since at the end of the day bits are bits, you never really know that a response came from a human and not a machine. There are systems out there that try to do human identification based on patterns that are difficult to parse without human senses -- text on noise, certain shapes, etc -- but they're just making reference to present state of the art in computer aided response. (They also can't really be deployed en masse, since they're inherently illegal under ADA.)
--Dan
I never said it was a very good security system -- but you can't deny:
1) You can't reset(RST) a connection without knowing the port pair and position along the sequence continuum,
2) When Mitnick (actually an associate of his) cracked Shimomura's machine using a blind spoofing attack, people were quite surprised.
Going from insecure challenge-response to secure challenge-response (due to deploying an actual RNG) to secure challenge-response at a higher level than TCP fails to add anything new -- we're talking about obvious moves on a clear continuum in direct response to exposed threats.
The moment people started attacking the 64K clock, people stopped using it. You can't say it was a novel idea to replace it; the attack exposed the defense. It's the same with SPAM: The moment you're receiving email from large numbers of false email addresses, it's obvious to test those email addresses before allowing a connection to get through. That's what you're already doing at the TCP layer -- no data generally passes until the handshake is complete; you're refusing to accept data until some level of authentication has occurred. But TCP isn't enough, because IP doesn't map well enough to identity. The IP can be true but the email is false. So we test email instead.
--Dan
"If you are who you say you are, repeat what I tell you."
It's a pretty thin line between pinging the TCP stack and pinging the email box. Indeed, the only reason why the latter exhibits any more security than the former is the moderate dependancy upon getting into DNS (which is mandatory for email, and non-existent at the level of TCP).
You're doing the exact same thing though -- providing some information to a remote party, and trusting them because they're able to reflect it back to you. You're providing that information to them based not on who they are, but on their ability to respond to you. You hand them data, they hand it back. The only difference is that it's at a slightly higher protocol layer -- the user is involved. I'm sorry, that's dead obvious -- this happens _all_ the time, once a protocol fails some critical requirement.
SMTP has been using challenge-response since before it was SMTP. The idea that it's some brilliant idea to patch challenge-response into higher layers -- when it was failing at a lower layer quite visibly -- can't be called obvious.
A simpler analogy? Fine. It's like you've gone twenty years with the blender on medium, but now circumstances demand something more intense.
So you put the blender on high.
Look at the definition: New _and_ useful. This ain't new. It's just the same old challenge-response kicked up a notch.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Yeah, but since SMTP runs over TCP, the core technique being claimed has been part of Internet E-Mail since the beginning. The only thing interesting is that the pre-established technique was tweaked to use e-mail addresses instead of IP addresses and some kind of unique value in the email instead of a sequence number. It's a one to one mapping -- they just moved something to a higher layer.
It's like claiming a patent on, well, raising the steering wheel because people keep knocking their knees on it. If something's too low, you raise it up.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Challenge-Response is the fundamental security mechanism for TCP, the reliable communication protocol used for everything from the web to SMTP itself. During the three way handshake between client and server, each sends the other a randomly generated 32 bit number, and each refuses to communicate unless that number is successfully returned intact. If either the client or the server fakes its identity, it will fail to receive the required value -- one of four billion -- and will thus be unable to complete the handshake.
:-)
At least, that's the thinking. Perfect security this ain't, but please -- the spec for TCP came out in 1981. TCP's security technique entirely encapsulates challenge-response systems for SMTP -- the same mitigation of false addresses through an inability to respond, the same caching of credentials once a response is received (you can think of a "trusted address" as a permanently open socket, with all the management headaches that implies!), etc.
In short, this is nothing new. But of course, we already knew that
Yours Truly,
Dan "I Do Way Too Much Stuff With TCP" Kaminsky
DoxPara Research
http://www.doxpara.com
It's pretty simple, really.
The threat model that the voting machine manufacturers want to work with is: "Given a particular system, how likely is it that it will get hacked?".
The real threat model is substantially different: "Given a particular system, how likely is it that it will be accused of having been hacked, and how damaging will that accusation be?" Much different scenario. Accusations, and the credibility they carry, are directly rebutted by evidence to the contrary. The simple availability of an irrevocable audit trail prevents challenges -- "they might be able to prove us wrong, so we better not challenge the results of the election."
No evidence, no risk of accusation, no credibility for the election.
None deserved, too.
Disclaimer: I _am_ a security engineer. This isn't a technical problem, it's a sociological one. Counting is easy.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Spoilers, etc.
William Gibson referred to cyberspace as a "consensual hallucination" -- millions of minds agreeing to see that which wasn't there. The Matrix has taken this to another level -- not only is the Matrix a hallucination, but the contents of the hallucination occur under the surface -- a summarization, agglomeration, and representation of the shared expectations of each observer. Can a spoon bend? Of course not, no spoon can bend. But if there is no spoon, then no spoon may bend -- the pathway is opened.
If we are shot, we die. If we attempt to jump a chasm, we will fall. If we fight the superhuman, we shall fall, for we are "Only Human". But it's beyond that. If we walk into a room, and somebody is in the room, we shall see them. If they drop a glass, it will break. If they start talking, we will hear them. The words they say will match the words we hear.
If we die in the Matrix, we die in the "real" world. If we die in the "real" world, we die in the Matrix. If you can't die, because somebody loves you, then there will be a way. There will be...hope.
How did Tank come back just in time to save Neo? All Cypher wanted to know was...did Trinity believe?
And she Did. (It's pretty clear the real world is another Matrix, a la the 13th floor. Sweet!)
The millions of rules, assertions, and consequences of Cyc become not merely descriptive, but prescriptive -- things happen because we have been convinced they already have, not the other way around.
Nowhere is this more clear than the experience of Persephone, the wife of a philandering man who wishes to experience one moment of true belief. The act is insufficient; the belief is key. "Kiss me as if I were her, expose me to a genuine truth rather than an intentionally manufactured lie." (As an interesting side note, much of love's courtship process can be thought of as a demonstration of addiction -- I _can't_ leave you, it would hurt me too much, I shall be forced to stay even through those times when others would offer something better in the short term.)
It is a peculiar testament to the power of Neo, to control his beliefs so powerfully, that's he's able to expose even that aspect of his self to sheer force of will -- because he believes it's necessary, and that if he does this deed, he will receive assistance. And so it is willed.
Science has, to some extent, been defined as the study of the observable. We may hold opinions, but we may only know what we could possibly see. But this is not the limit of human imagination...we envision realities that are implausible, fantastic, astonishing...
In the Matrix, if we believe hard enough, it becomes so. Vampires are simply another belief, made flesh by a shared architecture that only acts as people believe it must.
I have little respect for those who see the Matrix as little more than a slide show of explosions interspersed with mere yammering without a point. The most important aspect of the Matrix design is that no question is rhetorical; no answers already exist. The machines lie -- they're more than happy to imply that a decision has already been made, because once that belief takes hold, it is made real. The Oracle is astonishing -- she uses the trivialities of candy and a broken jar to to establish her power in the mind of Neo. She has no need to portray herself as a kindly old woman -- but this is precisely the form that Neo might believe to be trustworthy.
And, ironically enough, if he thinks hard enough that she'll tell him the truth, she may cease to have sufficient choice in the matter. Note all the times people tell Neo he doesn't truly understand, he's fast, but they're faster, the machine can peer into his soul and hear the thoughts he considers private. In a very interesting way, we were never given an incomplete view of the way the world worked; we were always given an incomplete view of the way the worl
RD--
Things are a bit different now. With 100MB/sec to 1GB/sec of bandwidth available from GigE/10GigE, the high speed bus itself is going commodity. But the speeds are so high that you wouldn't necessarily want to pump that through your CPU for serving purposes.
Enter RDMA -- which uses raw Ethernet messages, not IP.
--Dan
GigsVT--
Hardware support (_D_irect _M_emory _A_ccess).
--Dan
Others have rebutted your assertion on RAM availability.
:-)
Clearly you haven't used XP much. I've got an XP Video Server hooked up to a TV; it has uptime of around four months right now. Good luck getting a Win9x machine to do that -- 95 literally could never stay up more than 47 days, due to a clock related overflow. They've done ALOT to fix stability, and it's nothing but ignorance to claim otherwise.
It's nice to be able to finally change your IP address without rebooting, too.
95->98 was a huge jump. ME was an ummitigated disaster, but 2000 and XP have been herculean tasks that really have paid off well.
I'm a hardcore Linux/FreeBSD/OpenBSD user and programmer, but credibility demands honesty.
Linux would have many, many more viruses if it was even remotely as popular as a client platform. Since it's a popular server, it actually has more out-of-the-box remote roots (IIS notwithstanding).
Disks aren't necessarily simpler; the amount of work you need to do to keep really slow data on disk efficiently cached in RAM is monstrous. What you want to do is batch all sorts of operations together in RAM, then blast it onto the disks in an atomic operation, but do it such that if the disks crash during a blast, the data is still accurate...it's messy; disks introduce major latency within which failures can occur. RAM is so low latency that this is much, much less a problem -- the moment a batch is ready to be checkpointed, it's already practically there. So RAM approaches, beyond being faster, become simpler.
--Dan
Very, very insightful post. (Mods, do your thing.)
You are quite correct that enterprise scale databases have increased at a similarly astounding pace; however, one rarely taps OS resources to manage that space. Oracle is more than happy to access raw volumes, and any efficient memory management system at even the Terabyte scale _is_ _not_ going to resemble the average desktop or server's requirements. It's just a completely different layout.
I don't think "Virtual Memory" is the appropriate term for large database; the nature of the backing store is just so different. Among other things, the "swap file" is actually relevant upon reboot! So I stand by my original assertion -- VM is dying.
I had thought of RDMA as a more efficient model for cluster communication, i.e. shared memory models actually worked transparently across hosts, and MOSIX processes could simply migrate where required. Stability-wise, it seems _all_ cluster operations can involve hosts simply failing to respond; this just seems a more efficient way to exchange data (since DMA massively reduces the CPU involvement in data transfers).
IRAM doesn't seem to be what I'm thinking. Neomagic put out a GPU with integrated DRAM for laptops; logic and storage on the same die isn't so unique. But simple, non-branching math, massively distributed, could eventually grant order-of-magnitude speed improvements for a select group of operations by avoiding the Von Neumann bottleneck. I know that Don Becker had some work in this area, and I _know_ there are problems bringing it to market. My point is that RAM can't get much bigger, and soon enough it won't be able to get faster, so the only thing left is to make it smarter.
Thanks!
--Dan
RAM-resident Database? Yes, that would be Google -- a massive, massive cluster of x86 boxen with a couple gigs of RAM apiece. Each gets a portion of the hashspace, leading to near-O(1) searchability. I'm pretty sure all the big search engines work this way, at this point -- the DB is checkpointed into RAM, but is never actually run from it.
:-)
Recent discussions about disks vs. CPU's have ignored the massive decreases in the cost of RAM. For a very long time, the secret bottleneck in PC's (in that it wasn't advertised heavily) was RAM. That's starting to disappear -- there's a gig in my laptop, and there's no discernable improvement in all but the most intense applications if I were to go beyond that.
Virtual Memory is already on the chopping block; any time it's imaginable that a system might need another gig of storage, it's probably worth going to the store and spending the hundred dollars.
But what if more RAM is indeed needed? One of the most interesting developments in this department has involved RDMA: Remote DMA over Ethernet. Effectively, with RAM several orders of magnitude faster than disk, and with Ethernet achieving disk-interface speeds of 120MB/s, we can either a) use other machines as our "VM" failover, or more interestingly, b) Directly treat remote RAM as a local resource -- a whole new class of zero copy networking. This Is Cool, though there are security issues as internal system architectures get exposed to the rough and tumble world outside the box. It'll be interesting to see how they're addressed (firewalls don't count).
What next, for the RAM itself? I don't think there's much that value in further doublings...either of capacity, or soon, of speed. What I'm convinced we're going to start seeing is some capacity for distributed computation in the RAM logic itself -- load in a couple hundred meg in one bank, a couple hundred meg in another, and XOR them together _in RAM_. It'd just be another type of read -- a "computational read". Some work's been done on this, though apparently there's massive issues integrating logic into what's some very dumb, very dense circuitry. But the logic's already done to some degree; ECC verifiers need to include adders for parity checking.
My guess...we'll probably see it in a 3D Accelerator first.
*yawns* Anyway, just some thoughts to spur discussion. I go sleep now
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
I was just commenting how odd it was that the Prince track, once looking forward to an exciting future, now referred to a booming past...
You should try Knoppix. It's like one day, the instant-satisfaction of console systems hit the PC realm.
--Dan
While LibraNet is certainly impressive, I must mention that Knoppix provides the "cutting edge" traits mentioned -- KDE 3.1, Linux-2.4.20-xfs, etc. -- with the bonus of the most mature automatic hardware detection algorithms in the x86 space.
:-)
And once you run knx-hdinstall, apt-get is more than happy to function normally.
Knoppix is very fun to see spread through schools; it's exponential growth at its finest
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
If I put a mp3 player in a toilet seat do I get to be on slashdot?
Actually, yes.
If I have to choose between completely unauditable electronic voting and the present paper punching mess that can still be audited after the fact, I'll go with paper voting every time.
If I can get a touch-screen system that generates auditable, _human readable_ sheets of paper or some other voter-and-auditor readable medium, then I'm very interested in electronic systems -- they're faster, cheaper, and potentially much more accurate.
Do not mistake the path for the goal.
--Dan
The purpose of a democratic election is not to determine a winner. Every conflict, democratic or not, peaceful or not, ends up generating winners. No, the purpose of an election is to make everyone agree who lost, and to generate (through a future election) a preplanned battlefield for a future engagement.
Only through this process can the costs of conflict -- which are often substantial, sometimes far greater than the value of what's being fought over -- itself be minimized.
Some engineers with no knowledge of politics imagine voting is a counting problem. Given hundreds, thousands, maybe hundreds of thousands of individual polling sites, how can the numbers be collated and reported accurately? How can the top scoring candidate be identified and informed of his or her success? In short: Who won?
They miss the point entirely: The problem is never the winner. The winner is not the one to doubt or challenge the system. The winner is always happy to win -- it's never the party in the lead that calls for a recount. No. The problem is with those to whom power has been denied. They are the ones that the entire system exists for; they are the ones who the process is designed to satisfy. We hold out a carrot -- you will have your chance again in some time -- and ultimately, a stick: You failed to convince enough people that your cause was worthy, that your message was true. We brought your message to the people, and they turned away.
That doesn't say "You won." That proves "You lost." This is why it is so critical to have a genuine paper trail for voting systems: Any idiot can tell you who won, but once the facts disappear -- once the finger rises from the touch screen -- there is no mark, no evidence, no proof at all. That doesn't mean the election won't have an outcome: Courts can quite easily, by fiat, declare that the voting system may not be challenged. By fiat, then, they decide who won.
Fiat -- legalese for "Because I said so" -- does not a proof make. Fiat declares a winner; it cannot prove a loser. Thus it fails, utterly and completely, to serve the purpose of the election system itself. Open and unambiguous access to the voting architecture is critical if we are to provide an election system that defies the sour grapes of a failed candidate. Anything less makes a farce of the election process -- why go through the rigamarole if people have no reason to believe the results?
The sad part is, most engineers have settled on the most obvious solution: Touch screen voting, with a human readable (but easily computer-auditable, through the use of the standard OCR fonts that have been on checks for decades) printout that is stored for recount purposes. (The printout is on difficult to forge official paper, and contains some piece of data that did not exist before the election, akin to POW's holding a newspaper.) At that point, there are a few choices -- have the touch screens also communicate to a central office, which collates votes and designates 5% of precincts randomly for immediate on-site audit, or perhaps skip the touch screen link and have each site read the votes from the printouts and only the printouts. Given a challenge, the computers speak the same language we do, and possess logs in the same physical format we can analyze. A challenged result can be answered with evidence -- and thus the challenge is not likely to be made at all, for that would be yet another failure for the candidate.
Elections without evidence see their legitimacy drain away like blood from a sliced jugular. Without evidence, it's not that the victor cannot be shown, it's that the challenger cannot be refuted. Shaking ones shoulders, saying "I'm not going to prove a negative", is insufficient. Blind touch-screeners leave elections vapid and useless, an exercise in futility that doesn't raise an eyebrow when precisely 100% of the (remaining?) population votes for Saddam.
It's honestly surprising that, in this d
The author of UPX is nigh-obsessed with CPU performance; LZO's indeed pretty insanely fast and he's got another algo that decompresses almost entirely in-place. So I wouldn't be surprised to see launch times decrease.
--Dan
Have you tried runtime-compressing the Phoenix binary with UPX? Let me know how it goes.
--Dan
www.doxpara.com
coyote,
Strange how meaningful that meaningless square root is.
The point isn't that it's just close; it's that the integer value to the left of the decimal point will _always_ equal the lesser of the two primes. Thus the relevance of the limit.
--Dan
As much as I'd love to have come up with something novel, this really isn't.
a *b)9 99999 99
:-)
Take the limit as p approaches infinity of sqrt((p-1)(p+1)). It basically reduces to sqrt(p*p) = sqrt(p^2) = p.
So as p reaches infinity, the impact of those +- 1's goes to 0. The limit is p. p doesn't even need to be prime:
a=9845769847569845645692837498235
b=a+2
sqrt(
9845769847569845645692837498235.999999999999
You of course need all the other tricks for non-twin primes
--Dan
The sqrt optimization only works for twin primes, coyote-san. I'm actually starting to worry this method is mildly novel.
7 12296
)
:-)
It ends up truncating after the decimal point. So:
===
scale=20
sqrt(c)
18409199.99999997283966
===
This is, interestingly enough, essentially numerical error -- the actual square root appears to approach but never quite reach p. sqrt((p-1)(p+1)) is the kind of operation that math professors tend to kindly point out has undefined output, since addition and multiplication don't generally play nice together, but this is a curious exception -- there's a very small range within which the resulting value can lie:
==
sqrt(5*7)
5.91607978309961604256
sqrt(7*9
7.93725393319377177150
sqrt(18409199*18409201)
18409199.99999997283966712296
==
Neat
--Dan
No, it really is as simple as square roots :-)
Here, lemme pull out Acme Software's BIC (basically, bc with prime functionality). 18409199 is the 100,000th twin prime.
For those not proficient in bc, I've taken the liberty of illustrating when I type and when the computer responds. I'm basically setting variables; when there is no equality specified, the output is redirected to the screen. My typing is in bold.
===
a=18409199
b=a+2
c=a*b
c
338898644639999
d=sqrt(c)
d
18409199
c/d
18409201
===
I tried this for a couple twin primes -- it seems to always work. I've had a nagging suspicion that sums of square roots will eventually do something interesting for factorization, but I highly doubt the above process is at all novel.
--Dan