Nope. That's not it. g and p are always "public". And it doesn't help if an attacker were to chose them. You could specify them in the protocol (i.e. publish them so that eve knows them beforehand) and D-H would still be secure.
If you intercept all traffic, you can pretend to be A towards B and the other way around.
Just like in the case at hand you can provide a "free" accesspoint (with WPA password "free") and funnel it back into the real access point yourself.
Two guys, Diffie and Hellmann thought up a protocol that allows someone to listen to a "key exchange" without being able to determine the key that the two parties decide on.
One party decides on a base (g) and a modulus (p) and sends it to the other side. Our attacker will of course grab this info. Next each party will think up a number. Alice choses a, Bob choses b. Alice sends g^a mod p to Bob. Bob sends g^b mod p back to A. They key is then easy to calculate for Alice and bob. Alice does K = (g^b)^a = g^ab , while Bob does K = (g^a)^b = g^ab where the listening crook just has g^a and g^b and can't figure out a or b which are needed to find the key K in reasonable time.
Thus this protocol being known for almost 35 years allows easy encryption with a key that a eavesdropper cannot easily snoop..
A theoretical computation book had an example of a 100-city traveling salesman problem in the last pages of the book. I put the numbers into my PC-XT running at 10 MHz programmed for a day and found the exact same solution that was published in the book in just under a minute of CPU time. The authors of the book had spent an hour I believe on a CRAY to prove that my/their solution was indeed the best possible.
Some, if not most NP-Hard problems can be solved in reasonable time provided your problem size is small (e.g. a few tens of cities/flowers) or if you accept that your solution might be a few percent worse than the theoretical optimal solution.
My program simply did "hill climbing". It just used one solution and tested if it could improve on that one solution. This is effectively what the bees are doing as well. They take one solution (fly to that far flower), and if they stumble on a better solution (drain that other flower en route) they proceed to that one....
What I would like is a dynamic URL rewriter. When my browser notices a redirect, it submits the URL to a central database and asks for the rewrite rule for the rewriter behind that URL. (i.e. find the url=... in the google redirect).
So my browser would build up a locally cached redirect database, of redirecting rules of sites that I use.
The problem is that this will cause an arms race, that is easy to win for the redirectors. If they have "link=1928347234" instead of "url=http://www.slashdot.org/story/10/09/23/1851220/" it becomes difficult to find the destination URL without building a huge database, as big as the search-engine itself.
Something others are hinting at, but not really saying is GPS signal sensitivity. Phones are lowsy. Modern GPSes are pretty good. Sure, you can navigate (if you have the software) using your phone. But the GPS reception is not good. It can easily be off a few hundred meters. For example, we were navigating using my phone's GPS and driving on a freeway. Every minute or so, the phone would start saying: "After 300 meters, turn left" and "Observe speedlimit (50)" when we were driving on the 130km/h freeway... It would suddenly think we were driving in the village next to the freeway.
Inside the car, i.e. not directly touching the window, it would stop working completely.
A modern GPS-only device, my gps logger, was inside the car all the way, and logged points along the way, never more than a few meters off the center of the road.... It will often continue to work if you move inside a building.
So... Modern GPS chipsets for GPS-only devices are very very good, and even work in situations where you're used to not having GPS reception. The GPS in an older phone will first of all not have a modern GPS chipset, but it will also not have the antenna built-in optimally. It works acceptably in good conditions, but not excellent.
And yes, he does have the right to do that - his work, his call. If you don't follow those conditions you're in the wrong. So you go to a shop, buy a nicely shrink wrapped CD of your favorite band for $10. You go home, open up the shrink wrap, and out falls a little note:
"We're fed up with all this copying. We've encrypted the audio data on this CD, the key is safely stored in our vault. We're the copyright holders, so we get to decide what you can do with the audio data. In this case: nothing. We think that copying the data into the CD player constitutes copying, which is disallowed by the license we give you. You may safely store our intellectual property on this CD on the shelf of your closet. Thank you for understanding. Thank you for purchasing this CD".
And you think this is fair?
No! When you go to a shop to buy a CD, you expect to go home with a data-carrier containing audio-data that you can play at home or in your car for yourself, your house-mates and small groups of friends.
When they don't allow you to do that, they are putting unreasonable restrictions on you.
It is wrong. Copying music without permission is wrong. So you're telling me that I should be fined for buying a CD, ripping it to my computer and playing the MP3 on my computer? (I opted to do that with my CDs instead of building a big CD-changer).
According to the copyright holders I'm violating the copyright. I can jump up and down shouting "fair use" all I want, but it's "copying without permission" according to the record companies, even if they don't own the copyright themselves.
You need to choose your password from a large enough "pool" of possible passwords that brute-forcing them is not likely to be succesful.
I chose my root password from "the set of 8 character lower case letters", or about 208 billion possibilities. Is this a bad password? No not at all. A password from a pool of 208 billion is just fine. If you chose a line from a nursery rhyme and substitute 1 for i and 0 for o, you have a mixed-case with digits password, which on the surface looks as if it comes from a very large pool. But in fact there are not that much nursery rhymes, and just a few rules to modify them. In the end the pool isn't quite as large.
Some people I know chose a password as following: Take a vegetable capitalize the first letter and substitute i by 1, and o by 0. Mixed case, and only maybe 100 options. Not good. Quite awfully bad actually.
CFD is simple. for every timestep and every volume element, you calculate pressure and air (fluid) movement. If there is a pressure difference speed will increase (or decrease). When moving air can't go further, e.g. because it hits something solid, pressure increases.
In one paragraph I've explained the basics of CFD. This means you can teach it to high school students in an hour.
If they've played with say excel before, you can let them do a one-dimensional CFD in excel. (just pressure and speed.).
This effect goes faster the hotter things are. For a normal lifetime of components, manufacturers recommend keeping the junction temperatures below 125C.
Now, that thermo-electric-nuclear powerplant will generate some heat, and some of it will end up on the electronics... But if the specs say -40C.... 85C, don't you thing they would run the electronics around -40C? No nead to heat everything beyond the minimum I'd say...
Now with over 100 degrees between "manufacturer recommended max" and acutal temperature, I'd estimate a lifetime of the chips of around 20000 years. (20 years normal life expectency times 1000 for the 100 degrees lower temp.... )
Anyway, the way the memory cells are organized, with electronics degrading, a whole LINE of memory locations would start acting funny.....
You're the second one to suggest "age". When humans die of age, that's some failure in the human body that's common when people grow old. That's when we say someone died of old age. However when human made devices die, there is always a component that has failed. When you have a 5 year old mobile telephone that dies, you say it died of old age, and replace it. That's because you don't care and replacing it costs less than finding out the root cause for the failure.
When a properly designed computer flips a bit, SOMETHING happened. We may never know, it might have been a cosmic ray. But don't you think that they would use space-certified RAM chips for such a project?
In any case, I don't know what memory technology voyager uses. The (slightly) more modern space shuttles used magnetic core memory for essential systems. These are not affected by cosmic rays. If it isn't magnetic core, then it is likely to be static RAM. This too is not easily modified by a cosmic ray. Modern DRAM however is easily affected by cosmic rays. But exactly because of that, it's not likely that they used DRAM.
In 1977, when the voyagers were launched, DRAM had been commercially available for 7 years.... This might have been too new for NASA to design into their new babies....
I think they simulated Voyager with this bit flipped and saw the same output (that is transmitted to earth).
I hope they tried to flip ALL bits, and found that only this one bit would give the results seen. If you would follow the code and find and test just a few likely places, I'd expect a few more unexpected places to give the same results.
The quick fix is to send the correct byte to the craft and hope that fixes it. If the bit has become stuck in the new position, they will have to do a remote firmware upgrade (with the code rewritten to fit the stuck-at value...) Other memory cells may have broken down in the mean time, but with a stuck-at value that is correct for the current version of the firmware, which you won't know until you try them....
It's happened before. Last time they just rearranged the code so that the particular bit that had become stuck-at-0 was required to be 0. Might have been a mars mission and not voyager.
The disk probably is NOT IDE as the article says. The harddisk is probably MFM. It probably has 17 sectors per head, 4 tracks per cylinder and 312 cylinders.... IIRC...
The serial line sounds reasonable to me.
I'm currently recovering data from a seagate drive. The seagate drive has a debugging serial port. The sata port is completely dead.... I'm hoping to figure out which parts I need instead of having to copy everything over the serial port....
Oh, you care about disk space? Ah! Indeed I don't...:-)
Disk space is some 100 times cheaper than RAM. It's the bloat that ends up in RAM that means you have to buy 2G or 4G of ram in a modern machine to make it work. I can still make a (server-) install in under 1G of disk space, but running a desktop in under 1G of RAM is a performance problem.
The problem with demand paging is that bigger programs end up with small parts of each page that ARE used, while most of a page is unnecessary.
Someone needs to write a profiler that figures this out, and then allow gcc or the linker to take the profile to put all the actually used parts together and the unused (or little-used) parts somewhere else.
Similarly, demand paging back in '2000 (around when the article was written) caused a 7Mbyte binary to be read into memory non-linearly. All the seeking makes the loading slow. I and at least one distribution used to have a "dd if=netscape.bin of=/dev/null bs=64k ; netscape.bin $*" as a shell script instead of netscape. This would load all 7Mbytes into the cache circumventing demand paging which was much slower....
Having the important bits together in say the first megabyte would get us the best of both worlds.
Moreover, with faster harddrives we should be moving towards larger page sizes. Although the hardware has 4k pages, we should use 8k software pages adjacent page table entries are always set (almost) the same! This means that demand paging will fetch 8k at a time. Fetching a 4k page from a harddisk costs you an 8 ms seek time, 4 ms rotational latency, and.05ms for the actual transfer of the data. If we transfer 8k at a time, we go from 12.05ms to 12.1 ms. An increase of less than a percent.
On a modern system fetching this extra 4k comes at a price (besides the 0.05 ms extra transfer time). We'll have to forget about another 4k chunk of memory. However, if we achieve a 1% higher hit-rate on the just-transferred 4k chunk than on the chunk we just discarded, we'll be winning! So if we are able to evict memory that hasn't been used for say over a minute, we're very likely winning over the current strategy.
In practice, security is always a tradeoff between usability and security.
For me having the keys on the local disks is usability, and having them on a pen drive is not.
I personally try to know when a "unknown key warning" is valid or caused by a man-in-the-middle attack. However, imagine having to explain to some computer illiterate person (your mother? someone else's mother if she happens to be computer-literate) when to accept the unknown key prompt and when not. (if that person needs to connect to ONE server only, you can accept the warning once for her and then tell her to never again accept that warning. But if you can't predict to which servers she'll be connecting....)
You're right. changed keys are more difficult to accept than just type yes. Is that the same for putty under windows?
Slashdot Mirror
Nope. That's not it. g and p are always "public". And it doesn't help if an attacker were to chose them. You could specify them in the protocol (i.e. publish them so that eve knows them beforehand) and D-H would still be secure.
If you intercept all traffic, you can pretend to be A towards B and the other way around.
Just like in the case at hand you can provide a "free" accesspoint (with WPA password "free") and funnel it back into the real access point yourself.
Two guys, Diffie and Hellmann thought up a protocol that allows someone to listen to a "key exchange" without being able to determine the key that the two parties decide on.
One party decides on a base (g) and a modulus (p) and sends it to the other side. Our attacker will of course grab this info. Next each party will think up a number. Alice choses a, Bob choses b. Alice sends g^a mod p to Bob. Bob sends g^b mod p back to A. They key is then easy to calculate for Alice and bob. Alice does K = (g^b)^a = g^ab , while Bob does K = (g^a)^b = g^ab where the listening crook just has g^a and g^b and can't figure out a or b which are needed to find the key K in reasonable time.
Thus this protocol being known for almost 35 years allows easy encryption with a key that a eavesdropper cannot easily snoop..
A theoretical computation book had an example of a 100-city traveling salesman problem in the last pages of the book. I put the numbers into my PC-XT running at 10 MHz programmed for a day and found the exact same solution that was published in the book in just under a minute of CPU time. The authors of the book had spent an hour I believe on a CRAY to prove that my/their solution was indeed the best possible.
Some, if not most NP-Hard problems can be solved in reasonable time provided your problem size is small (e.g. a few tens of cities/flowers) or if you accept that your solution might be a few percent worse than the theoretical optimal solution.
My program simply did "hill climbing". It just used one solution and tested if it could improve on that one solution. This is effectively what the bees are doing as well. They take one solution (fly to that far flower), and if they stumble on a better solution (drain that other flower en route) they proceed to that one....
What I would like is a dynamic URL rewriter. When my browser notices a redirect, it submits the URL to a central database and asks for the rewrite rule for the rewriter behind that URL. (i.e. find the url=... in the google redirect).
So my browser would build up a locally cached redirect database, of redirecting rules of sites that I use.
The problem is that this will cause an arms race, that is easy to win for the redirectors. If they have "link=1928347234" instead of "url=http://www.slashdot.org/story/10/09/23/1851220/" it becomes difficult to find the destination URL without building a huge database, as big as the search-engine itself.
Something others are hinting at, but not really saying is GPS signal sensitivity. Phones are lowsy. Modern GPSes are pretty good. Sure, you can navigate (if you have the software) using your phone. But the GPS reception is not good. It can easily be off a few hundred meters. For example, we were navigating using my phone's GPS and driving on a freeway. Every minute or so, the phone would start saying: "After 300 meters, turn left" and "Observe speedlimit (50)" when we were driving on the 130km/h freeway... It would suddenly think we were driving in the village next to the freeway.
Inside the car, i.e. not directly touching the window, it would stop working completely.
A modern GPS-only device, my gps logger, was inside the car all the way, and logged points along the way, never more than a few meters off the center of the road.... It will often continue to work if you move inside a building.
So... Modern GPS chipsets for GPS-only devices are very very good, and even work in situations where you're used to not having GPS reception. The GPS in an older phone will first of all not have a modern GPS chipset, but it will also not have the antenna built-in optimally. It works acceptably in good conditions, but not excellent.
And yes, he does have the right to do that - his work, his call. If you don't follow those conditions you're in the wrong.
So you go to a shop, buy a nicely shrink wrapped CD of your favorite band for $10. You go home, open up the shrink wrap, and out falls a little note:
"We're fed up with all this copying. We've encrypted the audio data on this CD, the key is safely stored in our vault. We're the copyright holders, so we get to decide what you can do with the audio data. In this case: nothing. We think that copying the data into the CD player constitutes copying, which is disallowed by the license we give you. You may safely store our intellectual property on this CD on the shelf of your closet. Thank you for understanding. Thank you for purchasing this CD".
And you think this is fair?
No! When you go to a shop to buy a CD, you expect to go home with a data-carrier containing audio-data that you can play at home or in your car for yourself, your house-mates and small groups of friends.
When they don't allow you to do that, they are putting unreasonable restrictions on you.
It is wrong. Copying music without permission is wrong.
So you're telling me that I should be fined for buying a CD, ripping it to my computer and playing the MP3 on my computer? (I opted to do that with my CDs instead of building a big CD-changer).
According to the copyright holders I'm violating the copyright. I can jump up and down shouting "fair use" all I want, but it's "copying without permission" according to the record companies, even if they don't own the copyright themselves.
You need to choose your password from a large enough "pool" of possible passwords that brute-forcing them is not likely to be succesful.
I chose my root password from "the set of 8 character lower case letters", or about 208 billion possibilities. Is this a bad password? No not at all. A password from a pool of 208 billion is just fine. If you chose a line from a nursery rhyme and substitute 1 for i and 0 for o, you have a mixed-case with digits password, which on the surface looks as if it comes from a very large pool. But in fact there are not that much nursery rhymes, and just a few rules to modify them. In the end the pool isn't quite as large.
Some people I know chose a password as following: Take a vegetable capitalize the first letter and substitute i by 1, and o by 0. Mixed case, and only maybe 100 options. Not good. Quite awfully bad actually.
CFD is simple. for every timestep and every volume element, you calculate pressure and air (fluid) movement. If there is a pressure difference speed will increase (or decrease). When moving air can't go further, e.g. because it hits something solid, pressure increases.
In one paragraph I've explained the basics of CFD. This means you can teach it to high school students in an hour.
If they've played with say excel before, you can let them do a one-dimensional CFD in excel. (just pressure and speed.).
My colleague found lots of specs and info on the nasa site.
In short: Three different computers, with 4, 8 and 4 kwords of memory each. words are 16 or 18 bits (depending on which computer you're looking at).
Memory is plated-wire memory. http://en.wikipedia.org/wiki/Plated_wire_memory
Each computer has an identical sister, for redundancy.
This effect goes faster the hotter things are. For a normal lifetime of components, manufacturers recommend keeping the junction temperatures below 125C.
Now, that thermo-electric-nuclear powerplant will generate some heat, and some of it will end up on the electronics... But if the specs say -40C .... 85C, don't you thing they would run the electronics around -40C? No nead to heat everything beyond the minimum I'd say...
Now with over 100 degrees between "manufacturer recommended max" and acutal temperature, I'd estimate a lifetime of the chips of around 20000 years. (20 years normal life expectency times 1000 for the 100 degrees lower temp.... )
Anyway, the way the memory cells are organized, with electronics degrading, a whole LINE of memory locations would start acting funny.....
You're the second one to suggest "age". When humans die of age, that's some failure in the human body that's common when people grow old. That's when we say someone died of old age. However when human made devices die, there is always a component that has failed. When you have a 5 year old mobile telephone that dies, you say it died of old age, and replace it. That's because you don't care and replacing it costs less than finding out the root cause for the failure.
When a properly designed computer flips a bit, SOMETHING happened. We may never know, it might have been a cosmic ray. But don't you think that they would use space-certified RAM chips for such a project?
In any case, I don't know what memory technology voyager uses. The (slightly) more modern space shuttles used magnetic core memory for essential systems. These are not affected by cosmic rays. If it isn't magnetic core, then it is likely to be static RAM. This too is not easily modified by a cosmic ray. Modern DRAM however is easily affected by cosmic rays. But exactly because of that, it's not likely that they used DRAM.
In 1977, when the voyagers were launched, DRAM had been commercially available for 7 years.... This might have been too new for NASA to design into their new babies....
Certainty? I don't think so.
I think they simulated Voyager with this bit flipped and saw the same output (that is transmitted to earth).
I hope they tried to flip ALL bits, and found that only this one bit would give the results seen. If you would follow the code and find and test just a few likely places, I'd expect a few more unexpected places to give the same results.
The quick fix is to send the correct byte to the craft and hope that fixes it. If the bit has become stuck in the new position, they will have to do a remote firmware upgrade (with the code rewritten to fit the stuck-at value...) Other memory cells may have broken down in the mean time, but with a stuck-at value that is correct for the current version of the firmware, which you won't know until you try them....
It's happened before. Last time they just rearranged the code so that the particular bit that had become stuck-at-0 was required to be 0. Might have been a mars mission and not voyager.
I can hope, can't I?
Right! And from the way the original question is posted, I'm thinking he has at least SOME monetary power over the providers...
Right. 6 months is a bit excessive. But my "if all goes smooth" attack plan would incur more than 2 hours of work.
Of course, being able to (destructively) study the device for a month, and THEN given two hours makes sense.
Since the Nokia N95?
(At least, that's where I heard about that: from the manual).
The disk probably is NOT IDE as the article says. The harddisk is probably MFM. It probably has 17 sectors per head, 4 tracks per cylinder and 312 cylinders.... IIRC...
The serial line sounds reasonable to me.
I'm currently recovering data from a seagate drive. The seagate drive has a debugging serial port. The sata port is completely dead.... I'm hoping to figure out which parts I need instead of having to copy everything over the serial port....
Oh, you care about disk space? Ah! Indeed I don't... :-)
Disk space is some 100 times cheaper than RAM. It's the bloat that ends up in RAM that means you have to buy 2G or 4G of ram in a modern machine to make it work. I can still make a (server-) install in under 1G of disk space, but running a desktop in under 1G of RAM is a performance problem.
That's the bloat I care about.
The problem with demand paging is that bigger programs end up with small parts of each page that ARE used, while most of a page is unnecessary.
Someone needs to write a profiler that figures this out, and then allow gcc or the linker to take the profile to put all the actually used parts together and the unused (or little-used) parts somewhere else.
Similarly, demand paging back in '2000 (around when the article was written) caused a 7Mbyte binary to be read into memory non-linearly. All the seeking makes the loading slow. I and at least one distribution used to have a "dd if=netscape.bin of=/dev/null bs=64k ; netscape.bin $*" as a shell script instead of netscape. This would load all 7Mbytes into the cache circumventing demand paging which was much slower....
Having the important bits together in say the first megabyte would get us the best of both worlds.
Moreover, with faster harddrives we should be moving towards larger page sizes. Although the hardware has 4k pages, we should use 8k software pages adjacent page table entries are always set (almost) the same! This means that demand paging will fetch 8k at a time. Fetching a 4k page from a harddisk costs you an 8 ms seek time, 4 ms rotational latency, and .05ms for the actual transfer of the data. If we transfer 8k at a time, we go from 12.05ms to 12.1 ms. An increase of less than a percent.
On a modern system fetching this extra 4k comes at a price (besides the 0.05 ms extra transfer time). We'll have to forget about another 4k chunk of memory. However, if we achieve a 1% higher hit-rate on the just-transferred 4k chunk than on the chunk we just discarded, we'll be winning! So if we are able to evict memory that hasn't been used for say over a minute, we're very likely winning over the current strategy.
The article was written in 1999 (note how I have to be exact by including the millennium in the year!), and corrected in '01 and '09.
OK. makes sense! why didn't I think of that?
If you put the flywheel with the axis horizontal, the car will resist turning. My guess is that this doesn't work so well for a racing car....
If you put the flywheel with the axis vertical, the car would lift its inside wheels when cornering a banked turn, right?
In practice, security is always a tradeoff between usability and security.
For me having the keys on the local disks is usability, and having them on a pen drive is not.
I personally try to know when a "unknown key warning" is valid or caused by a man-in-the-middle attack. However, imagine having to explain to some computer illiterate person (your mother? someone else's mother if she happens to be computer-literate) when to accept the unknown key prompt and when not. (if that person needs to connect to ONE server only, you can accept the warning once for her and then tell her to never again accept that warning. But if you can't predict to which servers she'll be connecting....)
You're right. changed keys are more difficult to accept than just type yes. Is that the same for putty under windows?