- cypherpunks-legacy - lists.cpunks.org

Re: How to prevent a virus infection :-)
by dmandl＠panix.com 17 Dec '03

17 Dec '03

At 7:06 PM 2/6/96, Lucky Green wrote: >Just watched an "expert" on Bay TV (SF Cable). He stressed that websites >without firewalls pose the risk of spreading viruses when downloading files >from them. A GIF was being downloaded in the background... > >LOL. > >I only wonder who the fuck is hiring such idiots. Certainly not my former employer. This guy seems to know far too much about net security to work there. --Dave. -- Dave Mandl dmandl(a)panix.com http://www.wfmu.org/~davem

2 1

Java security (reposted from RISKS)
by stevenw＠best.com 17 Dec '03

17 Dec '03

------------------------------ Date: Fri, 10 Nov 1995 15:45:00 -0800 From: Marianne.Mueller(a)eng.sun.com (Marianne Mueller) Subject: regarding Java security This response was recently posted to comp.lang.java. Marianne Mueller <mrm(a)eng.sun.com>, Java Products Group, Sun Microsystems, Inc. Article 4356 of comp.lang.java: Path: handler.Eng.Sun.COM!puffin.Eng.Sun.COM!mrm >From: mrm(a)puffin.Eng.Sun.COM (Marianne Mueller) Newsgroups: comp.lang.java Subject: Re: PRINCETON STUDENTS FIND HOLE IN INTERNET SECURITY SOFTWARE Date: 9 Nov 1995 00:50:27 GMT Organization: Sun Microsystems, Inc. Mt. View, Ca. Keywords: alpha3 hotjava security The paper written by the two students at Princeton describes possible attacks on the alpha3 HotJava browser, which have all been fixed in JDK beta. Granted, until this week, the source code for JDK beta wasn't available, so it's understandable that they analyzed the alpha3 source base. We understand people need more information on the security model, and we're taking time right now to document the security story more rigorously. A security FAQ, an updated whitepaper, detailed user documentation and detailed implementor's documentation are all being worked on. The Java security mechanisms include: Java language mechanisms * no pointers * private interfaces, classes and methods * class loader that enforces namespace divisions * runtime byte code verifier that enforces language type rules and name space divisions Browser mechanisms, used by JDK beta appletviewer and by Netscape Navigator 2.0beta * AppletSecurity: extends java.lang.SecurityManager; strict applet checks * AppletClassLoader: extends java.lang.ClassLoader; strict class loading The goal for JDK beta is to enable browsers to run untrusted applets in a trusted environment. The approach is to be conservative at first, and to add functionality when it can be added securely. So, JDK beta applets (and Netscape 2.0beta applets) may not do the following. 1. Files: Access Control Lists are greatly restricted in beta, as compared to the situation in the alpha3 HotJava browser. ACLs are initialized - only once - by the applet security manager, and are not user configurable. For a file not on the access control list, an applet cannot - check for the existence of the file - read the file - write the file - check the file type - check if the file is a directory - check the timestamp when the file was last modified - check the file's size - create a directory - rename the file - list the files in this file (as if it were a directory) Applets cannot - create a FileInputStream - create a RandomAccessFile, either for reading or writing - Open file descriptors 2. Sockets: Applets cannot - Create socket connections other than to its own host - Create a socket factory 3. Loading/linking: Applets cannot - Create class loaders - Access a package in the sun.* hierarchy - Define a new class in the java.* hierarchy - Link dynamic libraries using System.loadLibrary() - Disable or override the AppletSecurityManager 4. Process control: Applets cannot - Define native methods - Fork processes - Manipulate threads or thread groups outside of the applet's thread group - Exit the virtual machine (e.g., the browser or the appletviewer) 5. awt: Applets cannot - Create toplevel windows that don't have a warning banner Applets can use network connections only to connect to the host they originate from, to download files that are part of the applet's implementation. Those files might be java bytecode class files, or they might be input files used by the applet (GIF, JPEG, audio, other data files.) Taking a look at the specific attacks mentioned in the paper - alpha3 HotJava JDK ---------------------- --- 1. socket accept() and applets cannot use listen() aren't protected accept() and listen() adequately, allowing a browser to eavesdrop 2. applets can connect to applets cannot connect the SMTP (mail) port on to the SMTP port on some web server and use the computer the applet that as a covert channel is visiting 3. InetAddress.getByName() applets cannot use is public and does not InetAddress to inquire check the security mode about hosts they are before making DNS request not already allowed to connect to 4. applets can use DNS to applets may not get the create a covert channel internet address of any host 5. Access Control Lists (ACLs) ACLs are greatly restricted for reading and writing in JDK beta. files are not strict enough Reading/writing files is disabled for web browsers, such as Netscape Navigator 2.0. 6. applets can use the System.getenv() is obsolete System.getenv() method and is not part of the JDK to gather information about API the computer that it is running on 7. applets can change the applets cannot read or alter property manager database client properties 8. applets can change the The fields that hold the HTTP and FTP proxy server HTTP and FTP proxy names are private. The values are stored in a property manager database that an applet cannot read or write. It's very difficult, if not impossible, for a web browser to completely prevent denial of service attacks. The JDK applet API doesn't claim to prevent denial of service attacks. A "denial of service" attack is where someone writes an applet whose goal is to consume all available resources on your computer, forcing you to kill the browser you're running. For example, someone could write an applet that creates a million pop-up windows. The windows don't do anything, but creating a million of them might use up all the virtual memory on your computer and you'd have to kill the web browser to reclaim the virtual memory. Before people engage in too much wailing and gnashing of teeth about how applets have been too severely restricted - We want to enable applets to do interesting things, including making socket connections, and reading and writing to the file system. One way to enable that is to used a signed class loader. When a trusted applet is loaded, then the applet could be granted permission to do some of the things they are prevented from doing by default. The goal is to ensure that untrusted applets can't steal or damage information on a computer running a Java-enabled browser. Later, we can allow trusted applets to do things that untrusted applets are not allowed to do. Since an implementation bug in a trusted applet could open a loophole that could be exploited by an untrusted applet, design matters. Marianne Java Products Group http://java.sun.com/people/mrm/ ------------------------------ ------------------------------------------------------------------------- Steven Weller | "The Internet, of course, is more +1 415 390 9732 | than just a place to find pictures | of people having sex with dogs." stevenw(a)best.com | -- Time Magazine, 3 July 1995

1 0

No Subject
by JMKELSEY＠delphi.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Date: Fri, 10 Nov 1995 11:52:41 -0800 >From: Bill Stewart <stewarts(a)ix.netcom.com> >Subject: Re: coding and nnet's >Schneier's 2nd edition says "Neural nets aren't terribly useful for >cryptography, primarily because of the shape of the solution space. >Neural nets work best for problems that have a continuity of >solutions, some better than others. This allows a neural net to >learn, proposing better and better solutions as it does. Breaking an >algorithm provides for very little in the way of learning >opportunities: You either recover the key or you don't. (At least >this is true if the algorithm is any good.) Has anyone tried using neural nets or similar techniques for searching for useful nonrandom properties of the round functions of block ciphers or hash functions? This might be useful in trying to prepare some new kind of attack, find a balanced binary function that is useful in using the generalization of linear cryptanalysis discussed by Harpes, Kramer, and Massey at Eurocrypt '95, find a better "difference" function for use in a differential attack, etc. >Neural nets work well >in structured environments when there is something to learn, but not >in the high-entropy, seemingly random world of cryptography." And he >doesn't give any references. Merkle's paper on Khufu and Khafre addresses this idea, I think. Merkle comments that it's not going to be useful against a full cipher, but that it might be useful against (say) Khufu with one or two octets. ># Thanks; Bill ># Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com ># Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281 Note: Please respond via e-mail as well as or instead of posting, as I get CP-LITE instead of the whole list. --John Kelsey, jmkelsey(a)delphi.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMKhv1UHx57Ag8goBAQE5IAQAtV3GTqZO08WwHDJSI3Dj2NgIu7rQPrUH V5vBCWTCvRsVNt07K8FbKMxPhF+QmXINPlOEMn4qZbhph0oyf/zAj3uV+6yzO3Eg FMXrZzc1zOOdcfp9IcMvoXvd/av9zq/jH6Sn6yZB3jTO42ENeSSLNbxtaBrzgABl zPklYWOnDrw= =x3kP -----END PGP SIGNATURE-----

1 0

Netscape RNG
by jpb＠miamisci.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I'd like to see the Netscape RNG implemented as a plug-in, preferably with sample source included to make it easier for other people to create compatible plugins. Once there was a published API for the RNG, other apps could use it as well. I like the option of using a cypherpunks approved RNG. No offense to Netscape, but I'd feel a lot more comfortable using a RNG with say Perry's signature or Matt Blaze's. jpb -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMGINp2GnwFiC3O2NAQGUYwf/e7D+Eg3FmPuovUOWEYFmh5T5PZlPD0BJ Ricg4f0UDA34IVrCCKoM1cDvRye8hUerVSjLJDcm/baghrHhoEZCevLsiq4SefbT XuDIjpE+6wM0I5Yz/bU4HK5O2PsvFXRbvgQog0evGKIT2CJPPY/XEBUyPJFTQRcZ 1zr8hbVD74Xj4Xs2q3FEpI7xT4brVFhOluF4j4/jDIbkR3cIbDB0SJgH838rrcjz kp6t+aRqYHJuBwIpVpA522yrhi07opXidTD6LjsZupkSkf3F7twDZwHwM5wv15YL kxhEMv7kREcNNcb1k1bC0luP5KrzDHtFG+wBKraTiSTJIqTGyXw5Ug== =4wHh -----END PGP SIGNATURE-----

2 1

Re: Netscape RNG
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 12:04 AM 9/22/95, Joe Block wrote: >I'd like to see the Netscape RNG implemented as a plug-in, preferably >with sample source included to make it easier for other people to create >compatible plugins. This sounds like a job for.... CyberDog!!! Well, OpenDoc, anyway. How 'bout Mozilloids? Any plans for OpenDoc parts in the works? There's talk on micp about making PGP parts... Cheers, Bob Hettinga I know, I know, If you told me, you'ld have to kill me... ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

Attention Bay Area (and West Coast?) Cypherpunks
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

The "Nova" PBS is tonight, at 8 p.m., repeating "The Codebreakers." On Channel 9, KQED, in San Francisco, and maybe elswhere...depends on when your area shows 'nova." I only mention this because last time it was on, a bunch of folks asked if anyone could send them copies, so there must be some interest. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

1 0

Re: Time Lag
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

> Sending one message and rigorously studying timestamps in the Received > lines and using that to draw conclusions about mail propagation is a > complete waste of time. Ah, but when there seems to be an ongoing pattern of delays, and many people check many messages and find that indeed there is a pattern, it's not a waste of time, no? Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

Cypherpunk FAQ
by cassiel＠alpha.c2.org 17 Dec '03

17 Dec '03

Hi, I'm new to the list, so please don't flame me too badly if this is a dumb question. At least restrict the flames to private email where no one else can hear me scream. :> I downloaded the Cypherpunk FAQ from the Cypherpunk Website. When I decompressed it, all it contained were the words "Yoo hoo, anybody home?" Has the FAQ been corrupted or is this an in-joke? Also, the Privacy FAQ states it was written by L. Detweiler. Is this THE L. Detweiler? If so, why is it in the archives? Thanks for helping me out. Cassiel

1 0

No Subject
by nobody＠flame.alias.net 17 Dec '03

17 Dec '03

> Two years ago, I pointed out that getting a single message past > the man in the middle isn't good enough; you have to convince your > readers that the key they received on one channel is more accurate > than the key they're receiving on all the other channels. > But if they'll believe that, they may also believe the man in the middle's > announcement that the key in your name on all the keyservers is > wrong, and the correct key is the one he's putting out. > Can't win either way, but it's still important to get the key out. > > My current key is 0x54696D4D; the fingerprint is > 4D 65 44 75 53 61 21 2F 41 73 55 64 85 6D 21 7F. but this is not Tim May's key, his key is: pub 1024/54E7483F 1992/11/20 Timothy C. May <tcmay(a)netcom.com> 11-20-92 Key fingerprint = 8C 79 1C 1B 6F 32 A1 D1 65 FB 5F 57 50 6D D3 28 And this one is signed by these people: pub 1024/54E7483F 1992/11/20 Timothy C. May <tcmay(a)netcom.com> 11-20-92 sig 0022E52D Eric Hughes <hughes(a)soda.berkeley.edu> sig DDBE0DD5 John T. Draper <crunch(a)netcom.com> sig 8F898631 Scott Collins (512) <Scott_Collins(a)genmagic.com> sig E972F011 E. Dean Tribble <tribble(a)xanadu.com> sig 4C131F57 Tim Oren <oren(a)apple.com> sig F5257117 <tomj(a)wps.com> sig 85197FB5 John Gilmore <gnu(a)cygnus.com> at level two in the web of trust are these people: pub 512/F5257117 1992/09/28 <tomj(a)wps.com> sig B1331439 Randy Bush <randy(a)psg.com> Tom Jennings <tomj(a)fido.wps.com> sig DA0EDC81 Phil Karn <karn(a)unix.ka9q.ampr.org> sig F572C6A7 Jim Cannell <Jim.Cannell(a)f21.n216.z1.fidonet.org> sig 0BD91A2D Phil Karn <karn(a)unix.ka9q.ampr.org> sig F5257117 <tomj(a)wps.com> Tom Jennings <tomj(a)fidosw.fidonet.org, 1:125/111> sig ADF733A9 Jesse David Hollington <1:225/1.1@fidonet.org> sig 4D077463 Steve Matzura <steve.matzura(a)f203.n2603.z1.fidonet.org> sig E7F23D95 Mike Laster <1:170/300.23@fidonet> sig DB910037 Barry Kapke <96:101/33@dharma> sig 5B77854F Depository #1 [Public Keys] sig 08F811DD Marcos R. Della <mdella(a)polyslo.calpoly.edu> sig 212EC54B Guy Martin 1:143/269 (guy.martin(a)f269.n143.z1.fidonet.org) sig F572C6A7 Jim Cannell <Jim.Cannell(a)f21.n216.z1.fidonet.org> sig BDFB1F2D George Gleason <gg(a)well.sf.ca.us> sig DDBE0DD5 John T. Draper <crunch(a)netcom.com> sig 8F898631 Scott Collins (512) <Scott_Collins(a)genmagic.com> sig 0022E52D Eric Hughes <hughes(a)soda.berkeley.edu> sig E972F011 E. Dean Tribble <tribble(a)xanadu.com> sig 4C131F57 Tim Oren <oren(a)apple.com> sig 85197FB5 John Gilmore <gnu(a)cygnus.com> sig DA27EC35 Wes Perkhiser <wes.perkhiser(a)weise.omahug.org> sig E7960501 Paul Schencke <1:135/340@fidonet.org> sig 9DB252DF Mike Riddle sig 734B9A59 Christopher Baker <1:374/14@fidonet.org> sig B1B6B823 GK Pace @ 1:374/26 <gk.pace(a)f26.n374.z1.fidonet.o pub 1024/85197FB5 1992/11/08 John Gilmore <gnu(a)cygnus.com> sig 5ACB1C6D (Unknown signator, can't be checked) sig 15100C27 (Unknown signator, can't be checked) sig DA0EDC81 Phil Karn <karn(a)unix.ka9q.ampr.org> sig 0BD91A2D Phil Karn <karn(a)unix.ka9q.ampr.org> sig 9F9F38BB Mark Eichin <eichin(a)athena.mit.edu> sig 5B415621 Mark Eichin <eichin(a)paycheck.cygnus.com> sig 66CE89B7 Mark Eichin <eichin(a)cygnus.com> sig 0022E52D Eric Hughes <hughes(a)soda.berkeley.edu> sig BDFB1F2D George Gleason <gg(a)well.sf.ca.us> sig DDBE0DD5 John T. Draper <crunch(a)netcom.com> sig 8F898631 Scott Collins (512) <Scott_Collins(a)genmagic.com> sig 0245C435 Dave Krieger <dkrieger(a)netcom.com> sig 4C131F57 Tim Oren <oren(a)apple.com> sig E972F011 E. Dean Tribble <tribble(a)xanadu.com> sig F5257117 <tomj(a)wps.com> sig 71946BDF Phil Karn <karn(a)qualcomm.com> If you knew any of the level 1, or level 2 signatories personally and had exchanged keys face to face, you'd have some assurance. Also this level 3: pub 1024/DA0EDC81 1994/07/25 Phil Karn <karn(a)unix.ka9q.ampr.org> sig ED2354B9 Ulla Sandberg <ulla(a)stupi.se> sig 9C57B951 Peter Lothberg <roll(a)stupi.se> sig C7A966DD Philip R. Zimmermann <prz(a)acm.org> PRZ, as your PGP distrbution is probably signed by this key, unless you've inspected the source personally, you're relying on this key anyway. Level 4 would be a big web as lots of people fan out from PRZ.

1 0

Get your own ITAR
by Rich Salz 17 Dec '03

17 Dec '03

1 703 875 6644. The kindly administrative assistant there will take your name and address and send you a hardcopy of the ITAR regulations. I don't know about overseas mailings. I also imagine you will have to wait until the current US budget stale-mate is resolved. (Thanks to digest-reader walt(a)osf.org for the phone number.) /r$

1 0