Preferably the image itself should be encoded with all textual details (date, time, speed, location, direction, etc) and that should be signed by the camera.
Actually, we sign hashes (and not messages) for both efficiency reasons AND security reasons. This is because, imagine we're using RSA and we have some values: x_1, x_2 and x = x_1 * x_2 mod N (pubkey is N,e; privkey is d, p, q). So we'll ask for two signatures and create an existential forgery.
S_1 = (x_1)^d mod N
S_2 = (x_2)^d mod N
Then we can create:
S = x^d mod N
S = ( x_1 * x_2 )^d mod N
S = (x_1)^d * (x_2)^d mod N
S = S_1 * S_2 mod N
So we've created a valid signature for x without having had to ask for a signature on x; this is an existential forgery. These are so-called blinding attacks.
My reading of the scant info on this case is that the villain being fingered is the MD5 algorithm, not the overall protocol which used that algo.
Let's assume this is the protocol:
camera takes snap shot, uses signing key on tamper-resistant chip inside camera to sign a hash of that photo (with the time, speed, etc. concatenated onto the end of the photo before hashing)
send bill to speeder (possibly including hash of picture or in some way "committing" to that particular md5sum)
Then, the problem the bad guy has is to find another picture with that same hash value. This is a preimage attack [find another photo that outputs this hash value] and the weaknesses in MD5 were collision weaknesses: particular collisions found and an algorithm for generating collisions. But collisions are just two messages that have the same hash value, not a particular hash value of your choosing.
If the protocol doesn't have a way to securely associate a hash with a photo (e.g. doesn't sign it), then it doesn't make a difference if you're using MD5 or SHA-1 or SHA-256, the cops can still just doctor photos at will and only produce the hashes of the doctored photos. So this line of "attack" has nothing to do with underlying cryptographic weaknesses.
[Note also that the weaknesses in MD5 don't affect the security of HMAC-MD5].
Hell, the case should be thrown out since the defense atty had the temerity to issue this stunning (even in buzz-word-addled tech) mischaracterization:
"People have shown it [the algorithm] has been hacked and it's open to viruses."
A cursory google search reveals that she's been working in the secure-systems group at Oracle (albeit in a Product Marketing role) for 12 years. I'd say that's fairly substantial.
I'd say YOU lack sufficient "credentials" to post on her lack of sufficient credentials since you obviously didn't look for any sense of her qualifications save for the two-sentence bio provided in the grandparent.
So you're thinking of a slight variation on the canonical DNS cache poisoning theme:
Victim gets email (allegedly from user@target.com--doesn't really matter) containing link to www.target.com
Victim clicks on link and in response victim's local name server send a query for www.target.com
Malicious guy interposes and spoofs a response to victim NS query: saying "I'm www.target.com and here is my [fake] IP"
Then victim connects to fake IP (spoofed paypal site)
So that really describes a timing attack on name server replies. Assuming you're not on the same network as the attacker this requires BOTH: very good timing (getting a response back to the requestor before the real name server does) AND having that response be a valid spoof (i.e. your NS query contains an ID#; the NS response must echo back that number. It's a 16-bit deal... so the attacker may need to spoof 65,535 packets... or expected 32,767). Of course your local name server MUSNT already have a cached value for www.target.com else it won't even generate a request... which means the timing game is nigh impossible.
Another kind of DNS cache poisoning (what I think as the more doable one, unless you're using old, old BIND with predictable query IDs):
Send you an email from www.badguy.com and get you to respond to it... or embed an image hosted at www.badguy.com in the email so that your name server has to figure out how to get that image. Whatever: basically get you to try to resolve badguy.com
Then your name server figures out how to get to www.badguy.com (maybe through.com) and then once he gets the name server for www.badguy.com, that name server actually responds and says: "badguy.com delegates to www.ns1.TARGET.com and www.ns2.TARGET.com" AND says "www.ns1.TARGET.com is at [IP address of name server under control of badguy] and www.ns2.TARGET.com is at [IP address of name server under control of badguy]."
So then when you LATER try to go to www.TARGET.com, you'll ask the name server www.ns{1,2}.TARGET.com, the IP of which is a name server under the control badguy.com.
Also there's scenario 3: badguy.com sends an NS request to your NS that contains fake info that he hopes your NS will cache...
Anyway, NB that yours could also be a Unicode hack; i.e. a name that looks indistinguishable from www.paypal.com but actually is different.
So he waits for his cached info to expire, and does it again... except this time, his reply packet includes extra information, "Oh, by the way, www.microsoft.com is on joes.evil.server.here."
What the badguy actually does is:
gets queried for www.badguy.com by target.com
delegates authority for HIS nameservers to ns.yahoo.com, for example; so he says:
www.badguy.com NS ns1.yahoo.com
www.badguy.com NS ns2.yahoo.com
...
ALSO includes fake mappings of the form:
ns1.yahoo.com A 1.2.3.4
ns2.yahoo.com A 1.2.3.4
...
so target.com contacts "ns1.yahoo.com" at 1.2.3.4 and asks to resolve "www.badguy.com"
since ns1.yahoo.com is *actually* a name server under bad guy's control (bad guy controls 1.2.3.4), ns1.yahoo.com returns how to get to www.badguy.com
then in future queries for www.yahoo.com, the name server will ask 1.2.3.4 for the IP for www.yahoo.com and send that reply to the requestor
The minimum TCP Maximum Segment Size is, as you say, 576 bytes (536 B TCP payload + 20 bytes TCP header + 20 bytes IP header).
So if the MSS option isn't used during connection set-up, 576 bytes will be used by default (536-byte segment size).
The minimum IP MTU is 68 bytes (for IPv6 it's 1280 bytes which is why there's a possibility for a Path MTU attack whereby some host sends an ICMP TooBig to the IPv6 tunnel source to force fragmentation -- since ICMP TooBigs can be spoofed...). How to detect false TooBig? How to track the source once detected?
This is why 3DES is actually encrypt-decrypt-encrypt.
Actually 3DES is encrypt-decrypt-encrypt for backward compatibility.
Use k1 = k2 = k3 to get single DES with a triple DES box.
Doing double encrypt doesn't buy you much in the face of brute force attacks (since you can build two tables: one with the encryption of the plaintext under all 2^56 keys k1 and the other with the *decryption* of the ciphertext using all 2^56 keys k2) so we don't get time complexity of 2^112 for a brute force attack.
OK, it's already been pointed out that HBS is perhaps trying to deflect attention from its own mistake via harshly punishing those involved.
Is it also possible that a motivation for punishing *all* students and not just the student who posted the hack that in order to punish the poster, they'd have to get BusinessWeek to give them the real name of the login of the poster who told folks about the hack? Seems possible to me though as I recall, BusinessWeek was pretty cozy with admissions folks and probably would have given up the name of the poster without thinking twice.
And anyone I'm doing an MSCS which I greatly prefer; never could quite sell myself on taking B-school classes; with the CS I really feel like I'm learning something hard, which I love.
In fact, a few years back I applied for business school and one of the schools on my list was MIT's Sloan. As I recall, there was some 'hack' (hack lite) one could use to determine whether one had been admitted and it consisted of this: you would basically ping the mail server and figure out if a UID had been created for you. If it had, then you were in; if it hadn't, then either you weren't in or your UID hadn't been created yet.
Near as I can tell this is exactly identical to what went on here; using some 'covert' mechanism to ascertain admission status.
I consider myself ethical to a ridiculous fault but I am sure I too would have checked and not thought much about it before hand (as being unethical). If you leave your pants down, you shouldn't be too surprised when people take a gander at what's there.
I think you and your SO have a different frame of reference than I do. And I'm not trying to be the one saying, "There is no man behind the curtain."
But I also think that what happens in an academic setting is possibly different than what would be allowed to happen out in the open in a business setting.
I have worked in an environment that was 90% male (as an engineer for a router manufacturer not Cisco) and I didn't face any of this bullshit that you mention. I was treated with respect. I'm currently in a graduate program in CS (a pretty good one, actually) and again, I face none of the bullshit you mention (being constantly harassed, treated poorly by female superiors,...).
Am I incredibly lucky? Or instead do I just project an attitude that enables me to be treated decently? I'm certainly NOT avoiding harassment because I'm too ugly to trifle with... suffice it to say that's not a problem.
I'll tell you this much too; I haven't been raised to worry about what might be going on, what might be being said about me. I was lucky enough to have the ideal instilled in me that merit would carry the day. So that's what I focus on (rather than focusing on excuses). Thus far I have not been disappointed in this regard.
I do have a problem as well with grown women complaining about mass media culture. Get over it, already.
These girls aren't showing aptitude because it's not socially acceptable to do so.
I don't buy this.
"Showing aptitude" == scoring well on standardized tests, doing well on homework, etc.
Do you really mean to suggest that there is a large swath of female Albert Einsteins who are failing their Pre-Calc so they can get the guy?
That's from the movie, "Mean Girls," not from most real life with which I am acquainted. Are there such girls? Yes, but probably very few (and they're probably lacking in the gumption that it takes to succeed in the business world in general if they are so willing to extinguish their light for purported improved social standing).
I will finally add that I think the problem (to the extent that one exists) is LESS that girls are trying to be socially popular and so are not showing their aptitudes and MORE the soft stuff that encourages girls to be popular and to put their efforts into gaining social standing (so it's not like they are intentionally not showing aptitude; it IS like they are just putting much more effort into other stuff that is, let's face it, transient). But I think most girls grow out of this by late high school, early college (I did, at least).
All sorts of bullshit like you mentioned is prevalent in almost any anonymous setting.
If this is actually going on in your (engineering/CS) work environment, then you've got a problem and I'd suggest you don't waste yourself toiling amongst such people.
Otherwise it's just jackoffs being jackoffs. Not relegated to the field of CS, unfortunately (just ask folks in Sales, or the Financial Industry or...). You get the point.
Why not just encourage folks who are good at math (and/or science) to broaden and deepen their capabilities in these core academic subjects?
My father became an engineer because a teacher at St. Dunstan's (in Milbrae, CA), his parochial grammar school, encouraged him to do so b/c the guy -- my dad -- was always good at math and science. It wasn't til much later that he actually settled on the particular subcategory of engineering (post tours as a Seabee in Nam) and began working on his career.
I think the same model should still hold. We should encourage those who show aptitude to get into this field. And instead of encouraging them to "join IT," we should be encouraging them to take as much math as they can handle and worry about specific job/career paths later on, when it's more appropriate.
So my two gripes are: (1) don't just encourage girls for the sake of encouraging girls, encourage those who are actually likely to excel and improve the field and (2) don't start pushing specific career paths to 14/15 year olds. Instead get them working on the academics that underpin many careers in technology in general. To encourage someone to become a help desk employee is a bit premature at age 14 imo.
"Peace in our time" is repeated today as a mockery of Neville Chamberlain thinking. The way it was used by grandparent poster (your parent) was not in support of this idealism but in defense of leaders' decisions to continue proliferating nuclear weapons...
Those actions are based on real fears and should not be looked back upon in hindsight as having been totally unnecessary.
I implore you to read more carefully before slamming someone next time. (And don't assume that just because he uses all lower case letters, he's some passive peace-nik).
"At their face-to-face summit of October 1986 in Reykjavik, Reagan went far beyond Gorbachev's proposal of a 50 percent strategic-arms cut. To the alarm of some aides, who were not let in on the discussion, he suggested that the two sides get rid of nuclear weapons altogether and jointly build an SDI system to guard against a nuclear revival.
"Gorbachev initially dismissed the idea. 'I do not take your idea of sharing SDI seriously,' the minutes (which were declassified by the Soviets 12 years ago) show him saying. 'You don't want to share even petroleum equipment, automatic machine tools, or equipment for dairies, while sharing SDI would be a second American revolution--and revolutions do not occur all that often.'
"'Reagan replied, 'If I thought that SDI could not be shared, I would have rejected it myself.'
"The Reykjavik talks finally fizzled. Gorbachev said he'd accept the zero-nukes plan if Reagan pledged not to test nuclear weapons in outer space (a crucial element of SDI). Reagan wouldn't accept that condition.
Doesn't matter. It isn't needed. It tries to address a threat that is not there now and NEVER will be.
Originally it was at least partially conceived as a bargaining chip.
Perhaps you're familiar with the disarmament agreements between the erstwhile USSR and the US during Reagan's term? Then perhaps you are aware that during negotiations in Reykjavik, Gorbachev was willing to agree to HUGE concessions (destruction of ICBMs,...) on one condition: that the US abandon its SDI efforts. Reagan said no (to the utter horror of the short-sighted folks who saw Gorbachev's concessions as "too good") and later of course was proven correct in his non-blinkingness.
After all a few years ago, the WSJ used to use crypt() with input == username || server_secret (where || means concatenation) to create a user's cookie (for access to the subscription-only portions of the site).
And crypt() only takes 8 chars of input; so if the username was longer than 8 chars then the server_secret was not used and if two usernames were identical in the first 8 chars (not prohibited by the WSJ system), then the two would have the same hashed value.
And the cookie consisted of: username || output_of_crypt (as above); so one could forge a cookie for any user (and thereby have access to that user's account info... and use that user's credit card info (if stored as part of the user's account)
So the adversary only needs to know a username to log in as a user (and can discover a username by trying to register one and IF registration fails (b/c "that username is not available") -- bam! you've got access).
Anyway, it was pretty easy to recover the server_secret because of this... which by the way was a value that could have been recovered via a dictionary attack anyway (IIRC, it was the original release date of the system).
Want the dets? Look here (*.pdf) -- "Dos and Don'ts of Client Auth on the Web" by Fu/Sit/Smith/Feamster.
As if we need to give cube mates some other bad habit to distract us with (where the first bad habit might be in { listening to something on the speakers with headphones on... but not plugged in, having intimate conversations with friends and loved ones 3 line-of-sight feet away,...}.
Slashdot Mirror
Actually polymorphic viruses do have a signature : the decryption loop that decrypts the payload. It's metamorphic viruses that have no signature.
Let's assume this is the protocol:
- camera takes snap shot, uses signing key on tamper-resistant chip inside camera to sign a hash of that photo (with the time, speed, etc. concatenated onto the end of the photo before hashing)
- send bill to speeder (possibly including hash of picture or in some way "committing" to that particular md5sum)
Then, the problem the bad guy has is to find another picture with that same hash value. This is a preimage attack [find another photo that outputs this hash value] and the weaknesses in MD5 were collision weaknesses: particular collisions found and an algorithm for generating collisions. But collisions are just two messages that have the same hash value, not a particular hash value of your choosing.If the protocol doesn't have a way to securely associate a hash with a photo (e.g. doesn't sign it), then it doesn't make a difference if you're using MD5 or SHA-1 or SHA-256, the cops can still just doctor photos at will and only produce the hashes of the doctored photos. So this line of "attack" has nothing to do with underlying cryptographic weaknesses.
[Note also that the weaknesses in MD5 don't affect the security of HMAC-MD5]. Hell, the case should be thrown out since the defense atty had the temerity to issue this stunning (even in buzz-word-addled tech) mischaracterization: http://www.smh.com.au/news/national/motorist-wins
No; bugger off.
Jesus, ease up, Sparky.
A CISSP?
y 2003/tc20030529_1659_tc111.htm
A cursory google search reveals that she's been working in the secure-systems group at Oracle (albeit in a Product Marketing role) for 12 years. I'd say that's fairly substantial.
http://www.businessweek.com/technology/content/ma
I'd say YOU lack sufficient "credentials" to post on her lack of sufficient credentials since you obviously didn't look for any sense of her qualifications save for the two-sentence bio provided in the grandparent.
What a lamer.
- Victim gets email (allegedly from user@target.com--doesn't really matter) containing link to www.target.com
- Victim clicks on link and in response victim's local name server send a query for www.target.com
- Malicious guy interposes and spoofs a response to victim NS query: saying "I'm www.target.com and here is my [fake] IP"
- Then victim connects to fake IP (spoofed paypal site)
So that really describes a timing attack on name server replies. Assuming you're not on the same network as the attacker this requires BOTH: very good timing (getting a response back to the requestor before the real name server does) AND having that response be a valid spoof (i.e. your NS query contains an ID#; the NS response must echo back that number. It's a 16-bit deal... so the attacker may need to spoof 65,535 packets... or expected 32,767). Of course your local name server MUSNT already have a cached value for www.target.com else it won't even generate a requestAnother kind of DNS cache poisoning (what I think as the more doable one, unless you're using old, old BIND with predictable query IDs):
- Send you an email from www.badguy.com and get you to respond to it... or embed an image hosted at www.badguy.com in the email so that your name server has to figure out how to get that image. Whatever: basically get you to try to resolve badguy.com
- Then your name server figures out how to get to www.badguy.com (maybe through
.com) and then once he gets the name server for www.badguy.com, that name server actually responds and says: "badguy.com delegates to www.ns1.TARGET.com and www.ns2.TARGET.com" AND says "www.ns1.TARGET.com is at [IP address of name server under control of badguy] and www.ns2.TARGET.com is at [IP address of name server under control of badguy]."
- So then when you LATER try to go to www.TARGET.com, you'll ask the name server www.ns{1,2}.TARGET.com, the IP of which is a name server under the control badguy.com.
Also there's scenario 3: badguy.com sends an NS request to your NS that contains fake info that he hopes your NS will cache...Anyway, NB that yours could also be a Unicode hack; i.e. a name that looks indistinguishable from www.paypal.com but actually is different.
http://www.schneier.com/blog/archives/2005/02/uni
What the badguy actually does is:
- gets queried for www.badguy.com by target.com
- delegates authority for HIS nameservers to ns.yahoo.com, for example; so he says:
- www.badguy.com NS ns1.yahoo.com
- www.badguy.com NS ns2.yahoo.com
- ...
- ALSO includes fake mappings of the form:
- ns1.yahoo.com A 1.2.3.4
- ns2.yahoo.com A 1.2.3.4
- ...
- so target.com contacts "ns1.yahoo.com" at 1.2.3.4 and asks to resolve "www.badguy.com"
- since ns1.yahoo.com is *actually* a name server under bad guy's control (bad guy controls 1.2.3.4), ns1.yahoo.com returns how to get to www.badguy.com
- then in future queries for www.yahoo.com, the name server will ask 1.2.3.4 for the IP for www.yahoo.com and send that reply to the requestor
Much better explained hereAs DJB says, the "work around" is not to accept authoritative mappings (e.g. ns1.yahoo.com A 1.2.3.4) from anyone but yahoo.com.
...wish I had mod points to acknowledge it.
The minimum TCP Maximum Segment Size is, as you say, 576 bytes (536 B TCP payload + 20 bytes TCP header + 20 bytes IP header).
So if the MSS option isn't used during connection set-up, 576 bytes will be used by default (536-byte segment size).
The minimum IP MTU is 68 bytes (for IPv6 it's 1280 bytes which is why there's a possibility for a Path MTU attack whereby some host sends an ICMP TooBig to the IPv6 tunnel source to force fragmentation -- since ICMP TooBigs can be spoofed...). How to detect false TooBig? How to track the source once detected?
Since a coward is the opposite of one exhibiting valor.
This is why 3DES is actually encrypt-decrypt-encrypt.
Actually 3DES is encrypt-decrypt-encrypt for backward compatibility.
Use k1 = k2 = k3 to get single DES with a triple DES box.
Doing double encrypt doesn't buy you much in the face of brute force attacks (since you can build two tables: one with the encryption of the plaintext under all 2^56 keys k1 and the other with the *decryption* of the ciphertext using all 2^56 keys k2) so we don't get time complexity of 2^112 for a brute force attack.
OK, it's already been pointed out that HBS is perhaps trying to deflect attention from its own mistake via harshly punishing those involved.
Is it also possible that a motivation for punishing *all* students and not just the student who posted the hack that in order to punish the poster, they'd have to get BusinessWeek to give them the real name of the login of the poster who told folks about the hack? Seems possible to me though as I recall, BusinessWeek was pretty cozy with admissions folks and probably would have given up the name of the poster without thinking twice.
I don't recall.
And anyone I'm doing an MSCS which I greatly prefer; never could quite sell myself on taking B-school classes; with the CS I really feel like I'm learning something hard, which I love.
I think HBS's response is way overboard.
In fact, a few years back I applied for business school and one of the schools on my list was MIT's Sloan. As I recall, there was some 'hack' (hack lite) one could use to determine whether one had been admitted and it consisted of this: you would basically ping the mail server and figure out if a UID had been created for you. If it had, then you were in; if it hadn't, then either you weren't in or your UID hadn't been created yet.
Near as I can tell this is exactly identical to what went on here; using some 'covert' mechanism to ascertain admission status.
I consider myself ethical to a ridiculous fault but I am sure I too would have checked and not thought much about it before hand (as being unethical). If you leave your pants down, you shouldn't be too surprised when people take a gander at what's there.
That robot is gonna need a beer.
I think you and your SO have a different frame of reference than I do. And I'm not trying to be the one saying, "There is no man behind the curtain."
...).
... suffice it to say that's not a problem.
But I also think that what happens in an academic setting is possibly different than what would be allowed to happen out in the open in a business setting.
I have worked in an environment that was 90% male (as an engineer for a router manufacturer not Cisco) and I didn't face any of this bullshit that you mention. I was treated with respect. I'm currently in a graduate program in CS (a pretty good one, actually) and again, I face none of the bullshit you mention (being constantly harassed, treated poorly by female superiors,
Am I incredibly lucky? Or instead do I just project an attitude that enables me to be treated decently? I'm certainly NOT avoiding harassment because I'm too ugly to trifle with
I'll tell you this much too; I haven't been raised to worry about what might be going on, what might be being said about me. I was lucky enough to have the ideal instilled in me that merit would carry the day. So that's what I focus on (rather than focusing on excuses). Thus far I have not been disappointed in this regard.
I do have a problem as well with grown women complaining about mass media culture. Get over it, already.
These girls aren't showing aptitude because it's not socially acceptable to do so.
I don't buy this.
"Showing aptitude" == scoring well on standardized tests, doing well on homework, etc.
Do you really mean to suggest that there is a large swath of female Albert Einsteins who are failing their Pre-Calc so they can get the guy?
That's from the movie, "Mean Girls," not from most real life with which I am acquainted. Are there such girls? Yes, but probably very few (and they're probably lacking in the gumption that it takes to succeed in the business world in general if they are so willing to extinguish their light for purported improved social standing).
I will finally add that I think the problem (to the extent that one exists) is LESS that girls are trying to be socially popular and so are not showing their aptitudes and MORE the soft stuff that encourages girls to be popular and to put their efforts into gaining social standing (so it's not like they are intentionally not showing aptitude; it IS like they are just putting much more effort into other stuff that is, let's face it, transient). But I think most girls grow out of this by late high school, early college (I did, at least).
...you should focus on being a careful thinker.
That would include, for example, not drawing inferences about "women in the US and Canada" based upon the reported meanderings of 14 year olds.
All sorts of bullshit like you mentioned is prevalent in almost any anonymous setting.
...). You get the point.
If this is actually going on in your (engineering/CS) work environment, then you've got a problem and I'd suggest you don't waste yourself toiling amongst such people.
Otherwise it's just jackoffs being jackoffs. Not relegated to the field of CS, unfortunately (just ask folks in Sales, or the Financial Industry or
Why not just encourage folks who are good at math (and/or science) to broaden and deepen their capabilities in these core academic subjects?
My father became an engineer because a teacher at St. Dunstan's (in Milbrae, CA), his parochial grammar school, encouraged him to do so b/c the guy -- my dad -- was always good at math and science. It wasn't til much later that he actually settled on the particular subcategory of engineering (post tours as a Seabee in Nam) and began working on his career.
I think the same model should still hold. We should encourage those who show aptitude to get into this field. And instead of encouraging them to "join IT," we should be encouraging them to take as much math as they can handle and worry about specific job/career paths later on, when it's more appropriate.
So my two gripes are: (1) don't just encourage girls for the sake of encouraging girls, encourage those who are actually likely to excel and improve the field and (2) don't start pushing specific career paths to 14/15 year olds. Instead get them working on the academics that underpin many careers in technology in general. To encourage someone to become a help desk employee is a bit premature at age 14 imo.
Oh yeah, I'm a girl (a woman, actually).
"Peace in our time" is repeated today as a mockery of Neville Chamberlain thinking. The way it was used by grandparent poster (your parent) was not in support of this idealism but in defense of leaders' decisions to continue proliferating nuclear weapons...
Those actions are based on real fears and should not be looked back upon in hindsight as having been totally unnecessary.
I implore you to read more carefully before slamming someone next time. (And don't assume that just because he uses all lower case letters, he's some passive peace-nik).
From here:
"At their face-to-face summit of October 1986 in Reykjavik, Reagan went far beyond Gorbachev's proposal of a 50 percent strategic-arms cut. To the alarm of some aides, who were not let in on the discussion, he suggested that the two sides get rid of nuclear weapons altogether and jointly build an SDI system to guard against a nuclear revival.
"Gorbachev initially dismissed the idea. 'I do not take your idea of sharing SDI seriously,' the minutes (which were declassified by the Soviets 12 years ago) show him saying. 'You don't want to share even petroleum equipment, automatic machine tools, or equipment for dairies, while sharing SDI would be a second American revolution--and revolutions do not occur all that often.'
"'Reagan replied, 'If I thought that SDI could not be shared, I would have rejected it myself.'
"The Reykjavik talks finally fizzled. Gorbachev said he'd accept the zero-nukes plan if Reagan pledged not to test nuclear weapons in outer space (a crucial element of SDI). Reagan wouldn't accept that condition.
Doesn't matter. It isn't needed. It tries to address a threat that is not there now and NEVER will be.
...) on one condition: that the US abandon its SDI efforts. Reagan said no (to the utter horror of the short-sighted folks who saw Gorbachev's concessions as "too good") and later of course was proven correct in his non-blinkingness.
Originally it was at least partially conceived as a bargaining chip.
Perhaps you're familiar with the disarmament agreements between the erstwhile USSR and the US during Reagan's term? Then perhaps you are aware that during negotiations in Reykjavik, Gorbachev was willing to agree to HUGE concessions (destruction of ICBMs,
True story; look it up.
After all a few years ago, the WSJ used to use crypt() with input == username || server_secret (where || means concatenation) to create a user's cookie (for access to the subscription-only portions of the site).
And crypt() only takes 8 chars of input; so if the username was longer than 8 chars then the server_secret was not used and if two usernames were identical in the first 8 chars (not prohibited by the WSJ system), then the two would have the same hashed value.
And the cookie consisted of: username || output_of_crypt (as above); so one could forge a cookie for any user (and thereby have access to that user's account info... and use that user's credit card info (if stored as part of the user's account)
So the adversary only needs to know a username to log in as a user (and can discover a username by trying to register one and IF registration fails (b/c "that username is not available") -- bam! you've got access).
Anyway, it was pretty easy to recover the server_secret because of this... which by the way was a value that could have been recovered via a dictionary attack anyway (IIRC, it was the original release date of the system).
Want the dets? Look here (*.pdf) -- "Dos and Don'ts of Client Auth on the Web" by Fu/Sit/Smith/Feamster.
As if we need to give cube mates some other bad habit to distract us with (where the first bad habit might be in { listening to something on the speakers with headphones on... but not plugged in, having intimate conversations with friends and loved ones 3 line-of-sight feet away, ...}.