December 2003 - cypherpunks-legacy

Re: Java insecurity - long - argumentative - you are warned.
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

On Tue, 7 Nov 1995, Dietrich J. Kappe wrote: > >>> While all this checking appears excruciatingly detailed, by the time > >>> the byte code verifier has done its work, the Java interpreter can > >>> proceed knowing that the code will run securely. Knowing these > >>> properties makes the Java interpreter much faster, because it doesn't > >>> have to check anything. > > > >Yikes!! I'll leave this for someone else to address. This sounds to me > >like a variation on virus scanning. I think that there are far more > >reputable virus experts than I who can comment and expand on *flaws* with > >that approach. > > This "checking," as any comp-sci undergrad will tell you, amounts to solving > the halting problem for the java interpreter. While this is possible for a > finite state automata like the java interpreter (made more difficult by the > fact that it can use the "net" for additional state), it is not even > remotely feasable. OK, so by saying that it is not "even remotely feasable", you're saying that any comp-sci undergraduate will say that it can't be done? That is what "not even remotely feasable" means, doesn't it?? I mean, even if Marketing wants this problem solved, that won't be enough? > If you can write a checker that works in a reasonable amount of time, I'll > write a turing machine simulator that'll do something nasty if the input > machine halts. Then we'll split the fame and fortune for solving the 5 state > Busy Beaver problem. Deal? I'm sorry, I only work for T-shirt and mug contests. <grin> That fifteen minutes of fame thingy, just isn't my cup of tea. > Dietrich Kappe | Red Planet http://www.redweb.com > Red Planet, LLC| "Chess Space" | "MS Access Products" | PGP Public Key > 1-800-RED 0 WEB| /chess | /cobre | /goedel/key.txt > Web Publishing | Key fingerprint: 8C2983E66AB723F9 A014A0417D268B84 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.

1 0

SPAM:E-CA$H Conference SF 11/16-17
by Kawika Daguio 17 Dec '03

17 Dec '03

COMMERCIAL - SPAM ALERT - I will be speaking at a conference on Electronic Money that might interest some of you sitting on some extra rEeal Money who also suffer from the burning desire to find out what ideas and technology other folks are flogging on the talk-circuit. The brochure is too long to type in but some excerpts follow: 10 key questions to be answered at this critical industry event: 10. What are the biggest avenues to entry into the world of electronic commerce? 9. Who will be the biggest users of electronic money? 8. Who should be allowed to issue E-cash? 7. How will debit and checking fit in with the electronic money future? 6. How do you balance privacy, security, and efficiency in E-cash systems? 5. How can electronic commerce be used for a business advantage? 4. How will the government regulate E-cash? 3. How will electronic payment systems protect against fraud? 2. What infrastructure is needed to provide security on open networks? 1. What are the leading technologies that will be used for E-cash? Speakers: Ernest Brickell Bankers Trust Electronic Commerce Richard K. Crone Center for Electronic Banking, KPMG Peat Marwick ME John Doggett Bank of Boston Peter Gemmel Sandia National Laboratories Gail Grant Open Market Edward Hogan MasterCard International Randy Kahn First Interstate of California Michael Killen Killen and Associates Steve Kimmey Tandem Computers Paul Lambert Barnett Banks Ron Laurie McCutchen, Doyle, Brown and Enersen Scott Loftesness First Data Corporation Greg McKenzie Canadian Imperial Bank of Commerce B. Clifford Neuman University of Southern California Deborah Owen Arent Fox Kinter Plotkin and Kahn Daniel Schutzer Citibank Financial Services Technology Consortium Bill Washburn Mecklermedia Magdalena Yesil CyberCash Sponsor: IBC USA Conferences Date: November 16 - 17 Venue: Pan Pacific Hotel 500 Post Street San Francisco EMAIL: questions or registrations skeyles(a)ibcusa.com Phone: 508.481.6400 ext 282 (Sherry)

1 0

Re: coding and nnet's
by Bill Stewart 17 Dec '03

17 Dec '03

At 02:17 PM 11/10/95 -0500, Atp3000(a)aol.com wrote: >I just resently got interested in coding and cryptography, and I was >wondering if you could suggest 3 or 4 papers that adresses the aplication of >neural networks in cryptography. 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.) 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. That's been my opinion of the issue as well; I looked into it a bit when I was doing a project with the neural net folks back at Bell Labs, partly because neural net chips typically have lots and lots of parallel bit-sized horsepower. Unfortunately, the horsepower isn't arranged in ways that are very useful for crypto; adding together a large bunch of short chunks of data (maybe using floating point addition) and thresholding the sum isn't the right thing to do with highly discontinuous functions. You could take a similar chip design and connect the pieces together differently to make a brute-force searcher, i.e. take a gate array and wire it to do crypto-like calculations, but the neural net stuff doesn't do that very efficiently. #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281

1 0

Re: Lotus Notes RSA Implementation Question
by eli＠GS160.SP.CS.CMU.EDU 17 Dec '03

17 Dec '03

In article <+cmu.andrew.internet.cypherpunks+kkcsTXG00UfAE0ynIq(a)andrew.cmu.edu> Charlie Kaufman writes: >Notes V3 (the one currently deployed) uses 512 bit RSA keys in both >the USA and exportable versions. 512-bit RSA is exportable? I'm surprised. It would be interesting to CJR a known-secure binary for 512-bit RSA, attempting a little differential cryptanalysis on the NSA's practices. A fair test would require that you have the political clout of Lotus/IBM, though. -- Eli Brandt eli+(a)cs.cmu.edu

1 0

Online ITAR and AECA; Bibliography of export control books
by John Gilmore 17 Dec '03

17 Dec '03

> > Where can one get a copy of ITAR ? Secondly , has anyone written any > > books on the subject and if so who and what? The ITAR is a regulation, not a law. You can find it via my crypto export control page at http://www.cygnus.com/~gnu/export.html under "State Department export guidance". Or at ftp://ftp.cygnus.com/pub/export/itar.in.full. It's 380 kbytes (but ignorance of it is no excuse!). That regulation is authorized by the Arms Export Control Act (AECA), a law (22 USC Sec. 2778). The law is also available in the same places. It's only 40 Kbytes. I own and can recommend several books on export controls. Layman's books on general export controls and technology policy issues: 90-26801: Finding common ground : U.S. export controls in a changed global environment / Washington, D.C. : National Academy Press, 1991. xviii, 390 p. : ill. ; 24 cm. LC CALL NUMBER: HF1414.5 .F56 1991 87-34877: Technology transfer : a policy model / Philip A. Roberts. Washington, DC : National Defense University Press, 1988. xiii, 86 p. ; 21 cm. LC CALL NUMBER: HC110.T4 R62 1988 SERIES TITLE: A National security essay DEWEY DEC: 338.973/06 dc19 93-50697: Silencing science : national security controls and scientific communication / Harold C. Relyea. Norwood, NJ : Ablex Pub., c1994. xvii, 248 p. ; 23 cm. LC CALL NUMBER: Q223 .R45 1994. SERIES TITLE: Information management, policy, and services. DEWEY DEC: 338.97306 dc20. ISBN: 156750096X; 1567500978 (pbk.) Lawyer's Tome on export controls, with detailed case citations and such: 91-37498: Root, William A. United States export controls / 3rd ed. Englewood Cliffs, NJ : Prentice Hall Law & Business, c1991- 1 v. (loose-leaf) : ill. ; 26 cm. ISBN: 0139529381 LC CALL NUMBER: KF1987 .L54 1990. DEWEY DEC: 353.0082/76 dc20 [This one is loose-leaf and gets annual updates at $80/year. I forget how much it cost originally.] By the way, if you're trying to find general references on export controls or crypto, or anything else, I recommend `telnet://locis.loc.gov' and searching the Library of Congress card catalog or the copyright records. The user interface is IBM mainframe oriented, but the information is without peer. John Gilmore

1 0

Re: coding and nnet's
by John Young 17 Dec '03

17 Dec '03

Bruce Schneier comments: Neural Networks Neural nets aren't terribly useful for cryptanalysis, primarily because of the shape of the solution space. Neural nets work best with 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.) Neural nets work well in structured environments where there is something to learn, but not in the high-entropy, seemingly random world of cryptography. "Applied Cryptography," second edition, 1996, p. 155.

1 0

Re: Exporting software doesn't mean exporting (was: Re: lp ?)
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

On Fri, 10 Nov 1995, Peter D. Junger wrote: > In any case, I want to thank him for doing so, because it brought home > to me the important fact that it is possible that the ITAR provisions > relating to cryptographic software could be struck down, not because > they violate the first amendment, or would violate it if passed by > congress, and not because the court is trying to dodge the difficult > first amendment issue, but simply because the provisions are not > authorized by any legislation. Hmmm, Peter actually has me worried. I actually _understood_ what he was talking about. And that has me worried. I guess that reviewing all that LIBOR financing documentation over ten years ago, when I was extending a helping hand to the CIBC helped. No one should ever attempt to figure out what happens when you have an American highrise owned by a private Canadian citizen, go into receivership with a syndicated Euro-financing while attempting a head lease to AT&T. An experience like that leaves you scarred for life. You actually learn to grok "lawyer speak". I guess that an interesting follow up occurs, if I perhaps muddy the chrystal clear waters of Peter's analysis. It relates to another thread on this list, the thread on time-release crypto and the economics of information. A hypothetical which might clarify by making things murky. If I ... as a foreign citizen ... a Canadian ... were to release an algorithm for time-release crypto to another Canadian ... another foreigner, could I actually be hauled down by the scruff of my neck to face US style "justice". Could I be deprived of our Canadian traditions of Napoleonic Code and of British Common Law, to face Americanism's. Does anyone from State have any clarification of this policy-shift?? I find it ridiculous to hear that if I load a series of messages into a fax machine, and instruct that machine to send out a series of documents at some set point in time -- and that if I were to *communicate* this method of time delay cryptographically secure communication to another Canadian citizen, that I could actually be hauled out of my own country and dragged across an international border to face charges of treason against a state to which I have no allegiance. This would be laughable, if it weren't so sinister. I mean, it's only a FAX machine ... for goodness sake's. Here I am as a Canadian citizen, a citizen of a sovereign State, a state which has historically been a friend of the American people. A State which has actually sacrificed its own international stature and the security of its citizens, to benefit Americans. (Most notably, when Canada rescued the hostages in Iran) and America repays the citizens of Ambassador Ken Taylor's home town how?? With an implied threat of making them subject to US law because its administratively convenient? Indeed. Can't anyone find acts of treason, a little closer to home?? Domestically maybe ... possibly even right under your nose ... > It's too far off topic to pursue any further, but I must take > exception to the suggestion that we are well served by separation of > powers intruding into other legal domains. Bowsher tells us that > causation principles go out the window in SOP cases. That alone > makes it radioactive. You ain't whistling Dixie. > I must admit that I don't know what it is that he is refering to. 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.

1 0

Re: [NOISE] DejaNews all over again--a URL for Usenet Searching
by Peter Trei 17 Dec '03

17 Dec '03

> I usually avoid passing on URLs of interesting sites, in the name of > conserving bandwidth (*), but this one really has me jazzed: > http://dejanews.com/ > It allows searching of Usenet archives (a few months' worth, from what I > can see). Unfortunately, it does not archive alt, soc, talk, or *.binaries (the latter is probably a blessing). Specialized news grepping is still useful - see http://www.iii.net/users/trei/usenet.html for an example. Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

1 0

Re: Yvette
by carolann＠censored.org 17 Dec '03

17 Dec '03

Just another Detweiler Tentacle...... Love Always, Carol Anne Tentaclefinder >> I'm wondering if Yvette from Smithfield, Va is as fine as most people say she >> is... -- Member Internet Society - Certified BETSI Programmer - Webmistress *********************************************************************** Carol Anne Braddock (cab8) carolann(a)censored.org 206.42.112.96 My Homepage The Cyberdoc *********************************************************************** ------------------ PGP.ZIP Part [017/713] ------------------- M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M MF=O0H+*%(-S%&>S%+FS&<LS%3(Q&#W1"<]2%`H^;,]^1C$'HBN8PX$4SYAU^ MPGD<Q0ZLA0D+,`MCT!LA**4M[-JPAK9F?40!AJ,CW"'%DR#:'9?Q)3[%<DQ` ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/

1 0

CFP: CARDIS 1996
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Found this in sci.crypt.research. Notice the name at the top of the program committee... Cheers, Bob Hettinga ___________________________________________ First Call For Papers CARDIS 1996 SECOND SMART CARD RESEARCH AND ADVANCED APPLICATION CONFERENCE September 18-20, 1996, Amsterdam, The Netherlands AIMS AND GOALS Smart cards or IC cards offer a huge potential for information processing purposes. The portability and processing power of IC cards allow for highly secure conditional access and reliable distributed information systems. IC cards are already available that can perform highly sophisticated cryptographic computations. The applicability of IC cards is currently limited mainly by our imagination; the information processing power that can be gained by using IC cards remains as yet mostly untapped and is not well understood. Here lies a vast uncovered research area which we are only beginning to assess, and which will have great impact on the eventual success of the technology. The research challenges range from electrical engineering on the hardware side to tailor-made cryptographic applications on the software side, and their synergies. Many currently existing events are mainly devoted to commercial and application aspects of IC cards. In contrast, the CARDIS conferences aim to bring together researchers who are active in all aspects of design of IC cards and related devices and environment, such as to stimulate synergy between different research communities and to offer a platform for presenting the latest research advances. CARDIS 1994, sponsored by the International Federation for Information Processing (IFIP) and held in November 1994 in Lille, France, has successfully brought together representatives from leading IC research centers from all over the world. CARDIS 1996 will be the second occasion for the IC card community in this permanent activity. CARDIS 1996 will be organised jointly by the Centre for Mathematics and Computer Science at Amsterdam (CWI) and the Department of Computer Systems of the University of Amsterdam (UvA). SUBMISSIONS Submissions will be judged on relevance, originality, significance, correctness, and clarity. Each paper should explain its contribution in both general and technical terms, identifying what has been accomplished, saying why it is significant, and comparing it with previous work. Authors should make every effort to make the technical content of their papers understandable to a broad audience. Papers should be written in English. Authors should submit: * 16 copies * of a full paper * typeset using the Springer LNCS format (see instructions below) * not exceeding 20 pages in length * printed double-sided if possible * addressed to Pieter H. Hartel Univ. of Amsterdam Dept. of Computer Systems Kruislaan 403 1098 SJ Amsterdam The Netherlands In addition, each submission should be accompanied by information submitted via WWW, (http://www.cwi.nl/~brands/cardis/submit.html) or submitted via email to cardis(a)fwi.uva.nl that consists of: * a single postal address and electronic mail address for communication * complete title, author and affiliation information * the abstract of the paper * a small selection of the keywords that appear on this call for papers, which best describe the contribution of the paper Proceedings will be available at the conference. It is intended to publish the proceedings in the Springer LNCS series. Authors of accepted papers may be expected to sign a copyright release form. IMPORTANT DATES Submission deadline March 1, 1996 Acceptance notification May 15, 1996 Camera ready paper due July 1, 1996 Conference September 18--20 1996 THEMES Technology/hardware 1 IC architecture and techniques 2 Memories and processor design 3 Read/Write unit engineering 4 Specific co-processors for cryptography 5 Biometry 6 Communication technologies 7 Interfaces with the user, the service suppliers 8 Reliability and fault tolerance 9 Special devices 10 Standards Software 11 The operating system 12 Models of data management 13 Communication protocols IC Card design 14 Tools for internal or external software production 15 Validation and verification 16 Methodology for application design Electronic payment systems 17 Road pricing 18 Internet payment systems 19 Untraceability Algorithms 20 Formal specification and validation 21 Identification 22 Authentication 23 Cryptographic protocols for IC cards 24 Complexity Security 25 Models and schemes of security 26 Security interfaces 27 Hardware and software implementation 28 Security of information systems including cards 29 Formal verification of transaction sets 30 Protocol verification IC Cards, individuals and the society 31 IC cards and privacy 32 Owner access of data 33 IC cards: political and economical aspects 34 Is the IC card going to change legislation? 35 Patents, copyrights Future of ic cards 36 Innovative technologies 37 Moving towards the pocket intelligence 38 Convergence with portable PCs, lap tops etc ... 39 PCMCIA Innovative applications 40 Design methodology of applications 41 IC cards and the information system 42 Examples of new applications 43 Requirements for innovative cards Standards 44 Emerging standards 45 Compliance and approval ORGANISATION Steering committee chairman: Vincent Cordonnier (Rd2p, Lille) Local organisation: Pieter Hartel (Southampton, UK and UvA, The Netherlands) Stefan Brands (CWI, The Netherlands) Eduard de Jong (QC consultancy, The Netherlands) General Chairman: Pieter Hartel (Southampton, UK and UvA, The Netherlands) Program Chairmen: Pierre Paradinas (Rd2p, Lille) Jean-Jacques Quisquater (Louvain-la-Neuve, Belgium) Program committee Stefan Brands (CWI, Amsterdam) Andr\'e Gamache (Qu\'ebec, Canada) Louis Guillou (CCETT, France) Josep Domingo Ferrer (Tarragon, Spain) Pieter Hartel (Southampton, UK and UvA, The Netherlands) Hans-Joachim Knobloch (Karlsruhe, Germany) Pierre Paradinas (Rd2p, France) Reinhard Posch (Graz, Austria) Jean-Jacques Quisquater (Louvain-la-Neuve, Belgium) Matt Robshaw (RSA, inc, USA) Bruno Struif (GMD, Germany) Doug Tygar (Carnegie-Mellon, USA) LECTURE NOTES IN COMPUTER SCIENCE Advice to Authors for the Preparation of Camera-Ready Contributions to LNCS/LNAI Proceedings The preparation of manuscripts which are to be reproduced by photo-offset requires special care. Manuscripts which are submitted in technically unsuitable form will be returned for retyping or cancelled if the volume otherwise cannot be finished on time. In order to make the volume look as uniform as possible the following instructions should be followed closely. ************ * PRINTING AREA: Using 10-point font size for the main text the printing area should be 12.2 x 19.3 cm. Manuscripts prepared in this preferred format are reproduced in the same size in the book. With these settings, the interline distance should be arranged in such a way that some 42 to 45 lines occur on a full-text page. * TYPEFACE and SIZE: We recommend the use of Times or one of the similar typefaces widely used in phototypesetting. (In Times and similar typefaces the letters have serifs, i.e., short endstrokes at the head and the foot of letters.) Please do not use a sans-serif typeface for running text, except for computer programs. The text should always be justified to occupy the full line width, so that the right margin is not ragged. For normal text please use 10-point type size and one-line spacing. Small print (abstract and affiliation) should be set in 9-point type size. Please use italic print to emphasize words in running text; bold type in running text and underlining should be avoided. Headings should be capitalized (i.e., nouns, verbs and all other words with at least five letters should have a capital initial) and should, with the exception of the title, be aligned to the left. The font sizes are as follows: ************ Heading level Example Font size and style Title (centered) Type Theory 14 point, bold 1st-level heading 1 Introduction 12 point, bold 2nd-level heading 2.1 Simple Connections 10 point, bold 3rd-level heading Typing Rules. 10 point, bold 4th-level heading Remarks: (text follows) 10 point,italic ************ * FIGURES: If possible, originals should be pasted into the manuscript and centered between the margins; if no originals of the required size are available, figures may be reduced in scale and pasted into the text. For halftone figures (photos), please forward high-contrast glossy prints and mark the space in the text as well as the back of the photographs clearly, so that there can be no doubt about where or which way up they should be placed. The lettering of figures should be in 10-point font size. Figures should be numbered. The legends also should be centered between the margins and be written in 9-point font size as follows: (bold) Fig. 3. (text follows) * PAGE NUMBERING: Your paper should show no printed page numbers; they are decided by the volume editor and finally inserted by the printer. Please indicate the ordering of your pages by numbering the sheets (using a light blue/green pencil) at the bottom of the reverse side. There also should be no running heads. * PRINTING QUALITY: For reproduction we need sheets which are printed on one side only. Please use a high-resolution printer, preferably a laser printer with at least 300 dpi or higher resolution if possible. It is desirable that on all pages the text appears in the middle of the sheets. * REMARK 1: If your typesetting system does not offer the variety of font sizes needed for the preparation of your manuscript according to these instructions, you may choose a different (larger) font size and a correspondingly scaled printing area (12-point font size for the running text, for example, corresponds to a printing area of 15.3 x 24.2 cm and to a final reduction rate of 80%). * REMARK 2: You are encouraged to use LaTeX or TeX for the preparation of you camera-ready manuscript together with the corresponding Springer style files "llncs" (for LaTeX) or "plncs" (for TeX) to be obtained by e-mail or by ftp/gopher as follows: Mailserver: Send an e-mail message to svserv(a)vax.ntp.springer.de containing the line get /tex/latex/llncs.zip for the LaTeX syle files or get /tex/plain/plncs.zip for the TeX style files. Sending "help" to the server prompts advice on how to interact with the mail server. The style files have to be unzipped and uu-decoded for use. In case of problems in getting or uu-decoding the style files please contact "springer vax.ntp.springer.de". Ftp: The internet address is "trick.ntp.springer.de", the user id "ftp" or "anonymous". Please enter your e-mail address as password. The (above mentioned) files reside in "/pub/tex/latex/llncs". Gopher: Point your client to "trick.ntp.springer.de". ----------------- 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