December 2003 - cypherpunks-legacy

Cellular Encryption Docs
by John Young 17 Dec '03

17 Dec '03

Thanks to David Wagner and Steve Schear, we've learned about the latest documents on cellular encryption which supercede the 1992 CAVE document, Appendix A to IS-54, which contained the CAVE algorithm. Here are the latest, followed by ordering information. TIA/EIA/IS-136.1-A -- TDMA Cellular/PCS - Radio Interface - Mobile Station - Base Station Compatibility - Digital Control Panel, October, 1996, 372 pp. $350.00. Addendum No. 1 to IS-136.1-A, November, 1996, 40 pp. Free. TIA/EIA/IS-136.2-A -- TDMA Cellular/PCS - Radio Interface - Mobile Station - Base Station Compatibility - Traffic Channels and FSK Control Channel, October, 1996, 378 pp. $310.00. TIA/EIA-627 -- 800 MHZ Cellular System, TDMA Radio Interface, Dual-Mode Mobile Station - Base Station Compatibility Standard, June, 1996, 258 pp. $120.00. These documents can be ordered from: Global Engineering Documents 15 Inverness Way East Englewood, Colorado 80112 Telephone: 1-800-854-7179 However, each of the documents lists the following related supplements which contain "sensitive information" and may be obtained by US/CA citizens from TIA by signing a Non-Disclosure Agreement and acceptance of export restrictions: Appendix A to IS-136. Appendix A to 627. Common Cryptographic Algorithms. Interface Specification for Common Cryptographic Algorithms. These controlled documents can be requested by calling Ms. Sharon Vargish at 1-703-907-7702, who will fax an NDA, and upon receipt of the completed form, will send the controlled documents at no cost. Here's the NDA: AGREEMENT ON CONTROL AND NONDISCLOSURE OF COMMON CRYPTOGRAPHIC ALGORITHMS REVISION A TO IS-54, IS-95, AND IS-136 [Note: 627 supercedes IS-54; IS-95 is for CDMA] "I, _________________________, an employee/consultant/affiliate (typed name) of __________________________, hereafter, "the company," (Company name) _____________________________ (Company address) _____________________________ and a United States or Canadian citizen, acknowledge and understand that the subject documents, to which I will have access contain information [which] is subject to export control under the International Traffic in Arms Regulations (ITAR) (Title 22, Code of Federal Regulations, Part 120-130). I also understand that the subject documents represent valuable, proprietary and confidential business information of TIA and its members. I hereby certify that this information will be controlled and will only be further disclosed, exported, or transferred according to the terms of the ITAR. ______________________________ _____________________________ Signature Date ______________________________ _____________________________ Printed Name Witness ______________________________ _____________________________ Title Printed Name of Witness [End NDA]

1 0

Re: Hi again, and an invitation to kibitz
by Bill Stewart 17 Dec '03

17 Dec '03

In addition to David Wagner's comments, I'd like to point out several more weaknesses. - Would Kerberos work just as well? No sense reinventing the 3-headed dog. - You're not authenticating the server to the client. - If the challenge is different every time, the server needs to keep the user's password in plaintext (unlike Unix encrypted passwords.) This means that attacks on the server's file system can steal it, and since the password is used for session encryption, it can be used to forge sessions as well. - Alternatively, if the challenge is always the same (per user), then even one eavesdrop kills you, as with Unix passwords. - Since you're using the same 7-byte password hash for the first third of the authentication as for the session key, the dictionary attack on E(challenge, First-seven-bytes) gives you the session key, so you can eavesdrop just fine. If the password is too short, you can then dictionary-attack MD4 to find it also. - There's a Diffie-Hellman variant that can do logins. Unfortunately, it's patented (by some guy from Siemens in Paderborn DE, who patented it in Germany about 2 years before I rediscovered it, and patented it in the US about 6 months before :-) It covers any login methods using commutative hashes H1(H2(x)) == H2(H1(x)). The Siemens version extends it to authenticate both ends to each other; I extended it to get a session key for encryption and/or authentication. This really shouldn't have been patentable - my rediscovery shows that it must be pretty obvious to anyone skilled in the trade :-), and rather than reinventing the wheel, I was reinventing the hubcap or tire swing.... > In article <199701140755.CAA04514(a)mail.intercon.com>, >Amanda Walker <amanda(a)intercon.com> wrote: >> (a) Server sends 8-byte challenge to client >> (b) Client sends Microsoft NT authentication response to the server >> (take the password in Unicode form, do an MD4 hash, pad with 0s to 21 >> bytes, split into 3 7-byte groups, use these as DES keys to encrypt >> the challenge three times, send the 24-byte result as the response). >> (c) If authentication fails, close the connection. >> (d) If authentication succeeds, all subsequent traffic is enccrypted with >> DES in CFB mode. Until April :), the DES key used is taken from the >> first 7 bytes of the MD4 hash of the password (after April, we expect >> to switch to Diffie-Hellman key exchange first, followed by a revised >> authentication handshake). > At 11:20 AM 1/17/97 -0800, David Wagner wrote: >Some weaknesses: >- It doesn't resist dictionary attacks (no salt) when the attacker can make > one active probe (forge a fixed challenge and get the client's response). In particular, an 8 byte challenge is nowhere near enough, though the average million-dollar DES-cracker won't be as easy to adapt for 2**64 cycles of hash+DES*3 - and don't handle each third separately! At least do something like 3DES-EDE and return an 8-byte response, or hash the three output bytes together and send the hash. Using >=16 bytes of challenge would be better, or >=24 if you want printable challenges. >- It doesn't stop replay attacks (replay a fixed challenge, now the same DES > key is used, so replay DES-encrypted session data). You may not be able to replay a given challenge usefully, assuming it's different each time, but MITM attacks work ok after you've cracked the password by dictionary attack in the previous round. >- DES-encryption doesn't provide message authentication against active > attacks; use a MAC too. >- You should use independent DES keys for each direction of the connection. >- Also the DES encryption key doesn't change for each connection. It should. # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp # (If this is a mailing list, please Cc: me on replies. Thanks.)

1 0

[Humor] Crypto in Traveller (a game)
by Jim Choate 17 Dec '03

17 Dec '03

Hi, I thought I would pass this along to demonstrate that all uses of crypto are not 'real world'... Hope you enjoy. Jim Choate CyberTects ravage(a)ssz.com Forwarded message: > To: traveller(a)MPGN.COM > Subject: Re: Aperture Synthesis, Aegis > Date: Sun, 26 Jan 1997 21:40:18 +0000 > > At 08:15 AM 1/26/97 +0000, you wrote: > <snip> > >For example, at 5 ls, you have ship A sending data to ship B, which has > >to know "exactly" how long it took for the data to cross the gap, as > >that's one of the parameters in the calculations. > > > >If it's "exactly" 5 seconds, then each ship "combines" the data it > >receives directly with the data received 5 seconds later from the other > >ship. The combining involves various things like trig and other messy > >stuff. But it all boils down to "A saw X1 from direction Y1 at time Z1, B > >saw X2 from Y2 at Z2". You combine the info and triangulate. > > > >So at 5 ls, you have a "data lag" of the 5 seconds it takes the signal > >to cross the distance *plus* the processing time. > > > >And since the distance *will* vary, even if only by a little bit, that > >changes the point in the your datastream that you are comparing with > >the datastream from the other ship. > > > > Could we presume that vessels operating together would have some type of > synchronized timekeeping, such as an atomic clock, in each ship, with each > message between ships being time & velocity stamped so that each receiver > could adjust the data for integration to local data? > > We should also assume a really good (and closely gaurded) encryption on the > interchanges, or enemy intercepts would be right dangerous. > > Adventure possiblity: trying to obtain a given unit's encryption code or > seeking to recover said code.

1 0

Re: David Kahn advocates GAK
by wlkngowl＠unix.asb.com 17 Dec '03

17 Dec '03

On Thu, 23 Jan 1997 17:32:56 GMT, you wrote: >This is surprising, given that (in Kahn on Codes) Mr. Kahn expressed >forceful opinions >- against certain aspects of export controls, >- questioning the value of the NSA's mission, in contrast to social >demands on government revenues. I didn't find his opinions forceful in Codebreakers, 2nd. ed. Questioning the NSA's purpose vs. advoctating GAK are not incompatible. >However, while I oppose making key escrow mandatory in general, and >share the general suspicion of a voluntary Clipper, if Mr. Kahn's >support for Clipper is limited to cellular telephones, then I have no >quarrel with such a position. >Encryption is illegal, without special permission, for use over the >airwaves, particularly where mobile radio is involved. This is a >long-standing restriction, and not unreasonable. Private communication >between people at home is one thing, but allowing criminals to closely >coordinate their activities on the move is another. [..] The problem is the technology is merged. What if you're using cellular links to your ISP, and use SSL or ssh or PGP? Radio is being advocated as a possible solution to some of the net's bandwidth problems. Rob

1 0

Re: Toto's database
by Dale Thorn 17 Dec '03

17 Dec '03

Greg Broiles wrote: > Toto writes: > >Has anyone actually 'seen' John Gilmore, lately? > He was at C2Net's party last Friday night (1/24), being interviewed by some > folks from a Japanese TV program. It would be interesting if someone could show up at Gilmore's press conferences to supply an alternative view of Gilmore himself. Of course, those still clinging to the notion that Gilmore is working for us might not be comfortable with this idea - biting the hand that feeds, etc., but I think it could be a good way to keep the moderator honest.

2 1

RE: overview.htm (fwd)
by blanc 17 Dec '03

17 Dec '03

>Igor Chudov @ home wrote: >>>Jim Choate wrote: >>>>>Dr.Dimitri Vulis KOTM wrote: >>>>>>>irrelevant(a)nowhere.com wrote: >>>>>>>>>>Dale Thorn wrote: It can be said 100,000 times, but it still comes out the same: Just as in "The only cure for bad speech is more speech", "the only cure for 'list-focus-drift' is more on-focus postings".

2 1

Re: David Kahn advocates GAK
by Robert Rothenburg Walking-Owl 17 Dec '03

17 Dec '03

On Thu, 23 Jan 1997 17:32:56 GMT, you wrote: >This is surprising, given that (in Kahn on Codes) Mr. Kahn expressed >forceful opinions >- against certain aspects of export controls, >- questioning the value of the NSA's mission, in contrast to social >demands on government revenues. I didn't find his opinions forceful in Codebreakers, 2nd. ed. Questioning the NSA's purpose vs. advoctating GAK are not incompatible. >However, while I oppose making key escrow mandatory in general, and >share the general suspicion of a voluntary Clipper, if Mr. Kahn's >support for Clipper is limited to cellular telephones, then I have no >quarrel with such a position. >Encryption is illegal, without special permission, for use over the >airwaves, particularly where mobile radio is involved. This is a >long-standing restriction, and not unreasonable. Private communication >between people at home is one thing, but allowing criminals to closely >coordinate their activities on the move is another. [..] The problem is the technology is merged. What if you're using cellular links to your ISP, and use SSL or ssh or PGP? Radio is being advocated as a possible solution to some of the net's bandwidth problems. Rob

1 0

Re: Cellular location...
by jim bell 17 Dec '03

17 Dec '03

At 07:54 PM 1/25/97 -0500, Mark M. wrote: >I wonder how expensive it would be to put a GPS receiver in a cell phone and >have the option to transmit the coordinates on a separate channel. There >would be little difference between this and forcing cell phone companies to >triangulate every call. The primary motivation for this is almost certainly >"location escrow" to make it easier for the feds to track drug dealers. It would only be marginally reliable. GPS signals are so weak (coming from satellites in 11,000 mile orbits) that reception outdoors is sometimes iffy if the signals have to go through foliage. Reception indoors is probably only rarely do-able. Jim Bell jimbell(a)pacifier.com

1 0

Re: DPT Win 3.xx, 95, NT ENCRYPTION program
by Igor Chudov ＠ home 17 Dec '03

17 Dec '03

In article <5cd7ki$52b(a)news.xs4all.nl> bernard(a)xs4all.nl Crypto wrote: Newsgroups: comp.security.misc * DPT Win 3.xx, 95, NT ENCRYPTION program * * DPT16 or DPT32 total encryption Windows program. * * Encrypt fast, Files, Dir, Floppys, e-mail, text or Messages .... * * Key up to 30 Kb, Hide your encrypted data's in a picture file. * Direct mail encryption, Visit the Data Privacy Tools home page. * * at; http://www.xs4all.nl/~bernard Bernard, thanks for an interesting post. I am Cc-ing your message to Cypherpunks mailing list which is ostensibly dedicated to discussions of cryptography. As follows from info on your home page, you do use simple XOR to encrypt your data. It was not clear to me though, how do you generate the keys to encrypt the data. I am sure that many readers of cypherpunks mailing list will be interested, so please send a copy of your reply to cypherpunks(a)toad.com. igor

2 1

WinKrypt
by Frank Willoughby 17 Dec '03

17 Dec '03

Out of curiosity, is anyone familiar with WinKrypt by Syncronsys? I picked up a copy & there is no mention in the documentation which encryption algorithm it uses & what the key lengths are. FWIW, my impression is that the documentation seems to deliberately avoid mentioning the algorithm/key lengths. Hmmmm. (food for thought) I was curious how it compares to McAfee's PC Crypto which uses 40-bit DES or 160-bit Blowfish (user-chooses) & other PC/laptop encryption products. BTW, I would also appreciate your input on any crypto products which you believe to be robust, easy-to-use & secure. (I know I can only have 2 out of 3, but it's worth a try anyway). 8^) Please send marketing info to me directly at: frankw(a)in.net and **NOT** to the entire mailing list. (BTW, I mentioned WinKrypt & PCcrypo because they are the only two which are available at many computer stores as COTS s/w). TIA for your help. Best Regards, Frank

1 0