December 2003 - cypherpunks-legacy

FW: Physical storage of key is the weakest link
by Claborne, Chris at SanDiegoCA 17 Dec '03

17 Dec '03

<< some suggestion to keep keys secure on floppy>> <<Lance Cottrel writes: If your passphrase is good (128+ bits of entropy), then your private key is as secure as the messages that you send. Although it need be broken only once, I see no real danger of IDEA being compromised in the near future. Given a good passphrase, I would suggest that you want multiple copies of your key to prevent loss or accidental destruction. My passphrase is > 30 characters. Fortunately Mac PGP remembers the key during any given session so typing is kept down a bit. >> If you are really paranoid, keeping your private keys super secure is a good idea. If a bad guy were come and steal them all she needs to do find out your passphrase (using all kinds of attacks.... camera over your desk....) and bingo, they can read all past and future message traffic to you... ... __o .. -\<, chris.claborne(a)sandiegoca.ncr.com ...(*)/(*). CI$: 76340.2422 PGP Pub Key fingerprint = A8 FA 55 92 23 20 72 69 52 AB 64 CC C7 D9 4F CA Avail on Pub Key server.

1 0

FW: Kevin Mitnik
by Claborne, Chris at SanDiegoCA 17 Dec '03

17 Dec '03

<< >From Edupage: ******************* FBI HUNT FOR HACKER Kevin Mitnick is wanted by the FBI for suspicion of software and data theft from leading telecom manufacturers and service providers. Among his victims have been MCI and Digital Equipment. An ex-convict, Mitnick was described by one judge as having an "addiction problem" with computers, similar to a drug or gambling addiction. During a six-month treatment program he was prohibited from touching a computer or a modem, but the treatment seems to have failed, and one detective says: "I've always considered him dangerous. I had to go underground. If he targets you, he can make your life miserable." (New York Times 7/4/94 A1) ************************** >> I also read an article in the Pheonix paper saying that he did a wire tap on the FBI guys that were trying to find him... among other things. QUESTION: How do they know it was him? I get tired of the News dudes printing stuff as if it were fact. ... __o .. -\<, chris.claborne(a)sandiegoca.ncr.com ...(*)/(*). CI$: 76340.2422 PGP Pub Key fingerprint = A8 FA 55 92 23 20 72 69 52 AB 64 CC C7 D9 4F CA Avail on Pub Key server.

1 0

Bit counting
by Ian Farquhar 17 Dec '03

17 Dec '03

>Why bother when you can simply do an eight line function? >int bitcount(char b) >{ >register int retval=0; > if (a & 1) retval++; > if (a & 2) retval++; > if (a & 4) retval++; > if (a & 8) retval++; > if (a & 16) retval++; > if (a & 32) retval++; > if (a & 64) retval++; > if (a & 128) retval++; >return retval; >} [...] Because on a lot of architectures this implementation may be hideously inefficient. All the world is not an Intel chip, thank god. Ian.

3 2

More Mitnik
by kentborg＠world.std.com 17 Dec '03

17 Dec '03

chris.claborne(a)sandiegoca.ncr.com wrote: > I also read an article in the Pheonix paper saying that he did a wire tap >on the FBI guys that were trying to find him... among other things. YES, whether it is true or not that is exactly the sort of stuff we need to get Joe Lunchbox saying "YES!"--and getting Joe Lunchbox on our side* is more important that you know. (Who do you think held down the tax on the beer I am drinking right now? That's right, it was Joe, and I admire that.) We need to watch our image, and Mitnik (if he is smart) is a great way to distact from the pedophile scare. How can people get indignant when they are too busy laughing? The idea of one social misfit wire tapping the FBI (and they want to put wiretaps in the *design*?) is so entertaining--and understandable by Joe Lunchbox--that I can't stand it. -kb * Our side: strong crypto without backdoors for either Mitnik or Freeh is good. Agree? -- Kent Borg +1 (617) 776-6899 kentborg(a)world.std.com kentborg(a)aol.com Proud to claim 31:15 hours of TV viewing so far in 1994!

1 0

Tim May and Security for The Millions
by kentborg＠world.std.com 17 Dec '03

17 Dec '03

Tim (yes, it was me--Kent Borg--you quoted the most recent time you said--roughly--that other people's security is no very important to you), there is a very good reason why you want *everyone* to have good security. The fact that "everyone" will use up the snooping resources of the TLAs, leaving less for them to throw at you, is not the main point, for the TLAs might come up with clever secret approaches which allow their resources do amazingly efficient things. What you really want to know is what the state of the art is inside the NSA, what efficient things they can do. (You want to know the *whole* story behind the S-boxes, what Skipjack is, etc.) The best way to do this is to badly, I mean *BADLY*, tempt them to tip their hand. If pedophiles (the canonical/mythical threat) are the threat they see then put the best security we (on the outside) have in the hands of the world's pedophiles and watch the prosecutions. Either the TLAs tip their hands by cracking the 1998 version of PGP 5.0.2 with IDEA^3 or they don't. If they do, you know they cracked it. If they don't you know one of two things: 1) They didn't crack it. 2) They did crack it *but* are too afraid to say they cracked it--which is nearly equal to not having cracked it. (Preventing them from acting on information is close to denying them the same information--the Coventry Legend and all.) A wonderful way for us to drive cryptological research out into the light is to *temp* them into showing their hands, and giving good security to *everybody* is the best way to do that. Following this argument, preventing trivial "quick brown fox"-attacks is part of the job of giving good security to everyone, make them work at the interesting problems. Conclusion: my recent "passwords are hard" tirade is not completely off-subject. More general conclusion: user interface issues ("My Mom" et al) are very important. Certainly, working on the gaping hole of Tempest attacts is very important (any ideas?), but don't forget that RF-snooping of moving notebooks requires risky ~field work~ and bad take-out food, something properly high-tech TLAs hate. Tempest attacks are only worthwhile against juicy targets, while some other attacks are useful in bulk. (For examples of how poor passwords are useful in bulk, read RISKS, use your imagination, and extrapolate to large populations.) Tim, the best way for you to have good security is to put good security in the hands of the millions. -kb, the Kent who can sometimes get personal and use first names -- Kent Borg +1 (617) 776-6899 kentborg(a)world.std.com kentborg(a)aol.com Proud to claim 31:15 hours of TV viewing so far in 1994!

1 0

Schneier Claims on Multiple Encryption
by kentborg＠world.std.com 17 Dec '03

17 Dec '03

In Applied Cryptography (at 8.2.5) Bruce Schneier says: "What about encrypting a block once with algorithm A and key K-a, and then again with algorythm B and key K-b? Aside from being susceptable to ... meet-in-the-middle attacks, there is no guarantee that the two algorythms will work together to increase security. There may be subtle interactions between the two algorithms which actually *decrease* security." Wait. If applying a different algorithm with an unrelated key might decrease security, then the TLAs could themselves apply another algorithm with their own unrelated key as an analysis technique, no? Kent's Hypothosis: Superencrypting different algorithms with unrelated keys can never weaken non-trivial algorithms. Stacking DES on top of IDEA on top of Ceasar can be no worse than the strongest of the the set--assuming the keys are unrelated and the attempted security is not through obscurity and the algorithms are not so confused as to be each other's analysis. -kb -- Kent Borg +1 (617) 776-6899 kentborg(a)world.std.com kentborg(a)aol.com Proud to claim 31:15 hours of TV viewing so far in 1994!

2 1

RE: Kevin Mitnik
by Random H0Z3R 17 Dec '03

17 Dec '03

Kent Borg wrote: > I am under the impression that I would not like Mitnik personally, but I > have never personaly met him... > Would I turn him in? Well, put it this way: I would not harbor him but > neither would I work very hard to figure out where he is or whether a > particular "nobody" on this list be him. Somehow, I get the idea that the "nobody" you're referring to is yours truly. Well, I'm not him, but your suspicion does bring up a valuable point, though: if you're suspicious that a certain "chained remailer user" is the infamous Mr. Mitnik, then certain TLAs might also share that suspicion. Therefore, anyone using such "underground" services as anonymous remailers should use exceeding care. If they start to use traffic analysis, or any of the other "sigint" techniques discussed here, even though you aren't Mr. Mitnik, you may well get "caught" in their "dragnet".

1 0

Re: Counting bits
by Ian Farquhar 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Just for entertainment value, I clipped your function and compiled it >with Turbo C++ 1.01 in default (ANSI C) mode. Here's the .asm code >produced (comments and setup code edited for brevity) Both Sun C and GCC on a Sun SPARC system running 4.1.3 produced this code for each bit-count line (-O4 optimization used): L77042: andcc %o0,2,%g0 ; AND the bit bne,a L77044 ; branch/anull if zero inc %o5 ; increment bitcount L77044: This, I believe, is as optimized as it is possible to get on a uniprocessor machine. On both compilers, the routine size was 28 instructions total, and that would also be the maximum path length for the execution of this routine when passed an ASCII 255 value. A MIPS-based DECserver running Ultrix 7.1 produced this (again, -O4): $34: lb $11, 0($sp) ; Load the byte off the stack and $12, $11, 16 ; AND the bit beq $12, 0, $35 ; branch/anull if zero addu $3, $3, 1 ; increment bitcount $35: Total instruction count was 28. This is non-optimal, as there is no need to reload off the top of the stack on every line, and if so modified it would be equivalently efficient to the SPARC implementation. On a Cray Y-MP/EL running UNICOS 7.0.6 (-O3, which is equivalent to - -hinline3,scalar3,task3,vector3): L5 = P.* S7 2 ; Move 2 into S7 S0 S2&S7 ; S0 = S2 AND S7 JSZ L6 ; Jump to L6 if the bit was zero S7 1 ; Move 1 into S7 S1 S1+S7 ; Up the bitcount in S1 L6 = P.* ; 9 Note that the Cray C compiler (or indeed any C compiler I know of) is not yet capable of recognising the option of using the population count instruction here, because it is nearly impossible to determine what this particular routine is doing. Even so, the total instruction count is 80, which is somewhat excessive. The "Move 1 into S7" could probably be eliminated by using another scalar register, and I suspect (but don't have the manual here so I cannot confirm) that they'd be better not to reload the mask every line, but instead to load it once and shift. Additionally, you could probably vectorise this, but I doubt it would buy you much. Anyway, that's an analysis of three high end architectures on this code fragment. Personally I feel that a lookup table would be a MUCH more efficient implementation for most systems which lack population count, even for words up to 20 bits or so in size (depending on your storage requirements and latency at accessing main memory, of course). Enjoy. One of these days I will get back to my project of implementing crypto primatives in CAL, but I do not have the time right now. BTW, folks, playing around with this is fun. I still believe that either the SKIPJACK interim reports Cray-implementation timing figures were wrong, or the conditions under which the program was compiled was incorrect (most likely), or that SKIPJACK contains no s-boxes. Take your pick. Ian. -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLhukvdCZASdT8NoBAQHe/wQAzW/zmoiiAz9vswLO5kQcs6TSoAhIK7SM 1hTrvbXTbNwrnK2FyhC4nZaUPIjnZufOeCoQPs1DJNsCZ1q6Gx1nlVj/hTyBUxYr THQ9ZLOUFruSDa18enx4J1iSrliBeoGcV0CuGRxClNoFrDkYedzRS0nN+m/rq35W Vcsk0HFxq0g= =Wpri -----END PGP SIGNATURE-----

2 1

Need help in Russia...............
by Robert M. Humphrey 17 Dec '03

17 Dec '03

This is the first time I've been in this system, so I guess I just jump in. I am an American Communications Engineer doing business in Russia. You think you have problems with privacy! Anyhow, after having to eat the contents of a few of my messages as served by the local Russian Administration (who aren't on my mailing list!), I decided to try for a little privacy. No joy in Mudville!! A friend in the US suggested that I try PGP. Then I find out that I can't have someone send me a copy. Then I find out that I can download something from CompuServe. Right! Have you ever tried data on a Russian Telephone line? I was abl to get about 20KB before Ma BellSkov decided to cut me off. Lots of times. I have access to InterNet e-mail through some system in Moscow (about 5000 miles from here) and I do have access to UUENCODE and DECODE plus the usual PkWare stuff. Anyone with any ideas how I can get going on PGP or something else under the circumstances would be more than welcome. By the way, a simple system probably won't do much good. When the climate changed in Russia, a lot of very capable KGB people ended up with no jobs. Since they had the skills needed, they either entered the Russian Mafia, went into Industrial Espionage or (just to show how desparate they were and how little self respect that had left) became lawyers! It's the second group that I have to deal with. If it's not well encrypted, you can buy any information that exists over here. If anyone has any ideas on how I can get going in this direction, let me know at: Robert(a)rmh.khabarovsk.su BTW...Khabarovsk is a city of about 700,000 located 20km from the Manchurian border with china in Far Far Eastern Russia (less than 500 miles from the Pacific coast. I do mostly Satellite communications and many types of radio communications. Thanks Bob

1 0

Re: (fwd) Cryptologist needed
by bart＠netcom.com 17 Dec '03

17 Dec '03

I guess when I first forwarded this to the list, the header was not included. What follows is the entire posting from the ba.jobs.contract Usenet group which includes the name of the person who posted it. dberg(a)netcom.com is the person to answer all questions about the job.

1 0

Re: Detwiler's Crypto Mailing List
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

: From: Peterwheat(a)aol.com : I found this by doing a keyword search (cryptography) in America Online's : database of mailing lists. I thought it might be of interest to the : cypherpunks mailing list: Oh God :-( Either Detweiler has got himself an AOL account or all AOL people are as clueless as they're reputed to be... He follows it with this... > From: Anonymous <remailer-admin(a)chaos.bsu.edu> > Can anyone tell me if one can use PGP 2.6 with an online service [America > Online]. From what the FAQ says, I need an actual UNIX account rather than > just an E-Mail Gateway. Is this true? > If not, then how do I encrypt without attaching the pgp file [which goes only > to other AOL users] or without using BinHex and inserting THAT into my > message body? Not all of my peers use AOl or possess BinHex. Hmmm... I think theory #1 is the more likely one. Is it time to shout 'He's baaaaack!' yet? - I'll know soon enough if I log on to cypherpunks and find 50 articles all following up posts from AOL... G

1 0

Re: entropy of data....?
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

: Hasn't someone come up with a name for this like "Entropy of the data is 30 : days" or... "the half-life of the data is 15 days". This is a critical : value when looking at it from a military point of view. If you can't decode : enemy plan for attack before a certain date/time then the info is : useless.... That betrays a bit of ignorance about the meaning of 'half-life'. I think the word you're looking for is 'lifetime'. G

1 0

Re: Counting bits
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

Why bother when you can simply do an eight line function? int bitcount(char b) { register int retval=0; if (a & 1) retval++; if (a & 2) retval++; if (a & 4) retval++; if (a & 8) retval++; if (a & 16) retval++; if (a & 32) retval++; if (a & 64) retval++; if (a & 128) retval++; return retval; } There's a man who has never had to code a critical inner-loop. When you're exhaustively testing keyspaces, or getting hard crypto to run at lan speeds, sometimes every cycle is critical. If the function above is in the main inner loop (say 80% of the CPU time as gleaned from a profile utility), the optimisations people suggested will speed your program up by a factor of 10. This is the one time that bit-twiddling optimisations are worthwhile. (Mostly they're irrelevant and just posturing by smart-ass kiddies...) G

1 0

Re: Counting bits
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

: Both Sun C and GCC on a Sun SPARC system running 4.1.3 produced this code : for each bit-count line (-O4 optimization used): : L77042: : andcc %o0,2,%g0: : ; AND the bit : bne,a L77044: : : ; branch/anull if zero : inc %o5: : : ; increment bitcount : L77044: : This, I believe, is as optimized as it is possible to get on a uniprocessor : machine. Using branches is seriously bad news on some machines, especially risk machines which are using a prefetched instruction pipeline. Then of course you get machines with an on-chip cache, in which case the looping variant becomes the best choice again. And you have to figure architectures where every instruction is conditional on the CC so you can have branches over (some) short instruction sequences for free. Serious optimization isn't a child's game. When we did the 1's-counting code for the Acorn RISC machine, every programmer in the office worked on it for a week. I think the best version in the end was a variation of the trick shown earlier and some sneaky use of ARM conditionals and address-loading instructions that could do arbitrary shifts on the fly while adding. I wish I'd kept it. If anyone bumps into Paul Bond, I think he was the guy who wrote the best one. I'd like to see that one again for nostalgia's sake :-) G

2 1

PGP Keys on a Floppy
by Duncan Frissell 17 Dec '03

17 Dec '03

C.><< some suggestion to keep keys secure on floppy>> DOS users can always encrypt their keyfile on a floppy encrypted with SecureDrive. <G> DCF

2 1

Unknown
by Random H0Z3R 17 Dec '03

17 Dec '03

============================================================================ SUBJECT: METHOD FOR UPDATING ENCRYPTION KEY INFORMATION IN COMMUNICATION UNITS SOURCE: MicroPatent via Fulfillment by INDIVIDUAL, Inc. DATE: July 6, 1994 INDEX: [2] ORDER NO: 402693# ---------------------------------------------------------------------------- MicroPatent via INDIVIDUAL, Inc. : Abstract: Within a communication system, an encryption controller receives unit identification information from a plurality of encrypting/decrypting communication units. For any individual communication unit, the encryption controller uses the unit identification associated with that transmitting communication unit to determine if it contains updated encryption key information. If the transmitting communication unit is not currently updated, a group call is used to send the current encryption key information to all communication units within the transmitting communication unit's group, thereby updating all active, non-current communication units. After a first predetermined period of time has elapsed, this process is allowed to repeat. Ex Claim Text: In a communication system that includes a plurality of communication units, an encryption controller, wherein the plurality of communication units includes a first set of communication units that are currently active and a second set of communication units that are currently inactive and wherein communication units of the plurality of communication units readily change from the first set of communication units to the second set of communication units and vice versa, a method for updating encryption key information to the plurality of communication units, the method comprises the steps of: a) transmitting, by a first communication unit in the first set of communication units, unit identification information to the encryption controller; b) when the unit identification information is received, determining, by the encryption controller, that the first communication unit does not have updated encryption key information; c) transmitting, by the encryption controller, updated encryption key information to the plurality of communication units, wherein only the first set of communication units are updated with the updated encryption key information; d) initiating, by the encryption controller, a predetermined wait period; e) changing, by a second communication unit, from the second set of communication units to the first set of communication units; f) after expiration of the predetermined wait period, receiving, by the encryption controller, unit identification information from the second communication unit; and g) when the unit identification information from the second communication unit is received, retransmitting, by the encryption controller, the updated key information to the plurality of communication units, wherein communication units that have changed from the second set of communication units to the first set of communication units are updated with the updated encryption key information. Patent Number: 5325432 Issue Date: 1994 06 28 Assignee: Motorola, Inc. Inventor(s): Gardeck, KevinCutts, Kevin M. If you require additional information on this patent, please call PatentQuery at 800-984-9800. [07-06-94 at 18:24 EDT, Copyright 1994, MicroPatent, File: m0701215.4pa]

2 1

WHITE HOUSE TO RETHINK CLIPPER
by Random H0Z3R 17 Dec '03

17 Dec '03

============================================================================ SUBJECT: PRESSURE GROWING ON WHITE HOUSE TO RETHINK CLIPPER CHIP POLICY SOURCE: Inside Washington via Fulfillment by INDIVIDUAL, Inc. DATE: June 30, 1994 INDEX: [5] ---------------------------------------------------------------------------- WASHINGTON TELECOM WEEK via INDIVIDUAL, Inc. : The White House came under increased pressure this week to withdraw its controversial Clipper Chip encryption proposal when the policy arm of a major computing society attacked the plan. The U.S. Public Policy Committee of the Association for Computing Machinery (USACM) said in a position paper that "communications security is too important to be left to secret processes and classified algorithms." USACM said that Clipper would put U.S. manufacturers at a competitive disadvantage in the global market and would adversely affect technological development within the United States. A statement by USACM pointed out that the Clipper technology has been championed by the Federal Bureau of Investigations and the National Security Agency. These agencies maintain that "non-escrowed" encryption technology threatens law enforcement and national security. "As a body concerned with the development of government technology policy, USACM is troubled by the process that gave rise to the Clipper initiative," said Barbara Simons, a computer scientist with IBM, in a statement. Simons, who chairs the ACM committee, added that it is "vitally important that privacy protection for communications networks be developed openly and with full public participation. The Clipper Chip, also known as the Escrowed Encryption Standard, raises fundamental policy issues, according to the analysis. After reviewing a new study by the ACM, the USACM makes the following recommendations: - The Administration should withdraw the Clipper Chip proposal and begin an open and public review of encryption policy. The escrowed encryption initiative raises vital issues of privacy, law enforcement, competitiveness and scientific innovation that must be openly discussed. - The Administration should encourage the development of technologies and institutional practices that will provide real privacy for future users of the National Information Infrastructure. - Public policies and technical standards should be developed for communications security in open forums in which all stakeholders -- government, industry and the public -- participate. Because the nation is moving rapidly to open networks, a prerequisite for the success of those networks must be standards for which there is widespread consensus, including international acceptance. "The USACM believes that communications security is too important to be left to secret processes and classified algorithms. We support the principles underlying the Computer Security Act of 1987, in which Congress expressed its preference for the development of open and unclassified security standards." - Any encryption standard adopted by the U.S. government should not place U.S. manufacturers at a disadvantage in the global market or adversely affect technological development within the Untied States. Few other nations are likely to adopt a standard that includes a classified algorithm and keys escrowed with the U.S. government. - Change the process of developing Federal Information Processing Standards (FIPS) employed by the National Institute of Standards & Technology. This process is currently predicated on the use of such standards solely to support federal procurement. Increasingly, the standards set through the FIPS process directly affect non-federal organizations and the public at large. The USACM said that the vast majority of comments solicited by the National Institute for Standards and Technology opposed the standard but were openly ignored. The standard therefore should be placed under the Administrative Procedures Act so that citizens may have the same opportunity to challenge government actions in the area of information processing as they do in other important aspects of federal agency policymaking. -- Joe Burey [06-30-94 at 17:05 EDT, Copyright 1994, Inside Washington, File: w0630041.6ip]

1 0

Unknown
by Random H0Z3R 17 Dec '03

17 Dec '03

============================================================================ SUBJECT: HOUSE PANEL BACKS DIGITIZATION, JOINT TELECOM NETWORK SOURCE: Phillips Publishing via Fulfillment by INDIVIDUAL, Inc. DATE: July 5, 1994 INDEX: [3] ---------------------------------------------------------------------------- C4I NEWS via INDIVIDUAL, Inc. -- In a boost to two nascent C3 programs, House appropriators are supporting the Pentagon's plans to merge defense and civilian telecommunications traffic and the Army's digitization effort. The House Appropriations Committee, in a report on its FY '95 Defense Appropriations Bill, calls DoD's plans to merge its information pipeline, the Defense Information Systems Network (DISN), with the follow-on to the federal telephone network, FTS 2000, "refreshing." But the panel does caution that DISN and the Defense Messaging System, an E-mail application that will run on the network, "must be carefully managed and security measures strongly endorsed." The panel also voices its support for the Army's digitization efforts, particularly the service's plans to "maximize the use of non-developmental and commercial off-the- shelf equipment." In good news for the firms lining up to bid on pieces the digitization work--including Science Applications International Corp., General Dynamics, ITT and Loral--the appropriators boost the Army's FY '95 request of $75.86 million to $115.86 million. Both the House and Senate Armed Services Committees also increased the digitization request: the House by $50 million; the Senate, by $3 million. But the panel agrees with the concerns HASC expresses in its report on the FY '95 Defense Authorization Bill, saying that the Army has not defined "the overall system architecture and digital interfaces, standards and protocols." Other areas of concern include "insufficient emphasis on digital integration with" aviation or Marine Corps' assets. The panel directs the Army to provide a report to the congressional appropriations committees by March 1, 1995, identifying a master plan for developing, testing and producing digitization hardware and software, including an architecture for interfacing with C3I systems. The appropriators also look favorably on the new Alert, Locate and Report Missiles (ALARM) effort, boosting the $150 million request to $330 million. The additional funds must be used to accelerate launch of the first ALARM bird, now slated for FY '04. In addition, due to the "national importance of the program" the panel directs the secretary of defense to: ensure the program is fully funded in the out-years; complete the engineering and manufacturing development downselect by March 31, 1996; and work toward first launch not later than 2000. ...Panel Hits SBIS, CHS Cutting the Army's operation and maintenance request for the Sustaining Base Information System (SBIS) by $24 million, the panel expresses concerns about "disturbing trends" in the program, for which Loral is the prime contractor. Such concerns include an increase in the number of lines of software code and the fact that the hardware has yet to pass a systems acceptance test. SBIS is the Army's base system modernization plan. The committee also criticizes the Army for planning to field hardware under the Common Hardware/Software II contract "prior to completion of all pre-production testing and engineering." Because the CHS-I contract will expire prior to the completion of all CHS-II qualification tests, "a serious break in production will occur." To minimize fielding interruptions, the panel directs the Army to examine the possibility of extending the CHS-I contract. Such an extension would be a boost to the contractor, Miltope Corp. [07-05-94 at 18:00 EDT, Copyright 1994, Phillips Publishing, Inc., File: d0705024.4sd]

1 0

INTERNET SECURITY VENTURE LAUNCHED
by Random H0Z3R 17 Dec '03

17 Dec '03

============================================================================ SUBJECT: INTERNET SECURITY VENTURE LAUNCHED SOURCE: CMP Publications via Fulfillment by INDIVIDUAL, Inc. DATE: July 5, 1994 INDEX: [2] ---------------------------------------------------------------------------- Information Week via INDIVIDUAL, Inc. : RSA Data Security in Redwood City, Calif., and Enterprise Integration Technologies in Palo Alto, Calif., have formed a joint venture to improve security for transactions on the Internet. The unit, called Terisa Systems, will develop and supply online security products to provide encryption, authentication, and other services. Improved security could give Internet commercial ventures a big boost. [07-05-94 at 17:42 EDT, Copyright 1994, CMP Publications, Inc., File: c0705022.8mp]

1 0

Unknown
by Random H0Z3R 17 Dec '03

17 Dec '03

============================================================================ SUBJECT: PRETTY GOOD PRIVACY 2.6 SOURCE: ZiffWire via Fulfillment by INDIVIDUAL, Inc. DATE: July 5, 1994 INDEX: [3] ---------------------------------------------------------------------------- PC Week via INDIVIDUAL, Inc. : Those opposed to, or even just worried about, the federal government's Clipper chip encryption proposal now have a free, easy, and legal alternative. The Massachusetts Institute of Technology and RSA Laboratories have teamed to produce a new version of Philip Zimmermann's PGP (Pretty Good Privacy), Version 2.6. The software and source code is being distributed by MIT along with a free license from RSA Laboratories for non- commercial use. The software was released at the end of May. PGP uses the Public Key encryption method, which has been patented by RSA. PGP has been distributed since 1990 as an implementation of the Public Key encryption algorithm and has gone a long way in popularizing that method of personal encryption and the use of what are called digital signatures. PGP has been the subject of controversy, however, since it used to use public-key encryption without a license from RSA, and because it has been distributed all over the world in source-code form, which some federal authorities say is against international encryption-export bans imposed by the United States. Version 2.6, however, is licensed through RSA, so there's no question about its legality. MIT and RSA's distribution of PGP Version 2.6 is an attempt to short- circuit PGP's popularity. After Sept. 1, 1994, PGP 2.6 will no longer work with documents and keys generated and encrypted by older versions of PGP, and it is licensed for use only in the United States. The release is already causing upheaval, since its public-key format is different than in prior versions, and numerous public-key repositories will have to be updated. An oversimplified explanation of public-key encryption is that users choose (or generate using software) two large, random prime numbers (only divisible by themselves or one), which remain private. They then distribute the product of those two numbers freely, which is the public- key part of the encryption. Anyone wishing to send an encrypted document to a user can encrypt it using that user's public key. Only the intended recipient can then decrypt the document. A related use of public-key encryption (and probably its more important use in the future of the information highway) is for digital signatures. A user wishing to "sign" a document uses a private key (the prime factors) and combines it with a checksum of the document. Anyone can then use that users's public key to verify the electronic signature and verify that the document was not altered since the user signed it. Public-key encryption is especially strong because there is no known "easy" method of breaking down extremely large numbers into their component prime factors (other than brute force). The largest supercomputers today would take centuries to break down a sufficiently large public key, but it only takes a few seconds to generate such a key and use it to encrypt and decrypt documents. The government's proposed Clipper chip uses a somewhat similar method of encryption. At least, it seems to be similar: Its exact algorithm is classified. With the Clipper chip, however, the federal government would hold the "key" that would let law-enforcement personnel decrypt the chip to be used when wiretapping is authorized by the courts. PGP comes with extensive documentation that clearly explains the public- key algorithm and provides both a DOS executable and source code for compiling the program on numerous other platforms. The program provides all the normal public-key functions (such as signing and encrypting) through the command line. Although command line is not the most intuitive method, it lends itself well to automation. Obtaining PGP 2.6 is a somewhat complicated process. Users must use ftp to get to net-dist.mit.edu and get a README file and various licenses in /pub/PGP, then use telnet to get to the same address to answer a questionnaire and get the address for the rest of the PGP files. Finally, users must use ftp a second time to actually obtain the files. If the user's IP address is not part of a Domain Name Service and can't be resolved to an address in the United States, the user must contact MIT through E-mail. -- Eamonn Sullivan [07-05-94 at 17:19 EDT, Copyright 1994, ZiffWire, File: c0705185.2zf]

1 0

SUPPORT FOR ARMY DIGITIZATION...
by Random H0Z3R 17 Dec '03

17 Dec '03

============================================================================ SUBJECT: SUPPORT FOR ARMY DIGITIZATION EXTENSIVE BUT CONCERNS ARISE SOURCE: Phillips Publishing via Fulfillment by INDIVIDUAL, Inc. DATE: June 30, 1994 INDEX: [6] ---------------------------------------------------------------------------- DEFENSE DAILY via INDIVIDUAL, Inc. -- Despite widespread support for the Army's multi-billion dollar digitization effort, concern is beginning to mount in the Pentagon and Congress about aspects of the program, including intraservice coordination, requirements, funding and interoperability. Officials in the Office of the Secretary of Defense and on Capitol Hill realize digitization, the buzz word for the Army's plan to pass information rapidly between disparate platforms, is a complex task and have thrown their support behind the effort. Emmett Paige, Jr., assistant secretary of defense for command, control, communications and intelligence, says the "Army is off to a good start." "I have no real concerns" about the service's plans, Paige told Defense Daily in a telephone interview. While others in OSD also support digitization, some are beginning to focus on a host of crucial issues they believe the Army must resolve. One such concern is that "different components of the Army perceive [digitization] differently," a senior OSD official believes. Since digitization involves various Army sectors, ranging from the Training and Doctrine Command to the Communications-Electronics Command, the perspective OSD receives "depends on who's doing the talking." In response, the Pentagon is counting on the Army Digitization Office to bring things together. Requirements are also a source of concern. OSD believes they must be developed prior to material solutions or architectures. A congressional source agrees, saying the service is putting the "cart before the horse" by developing an acquisition strategy without "definitized requirements." The massive digitization requirements process has proven slow-moving and somewhat contentious, according to service sources (Defense Daily, June 20). Interoperability is also a central consideration. "There appears to be no involvement of the Navy or Air Force at this point," although it may be a little "early to worry about that," according to the senior OSD source. Paige, though, said he has no doubt the Army realizes the "other services must be included as we digitize the battlefield." Specifically, he says, the "C4I for the Warrior concept is recognized in everything the services are doing today." Developed by the Joint Chiefs of Staff, C4I for the Warrior stresses interoperability and joint operations. Interoperability is also on the minds of lawmakers. This year, they pushed the Army to focus on interoperability with the Marines; next year they will emphasize interoperability with the Navy and Air Force, a congressional source says. Interoperability with the allies will be stressed the following year. A Defense Science Board summer study on the information architecture for the battlefield is dealing with such interoperability issues, according to Paige. The board hopes its study, slated for completion in late-September, will provide the Army with the "processes to evolve interoperability issues," a source says. The task, however, is a difficult one, he concedes. "It's one thing to have an architecture; another to control the builders." Indeed, development of an overall systems architecture is a primary concern of Congress. The service at this point has "no standards, protocols or interface requirements" but it is proceeding with billion-dollar digital upgrades to the Bradley Fighting Vehicle and M1A2 tank, the congressional source says. Turning to specific systems, OSD is interested in how the digitization effort will affect a range of existing C4I equipment, including the Army Battle Command System, Mobile Subscriber Equipment, the Single Channel Ground and Airborne Radio System and the Enhanced Position Location Reporting System, according to the senior OSD official. OSD plans to "force the Army to come up here and tell us how [the systems] fit and not be duplicative," he notes. As expected, in tough budget times, money is also a central concern. The service has probably underestimated the cost of digitization "200-400 percent," the congressional source argues. The Defense Science Board is also concerned about the amount of funding the Army will need to execute its strategy. The Army has placed the value of the portion of the digitization effort it will compete to industry at over $1 billion. Army charts show the Army Digitization Office will oversee over $8 billion in digitization funding into the next century (Defense Daily, June 23). At this point, both OSD and Congress are willing to give the service more time to work out the problems associated with digitization. "We'll give them a chance to get started," the senior OSD source notes, but "we'll ultimately decide whether the acquisition strategy makes sense." It "could get changed." [06-30-94 at 18:00 EDT, Copyright 1994, Phillips Publishing, Inc., File: d0630009.8sd]

1 0

TROJAN HORSE CALLED CHINON
by Random H0Z3R 17 Dec '03

17 Dec '03

============================================================================ SUBJECT: ALERT RAISED ON TROJAN HORSE CALLED CHINON SOURCE: Newsbytes via Fulfillment by INDIVIDUAL, Inc. DATE: July 1, 1994 INDEX: [1] ---------------------------------------------------------------------------- PITTSBURGH, PENNSYLVANIA, U.S.A., 1994 JUL 1 (NB) via INDIVIDUAL, Inc. -- Newsbytes has confirmed that a new "Trojan horse," named the "Chinon" or "CD-IT" program, is being spread by "unknown hackers" on the Internet. Newsbytes confirmed through the Computer Emergency Response Team at Carnegie-Mellon University in Pittsburgh that the program has been distributed by unknown persons on the Internet, from which it can be downloaded. Unlike a virus, a piece of code which hides from users and then causes destruction, a Trojan horse masquerades as a helpful program, but then causes damage when downloaded. The program alleges to be a shareware utility for PCs that will convert an ordinary CD-ROM drive into a CD-Recordable device. That is technically impossible. Instead the program destroys critical system files on a user's hard drive and can crash the CPU, forcing its user to reboot while remaining in memory. According to a spokesman for CERT, the only remedy now known for infected computers is a regular back-up of the hard drive. Once the Trojan horse is activated, there's nothing that can be done except to erase the hard drive and re-load it from the back-up, losing all work done since the last back- up. The program is not detected by most anti-viral programs in part because it's not a virus. Word of the program, and efforts to correct it, have spread quickly. Newsbytes got word through a bulk-mail from an OS/2 newsgroup, the message originating at the University of Georgia. UGA, meanwhile, apparently learned of Chinon through Doug Leonard, who spread an alert from the Sacramento PC Users Group. The original message, in turn, was written by Mark F. Haven of the US Department of Health & Human Services. The message to Newsbytes, sent around 4:30 PM Eastern Daylight Time, was confirmed through a phone call to Terry McGillan at Carnegie- Mellon, who checked with CERT to make sure the alert was genuine. (Dana Blankenhorn/19940701/Press Contact: Terry McGillan, Carnegie-Mellon University, 412-268-7394)

1 0

Any news on the crypto export bill?
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

The House Rules Committee was supposed to decide if the General Export Administration Act HR 3937 was going to be "open" or "closed". They were going to do this last Thursday. What did they decide? Or was the meeting postponed? Jim_Miller(a)suite.com

1 0

FW: Windows for Workgroups 3.11
by Blanc Weber 17 Dec '03

17 Dec '03

Below is the reply which I received internally on the question of whether WfW uses RSA: ---------- From: Michael Ginsberg To: Blanc Weber Cc: Cypherpunks Mailing List Redistribution Subject: RE: Windows for Workgroups 3.11 Date: Thursday, July 07, 1994 8:22AM [The following can be distributed outside of Microsoft, and redistributed thereafter, as long as it remains unaltered and is reproduced in it's entirety, including this header] In the Windows for Workgroups 3.11 fax enhancement, we provide the ability to send "email format" messages over fax. These are messages that do not lose their original format during faxing, so that they are still editable (ie: if you send a Microsoft Word document, the receiver gets an actual Microsoft Word document, not just printed pages). One feature of this format is that we allow security enhancements to be applied to the message before transmission. These enhancements are encryption (either secret key or public key) and signature (based on public key). I will describe a bit about how we implement these features. 1> Secret key encryption This is exposed to the user as password encryption. The user chooses a password (of as long a lenght as the user desires, composed of characters with ASCII values 1 through 255) and we hash it down to 64 bits. These 64 bits are used to encrypt the message (including all attachments, text, properties, etc) using RSA's RC4 algorithm. A header is then placed on the message with sufficient information for routing (subject, sender, receiver, time stamps, as well as a marker identifying the encryption type). The receiver enters the password to decrypt (the same as the encrypting password), and we verify that the password is correct by decrypting the message and seeing if it's valid (ie: has the right internal structure to be a mail message). 2> Public key encryption We allow the user to generate public/private key pairs. These key pairs are 512-bit RSA key pairs. The private part is stored encrypted (with the user's "fax security" password) on the user's hard drive, and the public part is stored in plain (binary form). The user exchanges his public keys with other users in various ways. If the user sends a fax with public key encryption, we first generate a random 64 bit number, and encrypt the message with RC4 using that number (similar to password encryption above). We then scatter the 64 bits in a 64 byte (randomly initialized) buffer and encrypt that buffer using RSA's RSA encryption scheme, using both the sender's private key and the recipient's public key. We then send the encrypted message and header containing routing information and the 64 byte block. The recipient performs a similar operation, using his private and the sender's public key to obtain the 64 bit "secret key", and then decrypting the message. 3> Digital signature While the above encryption schemes are performed on entire messages, we provide a method for digitally signing attachments. Microsoft Mail allows the entering of plain text into a message, as well as the embedding of entire files. It is these files which we sign. Signature is accomplished by computing a 128 bit hash of the file using RSA's MD5 message digest algorithm. This 128 bit hash is then embedded in a 64 byte buffer, and it is encrypted using the sender's private key. The buffer (along with some header information) is pre-pended to the document, and it's extension is changed to .aws, so that our applet to view signatures is called upon double clicking or "running" the signed document. Anyone receiving the document can see the validity of the signatures (by hashing themselves, and then decrypting the stored hash). If you sign a signed document, the signatures are cumulative, so multiple people can sign the same document. Signatures are either valid (hashes match), invalid (hashes differ), or unverifyable (you don't have the sender's public key). --Michael Ginsberg, Software Design Engineer, Microsoft Corporation. mikegins(a)microsoft.com

1 0

Re: Counting Bits
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

From: SINCLAIR DOUGLAS N <sinclai(a)ecf.toronto.edu> The only sane way to count the number of 1 bits in a byte is to use a lookup table: return table[result]; On an intel chip this produces ONE opcode: XLAT Do you think we'd all be spending weeks on it if it were that easy? Or are you suggesting that 32-bits of address space of RAM is reasonable for this problem? Even if it's a 16-bit table you still have to do the add; worse, the non-local access shits all over the bus timings and the cache. Much better to avoid going off-chip and keep the CPU running at full speed (which might be 100 times faster than memory). Again, remember we're nottalking about PCs here but real computers. G PS I dunno what superoptimisizer Perry is talking about but I've never heard of a real one that works. You have to feed in a complete machine description at register transfer level and i don't know if those exist for real machines; also the problem is almost certainly exponential time for a *guaranteed* solution as Perry claims is possible.

2 1