December 2003 - cypherpunks-legacy

Re: Q: Bookshop in Seattle
by blancw＠accessone.com 17 Dec '03

17 Dec '03

Can someone point me towards a bookshop in Seattle that is likely to have the second edition of Applied Cyptography ? ....................................... Tower Books (I've seen it advertised there) The University BookStore (probably) Barnes & Noble (potentially) .. Blanc

2 1

Offshore Assets Reconciliation using PGP
by Brad Dolan 17 Dec '03

17 Dec '03

ENCRYPTED ON-LINE FINANCIAL TRANSACTIONS are being offered by a Bahamian company, Offshore Assets Reconciliation, Ltd. As predicted by *SI*, the computer encryption technique called PGP would result in commercial services providing electronic transactions that are indecipherable by any government agency. OAR is in Nassau, and can execute PGP instructions to move cash from bank or brokerage accounts to bank, attorney, or escrow accounts. It is equipped to function throughout the Carribbean and in 20 international financial centers such as Isle of Man, Bermuda, Cook Islands, and Vanuatu. For more information contact OAR at phone: (809) 356- 2039, fax: (809) 356-2095, e-mail: 71522.2715(a)compuserve.com. OAR is the first of many such services to come. *Strategic Investment*, November 15, 1995 SI is published by Agora, Inc., 824 E. Baltimore St., Baltimore MD 21202-4799

1 0

Re: Repeated Words/characters in Password/Phrase
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 11:11 PM 11/14/95, Ted Cabeen wrote: >Do repeated words in a PGP passphrase make the pass phrase less secure than >a passphrase without any repeated words? And on the same note, do repeated >letters in a UNIX password make that password easier to break? I can't seem >to find anything in my books on cryptography that mention this. Thanks. More of an information theory question than a crypto question. There are no simple answers to this question, but some examples will help: The password "foo" is not very good, and "foofoo" is only slightly better. And "foofoofoo" is slightly better, and so on, to a point. But "foofoo....foo" is not N times better than a single "foo," because the _pattern_ is simply desribed: "repeat "foo" N times." Thus, the information content or entropy of "foofoofoo....foo" is not N times greater than the entropy of "foo." A some dictionary attacks which would trivially find "foo" will not find "foofoo," or "foofoofoo," etc., so this could be a great help. More sophisticated dictionary attacks may of course take the 30,000 or so most common names, words, places, and then do various permutations, reversals, repetitions, etc. So this is why there is not likely to be a simple answer to your question. Repeating words in a passphrase can make the passphrase easier to remember (such as "thequickquickbrownfox") and make certain kinds of attacks harder, but with not as much of an increase in entropy at the increased number of raw characters might otherwise suggest. Other "heuristics" (simple rules of thumb) for passphrases are contained in the PGP documents, and in numerous other places: avoid names, add nonstandard English keyboard characters liberally (even if using real words), etc. The "best" passphrases, it almost goes without saying, are the longest and most "unpredictable," so that "7f#qp)djQ10hB%3t+1?U4SVp5" is much superior to "%foo%foo". In the real world, where passphrases must be memorized, "long and random" is an elusive goal, which has to be weighed against the risk of other attacks (such as capturing keystrokes with a sofware monitor, or from afar with a van Eyk antenna, etc.). Me, I use a nonsense phrase which has meaning to me, with a few garbage characters added to confuse things further. I don't think my passphrase is the weak link. --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

2 1

ssl-encrypted web server comparison
by sameer 17 Dec '03

17 Dec '03

I've started a small summary of various features of encrypting web servers that I know about. http://www.c2.org/apachessl#compare Please send your comments criticisms and suggestions. Thanks. -- sameer Voice: 510-601-9777 Community ConneXion FAX: 510-601-9734 The Internet Privacy Provider Dialin: 510-658-6376 http://www.c2.org (or login as "guest") sameer(a)c2.org

1 0

Re: Who needs time vaults anyway?
by rah＠shipwright.com 17 Dec '03

17 Dec '03

>An application that I've seen is financial data, more specifically >MBS payment info. In the real world, there's a trustee/nominee of some sort who does this. What's that to keep that from happening on the net, just like our much maligned (guy's gotta make a living, fer chrissake!) assassination-payoff escrow agent... Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 958-3971 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

5 4

source of title
by Robert Hettinga 17 Dec '03

17 Dec '03

No need to answer the question. Just thought the DeToqueville quote was appropriate to our circumstances the last week or so... By, the way, if there ever was an Official Cypherpunks Reading List(tm), the "Road to Serfdom", by Hayek would certainly be on it. There's a 50th anniversary edition out, with a forward by Milton Friedman... Cheers, Bob --- begin forwarded text Date: Thu, 18 Sep 1997 11:33:07 -0500 Reply-To: Hayek Related Research <HAYEK-L(a)MAELSTROM.STJOHNS.EDU> Sender: Hayek Related Research <HAYEK-L(a)MAELSTROM.STJOHNS.EDU> From: Kent Guida <kent.guida(a)WORLDNET.ATT.NET> Subject: source of title To: HAYEK-L(a)MAELSTROM.STJOHNS.EDU Regarding the source of Hayekís title, The Road to Serfdom: Was it taken from Tocqueville? I assume it is, but Iíve seen no explicit acknowledgment. Hayekís references to T. all point to him as a soulmate and precursor. The passage in Democracy in America reads: I am convinced, however, that anarchy is not the principal evil that democracies ages have to fear, but the least. For the principle of equality begets two tendencies: the one leads men straight to independence and may suddenly drive them into anarchy; the other conducts them by a longer, more secret, but more certain road to servitude. Nations readily discern the former tendency and are prepared to resist it; they are led away by the latter, without perceiving its drift; hence it is peculiarly important to point it out. Vol 2, p.288 in Vintage edition of the Reeve translation Did Hayek ever refer to this as the source of his title? Can anyone help me out here? Kent Guida --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/

1 0

Re: DejaNews all over again
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

On Wed, 8 Nov 1995, Jeff Weinstein, self-styled "Electronic Munitions Expert", from Netscape Communications: >> Meanwhile people are having their PGP keyrings collected, their passwords >> monitorred, and all of the information -- even information which they have >> NOT posted to Usenet, information that is simply on their personal hard >> drives, or on a private corporate network that is behind a firewall -- >> collected by anyone who actualy understands *how* to use Netscape >> Navigator's standard features to do it. > > Please show us some proof. All you have done is post unfounded >allegations backed up by flawed logic and a misunderstanding of the >technology. Send me a URL, and I will point my navigator at it. If you >can collect my PGP key ring you can gloat here or anywhere else. I think "Jeff" ... Mr. unofficial not speakng for the company Netscape spokesperson, I think that you should rethink what you're suggesting. Your tactics won't serve your personal interests on this one. I really would recommend that you come clean. This is not about "gloating". I really take very little pleasure in this. It's really not a good plan, to suggest that I contravene your "license agreement" or break the laws of my country to satisfy some ego-centred game on your part not to face the FACT, that you have been caught. Not arrested yet, but you have been found out. Or as I wrote some weeks ago, in some oddly inspired flash ... You're "Hoist by your own 'petar" ... (which is a quote that Johnnie Cochrane used during the OJ trial ... a quote taken from Shakespeare which *translated* means that you've been blown up by your own bomb.) I am not nearly so *SLOW* as to offer you ammunition to use against me. Your license agreement -- pardon me -- Netscape's license agreement explicitly sets out the limitations underwhich I must function. An agreement, I respect. It states in part. > RESTRICTED USE. You may not copy the software, except for backup or > archival purposes. Any such copy made by you shall be subject to this > Agreement and shall contain all of Netscape's notices regarding > copyrights, trademarks and other proprietary rights as contained in the > Software originally provided to you. You may not lend, rent, lease or > otherwise transfer the Software. The Software is protected by the > copyright laws of the United States and international copyright > treaties. Ya see ... "Jeff" ... I actually respect that ... and I'll operate within those constraints on this one. Later the Agreement continues with more legalistic boiler plate and says, > TITLE. Title, ownership rights, and intellectual property rights in > and to the Software and Documentation shall remain in Netscape and/or > its suppliers. This Agreement does not include the right to sublicense > the Software and is personal to you and therefore may not be assigned > (by operation of law or otherwise) or transferred without the prior > written consent of Netscape. You acknowledge that the Software in > source code form remains a confidential trade secret of Netscape and/or > its suppliers and therefore you agree not to attempt to decipher, > decompile, disassemble or reverse engineer the Software or allow others > to do so, except to the extent applicable laws specifically prohibit > such restriction. You further agree not to modify or create derivative > works of the Software. Now how do you expect me ... poor little "Alice" ... to exploit KNOWN documented and undocumented security holes in Netscape Navigator ... holes which Netscape willfully and deliberately or alternatively through the grossest of negligence, engineered into the product, when I have implicitly agreed not to violate your License Agreement. My hands are kindof tied, aren't they "Jeff". I need written permission to do that, and considerring that Netscape hasn't even *bothered* to acknowledge email which was sent to them, email which asked whether they will voluntarily open up their experimental MIME objects to IETF review, I somehow doubt that permission will be forthcoming. You can't suck and blow at the same time Jeff. Maybe, what I'll do ... is snail mail Netscape and ask for explicit permission to do just that. I'll also ask for access to all of the source code, and maybe at the same time ask for the email address of Dr James H. Clark, since the Netscape postmaster doesn't seem to reply to email. Afterall, he DOES know about this issue, doesn't he?? Dr. James H. Clark has been briefed, I hope ... Let's see ... Dr. James H Clark, founder of Silicon Graphics Inc, and co-founder of Netscape Communications Corp. does know about this "itsy bitsy" "teeny-weeny" problem doesn't he?? I mean there _will_ be questions as to what he knew and when he knew it and what he did about it. But that'll be his baby ... and I'll let him speak for himself on that one. But the other question ... the question of what the other co-founder of Netscape Communications Corp., Marc Andreessen, knew is not a subject for speculation. We know that. Marc Andreessen, vice-president of technology at Netscape, and creator of NCSA Mosaic's knowledge is clear. We "know" what Marc knew. Marc won't be able to pull an "Ollie North" and redact the public domain electronic archives. It's clear what he knew and when he knew it. A simple one line command tells all ... a command like, maybe: mget rfc* |grep Andreessen run at one of the public domain archives might give us some clues and pointers to anyone who might be familiar with how the net works. Then a little follow up and search of some mailing lists ... lists of the Internet Engineering Task Force ... cross-referencing the records of the IETF might tell us what Marc knew and when. NOTHING which has been written, is gone, is it Jeff?? There are no hidden acts, and there are no solitary acts when it comes to the Network. And isn't that a shame, "Jeff"?? But then what would I know about such things ... I don't *understand* the technology, do I "Jeff", my boy?? Simple question, once again ... does Netscape have any comment to make? Or does it continue to say "no comment". Will Dr. James H. Clark, and/or Marc Andreessen please step forward and address this issue at this time? The international community is beginning to loose its patience. > --Jeff > > -- > Jeff Weinstein - Electronic Munitions Specialist > Netscape Communication Corporation > jsw(a)netscape.com - http://home.netscape.com/people/jsw > Any opinions expressed above are mine. Alice de 'nonymous ... ...just another one of those... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.

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

ALERT: On Monday, call Congress to stop Big Brother amendment!
by Shabbir J. Safdar 17 Dec '03

17 Dec '03

=========================================================================== ____ _ ____ _ _ | __ )(_) __ _ | __ ) _ __ ___ | |_| |__ ___ _ __ Stop the Big Brother | _ \| |/ _` | | _ \| '__/ _ \| __| '_ \ / _ \ '__| Amendment, coming next | |_) | | (_| | | |_) | | | (_) | |_| | | | __/ | week in the House |____/|_|\__, | |____/|_| \___/ \__|_| |_|\___|_| Commerce committee! |___/ Posted September 18, 1997 Please forward where appropriate until September 28, 1997 This alert brought to you by The Voters Telecommunications Watch, The Center for Democracy & Technology, the Electronic Frontier Foundation, Wired Magazine, and Americans for Tax Reform _________________________________________________________________ Table of Contents Stop the Government From Building Big Brother Into The Internet What You Can Do -Please contact four leading members of Congress Background About This Alert _________________________________________________________________ STOP THE GOVERNMENT FROM BUILDING BIG BROTHER INTO THE INTERNET In 1948, George Orwell described a future world in which Big Brother peaked over the shoulder of every citizen -- watching every move and listening to every word. Now, in 1997, the FBI is pushing the United States Congress to pass legislation which would make George Orwell's frightening vision a reality. Next week the House Commerce Committee will meet to consider a proposal that would require all Americans to provide the government guaranteed access to their private online communications and business transactions. Taking a page out of Orwell's 1984, the FBI-spawned proposal would require that every part of the Internet -- from the software on your computer to the network provider that carries your messages around the net -- be jury-rigged to divulge your private conversations immediately on request by the FBI (see below). Unfortunately, this is not a work of fiction. The amendment, to be offered by Representatives Mike Oxley (R-OH) and Thomas Manton (D-NY), is a serious threat to your privacy and represents the first and final step in the construction of a National Surveillance Infrastructure. A vote is expected on September 25. The future of privacy and security in the information age is in the hands of the Commerce Committee, and they need to know that folks are watching and care about the outcome. On Monday September 22, please join thousands of Internet users all across the country as we call on Congress to stop big brother. With your help and support, we can ensure that George Orwell's 1984 does not become a reality. All the information you need is attached below. _________________________________________________________________ WHAT YOU CAN DO 1. ON MONDAY SEPTEMBER 22, pick up the phone and call as many of the four leading members of the Commerce committee as you can: Chairman Thomas Bliley (R-VA) (202) 225-2815 Ranking member John Dingell (D-MI) (202) 225-4071 Rep. Tauzin (R-LA) (202) 225-4031 Rep. Markey (D-MA) (202) 225-2836 2. Ask for the staffer that handles the encryption issue. 3. Say that you're calling to urge the Congressman to pass SAFE (HR695) without amendments. Specifically, say that you "OPPOSE THE OXLEY/MANTON BIG BROTHER AMENDMENT. Americans should not be required to give the government keys to the front door of their house, and they shouldn't be required to give the government the keys to unlock their private online communications." Other amendments may be proposed. Please urge the Congressman to pass SAFE "as is" and oppose any amendments. Feel free to use your own words though here are some points you might want to stress: - Oxley/Manton is a dramatic expansion of law enforcement power. It would give law enforcement "immediate" access to private online communications and business transactions without any notice or knowledge to the user. - Oxley/Manton is NOT A BALANCE BETWEEN PRIVACY INTERESTS AND LAW ENFORCEMENT CONCERNS, as some supporters have argued. It gives the FBI broad new power while stripping Americans of their Fourth Amendment right to be secure from unreasonable searches and seizures. - Oxley/Manton would give the Attorney General authority to dictate the design of Internet services and software to suit the needs of law enforcement. - Oxley/Manton would not stop crime. Strong encryption without "immediate access" features is available today at home and abroad. - Oxley/Manton would increase opportunities for cybercrime as criminal hackers attack vulnerabilities in the key recovery access system. 4. Let us know how it went! Go to one of the following web pages, depending on who you called, and tell us about the conversation. Rep. Bliley http://www.crypto.com/member/meet.cgi?membid=va07 Rep. Dingell http://www.crypto.com/member/meet.cgi?membid=mi16 Rep. Tauzin http://www.crypto.com/member/meet.cgi?membid=la03 Rep. Markey http://www.crypto.com/member/meet.cgi?membid=ma07 5. Forward this ALERT to your friends and colleagues. 6. Feel good about yourself! Know that you've stood up for privacy, and contacting Congress is more than most people take the time to do! _________________________________________________________________ BACKGROUND The House Commerce Committee is considering a bill known as the "Security and Freedom through Encryption Act" (HR 695, a.k.a. SAFE). SAFE would encourage the widespread availability of strong, easy-to-use encryption technologies in order to protect privacy and promote electronic commerce on the Internet. SAFE enjoys broad support from Internet users, civil liberties advocates, and over 250 members of Congress. Last week, the Commerce Committee delayed its vote on the SAFE bill in order to give the Committee more time to study the implications of the Oxley/Manton amendment, which would change SAFE to ban encryption which does not contain features that provide law enforcement with "immediate access" to the plain text of encrypted information, including private communications and business transactions (visit http://www.crypto.com/safe_bill/) The Oxley/Manton amendment would for the first time impose sweeping restrictions on the ability of American citizens to protect their privacy on US soil. Specifically, the amendment would: * PROHIBIT THE DOMESTIC MANUFACTURE AND SALE OF ENCRYPTION PRODUCTS OR SERVICES WHICH DO NOT PROVIDE INSTANT ACCESS FOR LAW ENFORCEMENT: The proposal would prohibit the manufacture, sale, import, or distribution within the United States of any encryption product unless it allows "immediate access" to the plain text of any user's messages or files without the user's knowledge. * GRANT BROAD NEW AUTHORITY FOR THE ATTORNEY GENERAL TO SET TECHNICAL STANDARDS FOR ENCRYPTION PRODUCTS: The proposal allows the Attorney General to set standards for what are and are not acceptable encryption products. The proposal's requirement of immediate access to plain text would seem to seriously limit the options available to encryption manufacturers seeking approval of their products. The amendment does not specify whether the immediate access "features" could be activated (or not) at the option of the purchaser or end user. Nonetheless, requiring that such a capability be installed in all domestic communications networks and encryption products is the equivalent of enabling a national surveillance infrastructure and asserts unprecedented control over the design of Internet software, hardware, and services. The amendment is analogous to the government requiring surveillance cameras in every new house built in the United States, which could be turned on remotely by the police if you were ever suspected of committing a crime. Worse yet, such "key escrow" or "key recovery" technologies pose significant risk to the security of the Internet -- providing new points of vulnerability for hackers, terrorists, and industrial spies to exploit. A recent study by 11 of the worlds leading cryptographers concluded that the large scale deployment of such technologies would be too complex and too insecure to meet the needs of an Information Age society (see http://www.crypto.com/key_study/) Despite widespread opposition from Internet users, civil liberties groups, privacy advocates, and the computer and communications industries, Oxley and Manton plan to push for this FBI spawned amendment at the Commerce Committee vote. If it is adopted, it would represent the first and final step in the development of a national surveillance infrastructure. _________________________________________________________________ ABOUT THIS ALERT This message was brought to you by the Center for Democracy and Technology (http://www.cdt.org) the Voters Telecommunications Watch (http://www.vtw.org/) the Electronic Frontier Foundation (http://www.eff.org/) Wired Magazine (http://www.wired.com/) and Americans for Tax Reform (http://www.atr.org/) who have joined together on this alert. _________________________________________________________________ end alert 09.18.1997 net ===========================================================================

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