December 2003 - cypherpunks-legacy

New PGPfone Beta Test Available (1.0b5) Still Mac only
by jis＠mit.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- MIT is now distributing a new beta test version of PGPfone. This version (1.0b5) is not compatible with the previous version (1.0b4) and may not be compatible with the final 1.0 release. This version supports Macintoshes with half-duplex hardware. It also supports secure voice communication over the Internet (the "Internet" button that had been grayed out in earlier versions is now active). PGPfone is being distributed both via anonymous FTP and via the World Wide Web (WWW). The WWW retrieval path is preferred because it is much easier to use. U.S. and Canadian FTP users should retrieve the file /pub/PGPfone/README via anonymous FTP from net-dist.mit.edu. It explains how to obtain the PGPfone release via FTP. Note: The old release is still located on the FTP site. The new version is named "PGPfone10b5.sea.Hqx." Web users should visit the PGPfone home page located at: "http://web.mit.edu/network/pgpfone/" In addition to general information and information on getting PGPfone, the home page also contains a link to the PGPfone HTML on-line manual. The manual can also be found directly at: "http://web.mit.edu/network/pgpfone/manual/". THE WINDOWS '95 VERSION IS EXPECTED TO BE AVAILABLE WITHIN THREE WEEKS. However schedules can and do often change. Please DO NOT send me e-mail requesting information on release scheduling. I will also be releasing shortly the SOURCE CODE to this beta test version. We (the PGPfone development team and myself) do not recommend that people attempt to compile this source (unless you are a real wizard). YOU SHOULD NOT ATTEMPT TO DO PGPFONE PORTS TO OTHER PLATFORMS with this code. I say this because this is still a beta test version and things are likely to still change significantly. If you port this source code, you may be wasting your time! However I doubt that the basic structure of the code will change, so you can get an idea of how it works and how much effort a port would require. NOTE: The FTP PGP/PGPfone distribution site has recently been updated with a list of many more "known to be in the U.S. or Canada" domain names. If you are a U.S. or Canadian user and you cannot get access to the PGPfone distribution it is either because your domain name is not known to us to be located in the U.S. or Canada *or* we could not determine your host's domain name given its Internet address. IF YOU CANNOT GET PGPFONE FROM US try to get it from somewhere else. I cannot afford the time to e-mail people personal copies at this time. We are working on alternative technology for the FTP/WWW distribution site so that the number of bad denials (i.e., not letting people in the U.S. or Canada get in) is reduced. Bugs and Questions should be directed to pgpfone-bugs(a)mit.edu. -Jeff -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMPAeNcUtR20Nv5BtAQEz6AP+JUSyBUGH1iZHCTxGICfcuZy4qTlDpqXJ xUDaS6IPKJKHPj5Np0EghRQ4e5CMQcknlz4WN6G++Zoy2tMUOVkpIe20Oor/XTia xCQVyydXDfHk0U6nv4HxVMxBajL6YSzw0Kb+L2JQDbSSbt3DGkujnT003bxvUZgi syDfLcUl7ks= =tiRZ -----END PGP SIGNATURE-----

1 0

Re: phone calls from hell
by David K. Merriman 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 11:16 AM 01/7/96 -0800, you wrote: >At 01:15 PM 1/7/96 -0500, you wrote: > >>SNS News Service "Exploding Phone" >>January 7, 1996..15 Teves 5756..Number 850..Update from Israel >>It is now being reported that the cellular phone that killed him was >>detonated by a remote control. The son of Ayyash's landlord, identified >>as Ikrimeh Hamad, was expected to have handed Ayyash the phone >>earlier in the day. Some reports state that his whereabouts are >>unknown but other reports stated that he is now hiding-out in Israel. >>>>27 Heathway Court * London England * NW3 7TS * 44-181-458-6510 >>Fax: 44-181-455-8701 >> Copyright, Shomron News Service, 1996 >> >>*** >> >>Comment by bd: >> >>I suppose this phone was prepared especially for Ayyash, but the >>imagination wanders. Imagine a world in which *every* cellphone >>(or other net-connected computer or ....) had a little explosive built >>in. For that matter, the case itself could be constructed of a plastic >>explosive. >> >>Sure would make it easy to get rid of unwanted citizens. >>Just match the voice pattern on the cellphone or confirm the password >>issuing from the computer, send the special signal down the line and >>*BOOM*, one less nuisance for the state. > > >Sorta gives new meaning to the term "_Terminate_ and Stay Resident" program, doesn't it?!? > >(Or "end of file.") > Wrong number? Nuisance Call? Termination of Service? -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMO9fIsVrTvyYOzAZAQGIIAP/YgT7jrlyUOTLVPHn1HytkYr5PbQoeiCd 3M1n+WRXEWJAEVEDZ5+FpxKcW+5b9qXjZyeL+PmGy90xQ6LaBewQ2EIMJFw48PZw TsZ8kalL8s2+rSOuxJJmVVBuUs3P4RzIJ0qL1A43SNf4AJb/V4COmvFf3wfHwYI0 zyfVH+435Fg= =gQRH -----END PGP SIGNATURE----- ------------------------------------------------------------- "It is not the function of our Government to keep the citizen from falling into error; it is the function of the citizen to keep the Government from falling into error." Robert H. Jackson (1892-1954), U.S. Judge <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> My web page: http://www.geopages.com/CapitolHill/1148

1 0

Jan 13 CA bay area meeting - time
by mrm＠netcom.com 17 Dec '03

17 Dec '03

Sorry! I forgot to mention that the meeting is held from 12 noon to 6 p.m. Date: Saturday January 13 Time: 12 noon - 6 p.m. Location: Building 21, Sparcy's cafeteria, Sun Microsystems Agenda: YOUR NAME HERE! (hint hint) Food: Bagels provided. Feel free to bring lunch to munch. Directions: Take 101 to Amphitheater Parkway. At the end of the exit ramp, turn left at the light onto Charleston. (This street is also known as Garcia.) After about 1/3 mile, turn right onto the side street. This will be the first city side street on your right, as you drive down Charleston/Garcia. In about 2 or 3 blocks, you'll see purple signs for Building 21 of Sun. If anyone driving down from SF or Berkeley can pick up Ian at the SF airport that would be way groovy. Marianne mrm(a)netcom.com mrm(a)eng.sun.com

1 0

PGP 3.0
by amp 17 Dec '03

17 Dec '03

-- [ From: amp * EMC.Ver #2.3 ] -- -----BEGIN PGP SIGNED MESSAGE----- Hello all, I've seen a couple of messages here about possibilities of what might be in pgp 3.0. I am in agreement that keys should be expirable. I produce new keys once a year anyway. This is probably excessive given my probable threat models, but I think it lends itself well to having a sort of time-stamp on documents. Given that it is true that I could keep a copy of my unrevoked key after I've formally revoked it, I still think that it is beneficial to have signed documnents produced over time bear keys that are time-bound at least as far as the way I use pgp. The main point of this post was really to ask if there is a page or rfc somewhere that describes what is expected to be in pgp 3.0. Is there a particular reason that this to-be-released-with-source program is shrouded in what appears to be secrecy? As usual, I'm confused. It would help me greatly if I were able to give people an idea of the added capabilities pgp will posess whenever it is finally released. This isn't a flame as I'd like to see it done right the first time rather than have it released then see 4 or 5 different bug fixes quickly come out that confuse the issue during its introduction. I found the FUD surrounding 2.6.x to be hard to overcome with some people. <non-ob-crypto:> Heck, I found a copy of pkz204e the other day on a pc in my office. The FUD surrounding this product was pretty great if y'all recall. <back on crypto:> I give talks occasionally about my company's internet offerings for business. It would be nice to be able to speak of the future of crypto with pgp with a bit more certainty. Thanks for your time and consideration, amp <0003701548(a)mcimail.com> (since 10/31/88) <alan.pugh(a)internetmci.com> PGP Key = 57957C9D PGP FP = FA 02 84 7D 82 57 78 E4 E2 1C 7B 88 62 A6 F9 F7 January 7, 1996 15:12 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMPApK4dTfgZXlXydAQHRagf/dqF+gF41JYIBroUlmddgX6Lur3ISBxrl MhtMAdcFzyBcRxrYIgPf+gkkzOqNSBeXHvwvZ/CWLuJpvbRXnCD0IL3hhoYGVIl5 UxvP2gh1M+wU7pEm6DYlQpq2z3OVxoG62LW6+v1YgVP6hHOEQNUYGn64TSFMDbdr cU63c3pXLusBb6yLM5dKaPZDqo8y2YHo6hYDT21SW+Tx0MxOK7/diL9qfbBXyitk 8tmNmgti6V0MCatRAh0L4xc7kkDq33RXhyEgjTimTTwt0QIgV/QLAPN1Mdj/ZEoj U599xGySNUfPXLwJz5mda0UDS3Pp1CNHpjdUzpFUbhDndSo1sh+ocA== =cxUU -----END PGP SIGNATURE-----

1 0

RE: "trust management" vs. "certified identity"
by Alan Olsen 17 Dec '03

17 Dec '03

At 12:00 PM 1/7/96 -0800, you wrote: >We already operate largely in a "web of trust" model world. > >Here's a pertinent example. I've met perhaps 100 people from this list, >over the last several years. Not a single one--not even one--have I ever >seen any "proofs of identity" for. Did I say "Not a single one"? How many people ask for "proof of Identity" from their friends? Not very many, I can bet... (Maybe the excesivly paranoid.) >I deal with them as "persistent personnas," with either their physical >appearances (biometric security) or their writing styles/e-mail addresses >providing the continuity of their persistent personna. Things like this can complicate depending on your social circles. For those involved in the SCA (Society for Creative Anacrnyms) or Science Fiction conventions people may or may not go under a host of names. You may or may not know their "true" name. There are people who i have known for many years who are good friends and yet I do not know their "real" name. (And I am not really concerned about not knowing that name.) Some people I know by multiple names. (Makes conversations interesting when the nyms change every few sentences...) What matters is the continuity of the individual, not what nym they happen to be using at any given point. (The net makes this alot more complex though, as you usually do not have visual contact with the people you are responding to... Individuals are harder to forge than e-mail.) The criteria I use as to whether I can "trust" a source is based on a number of factors. Have they given reliable information in the past? Does the information corilate with other information from reliable sources? Does their attitude get in the way of the information provided? (Sometimes it takes heavy filters to discern fact from opinion or just a pissy attitude...) What gains my respect is similar, but also based on their general attitude and how they treat people. (Of course there is not cert mechanism for a "web of respect".) [examples cliped] >Frankly, the notion that a central government would issue proofs of >trustability, via identity cards and the like, is a modern invention. I find the idea that a little card "proves" my identity a bizarre form of mystisism. (Especially when that "proof" can suddenly expire or be revoked by the whims of the State.) >(The message of Vinge's "True Names" was partly ironic, that one's True >Name is important primarily in allowing tagging by the government. As has been said before, one of the main reasons for the Government's (and others) desire for "true names" is so those that offend them can be punished. >Ordinary >people rarely need True Names. As I said, I've never checked the supposed >True Names of those I deal with. Nor have most of you, I strongly suspect. >In fact, given the way credentials can be so easily forged, I wouldn't >trust a driver's license or even a passport. And given the government's >ability and demonstrated willingness to generate false >documentation--60,000 new identities in the Witness Security Program, plus >all the spies, narcs, etc.--I even more surely don't care what official >identification supposedly proves.) Government paperwork proves that "they" know who you are and have some sort of hooks into your persona. (taxation, legal, and/or otherwise.) This is, of course, if it is "real" identification and not forged by a competing interest. >I don't want official proof of my identity. If others want it, let them >make their own arrangements. > >"Papieren, bitte! Macht schnell!" "I don't have any papers. All I got is a pipe!" | Remember: Life is not always champagne. Sometimes it is REAL pain. | |"The moral PGP Diffie taught Zimmerman unites all| Disclaimer: | | mankind free in one-key-steganography-privacy!" | Ignore the man | |`finger -l alano(a)teleport.com` for PGP 2.6.2 key | behind the keyboard.| | http://www.teleport.com/~alano/ | alano(a)teleport.com |

1 0

Re: NSA says strong crypto to china??
by zinc 17 Dec '03

17 Dec '03

On Sun, 7 Jan 1996, Timothy C. May wrote: > Date: Sun, 7 Jan 1996 11:43:40 -0800 > From: Timothy C. May <tcmay(a)got.net> > To: cypherpunks(a)toad.com > Subject: Re: NSA says strong crypto to china?? > > At 10:37 AM 1/7/96, Alex Strasheim wrote: > > By the way, this is related to why I think you folks should all be > supporting the "flat tax" and similar proposals. (Especially the proposal > to end the double taxation of corporate income: tax the company and not the > individual shareholders, or vice versa, but don't first tax the income to > the corporation and then tax the distributed income/dividends/capital gains > again.) you think that's a bit ridiculous? i'm paid via an NIH grant given to my adivisor by the govt. this stipend is taxed. it didn't used to be (started to be taxed around '86 i believe). why the hell doesn't the govt just save everyone the trouble and pay me less. i'm sure they could get rid of a couple of IRS people this way. -pjf patrick finerty = zinc(a)zifi.genetics.utah.edu = pfinerty(a)nyx.cs.du.edu U of Utah biochem grad student in the Bass lab - zinc fingers + dsRNA! ** FINGER zinc-pgp(a)zifi.genetics.utah.edu for pgp public key - CRYPTO! zifi runs LINUX 1.2.13 -=-=-=WEB=-=-=-> http://zifi.genetics.utah.edu

1 0

Re: "Re: NSA says strong crypto to china??
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 7:32 PM 1/7/96, Alan Olsen wrote: >I can also think of another good reason that no dissident in their right >mind would want to use US escrowed GAK. How many times have individuals >been sold out for some "greater good". I can just imagine some dissident >getting sold out as the result of some mega-trade deal or the like. (And I >am sure that they can too...) As when the Cossacks who fled the U.S.S.R. after the war and pledged to help the West fight Communism were returned by the British to Stalin, where they were executed. (I was reminded of this by the latest Bond movie, where Bond avers, "Not exactly Britain's finest moment.") Had they been using Brit-GAK, then even more of them could've been rounded up by the Brits and send packing. >Why does this news report sound more like someone trying to sell GAK to the >US public and not "chinese dissidents? Was Noriega our friend or our enemy, and when? If his followers were using the U.S. as their friendly keyholder, how would this have played out when the U.S. government decided to switch sides? When governments change, the U.S. often switches sides as well. The U.S. holding the keys of dissidents will not fly. The notion that the U.S. will become the GAK-holder for the world's dissidents is too absurd to waste more time on. --Tim May We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 - 1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

A couple of ideas for PGP-based programs
by Alan Olsen 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I am posting these ideas here before I annoy the people who will probibly implement them just to see if they have much merit... (If this is incoherent it is because of the late night posting, but I want to get it done while the thoughts are still there...) Maybe some of this will occur after PGP 3.0 is released. (That is, if the universe has not cooled down into a small lump of coal before then...) 1) Something I would like to see on the keyservers for PGP is a way of retreving all of the key revokations since x date without having to get all of the keys since that date. I hate having to check each key every so often to see if it is revoked. It would make it alot easier to avoid using compromised or old unused keys. 2) I would like to see a program like private Idaho have the ability to send mail to the key server and grab all of the "unknown signator" keys. This would have the interesting effect of building a more complete keyring, while using the "web of trust" to weed out alot of the bogus keys that tend to crop up on the key servers. After n number of itenerations you would have more of the "important keys" and the ones that have little or no signage would be left to grab when needed. This would avoid the need to grab the entire key database. (In fact, it would make it desirable NOT to...) More later when I am not so tired... -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMO5PTOQCP3v30CeZAQET8wf/WI8o18pAol3HcN8j+EZyM7aIkPRFg/EQ IYU+J8c5UrXrHDyUY+lZI11Ip2CgXfL/9ER6+vJ/xKPRfNOYnzOe+53FIOKbhJ0U VPGCJYi7tbIpqBB+SHJe555fijEeGAORMvGqCVosb+KKsZQvQP5SHGK3zsy9rBP+ ojkM3AyJs5uyia4pAjV1Zz3DfxEgMPvBPtqXObN32FVbAq7hGmscDKNHEJ7ifO7H xQiMWyzPJgWdUttdoi9ko7kFYLzze4472hEGNV9DbFZMlpVn6Eex9Hhz/wq20j4i mgfyjU3GF+6+OY8KgkXU79FYKkZYqa019uCuPk50cgRdUZsI1BLyHA== =ImCD -----END PGP SIGNATURE----- Alan Olsen -- alano(a)teleport.com -- Contract Web Design & Instruction `finger -l alano(a)teleport.com` for PGP 2.6.2 key http://www.teleport.com/~alano/ "Governments are potholes on the Information Superhighway." - Not TCMay

2 1

Toad Hop
by John Young 17 Dec '03

17 Dec '03

[Before it is publicized, KM describes for Littman the Christmas 1994 attack on Shimomura's systems as a "TCP/IP prediction packet attack." (. . .) below are by Littman.] Three days later, on January 23, Shimomura will describe the attack in a widely distributed public Internet post. IP source address spoofing and TCP/IP sequence number prediction are the technical terms Shimomura uses to describe it, much like Mitnick's description. But his analysis is extremely technical, and even some UNIX security experts find it tough going. That same day, about 2 P.M., CERT will blast out an advisory to its international mailing list of 12,000 Internet sites in the United States, Germany, Australia, the United Kingdom, Japan, and other countries. The vaguely worded report is much less specific than Mitnick's one-minute explanation on the telephone. Most likely, CERT is trying to provide enough detail so Internet sites can protect themselves against future attacks without providing so much detail that it could encourage copycat attacks. On one level, the hack is simple, a clever strike at a basic weakness of the Internet. Computers on the Internet are often programmed to trust other computers. The Internet was created to share information, and the attack on Shimomura, just like the Robert Morris Internet Worm attack seven years before, exploits that trust. The Internet has its own way of sending e-mail or files. Messages or files are split into smaller digital chunks or packets, each with its own envelope and address. When each message is sent, it's like a flock of birds that migrates to a planned location and reunites as a flock at the destination. Computers on the Internet often act like great flocks of birds that trust one another too. And all it takes is one enemy bird to infiltrate the flock. . . . On Christmas Day 1994 the attack begins. First, the intruder breaks into a California Internet site that bears the cryptic name toad.com. Working from this machine, the intruder issues seven commands to see who's logged on to Shimomura's workstation, and if he's sharing files with other machines. Finger is one of the common UNIX commands the intruder uses to probe Shimomura's machine. As a security professional Shimomura should have disabled the feature. Finger is so commonly used by hackers to begin attacks that 75 percent of Internet sites, or about 15 million of the more than 20 million Internet users, block its function to increase security. The intruder's making judgment calls on the fly about which commands will help him uncover which machines Shimomura's workstation might trust. He works fast. In six minutes he deduces the pattern of trust between Shimomura's UNIX workstation and an unknown Internet server. Then the automatic spoofing attack begins. It will all be over in sixteen seconds. The prediction packet attack program fires off a flurry of packets to busy out the trusted Internet server so it can't respond. Next, the program sends twenty more packets to Shimomura's UNIX workstation. The program is looking for a pattern in the initial sequence numbers -- the numbers used to acknowledge receipt of data during communications. The program deciphers the returned packets by subtracting each sequence number from the previous one. It notes that each new initial sequence number has grown by exactly 128,000. The program has unlocked the sequence number key. Shimomura's machine has to be idle for the attack to succeed. New Internet connections would change the initial sequence number and make it more difficult to predict the key. That's why the hacker attacks on Christmas Day. The attack program sends packets that appear to be coming from the trusted machine. The packet's return or source address is the trusted machine's Internet address. Shimomura's workstation sends a packet back to the trusted machine with its initial sequence number. But flooded by the earlier flurry of packets, the trusted server is still trying to handle the earlier traffic. It's tangled up. Taking advantage of the gagged server, the attacking program sends a fake acknowledgment. It looks real because it's got the source address of the trusted server, and the correct initial sequence number. Shimomura's workstation is duped. It believes it's communicating with a trusted server. Now the attacking program tells Shimomura's obedient workstation to trust everyone. It issues the simple UNIX "Echo" command to instruct Shimomura's workstation to trust the entire Internet. At that point, Shimomura's personal and government files are open game to the world. It's more than a humiliating blow to the security expert. By making Shimomura's machine accessible from any Internet site, the intruder has masked his own location. He can return from anywhere. The hacker can't believe his good luck. The attack is only successful because Shimomura has not disabled the "R" commands, three basic commands that allow users to remotely log-in or execute programs without a password. Tens of thousands of security-conscious Internet sites, representing well over a million users, routinely block access to the R commands to avoid its well publicized abuse by hackers. It takes a few keystrokes and about thirty seconds to shut off the R commands on an Internet server. You don't even have to turn off the machine. Why didn't Shimomura do it? . . . Mitnick laughs. "He's [Shimomura's] not happy. I have nothing to do with it. I'm just telling you what I hear through the grapevine." [Littman] "Who do you think might have done it?" I ask the likely suspect. "How did he figure it out himself?" "He [Shimomura] realized that somebody had edited his wrapper log, which shows incoming connections. Somebody actually modified those logs, and then he was able to reconstruct what happened through these logs that were mailed to another site unbeknownst to the intruder." Mitnick's actually telling me the evidence Shimomura collected to figure out the attack. The wrapper is supposed to control connections to Shimomura's server and log all connection attempts. It failed to protect Shimomura but still it logged the hacker's spoofed connection, and a copy of the log was e-mailed off-site. "So you were asking me if there's a secure e-mail site?" Mitnick continues, his voice suddenly hard. "My answer is no. This guy in my estimation is the brightest in security on the whole Internet. He blows people like Neil Clift away. I have a lot of respect for this guy. 'Cuz I know a lot about him. He doesn't know anything about me, hopefully, but he's good. "On the Internet, he's one of the best in the world." [pp. 222-25] ----- [KM] "I don't know what his motive is. I don't know the man at all. Alls I know is he's very technical and he's very good at what he does. He's in the top five." [JL] "What makes Shimomura so good?" [M] "When someone penetrates his system he knows what to look for. When you compile a program, it uses external files and libraries. This is the type of guy that would look at the access times of the files to try to figure out what type of program somebody was compiling. The guy's sharp." On UNIX systems it's possible to tell the last time a file was read. Mitnick's guessing that Shimomura could determine the type of application that was compiled (converted into the computer's most basic machine language) by examining the date stamps in certain system directories. He's also acknowledging he knows that the intruder compiled a program while he was on Shimomura's machine. Once again, Kevin Mitnick seems to have an amazing amount of detail on how Shimomura analyzes an attack. [M] "He's just very good at -- well, he's a spook. What do you expect? This is only what I hear in the grapevine." ... [L] "But does the grapevine say he's primarily a spook?" [M] "Unknown. He's good in security and he consults with companies like Trusted Information Systems, the people that develop Internet fire walls, and a lot of people in D.C. and the Virginia area." Trusted Information -- the name strikes a bell. Markoff quoted someone from Trusted Information in his front-page "Data Threat" article. [L] "Where is Trusted Information?" [M] "Oh, in Maryland, 301 area code. Baltimore, I believe." [L] "What are some of the Virginia companies Shimomura works with?" [M] "I just have the phone numbers," Mitnick reveals casually. "I haven't called them yet to see." [pp. 252-53] ----- Why not ask John Markoff about the real reason he called me twice this morning? So I ask him about the Shimomura Newsweek story, and the odd reference to cellular phones. He comes back with a stunning revelation. "Somebody hit a different Tsutomu machine last summer and the NSA was pissed," Markoff tells me. "They freaked out. There's no question about it." Why didn't he mention this in his New York Times stories? Why create the false appearance Shimomura was first hacked Christmas Day? "But it was a different machine?" I ask. "Am I being interviewed here?" It strikes me as an odd question. Markoff was the one who called me twice in the space of an hour. Who's interviewing whom? "Let's get on the same wavelength," Markoff suggests. "I'm glad to share this stuff with you, but I want to know where it's going to show up. 'Cuz I'm pretty close to Shimo and it's an issue for me." Before I can respond, he starts talking about Shimomura again. "I wrote that profile of Tsutomu because after I mentioned him in the bottom of my story ["Data Threat"] I basically outed him and a million reporters were all over him." "He wasn't happy about that?" "No, Tsutomu loves it," Markoff says. "He's playing his own games. "I'II tell you it's unclear what was taken [referring to the Christmas hack], and point two, I can send you a public posting by an Air Force information warfare guy who described what was taken and their assessment of the damage. "And there are lots of little snips of code that a brilliant hacker could probably use. But Tsutomu's mind works in very cryptic ways. It's not clear that without Tsutomu you're going to be able to do anything with it. "Now in this break-in I don't actually think a lot of stuff was taken." This break-in? Just how many times was Shimomura hacked before Christmas? But I ask a different question. "Why would an Air Force guy post something?" "Oh, Tsutomu," Markoff casually replies. "He produced a lot of software for the Air Force." "Where would he post this?" "Oh, to a mailing list. A lot of people were concerned about what was taken from his [Shimomura's] machine. What they [the hacker] got was a lot of his electronic mail. Some of it's kind of embarrassing. [But] I don't think people are going to find new ways to attack the network based on this particular attack. "There is another issue," Markoff cautions in a serious tone. "Tsutomu is a very sharp guy, and it is not impossible that that was a bait machine, which is why I stayed away from the issue." Is Markoff implying Shimomura, a rumored NSA spy, laid a trap? And what about Markoff's New York Times articles? Were they part of the trap, too? "Think about it for a second," Markoff pauses dramatically. "And you get into this wilderness-of-mirrors kind of world. And a lot of people that are writing don't know everything, and I don't know everything. "I've been protecting him [Shimomura] for five years. I get the profile and the [Wall Street] Journal is on him. They don't know how close he is to the military. It would make perfect sense. Who knows what's on the code? The guy is in the counterintelligence business." [pp. 258-60]

2 1

Re: Revoking Old Lost Keys
by Deranged Mutant 17 Dec '03

17 Dec '03

Adam Shostack <adam(a)lighthouse.homeport.org> wrote: I wrote: > | PGP should give a warning when the key passes the expiration date. It > | should not prevent you from using it, but should remind you that the > | key is rather old, and that the owner may have moved, etc. [..] > Expire should mean expire, i.e., no longer valid, useful or > useable. If you want to have a 'depreciated after' and an expire > date, that might be useful, but it seems more like feeping creaturitis > to me. It adds bulk to every key, when a better solution would be to > have keys automatically deprecitated some time before they are due to > expire. The reason I think a warning option is good (really, 1 bit bit flag for warn rather than kill... that's "bulk" to every key?) is so that if for whatever reason the key is used (say I am unable to get a newer key for you but really need to send you a private message) I have something to use... and you, if you choose to hold onto old keys, can decrypt it. If not, the sender was warned. > Also, the ability to extend the life of a key is fraught with > danger. The longer a key is around, the more likely it is to become > comprimised. The user might not be aware that the key is comprimised. > Better to have an unchangeable date. (On a more technical level, > allowing users to change the expiry date on a key means that the key's > expiry date is not signed by the signatories, and an opponent who > comprimised a key could simply change the expiry date on that key and > send it to the servers, so that it would continue to be used, and your > opponent could continue to read all your communications.) > > Adam > > -- > "It is seldom that liberty of any kind is lost all at once." > -Hume > > > --- "Mutant" Rob <wlkngowl(a)unix.asb.com> Send a blank message with the subject "send pgp-key" (not in quotes) for a copy of my PGP key.

2 1