As Warren Ellis wrote on his blog (which of course is where I found this, right next to the mind-boggling sci-fi snippets), This Is Essential.
For the curious, take the most regal sounding brit you've ever heard. Now make him sell something utterly absurd -- and give him the cojones to say so.
I can definitely see google searching by speech, but results will almost certainly come back via a visual display. This is part of that classic paradox of communication: We read faster than we hear, but we speak faster than we write. Particularly with google, which has easily scannable chunks of content that hyperlink you to what you're looking for, speech reply would be a horribly inefficient channel to introduce except for the most straightforward questions.
I do expect voice control of google soon (they're already working on it; it was one of their lab tools).
I was at Toorcon, when Bruce Schneier was talking about this very event.
It was pretty painful, but not like you'd think.
"For those who don't know, Geer wrote an article talking about the risks of monoculture that situations like we have with Microsoft expose."
Lets look at the article's title:
>
CyberInsecurity: The Cost of Monopoly
How the Dominance of Microsoft's Products Poses a Risk to Security
Does anyone see the word Monoculture in there? No, just monopoly. It's up there next to "Dominance", "Cost", and "Insecurity".
Somewhere along the lines, this paper jumped from technical analysis to political polemic, and Geer got the political response. Don't get me wrong: The vast majority of the conclusions reached in this article have way more than a grain of truth in them. But the degree to which Schneier backpedalled on the tone was pretty noticable, and stood in stark contrast to the near-rage of the paper itself.
Would Geer have kept his job if the paper was more objectively written? I don't know. But I sure note what I see reported on doesn't match what I read in that paper, and I have to wonder why.
Yours Truly,
Dan Kaminsky, CISSP
DoxPara Research
http://www.doxpara.com
We have many stateless cryptosystems, none of them good. They all struggle with replay attacks (it's hard to detect a replay when you're not keeping track of a session) and dropped packets (it's hard to synchronize keystreams when there is no inherent stream at work).
Gutmann does know what he's talking about, and is mostly right. He just didn't really express that there's a *reason* people aren't using SSL and SSH, and I moved to correct that.
Hmmm. Looks like I misread the OpenSSH source code. You're quite right, set_newkeys for SSH2 modifies different contexts depending on whether the mode is set to MODE_IN or MODE_OUT.
SSHv1, by dint of depending on the validity of the encryption to secure the CRC, does sort of use the same key for both. But, yeah.
Incidentally, this is really useful knowledge (it means my SSL hack now works for SSH).
The problem isn't that TCP is assuming an unreliable medium underneath; TCP is as happy to operate over a perfectly reliable IP network as it is to operate over a somewhat unreliable one (significantly unreliable networks outstrip TCP's ability to compensate, mandating solutions like Airhook). The problem is that, when packets are dropped, the nature of the network changes, because both the external and the internal networks move to compensate.
UDP is a thin wrapper that basically adds ports and a checksum to IP and nothing more.
It's one of those "tiny systems that popped up because we don't have good stateless crypto" -- as Guttman points out, it's as flawed as everything else that didn't go through SSH and SSL's trial by fire.
The point to my post was, damnit, there's a *reason* SSH and SSL aren't good enough: They utterly ignore the fact that unreliable networks need to be secure too, by mandating an underlying reliable transport.
It's much easier to keep your crypto synced when you can't drop packets.
First of all, I've got a tremendous amount of respect for Peter Guttman, and not just because he's the author of the coolest quote relating to computer security of all time (if you can't find it in that essay, you're not paying attention). But...he misses the point.
We do not have an effective method of running a stateless cryptosystem, but IP actually does require stateless operation. All these mini-systems that have sprouted up exist because of this.
SSH(which, incidentally, violates Guttman's rules by using "the same key for encryption and authentication") and SSL(which utterly falls apart when the cert gets compromised) both run over TCP. TCP is not IP. TCP adds reliability, through error detection, correction, order management, and congestion management. That's all well and good, but sometimes I really don't care when I drop a packet. Voice traffic is a fantastic example -- by the time the retransmission is complete, the data is stale and irrelevant. But TCP will not only stop to retransmit, it'll hold up everything else while it does so, and even slow down the connection to be sure a dropped packet doesn't happen again.
There are _many_ protocols which can accept these semantics. But there are many that cannot, and there's a bigger problem: By supporting those protocols that do not share the connection semantics of TCP -- DNS, VoIP, etc -- we end up being forced to carry either GRE or PPP packets over the SSL/SSH tunnel -- and inside these PPP packets, that are being carried by TCP, is more TCP.
This doesn't work very well at all -- effectively, both sockets attempt to simultaneously adjust to changing network conditions, and since neither knows about eachother, they both screw up badly.
All because we do not have a stateless cryptosystem that works. It may very well be that such a demand is impossible. Stateless cryptosystems can send a message and not only not prenegotiate a session key, but tolerate large number of dropped packets. Replay attacks need to be suppressed, but packets need to be able to survive high latencies. CPU load needs to be kept reasonable, but no message can rely on the asymmetric results of another.
In short, normal cryptosystems are built to be inflexible to attackers; we do not know how to make them simultaneously flexible for networks. The reasons why should be obvious -- anything that can go wrong on the network, will go wrong because of an attacker. So telling everybody to use SSH/SSL is ultimately code for, "We just don't have the crypto to secure IP." And we know IPSec is a failure; if it hadn't been for VPN's, it'd be as rare as multicast and a hundred times more expensive.
Solutions? I suspect short signatures will ultimately make the difference, as will better time-based protocols (at least for intra-admin-domain work.) But no matter how high my opinion is of Guttman, I cannot ignore he considers solved problems that fundamentally refuse to go away.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
P.S. There is an immediately available VPN solution that's free and doesn't suffer from TCP-over-TCP effects. Look up Dynamic Forwarding for OpenSSH... TCP is terminated at the forwarder, addressed using SOCKS4 or SOCKS5(>3.7.0), and forwarded to the appropriate destination on the other side of the tunnel. It's TCP _only_, but it operates completely in userspace.
Again, explanation is not an excuse. My point is that, until such time as the user executes a mathematical operation whose result becomes a repeating decimal (divide, not add/subtract/multiply/exponentiate), it's mathematically incorrect to employ the FPU in the first place.
I'm well aware the original poster knew little or nothing about floating point math...my question is, where do we get off talking down to him when *ours* are the incorrect results?
I don't know how fine a point I can put on this, but...
He's right. You're wrong. The reason why really shows up here: "What throws most people is that although they are used to 1/3 being a repeating decimal, they think 0.1 should be an exact number in floating point."
No, they don't. Most people don't have a clue what floating point means. They are quite blissfully unaware that there's any mindset that would find 1+1 to equal 2 but 0.1 + 0.1 to only sort of equal 0.2.
And they're right not to. 0.1 is fundamentally a nonrepeating value in the standard, Base 10 Arabic numbering system -- it is not a range, it is an edge. That computers don't use Base 10 internally is not an excuse for them to be providing inaccurate answers to relatively simple problems, it's only an explanation. Intel's FDIV bug couldn't be explained away with a detailed technical description of the bug("Oh yeah! That's because we forgot to set that bit! What? There's still a problem? We told you its cause..."); neither can the use of floats be forgiven in applications that are expected to operate on discrete values.
I am, of course, not the first to point this out. More than a few systems -- usually for the financial types -- operate using BED(Binary-Encoded Decimals), which are quite slow and horrifyingly inefficient but do not suffer from the artifacts mentioned. Fundamentally, while floats(and particularly doubles) can be munged into being "accurate enough" for most discrete computations, ultimately their use is very reminiscent of the classic quote by John Von Neumann:
"Anyone who attempts to generate random numbers by deterministic means is, of course, living in a state of sin."
Speeding is illegal. Suggest that every car should have a sensor that detects itself speeding, and automatically assesses a fine to be paid to the appropriate jurisdiction, and watch people recoil in horror.
Underage drinking is illegal. Suggest that random door-to-door searches for alcohol be employed to enforce that particular set of laws, and watch respect for the law diminish to nothing.
This does not mean there is not a critical purpose for GPS-based tracking devices (yes, even covertly deployed) and canvassing a region, for there certainly is. As uncomfortable as Patriot makes us, we cannot deny there are circumstances that indeed justify significantly more zealous investigation and prosecution.
But the circumstances matter.
To those whose powers are wide, their interest must be narrow. To those whose interests are wide , it is a matter of life and death that their powers be kept narrow. A team dedicated to the prevention of nuclear terror must not have their procedures threatened by, say, a "moral police" seeking to police adultery! Gloating about mission creep and the utter inability to keep sacred maybe the only saving grace of Patriot ("really, we just want to go after those who want to kill us all") is astonishing.
This is a slippery slope that costs lives. I cannot believe I am hearing it praised.
Cell phones involve ignoring whoever's around you while making them painfully aware there is a conversation occuring that they may not join. Cell phones cause cancer.
WiFi involves sitting quietly, tapping away, but easy to interrupt on a whim. WiFi does not cause cancer.
Smoking involves making other people smell you. Smoking causes cancer.
Nobody wants to see you get your colon checked for polyps. Not going to the proctologist doesn't cause cancer.
So says those who can't shut up about cancer.
Don't take annoyance for granted -- a large part of the law, a much larger part than you'd expect, is purely devoted to preventing people from bothering eachother excessively. But never, ever forget the true meaning of statements like "the intense use of mobile phones by youngsters": It is great for me, but I do not like it for you.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Of course, this was the concept behind the Dracucell, which theoretically will be able to extract about 100W from the bloodstream (though actual efficiencies will be quite a bit below that).
I suspect Dracucells will do wonders for the diabetic population.
Same difference -- stunnel also terminates the TCP session (necessary, since it's operating at userspace), extracts the payloads, and sends them over an encrypted pipe. The differences are:
1) SSL has theoretically better key management, which is actually not theoretical for browsers (it's the only successful deployment of certificates in history), but stunnel by default barely checks SSL certificates. So, unfortunately, you're very vulnerable to a MITM attack (but you probably were anyway, since even if you had a cert, you almost certainly get it signed.) 2) SSH has theoretically worse key management, which is actually not theoretically awful for large installations (there's no real deployable cert systems, no centralized authority, etc.), but ssh by default actually does manage to allow one individual to manage access to a couple of personally relevant servers surprisingly well. SSH also has the advantage of having a port forwarding system flexible enough to execute VPN behaviors through, whereas SSL is really just a pipe to whatever's on the other end. (This is actually sometimes a good thing.)
(Full Disclosure: I designed part of OpenSSH's tunnelling subsystem.)
TCP over TCP has issues when both stacks attempt to respond to the same error conditions. This happens very commonly with PPP over SSH. However, TCP port forwards in OpenSSH actually terminate at the daemon, which extracts the payloads, repacks them into completely independent streams, and sends them on their way.
In other words, an error condition on the routerexternal_site link doesn't show up on the clientrouter link.
OpenSSH tunnels have surprisingly high performance (it certainly beats most proxy implementation hands down). Easy to set up, too: Simply SSH into your host of choice with the -D option(say, ssh -D1080 user@host), set the SOCKS4 proxy in your application to 127.0.0.1:1080, and you're done. It's really quite simple.
Re, V.90/V.92 having faster upstream...I doubt it: 56K only became possible due to the proliferation of digital interfaces to the PSTN. Put simply, the upstream side has more control over their signal than the downstream. A "peer to peer" 56K connection will never exceed 33.6.
They may have fixed the FCC 53.3 limit, or they may have just decided to call whatever they were getting 56K (certainly, there's so much error correction and retransmission anyway that the idea of a consistent fixed speed for an entire session is starting to border on ludicrous).
This is, of course, quite true for several reasons. First of all, a 56k FR line is actually 56K bidirectionally -- by contrast, v.90 (the spec for 56k over PSTN) is actually only a specification for downstream traffic, and even then downstream only occurs at 53.3 "due to FCC restrictions". Upstream still pokes along using v.34 at between 28.8 to 33.6.
Inline compression is also a large contributer to latency -- modems do it, frame relay systems simply don't (to my knowledge, anyway). Compression always has a cost; beyond CPU time, you must actually store data for a bit to see if you can send
Even though you'd think the text inherent to telnet would compress well, you must remember that individual characters are basically one ~54 byte packet per keystroke -- and these are binary packet headers encapsulated by PPP, so good luck compressing that with RLE. (I haven't checked if v.34 had a more intelligent algorithm...if so, the redundant binary headers might actually be symbolizable.) Regardless of compressibility, though, the system will continue to delay the sending of data as it evaluates whether or not it can save bandwidth through compression. So you get added latency here too.
Another small issue is that less overhead may exist for certain types of terminal-over-FR systems, where packets are simply tagged with a header symbol rather than the full thing. For a full serial emulation, it's imaginable for there to not really be packetization at all -- the moment a byte comes in, it is sent upstream. But I think that defeats the multi-terminal case.
The biggest potential hit to latency is someting I suspect but haven't verified: Modems appear to suffer _badly_ from half-duplex crosstalk. In other words, much more than FR lines, if a modem is receiving a significant amount of data, its ability to send is significantly hampered. Now, I could be wrong -- haven't fully tested FR, and Bimodem (a transfer protocol built for uploading and downloading simultaneously from BBSes) did seem effective in the 14.4 days. So I'm unsure.
Actually, some of the most interesting commentary about modem latency has come from John Carmack, the creater of Doom and Quake. IP over Modem users struggle to achieve round trip latencies less than 200ms, and 300-350ms are quite common. This creates a maximum game-world frame rate of about 3-5FPS (since you can only get as many updates as you have round trips!). Carmack's type of games really want 15-30 FPS, so this is a problem. He found that the softmodems could actually be tweaked massively to reduce latency (disable FIFOs and compression, add explicit support for urgent sends, etc). I don't think he ever got the code to build this, though.
So, yes. I'm quite aware of the difficulties with modem latency. Thanks for making me realize that, among other things, modem users can be detected simply by analyzing the latency difference between the hop right before them and their own hop:-) This will be useful.
A little humility, Tom?:-) There are some people who've been in this game even longer than we have.
You actually haven't lived through it all. Neither have I. (Backstory: Tom and I are friends.)
What he's referring to is Frame Relay -- the method by which X.25 networks (telenet/tymnet, for the Delphi/Source/Compuserve/GEnie folks of the mid 80's) propogated their traffic, and ultimately the way most nationally dispersed data centers exchanged their data. Those networks didn't run on modems per se (they didn't convert signals into something that ran over POTS), but the converters that interfaced local hardware to the telco's 9600bps line could almost certainly cost $10K -- it's a simple matter of small market, large investment in R&D, and, oh yes, a monopoly too:-)
CSU/DSU's for T1's aren't cheap either, even with SDSL modems running a couple hundred dollars.
Incidentally, this isn't even a thing of the past. It turns out 56K Frame Relay links live on. I know of a _massive_ corporation that links most of its stores to the central mainframe via 56K FR links. Why? Because It Works.
Alright, I can buy AND/OR -> min/max translation (particularly since it leads to correct results in the binary case), but I can't seem to find any writings on which De Morgan algebra you're referring to that uses this property. Linkage?
Slashdot Mirror
http://www.boomspeed.com/kajardine/Tom_Baker-Comme rcial_Voiceover_Outtakes.mp3
As Warren Ellis wrote on his blog (which of course is where I found this, right next to the mind-boggling sci-fi snippets), This Is Essential.
For the curious, take the most regal sounding brit you've ever heard. Now make him sell something utterly absurd -- and give him the cojones to say so.
Repeatedly.
A new classic.
--Dan
--Dan
Hmmm. Not exactly.
I can definitely see google searching by speech, but results will almost certainly come back via a visual display. This is part of that classic paradox of communication: We read faster than we hear, but we speak faster than we write. Particularly with google, which has easily scannable chunks of content that hyperlink you to what you're looking for, speech reply would be a horribly inefficient channel to introduce except for the most straightforward questions.
I do expect voice control of google soon (they're already working on it; it was one of their lab tools).
--Dan
It was pretty painful, but not like you'd think.
"For those who don't know, Geer wrote an article talking about the risks of monoculture that situations like we have with Microsoft expose."
Lets look at the article's title:
Does anyone see the word Monoculture in there? No, just monopoly. It's up there next to "Dominance", "Cost", and "Insecurity".
Somewhere along the lines, this paper jumped from technical analysis to political polemic, and Geer got the political response. Don't get me wrong: The vast majority of the conclusions reached in this article have way more than a grain of truth in them. But the degree to which Schneier backpedalled on the tone was pretty noticable, and stood in stark contrast to the near-rage of the paper itself.
Would Geer have kept his job if the paper was more objectively written? I don't know. But I sure note what I see reported on doesn't match what I read in that paper, and I have to wonder why.
Yours Truly,
Dan Kaminsky, CISSP
DoxPara Research
http://www.doxpara.com
Paul,
We have many stateless cryptosystems, none of them good. They all struggle with replay attacks (it's hard to detect a replay when you're not keeping track of a session) and dropped packets (it's hard to synchronize keystreams when there is no inherent stream at work).
Gutmann does know what he's talking about, and is mostly right. He just didn't really express that there's a *reason* people aren't using SSL and SSH, and I moved to correct that.
--Dan
Hmmm. Looks like I misread the OpenSSH source code. You're quite right, set_newkeys for SSH2 modifies different contexts depending on whether the mode is set to MODE_IN or MODE_OUT.
SSHv1, by dint of depending on the validity of the encryption to secure the CRC, does sort of use the same key for both. But, yeah.
Incidentally, this is really useful knowledge (it means my SSL hack now works for SSH).
--Dan
Ordering issues and dropped packet management are what you're missing. SSL and SSH get it for free by running over TCP.
Is a dropped packet an attack, or a normal error? It's nontrivial to know.
--Dan
The problem isn't that TCP is assuming an unreliable medium underneath; TCP is as happy to operate over a perfectly reliable IP network as it is to operate over a somewhat unreliable one (significantly unreliable networks outstrip TCP's ability to compensate, mandating solutions like Airhook). The problem is that, when packets are dropped, the nature of the network changes, because both the external and the internal networks move to compensate.
It's the dual adjustment that breaks everything.
--Dan
UDP is a thin wrapper that basically adds ports and a checksum to IP and nothing more.
It's one of those "tiny systems that popped up because we don't have good stateless crypto" -- as Guttman points out, it's as flawed as everything else that didn't go through SSH and SSL's trial by fire.
The point to my post was, damnit, there's a *reason* SSH and SSL aren't good enough: They utterly ignore the fact that unreliable networks need to be secure too, by mandating an underlying reliable transport.
It's much easier to keep your crypto synced when you can't drop packets.
--Dan
First of all, I've got a tremendous amount of respect for Peter Guttman, and not just because he's the author of the coolest quote relating to computer security of all time (if you can't find it in that essay, you're not paying attention). But...he misses the point.
... TCP is terminated at the forwarder, addressed using SOCKS4 or SOCKS5(>3.7.0), and forwarded to the appropriate destination on the other side of the tunnel. It's TCP _only_, but it operates completely in userspace.
We do not have an effective method of running a stateless cryptosystem, but IP actually does require stateless operation. All these mini-systems that have sprouted up exist because of this.
SSH(which, incidentally, violates Guttman's rules by using "the same key for encryption and authentication") and SSL(which utterly falls apart when the cert gets compromised) both run over TCP. TCP is not IP. TCP adds reliability, through error detection, correction, order management, and congestion management. That's all well and good, but sometimes I really don't care when I drop a packet. Voice traffic is a fantastic example -- by the time the retransmission is complete, the data is stale and irrelevant. But TCP will not only stop to retransmit, it'll hold up everything else while it does so, and even slow down the connection to be sure a dropped packet doesn't happen again.
There are _many_ protocols which can accept these semantics. But there are many that cannot, and there's a bigger problem: By supporting those protocols that do not share the connection semantics of TCP -- DNS, VoIP, etc -- we end up being forced to carry either GRE or PPP packets over the SSL/SSH tunnel -- and inside these PPP packets, that are being carried by TCP, is more TCP.
This doesn't work very well at all -- effectively, both sockets attempt to simultaneously adjust to changing network conditions, and since neither knows about eachother, they both screw up badly.
All because we do not have a stateless cryptosystem that works. It may very well be that such a demand is impossible. Stateless cryptosystems can send a message and not only not prenegotiate a session key, but tolerate large number of dropped packets. Replay attacks need to be suppressed, but packets need to be able to survive high latencies. CPU load needs to be kept reasonable, but no message can rely on the asymmetric results of another.
In short, normal cryptosystems are built to be inflexible to attackers; we do not know how to make them simultaneously flexible for networks. The reasons why should be obvious -- anything that can go wrong on the network, will go wrong because of an attacker. So telling everybody to use SSH/SSL is ultimately code for, "We just don't have the crypto to secure IP." And we know IPSec is a failure; if it hadn't been for VPN's, it'd be as rare as multicast and a hundred times more expensive.
Solutions? I suspect short signatures will ultimately make the difference, as will better time-based protocols (at least for intra-admin-domain work.) But no matter how high my opinion is of Guttman, I cannot ignore he considers solved problems that fundamentally refuse to go away.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
P.S. There is an immediately available VPN solution that's free and doesn't suffer from TCP-over-TCP effects. Look up Dynamic Forwarding for OpenSSH
Again, explanation is not an excuse. My point is that, until such time as the user executes a mathematical operation whose result becomes a repeating decimal (divide, not add/subtract/multiply/exponentiate), it's mathematically incorrect to employ the FPU in the first place.
I'm well aware the original poster knew little or nothing about floating point math...my question is, where do we get off talking down to him when *ours* are the incorrect results?
--Dan
Dave--
I don't know how fine a point I can put on this, but...
He's right. You're wrong. The reason why really shows up here: "What throws most people is that although they are used to 1/3 being a repeating decimal, they think 0.1 should be an exact number in floating point."
No, they don't. Most people don't have a clue what floating point means. They are quite blissfully unaware that there's any mindset that would find 1+1 to equal 2 but 0.1 + 0.1 to only sort of equal 0.2.
And they're right not to. 0.1 is fundamentally a nonrepeating value in the standard, Base 10 Arabic numbering system -- it is not a range, it is an edge. That computers don't use Base 10 internally is not an excuse for them to be providing inaccurate answers to relatively simple problems, it's only an explanation. Intel's FDIV bug couldn't be explained away with a detailed technical description of the bug("Oh yeah! That's because we forgot to set that bit! What? There's still a problem? We told you its cause..."); neither can the use of floats be forgiven in applications that are expected to operate on discrete values.
I am, of course, not the first to point this out. More than a few systems -- usually for the financial types -- operate using BED(Binary-Encoded Decimals), which are quite slow and horrifyingly inefficient but do not suffer from the artifacts mentioned. Fundamentally, while floats(and particularly doubles) can be munged into being "accurate enough" for most discrete computations, ultimately their use is very reminiscent of the classic quote by John Von Neumann:
"Anyone who attempts to generate random numbers by deterministic means is, of course, living in a state of sin."
--Dan
Speeding is illegal. Suggest that every car should have a sensor that detects itself speeding, and automatically assesses a fine to be paid to the appropriate jurisdiction, and watch people recoil in horror.
Underage drinking is illegal. Suggest that random door-to-door searches for alcohol be employed to enforce that particular set of laws, and watch respect for the law diminish to nothing.
This does not mean there is not a critical purpose for GPS-based tracking devices (yes, even covertly deployed) and canvassing a region, for there certainly is. As uncomfortable as Patriot makes us, we cannot deny there are circumstances that indeed justify significantly more zealous investigation and prosecution.
But the circumstances matter.
To those whose powers are wide, their interest must be narrow. To those whose interests are wide , it is a matter of life and death that their powers be kept narrow. A team dedicated to the prevention of nuclear terror must not have their procedures threatened by, say, a "moral police" seeking to police adultery! Gloating about mission creep and the utter inability to keep sacred maybe the only saving grace of Patriot ("really, we just want to go after those who want to kill us all") is astonishing.
This is a slippery slope that costs lives. I cannot believe I am hearing it praised.
...is annoying other people:
Cell phones involve ignoring whoever's around you while making them painfully aware there is a conversation occuring that they may not join. Cell phones cause cancer.
WiFi involves sitting quietly, tapping away, but easy to interrupt on a whim. WiFi does not cause cancer.
Smoking involves making other people smell you. Smoking causes cancer.
Nobody wants to see you get your colon checked for polyps. Not going to the proctologist doesn't cause cancer.
So says those who can't shut up about cancer.
Don't take annoyance for granted -- a large part of the law, a much larger part than you'd expect, is purely devoted to preventing people from bothering eachother excessively. But never, ever forget the true meaning of statements like "the intense use of mobile phones by youngsters": It is great for me, but I do not like it for you.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Does Microsoft garner enough of a gain from patent law to offset potential $500M losses?
If not, simple economics argues it will (not could, not should, but will) join the Open Source community in opposition to software patents.
The swipe against IBM, which *does* accrue such gain, is just gravy.
Then it gave up.
Too unstable, too unreliable, too much work to keep up. Meanwhile, KDE Just Worked.
Things might be better now, though.
--Dan
Of course, this was the concept behind the Dracucell, which theoretically will be able to extract about 100W from the bloodstream (though actual efficiencies will be quite a bit below that).
I suspect Dracucells will do wonders for the diabetic population.
--Dan
Same difference -- stunnel also terminates the TCP session (necessary, since it's operating at userspace), extracts the payloads, and sends them over an encrypted pipe. The differences are:
1) SSL has theoretically better key management, which is actually not theoretical for browsers (it's the only successful deployment of certificates in history), but stunnel by default barely checks SSL certificates. So, unfortunately, you're very vulnerable to a MITM attack (but you probably were anyway, since even if you had a cert, you almost certainly get it signed.)
2) SSH has theoretically worse key management, which is actually not theoretically awful for large installations (there's no real deployable cert systems, no centralized authority, etc.), but ssh by default actually does manage to allow one individual to manage access to a couple of personally relevant servers surprisingly well. SSH also has the advantage of having a port forwarding system flexible enough to execute VPN behaviors through, whereas SSL is really just a pipe to whatever's on the other end. (This is actually sometimes a good thing.)
HTH.
--Dan
(Full Disclosure: I designed part of OpenSSH's tunnelling subsystem.)
TCP over TCP has issues when both stacks attempt to respond to the same error conditions. This happens very commonly with PPP over SSH. However, TCP port forwards in OpenSSH actually terminate at the daemon, which extracts the payloads, repacks them into completely independent streams, and sends them on their way.
In other words, an error condition on the routerexternal_site link doesn't show up on the clientrouter link.
OpenSSH tunnels have surprisingly high performance (it certainly beats most proxy implementation hands down). Easy to set up, too: Simply SSH into your host of choice with the -D option(say, ssh -D1080 user@host), set the SOCKS4 proxy in your application to 127.0.0.1:1080, and you're done. It's really quite simple.
--Dan
He seems to be saying IP addresses aren't private, in the way credit card numbers and even telephone numbers are.
Is he wrong?
AFS: Any Flat Surface :-)
Re, V.90/V.92 having faster upstream...I doubt it: 56K only became possible due to the proliferation of digital interfaces to the PSTN. Put simply, the upstream side has more control over their signal than the downstream. A "peer to peer" 56K connection will never exceed 33.6.
They may have fixed the FCC 53.3 limit, or they may have just decided to call whatever they were getting 56K (certainly, there's so much error correction and retransmission anyway that the idea of a consistent fixed speed for an entire session is starting to border on ludicrous).
--Dan
This is, of course, quite true for several reasons. First of all, a 56k FR line is actually 56K bidirectionally -- by contrast, v.90 (the spec for 56k over PSTN) is actually only a specification for downstream traffic, and even then downstream only occurs at 53.3 "due to FCC restrictions". Upstream still pokes along using v.34 at between 28.8 to 33.6.
:-) This will be useful.
Inline compression is also a large contributer to latency -- modems do it, frame relay systems simply don't (to my knowledge, anyway). Compression always has a cost; beyond CPU time, you must actually store data for a bit to see if you can send
Even though you'd think the text inherent to telnet would compress well, you must remember that individual characters are basically one ~54 byte packet per keystroke -- and these are binary packet headers encapsulated by PPP, so good luck compressing that with RLE. (I haven't checked if v.34 had a more intelligent algorithm...if so, the redundant binary headers might actually be symbolizable.) Regardless of compressibility, though, the system will continue to delay the sending of data as it evaluates whether or not it can save bandwidth through compression. So you get added latency here too.
Another small issue is that less overhead may exist for certain types of terminal-over-FR systems, where packets are simply tagged with a header symbol rather than the full thing. For a full serial emulation, it's imaginable for there to not really be packetization at all -- the moment a byte comes in, it is sent upstream. But I think that defeats the multi-terminal case.
The biggest potential hit to latency is someting I suspect but haven't verified: Modems appear to suffer _badly_ from half-duplex crosstalk. In other words, much more than FR lines, if a modem is receiving a significant amount of data, its ability to send is significantly hampered. Now, I could be wrong -- haven't fully tested FR, and Bimodem (a transfer protocol built for uploading and downloading simultaneously from BBSes) did seem effective in the 14.4 days. So I'm unsure.
Actually, some of the most interesting commentary about modem latency has come from John Carmack, the creater of Doom and Quake. IP over Modem users struggle to achieve round trip latencies less than 200ms, and 300-350ms are quite common. This creates a maximum game-world frame rate of about 3-5FPS (since you can only get as many updates as you have round trips!). Carmack's type of games really want 15-30 FPS, so this is a problem. He found that the softmodems could actually be tweaked massively to reduce latency (disable FIFOs and compression, add explicit support for urgent sends, etc). I don't think he ever got the code to build this, though.
So, yes. I'm quite aware of the difficulties with modem latency. Thanks for making me realize that, among other things, modem users can be detected simply by analyzing the latency difference between the hop right before them and their own hop
--Dan
A little humility, Tom? :-) There are some people who've been in this game even longer than we have.
:-)
You actually haven't lived through it all. Neither have I. (Backstory: Tom and I are friends.)
What he's referring to is Frame Relay -- the method by which X.25 networks (telenet/tymnet, for the Delphi/Source/Compuserve/GEnie folks of the mid 80's) propogated their traffic, and ultimately the way most nationally dispersed data centers exchanged their data. Those networks didn't run on modems per se (they didn't convert signals into something that ran over POTS), but the converters that interfaced local hardware to the telco's 9600bps line could almost certainly cost $10K -- it's a simple matter of small market, large investment in R&D, and, oh yes, a monopoly too
CSU/DSU's for T1's aren't cheap either, even with SDSL modems running a couple hundred dollars.
Incidentally, this isn't even a thing of the past. It turns out 56K Frame Relay links live on. I know of a _massive_ corporation that links most of its stores to the central mainframe via 56K FR links. Why? Because It Works.
--Dan
Alright, I can buy AND/OR -> min/max translation (particularly since it leads to correct results in the binary case), but I can't seem to find any writings on which De Morgan algebra you're referring to that uses this property. Linkage?
--Dan
0 AND 0 = 0
0 AND 0.5 = 0
0.5 AND 0.5 = 0.5
0.5 AND 1 = 0.5
1 AND 1 = 1
------------------
This is weighted asymmetrically -- 0 and 0.5 must be 0.5, or 0.5 and 1 can't be 0.5.
--Dan