- cypherpunks-legacy - lists.cpunks.org

strengthening remailer protocols
by peter.allan＠aeat.co.uk 17 Dec '03

17 Dec '03

This is long enough. I've been brutal and cut sections less likely to promote discussion. (I've also contacted OUP about Ganley's book, and may buy it if I can kid myself I don't need the money.) ============================================================ August 1996 Peter M Allan peter.allan(a)aeat.co.uk Strengthening Remailer Protocols STATUS OF THIS MEMO This memo proposes improvements for the Mixmaster protocol and requests discussion and further suggestions. Distribution of this memo is unlimited. INTRODUCTION Lance Cottrell's documents [1] and [2] describe the current Mixmaster protocol and attacks against it. This memo began as a response to those thoughts, but has developed in discussion with Cottrell. SPAMMING ATTACK [2] describes an active attack where many messages are sent to an honest remailer to separate a message of interest from other traffic. The aim is to clear other messages out of the message pool, wait for the target and finally eject that from the pool. The target message is identified because the attacker can recognise his own messages. Attempts to defeat this attack could well be based on preventing the attacker from recognising his own messages. That is the approach taken here. RE-ENCRYPTION AS A SPAM DEFENCE In this diagram remailer 'A' has received a message addressed to himself. Inside that is one to 'B' - unreadable to A. Further layers are hidden of course. AB????? decrypts to B????? This means that our remailer can only disguise the message by re-encrypting it on the outside. But the message has got to make some net progress toward delivery. The trick is that a remailer can find the outer two headers addressed to him and process both of them. Two headers processed and one rewound is net progress. When the header rewound is addressed to the same recipient as was next on the list anyway the diagram looks like this. Actions at 'A': AB????? decrypts to B????? B????? encrypts to BB????? Actions at 'B': BB????? decrypts to B????? decrypts to C???? encrypts to CC???? The beauty of this is that it is compatible with the existing protocol. If a remailer only knows about removing layers of encryption it still fits into a network where some can do both actions. Whether it sends or receives the message it still works. RE-ENCRYPTION IN THE MIXMASTER ROTATING QUEUE MODEL Instead of layers like an onion, Mixmaster has a queue of headers that get rotated. A used header goes to the back of the queue where it can never again be read. At some point the header at the front of the queue is found to be the last one, and the message is sent on its final hop. For a header queue the above actions look like this: Actions at 'A': AAAB??? -> AAB???a -> AB???aa -> BB???aa In general when the first H headers are addressed to the remailer reading them, (H-1) rotations will be performed, and the top header will be overwritten with another one with a random key and IV to encrypt the rest of the message. The number of headers present remains 20, however many or few of these are still to be read. No valid header block is ever overwritten, only used header blocks that are good for nothing. This is always possible because after a remailer receives a message at least the one header it has just read must be of no further use. This will hide the message content from eavesdroppers, but not from the next remailer in line - 'B'. Assume that remailer B is operated by an attacker, and that he directs spam messages there after host A (which is holding your message in the pool at the time of the attack). B can read all messages sent by the attacker (who knows B's private key). This is also why I think link encryption offers incomplete protection. RE-ENCRYPTION WITH CHEATERS Mixmaster assumes that no particular remailer in the network can be trusted and that the user does not know which remailers cheat. The message passes through a chain of remailers, who aim to hide information from each other so that the compromise of some of them will not disclose the original sender and final destination. Central to the spamming attack is the idea that the attacker can recognise the messages he is trying to trace. This is done by eliminating his own messages. The whole set - not just some of them. It can be arranged that the attacker does not obtain the whole set until it is too late to trace the target message (i.e. after a few hops, when it is likely to have met other legitimate traffic). The partial information the attacker obtains before all the spams are identified will be of some use, but following each of several leads with a new spam attack is unappealing as the number of suspect messages will just grow. The remailer needs the freedom to divert packets to another remailer. This is shown below; where remailer C was chosen at random. Actions at 'A': AAAB??? -> AAB???a -> AB???aa -> CB???aa Each remailer could have three options when sending a packet to its next host. 1) rotate all possible headers, and send the result (current protocol) 2) re-encrypt message with new 3DES key and IV. Do not divert. 3) re-encrypt message with new 3DES key and IV. Divert at random. Good probabilities for these options might be: 1) 20% P(1) = P(3) The number of headers the next host can read should not reveal whether a diversion has just been made. (We care about this because it discourages cheaters deliberately refusing to pass on your mail.) 2) 60% Other outgoing packets are not distinguishable from spams. 3) 20% Should not approach 100%. (To arrive is better than to travel in hope.) A spam attack as described in [2] would use many more packets than those in the message pool (N) on the host under attack. The number of spam packets diverted to honest remailers (a proportion R of the whole) would be about MANY . N . P(3) . R and those diverted twice in succession to honest remailers would be about MANY . N . P(3) . P(3) . R . R and I'd expect a figure above 5 here to thwart the spammer, because of the time taken to collect the 5 spams. This diversion (adding steps to the middle of a chain) seems different from a Middleman scheme [3] where extra hops are added at the end. This scheme does NOT allow a remailer to choose the rest of the chain to be followed. A dishonest remailer cannot bypass any remailer chosen by the original sender (in the hope of following the message to its destination) using only cooperating dishonest remailers) because the message has been encrypted in the public key of each remailer the sender chose before it entered the network. REFERENCES 1 Frequently Asked Questions about Mixmaster Remailers FAQ Version 1.8 July 4 1996 by Lance Cottrell <loki(a)obscura.com.> 2 http://www.obscura.com/~loki/remailer/remailer-essay.html by Lance Cottrell <loki(a)obscura.com.> 3 email "Re: middleman - what is it ?" "John A. Perry" <perry(a)alpha.jpunix.com>

4 3

Re: The Future Of Cyber Terrorism
by jya＠pipeline.com 17 Dec '03

17 Dec '03

http://www.acsp.uic.edu/OICJ/CONFS/terror02.htm This quackery-puffery is truely hilarious. Worth reading for brave attempt to distinguish between our-adorable-intelligent-children qua hackers and terrifying next-door-neighbors so differently-abled-from-us cyber-terrorists. Unsubtly shaded white, off-white, black and blacknet movie-plotting. Thus Sprachen Zarathrustran Klaus: Commerce in ignorant-inner-fear-panderings regulation time.

2 1

Anonymous Remailers
by chris230＠juno.com 17 Dec '03

17 Dec '03

When you mail an item through more than one anonymous remailer, how does that make it anymore anonymous, or doesn't it?

1 0

FW: Cryptography Revisited
by Paul Robichaux 17 Dec '03

17 Dec '03

Anybody want to give this guy The Business? Earlier attempts didn't seem to sink in. -Paul >Path: HiWAAY.net!imci2!imci3!newsfeed.internetmci.com!news.mathworks.com!nntp.primenet.com!news.primenet.com!btcarey >From: btcarey(a)primenet.com (Brent A. Carey) >Newsgroups: comp.sys.mac.programmer.help >Subject: Cryptography Revisited >Date: 23 Aug 1996 01:15:01 -0700 >Organization: Primenet Services for the Internet >Lines: 67 >Message-ID: <btcarey-2308960115290001(a)news.primenet.com> >X-Posted-By: @198.68.41.180 (btcarey) >Mime-Version: 1.0 >Content-Type: text/plain; charset=ISO-8859-1 >Content-transfer-encoding: 8bit >X-Newsreader: Yet Another NewsWatcher 2.2.0 > >I am posting again to hopefully clear up my last post on this topic. I >have received a dozen e-mail replies since I posted less than a day ago. >I believe I poorly represented my request earlier. > >I am retired professional with several years of training and experience in >intelligence analysis and cryptanalysis. The encryption scheme I >developed was employed for 3 years for passing sensitive data over >unsecure channels. Working for the government, the original program was >written for DOS and enjoyed the benefit of physical security. That is to >say, access to the encryption program itself was carefully restricted. > >Where I feel I was unclear is on the key to the scheme's security. Any >encryption scheme can be cracked provided the cryptanalyst has enough of a >sample to work with, enough time, and/or enough processing power. My >encryption scheme relies on data bursts of time-sensitive packets. Each >machine running the program has its own time and packet signature. The >unique signatures make it impossible (nothing is impossible) to decrypt a >complete file without access to both the sender's and receiver's >signatures. Even then it would take an enormous amount of processing >power to crack (more than big business can justify, but not much for major >governments). The only way to obtain a computer's signature (which is >easily changed on a regular basis), is to have physical access to the >computer's encryption application and support files. > >With the help of a more experienced DOS programmer, an application was >built that provided adequate protection that would increase the time >required to extract a computer's signature (even if one knew exactly how >to do it), that it was impractical to attempt. > >I am now porting the application to the Mac with the intent to sell it to >a private contractor that is developing RISC-based computers for >specialized use in the government. I have been assured that a PPC native >application will run on the computers, and was encouraged to develop the >application. Mostly what I need to know is how long it would take a >super-human cracker to obtain a signature and how she would do it. If I >can increase the expected time to 96+ hours, I'm in business (I always >assume half of my best guess - 48 hours is the required specification). > >I am developing the code with the help of an excellent Mac programmer. >The problem is, that neither of us can crack it at all, although we know >that is theoretically possible. He lacks sufficient crypto understanding, >and I lack sufficient computer knowledge. Working together we make little >progress, and truthfully don't have enough time to develop and crack at >the same time. I will not be comfortable with the final product until >someone cracks it and I have a sound understanding of the weaknesses that >I have not considered. > >Finally, MacPGP is a GREAT program. I didn't mean to belittle any of the >PGP programs. PGP carries much more protection than necessary for it's >intended and practical uses. Granted, it could use a new interface, but >it is certainly functional and not lacking in features. Initially, I >considered releasing a public version of my application in response to the >need for a more Mac-like encryption program. There is no reason for the >average Mac user to switch from PGP to my program. It lacks (and will >always lack) the features of MacPGP, and although it is more secure than >PGP the user must accept some increased inconvenience to realize the bulk >of the added security. For most users, this is adding overkill to >overkill. > >I extend my apologies for posting this huge message off topic, but I felt >I had grossly misrepresented my request. I feared the influx of e-mail >tomorrow morning if I didn't clarify. I appreciate all those that >extended advice. I will follow up on much of it, and I thank those who >replied. > > >Brent A. Carey -- Paul Robichaux LJL Enterprises, Inc. paul(a)ljl.com Be a cryptography user. Ask me how.

1 0

Re: Re:phoneco vs X-phone
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

Don't forget opportunity costs. With the money it spent to put in the fiber optics, the phone company could have made some loans and gotten interest back. -Allen

1 0

Intel to rule the basic crypto engine market?
by Bruce M. 17 Dec '03

17 Dec '03

InfoWorld, August 19, 1996, p1 By Luc Hatlestad & Tom Quinlan ------------------------------ Looking to bring a standard infrastructure to hardware- and software-based encryption offerings, Intel Corp. has started developing a Common Data Security Architecture (CDSA) designed to integrate security software, operating systems, and third party applications. [...] ------------------------------ http://www.infoworld.com/cgi-bin/displayArchives.pl?960816.encryption.htm ________________________________ [ Bruce M. - Feist Systems, Inc. ] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "Official estimates show that more than 120 countries have or are developing [information warfare] capabilities." -GAO/AIMD-96-84 So, what is your excuse now?

2 1

[off-topic] Re: Verdict in "MTV" Case
by Daemon 17 Dec '03

17 Dec '03

At 10:15 AM 8/23/96 -0700, Timothy C. May wrote: As the youngest Cypherpunk in the world (or at least i am aware of) I think a little reply is in order from my self. > "Like, like the kids are, like, >goofin' off. Besides, MTV doesn't like play enough old stuff, like Zeppelin >and Floyd." Thats what those old records are for. (no offense) If they are sueing MTV why not other TV stations.... If I was going to sue someone for not doing my homework i would sue Jarkko Oikarinen, the creator of IRC. I just think that this is really pathetic.... but then again I am famous for my flame replys in the past. Why not make the school pay MTV for keeping kids away from there station while they are doing homework (hehehe) FYI i thought this reply out. Blake Wehlage ========================================== Blake Wehlage <jwilk(a)iglou.com> ±» RëVðLû¡ØÑ Bø+ ©ÖmP@ñ¥ «± Goto: http://members.iglou.com/jwilk

1 0

Some cypherpunks-relevant Risks articles
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

In regards to the first part (the 911 transcript), I was considering the idea (common in cyberpunk RPGs) of a privately-set-up ambulance and emergency room service, with monitors (possibly with action capabilities) on registered clients. You'd want the data flow from and to the monitors encrypted, of course. -Allen From: IN%"rre(a)weber.ucsd.edu" 20-AUG-1996 22:41:21.74 To: IN%"rre(a)weber.ucsd.edu" CC: Subj: Risks: Atlanta 911 transcript, SSN's, web plagiarism [If you've never seen the famous Olympic Park 911 transcript, it's worth reading closely. I'm embarrassed to say this, but it always reminds me of the time I couldn't get a taxi in Chicago because I could tell the dispatcher what intersection I was standing on but I could not see any of the street addresses anywhere around me, and her dispatch computer needed an address to dispatch a cab. Dispatch systems requiring addresses are one of those absolutely classic cases of system being driven by the database designer rather than by the people who know how the system will actually be used. Database designers are fine people, but they shouldn't be doing requirements analysis unless they're trained for it. Also in this issue of Risks is an interesting message from Robert Ellis Smith about managing social security numbers and other identifiers for privacy, and a funny/scary piece about web plagiarism.] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This message was forwarded through the Red Rock Eater News Service (RRE). Send any replies to the original author, listed in the From: field below. You are welcome to send the message along to others but please do not use the "redirect" command. For information on RRE, including instructions for (un)subscribing, send an empty message to rre-help(a)weber.ucsd.edu =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Date: Mon, 19 Aug 1996 18:11:10 -0700 (PDT) From: risks(a)csl.sri.com RISKS-LIST: Risks-Forum Digest Monday 19 August 1996 Volume 18 : Issue 35 ---------------------------------------------------------------------- Date: Fri, 16 Aug 96 10:45:34 PDT From: "Peter G. Neumann" <neumann(a)csl.sri.com> Subject: The Atlanta 911 transcript [The following transcript of the Olympic 911 bomb call and the ensuing conversation suggests that many of our nontechnological risks are not being adequately addressed. PGN] http://www.cnn.com/US/9608/09/olympics.bomb.911/911.transcript.wir/transcri… Excerpts from a transcript released Thursday by the Atlanta Police Department regarding the bomb threat telephoned to 911 on July 27. Times have been converted from military time to standard notation, and punctuation and spelling have been edited. Parenthetical notes are part of the police transcript except where labeled as an editor's note. The transcript refers to these police terms: Code 73, bomb threat; and Zone 5, a police precinct near Centennial Olympic Park. The transcript did not explain the Zone 5 dispatcher's references to Code 17 and Code 8, which apparently were unrelated to the bomb call. 12:58:28 a.m.: [Call to 911] 12:58:32 a.m.: Atlanta Police Department 911 Operator: "Atlanta 911." Caller: "There is a bomb in Centennial Park, you have 30 minutes." 12:58:45 a.m.: Caller hangs up. 1:01:20 a.m.: 911 operator calls APD Agency Command Center (all lines busy). .... 1:01:30 a.m.: 911 operator calls Zone 5 and notifies Zone 5 of Signal 73 and requests address of Centennial Park -- unable to get street address. Dispatcher: "Zone 5." 911 Operator: "You know the address to Centennial Olympic Park?" Dispatcher: "Girl, don't ask me to lie to you." 911 Operator: "I tried to call ACC but ain't nobody answering the phone ... but I just got this man called talking about there's a bomb set to go off in 30 minutes in Centennial Park." Dispatcher: "Oh Lord, child. One minute, one minute. I copy Code 17. OK, all DUI units are Code 8 and will not be able to assist on the freeway. Oh Lord, child. Uh, OK, wait a minute, Centennial Park, you put it in and it won't go in?" 911 Operator: "No, unless I'm spelling Centennial wrong. How are we spelling Centennial?" Dispatcher: "C-E-N-T-E-N-N-I -- how do you spell Centennial?" 911 Operator: "I'm spelling it right, it ain't taking." Dispatcher: "Yeah." 911 Operator: "Centennial Park is not going. Maybe if I take 'park' out, maybe that will take. Let me try that." Dispatcher: "Wait a minute, that's the regular Olympic Stadium right?" 911 Operator: "Olympic Stadium is like Zone 3, though. Centennial Park." Dispatcher: "That's the Centennial Park?" 911 Operator: "It's near the Coca Cola Plaza, I think." Dispatcher: "In 5?" 911 Operator: "Uh huh." Dispatcher: "Uh, hold on. Sonya, you don't know the address to the Centennial Park?" 2nd Dispatcher (in background): "Downtown." 911 Operator: "Male, about 30." Dispatcher: "1546, Code 17, 23." 911 Operator: "White." Dispatcher: "Uh, you know what? Ask one of the supervisors." 911 Operator: "No, Lord help me, you know they don't know." Dispatcher: "I know, but it gets it off you." 911 Operator: "Alrighty then, bye." Dispatcher: "Bye." 1:02:40 a.m.: 911 operator calls APD ACC for address (telephone line problem; operators cannot hear each other.) ... 1:02:50 a.m.: 911 operator calls APD ACC again and requests address for Centennial Park and is given the telephone number. ACC: "Atlanta Police, Agency Command Center." 911 Operator: "Hey, can you hear me now?" ACC: "Uh huh." 911 Operator: "OK, can you give me the address of the Centennial Park?" ACC: "I ain't got no address to Centennial Park, what y'all think I am?" 911 Operator: "Can you help me find the address to Centennial Park?" ACC: "I can give you the telephone number of Centennial Park." 911 Operator: "I need to get this bomb threat over there to y'all." ACC: "Well." 911 Operator: "But I need the address of Centennial Park. It's not taking, the system is not taking Centennial Park, that's not where it came from, but you know the system is not taking Centennial Park, that's where he said the bomb was." ACC: "No particular street or what?" 911 Operator: "He just said there's a bomb set to go off in 30 minutes in Centennial Park." ACC: "Ooh, it's going to be gone off by the time we find the address." 911 Operator: "Are you kiddin'? Give me that, give me that." ACC: "I mean I don't have an address, I just have phone numbers." 911 Operator: "Give me the phone number." ... 1:05:10 a.m.: 911 operator calls Centennial Park for street address and is placed on hold. Receives address at 1:07:10 a.m. Centennial Park: "Centennial Park, this is Operator Morgan." 911 Operator: "Hi, can you give me the address to Centennial Park?" Cen Park: "The address?" 911 Operator: "Uh huh." Cen Park: "Uh, hold on a second." 1:06:30 a.m.: 911 operator notifies Communications Supervisor, Sgt. Montgomery. 911 Operator: "Does anybody -- Sgt. Montgomery, do you know the address of Centennial Park? Do you know the address to Centennial Park. Well, I need to get the address of Centennial Park 'cause, I mean I don't mean to upset nobody, but we got a bomb threat over there." (Editor's note: The transcript does not further indicate whether this comment about a bomb threat was directed only to Sgt. Montgomery in the 911 center or to Centennial Park's Operator Morgan, who is shown to come back on the line just after the comment.) Cen Park: "Ma'am." 911 Operator: "Yes." Cen Park: "OK, it's 145 International Boulevard." 911 Operator: "145 International Boulevard." Cen Park: "Uh huh." 911 Operator: "OK." Cen Park: "All right, uh huh." 911 Operator: "Thank you. Bye bye." 1:08:35 a.m.: 911 operator sent call to dispatch. 1:11:10 a.m.: Dispatcher: "1591. Radio raising 1594." Unit 1594: "1594. You call?" 1:11:20 a.m.: Dispatcher: "1594, that's affirmative, got a Signal 73 at 145 International Boulevard. It came from the pay phone at the Days Inn. The caller is advising that he has one set to go off in 30 minutes at Centennial Park. Sounded like a white male." (Editor's note: The same information is then given to Unit 1593 and the dispatcher calls Unit1546.) 1:12:30 a.m.: Dispatcher: "Did you copy?" 1:12:40 a.m.: Unit 1546: "1546. I copy. Advise the state police, they police that park. I'll go the Days Inn and see if I can locate the caller." Dispatcher: "OK, that's affirmative." (Editor's note: There are sporadic entries over the next seven minutes. Another officer, designated Unit 1593, also instructs the dispatcher at 1:18:50 a.m. to "contact the state police supervisor." The transcript contains no indication, however, that state police were notified.) 1:20:00 a.m.: Unit 2924: "2924 to Radio, be advised that something just blew up at Olympic Park." ------------------------------ Date: Fri, 16 Aug 96 15:24 EST From: Robert Ellis Smith <0005101719(a)mcimail.com> Subject: Alternatives to Social Security Numbers Last spring, I asked readers of RISKS for suggestions on alternatives to Social Security numbers in organizations with large data bases of information about individuals. Many such organizations find they do not need to use SSNs, and avoid privacy problems associated with using them. For a copy of all of the responses, send a request to us and specify whether you want hard copy or electronic edition of our August issue, and provide postal address or e-mail address. Robert Ellis Smith, Publisher, Privacy Journal newsletter, Providence, RI, 401/274-7861, e-mail 5101719(a)mcimail.com. Excerpts from the suggestions follow: * FROM WASHINGTON, D.C.: Maryland uses Soundex (of name and birth date concatenated [linked in a chain]) both for driver and vehicle registrations. * FROM CAMBRIDGE, MASS.: "Against Universal Health-Care Identifiers" in the JOURNAL OF THE AMERICAN MEDICAL INFORMATICS ASSOCIATION 1:316-319, 1994, by Dr. Peter Szolovits of MIT and Dr. Isaac Kohane of Children's Hospital in Boston, discusses a number of ways in which cryptography- based health care identifiers can be used to preserve privacy while remaining manageable for typical medical purposes. This is publication #49 (in Postscript format) at http://medg.lcs.mit.edu/people/psz/publications.html. * FROM YARDLEY, PA.: One way is to use a simple scheme like three letters from last name, the first initial, and some digits; another is just to use sequential numbers. Another is an MD5 hash of the full-name string [a one-way mathematical function as a stand-in for the name that makes translation back to the original name impossible]. This is always unique for a unique string, so you might need to add some numbers. * FROM MADISON, WISC.: When I was working on the development of the Wisconsin Student Data Handbook - we tried to develop what we called an "SSN surrogate," also of nine bytes per individual. It involved an algorithm which combined year, month, and date of birth with sex and two consonants each extracted from the first and middle names. * FROM CYBERSPACE: I worked with a banking software company that set up employee records simply by exact hire date and time. Since they never hired anyone at exactly the same time, it gave each person a unique number. You could do the same for any data base in which records are added gradually one at a time - just number them based on exact date and time added. * FROM PALO ALTO, CAL.: At Stanford University we made a decision long ago not to use SSN for identification except where required by law (payroll taxes, for example). We use a unique Stanford University ID (SUID), which is a lifetime number and applies to all students, alumni, faculty, staff, and patients. It serves all the same purposes that the SSN would do if it were used. ------------------------------ Date: Wed, 14 Aug 1996 00:03:42 +0200 From: "Roy Dictus, NET" <roy(a)net.be> Subject: The risk of plagiarism with Websites My company recently got ripped off by a competitor. We build Websites and thus had constructed a site detailing our products and services. A rival Website constructor (!) copied practically the entire site, changing the background color, changing our name into theirs, and making other slight changes like alignment, add and delete a word or phrase here and there... I complained about it, not only to them directly, but also on a local USENET newsgroup (we're both located in Belgium, so the newsgroup was be.providers). On the phone they just laughed at me and admitted to copying, but on USENET they claimed I had copied their site! There's nothing I can do to prove them wrong, even though we both know what happened. The risk: if you put your materials on the Internet, where they can be freely copied, make sure you have some way to prove you made them yourself, and when you did it. Roy Dictus, NET bvba, Internet Projects & Consulting roy(a)net.be http://www.net.be [Interdictus becomes Enter Dictus. PGN] ------------------------------ End of RISKS-FORUM Digest 18.35 ************************

1 0

Re: CyberTerrorism
by jya＠pipeline.com 17 Dec '03

17 Dec '03

On Aug 23, 1996 18:34:42, '"Institute for Security and Intelligence" <isi(a)hooked.net>' wrote: >John: > >Your message regarding my comments on CyberTerrorism was forwarded to me. >Rather than waxing poetic beration, how about some actually useful >perspective? > >If you have experience in this area, let's talk. If you have something to >contribute, let's get it out where it can be useful. > >It's time to put up, or shut up John. > >Regards, >Barry C. Collin --------- Dear Mr. Collin, Thank you for writing. And for the cyber-terrorism hoot, which helps purge ignorant fears with insightful laughter. The best way I know for citizens to ease their induced- panic of terrorism in all forms -- gov, com, edu, org -- is to become more informed. And to be wary of "terrorist threats" in all their burgeoning guises -- "national security" being one of the most deceitful. To counter Nat Sec snake oil in the rising commerce in "cyber-terrorism" (a residue of the natsec oil tank) citizens should participate in the wit and wisdom of wide-open Internet mail-lists dealing with computer privacy and security. The best of these is the list Cypherpunks. (E-mail "info" to majordomo(a)toad.com.) Cypherpunks, far more tolerant and less treacherously commercially self-serving than all others, explores an amazing range of CompSec issues, technologies, policies, strategies and fantasies. Its archive of several years offers a historical treasure on the transformation of state control of comp tech to its service of the citizenry. This is exemplified by Cypherpunks primary focus, cryptography, and the diverse ways it has moved from narrow use to conceal privileged power to widespread application to protect individual privacy (especially those dissenting to heirarchical authority -- gov, com, edu, org). Your agent provocateurist comedy on cyber-terrorist inebriation could be enriched by hanging on Cypherpunks, say, your buffoonery for secret briefing. "If you knew what I knew" is a natsec-butt joke there, as it is becoming globally to liberated citizen-units bellowing "FA." Congrats on exposing TLA-dementia of cyber-terrorism and defanging its counter-agents by encouraging belly- laughing at the all-too-blatant hype-artistry. Only Jim Kallstrom does it better. Best regards, jya

1 0

SecureDrive News 8/24/96
by Edgar Swank 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- SecureDrive Users: It's been brought to my attention that users who attempt to compile SecureDrive 1.4b using Turbo C++ 3.00 are haveing a problem in that the MD5 routine does not produce a correct result, so that the key generated from a given passphrase will not be the same as the pre-compiled version. This is a bug in Turbo C++, not SecureDrive! However, a bypass for the problem is possible by modifying SD source as follows - ------------------------------cut here----------------------- *** C:\SECDR14B\UNC\MD5.C Sun May 09 19:38:36 1993 - --- MD5.C Wed Aug 14 00:58:46 1996 *************** *** 12,17 **** - --- 12,20 ---- * of the MD5 routines in RSAREF. Due to this alteration, this * code is "derived from the RSA Data Security, Inc. MD5 Message- * Digest Algorithm". (See below.) + * + * Simplified some expressions to avoid incorrect compiles with + * some compilers, e.g. Turbo C 3.0 EWS 8/96 */ /* *************** *** 135,145 **** - --- 138,158 ---- /* transform if necessary */ if (mdi == 0x40) { + #if defined (__TURBOC__) for (i = 0, ii = 0; i < 16; i++, ii += 4) + { + in[i] = (((UINT4)mdContext->in[ii+3]) << 24); + in[i] |= (((UINT4)mdContext->in[ii+2]) << 16); + in[i] |= (((UINT4)mdContext->in[ii+1]) << 8); + in[i] |= ((UINT4)mdContext->in[ii]); + } + #else + for (i = 0, ii = 0; i < 16; i++, ii += 4) in[i] = (((UINT4)mdContext->in[ii+3]) << 24) | (((UINT4)mdContext->in[ii+2]) << 16) | (((UINT4)mdContext->in[ii+1]) << 8) | ((UINT4)mdContext->in[ii]); + #endif Transform (mdContext->buf, in); mdi = 0; } *************** *** 167,178 **** padLen = (mdi < 56) ? (56 - mdi) : (120 - mdi); MD5Update (mdContext, PADDING, padLen); ! /* append length in bits and transform */ for (i = 0, ii = 0; i < 14; i++, ii += 4) in[i] = (((UINT4)mdContext->in[ii+3]) << 24) | (((UINT4)mdContext->in[ii+2]) << 16) | (((UINT4)mdContext->in[ii+1]) << 8) | ((UINT4)mdContext->in[ii]); Transform (mdContext->buf, in); /* store buffer in digest */ - --- 180,201 ---- padLen = (mdi < 56) ? (56 - mdi) : (120 - mdi); MD5Update (mdContext, PADDING, padLen); ! /* append length in bits and transform 1.4c*/ ! #if defined (__TURBOC__) ! for (i = 0, ii = 0; i < 14; i++, ii += 4) ! { ! in[i] = (((UINT4)mdContext->in[ii+3]) << 24); ! in[i] |= (((UINT4)mdContext->in[ii+2]) << 16); ! in[i] |= (((UINT4)mdContext->in[ii+1]) << 8); ! in[i] |= ((UINT4)mdContext->in[ii]); ! } ! #else for (i = 0, ii = 0; i < 14; i++, ii += 4) in[i] = (((UINT4)mdContext->in[ii+3]) << 24) | (((UINT4)mdContext->in[ii+2]) << 16) | (((UINT4)mdContext->in[ii+1]) << 8) | ((UINT4)mdContext->in[ii]); + #endif Transform (mdContext->buf, in); /* store buffer in digest */ - ------------------------------cut here----------------------- This code will be inserted into any future version of SecureDrive, but no new release is planned at this time. For those users of Win95 and SecureDrive who are concerned about loss of 32-bit disk access, I've recently learned that use of Secure Device ftp.demon.co.uk:/pub/ibmpc/secdev/secdev14.arj instead avoids this requirement. Although the Secure Device virtual drive is listed as in compatibility mode, the real drives are not so affected. And since the virtual drive is mapped to a dos file on one of the real drives, I believe you get 32-bit phyical drive access there as well, although access is still slowed by CPU time necessary to encrypt and decrypt. Edgar W. Swank <edgar(a)Garg.Campbell.CA.US> Edgar W. Swank <EdgarSwank(a)Juno.com> Edgar W. Swank <Edgar_W._Swank(a)ilanet.org> Home Page: http://members.tripod.com/~EdgarS/index.html -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCUAwUBMh7d4t4nNf3ah8DHAQHNdAP3RKd07B55fkW5CazT8mMaGUoTtjxSvUBv 3ykPvBhHvu7egb4EB1/XcBTM3K/6QeE8Dt10XJVX15Fd9nHY+XI0c0VB8Trlb/NB 0ymq+/SchedtUNmCgDeycbF104bfirpuXKy0OChDfpgMe0d/ifCXny6Co0BqIbRi fQyKtXzOxQ== =h1RT -----END PGP SIGNATURE----- -- edgar(a)Garg.Campbell.CA.US (Edgar Swank) The Land of Garg BBS -- +1 408 378-5108

1 0