December 2003 - cypherpunks-legacy

GUCAPI (Grand Unified Crypto API)
by L. Todd Masco 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I've been thinking a lot recently about how to implement a generic API for crypto such that the interface could be independent of the cipher used. What I'm thinking of is something like: guc_init_crypto(); guc_encrypt(); guc_decrypt(); guc_assemble(); guc_key_get(); guc_key_put(); guc_key_gen(); So, to encrypt a PGP-style message, you'd: guc_init_cypto("PGP_26", &context, &keys, &message ); Which would initialize whatever random vectors you're likely to need for a PGP session and allocate the appropriate space to the pointers. The types should be totally opaque, implemented in the library. guc_key_gen("PGP_26", &keys); Which would generate a session key for IDEA and grow the keys structure appropriately; guc_get_key("PGP_26", &keys, originator); guc_get_key("PGP_26", &keys, recipient1); guc_get_key("PGP_26", &keys, recipient2); ... Which would grow the keys structure and add in appropriate RSA keys. (Alternatively, it could be done as one vector with all the recipients lists). guc_encrypt("PGP_26", &keys, &input, &message); Which would encrypt the IDEA session key with the appropriate RSA key and the input with the IDEA session key. And, guc_seal("PGP_26", &message, &output); Which would put the messages into the appropriate (Radix-64?) format and put it out to the output, (the output structure would specify whether memory is to be allocated and filled, files written to, whatever). My goal is to come up with an API that could be integrated once into an application and would be flexible enough that new crypto methods, whether ciphers or key management, could be supported entirely by upgrading the library. This includes being flexible enough to cover as diverse methods as OTPs (where the init function would open a file or other pad as its "random vector," key retrieval would be a noop, and encode would just XOR) and PEM (key management would be done on the basis of the method specified. I'm fuzzy on how to generalize key management into a model that would include both web-of-trust and PEM-style certificates, so conversation on this would be greatly appreciated). It seems to me that the benefits are pretty clear: Set up such an API as a spec that can be implemented both inside and outside of the US and it allows everybody to implement to one API. There's no good reason to have a bazillion different crypto APIs if a generalized one can be achieved. I've posted about this before and received no response: since I'd like to solidify the API soon so I can firm up the coding I'm doing, I ask that folks take the time to comment. The code I end up producing will be publicly available, possibly as a "non-commercial use" copyright, perhaps PD. Thoughts? - -- Todd Masco | "'When _I_ use a word,' Humpty-Dumpty said, in a rather cactus(a)hks.net | scornful tone, 'it means just what I choose it to mean - cactus(a)bb.com | neither more nor less.'" - Lewis Carroll - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLuTVNCoZzwIn1bdtAQFK1AGA16g1wgKMc4qg3SVxDMW3y+1IGeWDbVvj Q6uqlRmyaFNm1NjNfV0gCxZgAZ9oM338 =br4C -----END PGP SIGNATURE-----

2 1

CIAC Notes 94-04
by Karyn Pichnarczyk 17 Dec '03

17 Dec '03

U.S. DOE's Computer Incident Advisory Capability ___ __ __ _ ___ __ __ __ __ __ / | /_\ / |\ | / \ | |_ /_ \___ __|__ / \ \___ | \| \__/ | |__ __/ Number 94-04 December 6, 1994 ------------------- A - T - T - E - N - T - I - O - N ------------------- | CIAC is available 24-hours a day via its two skypage numbers. To use | | this service, dial 1-800-759-7243. The PIN numbers are: 8550070 (for | | the CIAC duty person) and 8550074 (for the CIAC manager). Please keep | | these numbers handy. | ------------------------------------------------------------------------- Welcome to the fourth issue of CIAC Notes! This is a special edition to clear up recent reports of a "good times" virus-hoax. Let us know if you have topics you would like addressed or have feedback on what is useful and what is not. Please contact the editor, Allan L. Van Lehn, CIAC, 510-422-8193 or send E-mail to ciac(a)llnl.gov. $-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$ $ Reference to any specific commercial product does not necessarily $ $ constitute or imply its endorsement, recommendation or favoring by $ $ CIAC, the University of California, or the United States Government.$ $-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$ THE "Good Times" VIRUS IS AN URBAN LEGEND In the early part of December, CIAC started to receive information requests about a supposed "virus" which could be contracted via America OnLine, simply by reading a message. The following is the message that CIAC received: --------------------------------------------------------------------------- | Here is some important information. Beware of a file called Goodtimes. | | | | Happy Chanukah everyone, and be careful out there. There is a virus on | | America Online being sent by E-Mail. If you get anything called "Good | | Times", DON'T read it or download it. It is a virus that will erase your | | hard drive. Forward this to all your friends. It may help them a lot. | --------------------------------------------------------------------------- THIS IS A HOAX. Upon investigation, CIAC has determined that this message originated from both a user of America Online and a student at a university at approximately the same time, and it was meant to be a hoax. CIAC has also seen other variations of this hoax, the main one is that any electronic mail message with the subject line of "xxx-1" will infect your computer. This rumor has been spreading very widely. This spread is due mainly to the fact that many people have seen a message with "Good Times" in the header. They delete the message without reading it, thus believing that they have saved themselves from being attacked. These first-hand reports give a false sense of credibility to the alert message. There has been one confirmation of a person who received a message with "xxx-1" in the header, but an empty message body. Then, (in a panic, because he had heard the alert), he checked his PC for viruses (the first time he checked his machine in months) and found a pre-existing virus on his machine. He incorrectly came to the conclusion that the E-mail message gave him the virus (this particular virus could NOT POSSIBLY have spread via an E-mail message). This person then spread his alert. As of this date, there are no known viruses which can infect merely through reading a mail message. For a virus to spread some program must be executed. Reading a mail message does not execute the mail message. Yes, Trojans have been found as executable attachments to mail messages, the most notorious being the IBM VM Christmas Card Trojan of 1987, also the TERM MODULE Worm (reference CIAC Bulletin B-7) and the GAME2 MODULE Worm (CIAC Bulletin B-12). But this is not the case for this particular "virus" alert. If you encounter this message being distributed on any mailing lists, simply ignore it or send a follow-up message stating that this is a false rumor. Karyn Pichnarczyk CIAC Team ciac(a)llnl.gov ------------------------------ Contacting CIAC If you require additional assistance or wish to report a vulnerability, call CIAC at 510-422-8193, fax messages to 510-423-8002 or send E-mail to ciac(a)llnl.gov. For emergencies and off-hour assistance, call 1-800-SKY-PAGE (759-7243) and enter PIN number 8550070 (primary) or 8550074 (secondary). The CIAC Duty Officer, a rotating responsibility, carries the primary skypager. The Project Leader carries the secondary skypager. If you are unable to contact CIAC via phone, please use the skypage system. ------------------------------ This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. ------------------------------ End of CIAC Notes Number 94-04 94_12_06 ****************************************

1 0

Re: GUCAPI (Grand Unified Crypto API)
by maschino＠phx.sectel.mot.com 17 Dec '03

17 Dec '03

(This is my first attempt at posting, please excuse any errors, and I do not yet have PGP on my employer-owned machine) > I've been thinking a lot recently about how to implement a generic API for > crypto such that the interface could be independent of the cipher used. > What I'm thinking of is something like: There are numerous industry groups working on a "security" API, including Microsoft, Novell, Motorola, Intel, etc. Major focus is transparent (to the user) security (encryption, KCA, signatures, etc) for email, local and remote file access, generalized and integrated telephony, and so forth. Of course, there are many approaches, generation by committee, personal and corporate biases, and other garbage to get in their way. What may be interesting is to look at their proposed security APIs and glean interesting ideas to be incorporated into your API. Some ideas on effective APIs: - the process of encryption/decryption, signaturing, etc should be independent of the destination/source of the data. The same API should be able to process a file, an e-mail message, an inter-process control message, etc. The API does not care what the data is from or for, it just operates on it. Of course, the API should be able to process in the various encryption modes, and may have to discriminate between a continuous flow of data and a finite size of data. - API's at this level must NEVER directly utilize the User Interface (regardless of whether the UI is graphical or textual). It should be completely irrelevant to the API whether it was invoked by an actual user, a local system process, or a remote system process. Return and error conditions are returned to the caller, which then decides what to do with the erroneous result. Error traps are acceptable too, though the trap should allow the "trapper" to decide what to do about notification or handling of the error. Of course, you recognize the hardest API is key management. Use some data and/or object modeling techniques to handle the two basic senarios and see if you can generalize it sufficiently. I have no idea about how to get the group's proposed API's. There has been several mentions in the networking trade papers about them though. Windows 95 and NT WILL have a security API based in part on the existing one worked out with Novell. Of course, security is a local issues as well as a networking or messaging issue, so I doubt their implementation will be thorough. Hope this is of some help. - Mike ***************************************************************************** Mike Maschino Email: Mike_Maschino-P17960(a)email.mot.com Motorola | "I am not speaking for my employer, Government and Systems Technology Group | and they do not speak for me" Scottsdale, AZ, USA | "Neuro-encrypto-psycho-telco-photo-proto-nympho-lego <g>-maniacs wanted by same; applications available; god-like entities always welcome" *****************************************************************************

1 0

Re: GUCAPI (Grand Unified Crypto API)
by L. Todd Masco 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Derek Atkins writes: > Why do all this? There already exists a Generic Security System API, > GSSAPI, which is an Internet standard (or there is at least an Internet > Draft -- I'm not sure what the current status is right now, and given > that the IETF is going on this week, it's status may change). Ah, I knew of the GSSAPI's existence but hadn't realized that its scope included what I wanted. I'll read the draft on the internic and see if it does what I want. If so, the next logical step is to wrap RSAREF in it and to make a PGPish-wraparound. I'd certainly be up to the former; Would anybody else be interested in ponying up their time and effort for the PGP instance? (The draft is ftpable from ftp.internic.net, /internet-drafts/draft-ietf-cat-gssv2-00.txt) - -- Todd Masco | "'When _I_ use a word,' Humpty-Dumpty said, in a rather cactus(a)hks.net | scornful tone, 'it means just what I choose it to mean - cactus(a)bb.com | neither more nor less.'" - Lewis Carroll - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLuT4LCoZzwIn1bdtAQHh9wF/TyMkm4Cd0gFzk26mdufgytY6NnHfiT3C heS9ACR9d8jwS2pu8/wvF84+sQs0nTEc =bY6Z -----END PGP SIGNATURE-----

2 1

Successful use of e-cash!
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

I just made my first e-cash transaction. Using, SLIP and Netscape, I webbed to HotWired to uy a sneak preview of Bruce Sterling's Prague story to appear in the Jan issue for 0.50 cyberbucks. At the same time, I ran the e-cash client (for Windows) from DigiCash. It has a beautiful interface - just a few little icons visible on the screen; it went to the back, asked me for my password to open my account, found out what my balance was, and asked me whether I wanted to withdraw $10 from the total of $100. I said yes. Meanwhile I asked HotWired to send me the Sterling piece. Unfortunately it was too quick - it came in on port (something) before the e-cash client had filled my wallet; I tried again at HotWired, by which time the e-cash status showed $10. My cyberwallet made a nice clanging sound, asked me whether I wanted to pay "Wired Ecash Shop" $0.50, and whether I wanted to set a payment policy. I'm so smart - I told the client to automatically pay "Wired Ecash Shop" if it asked for less than $2 up to 10 times. Ouch! Now I can't go back up my Web trail! When I went one step back at HotWired, for some reason it ran the e-cash 'charge?' URL, and so 'clang' went my wallet and automatically deducted another 50c! Oops. Oh well, the whole experience was worth a whole cyberdollar. I also 'bought' Chaum's SciAm article, and got the reasonable lengthy list of shops. Then I noticed it was 4 in the morning... Rishab "We know everything about you that we need to know" - Coleta Brueck, IRS ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "In between the breaths is rishab(a)dxm.ernet.in the space where we live" rishab(a)arbornet.org - Lawrence Durrell Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

NYT on N2 and Star Wars
by John Young 17 Dec '03

17 Dec '03

Some cries of no-gets of N2_duh and RAY_dem. N=N lobbed by 8 PM EST. No get, retry. Frantic PBM sez excuse this msg.

1 0

Re: GUCAPI (Grand Unified Crypto API)
by cactus＠seabsd.hks.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <199412070014.AA13652(a)sequoia.itd.uts.EDU.AU>, Matthew Gream <M.Gream(a)uts.EDU.AU> wrote: >Ohh, I misinterpreted. You're talking about a high level interface that >assumes cryptographic operations are already being used for specific >purposes (ie. `signature', `GetMIC', `VerifyMIC', `Wrap', `Unwrap'). > >I was thinking more about the layer below this, the primitive operations >that don't make assumptions on what the user is going to do; and >limitations placed thereupon. Actually, both interfaces are reasonable for the scope of this discussion. I don't have specific goals in mind yet: I want to bounce around ideas before coming up with something more specific. The GSSAPI has the advantage that Kerberbos services have already been provided for that API: There's no reason, however, that the two goals need to be mutually exclusive. I'll have to read the GSSAPI doc carefully and get a sense of what problems it solves. >I found >out yesterday that I've taken out a prize for the best work conducted >by someone under the age of 26. There is a certain irony in being >awarded the prize by a Government department :-). Nevertheless, congratulations! - -- Todd Masco | "'When _I_ use a word,' Humpty-Dumpty said, in a rather cactus(a)hks.net | scornful tone, 'it means just what I choose it to mean - cactus(a)bb.com | neither more nor less.'" - Lewis Carroll - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLuUhSyoZzwIn1bdtAQFmRwF7BtmxdCQCHirWle87iUsqz2GnCt+dSvCR JzONMasccbF08lWnfRc0ACAQNyQIfEkD =L3dn -----END PGP SIGNATURE-----

1 0

Re: backing ecash
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 10:47 PM 12/06/94, Paul Ste. Marie wrote: >Isn't there a problem with net-based distribution of ecash? It would >seem that Eve could intercept the ecash and spend it first. Encrypted >email return of the ecash would seem to violate the anonymity of the >ecash. Some sort of one-time encrypted return address would seem to >be necessary, but better yet would be a vending machine that took a >floppy disk and some currency and stuck the ecash on the floppy. Diffie-Hellman would seem appropriate here. Look it up in Schneier. Vending machines seem a good idea too, but one unlikely to develop any time soon. Or possibly ever, if the net becomes so prevalent that no one would think of doing anything offline that could just as well be done online.

1 0

Re: GUCAPI (Grand Unified Crypto API)
by bshantz＠spry.com 17 Dec '03

17 Dec '03

L.Todd Masco <cactus(a)hks.net> writes: >I've been thinking a lot recently about how to implement a generic API for >crypto such that the interface could be independent of the cipher used. So, you just want a generic overlay (wrapper) to any of the existing encryption algorithms? Is this correct? >My goal is to come up with an API that could be integrated once into an >application and would be flexible enough that new crypto methods, whether >ciphers or key management, could be supported entirely by upgrading the >library. This includes being flexible enough to cover as diverse >methods as OTPs ... Well, it sounds good in theory. However, trust me, Todd, writing a generic API that is multi-platfomr is not necessarily as easy as it sounds. There's alot of code in this prioject. You would also have to make sure that the API is generic so it could work in ANY program that might use encryption or digital signatures. (i.e. e-mail, USENET news, possibly even lending itself to a Secure HTTP implementation.) >(key management would be done on the basis of the method specified.) Uh, just from a first glance, I'd say that this is going to slip gently into the ITAR pits. There are very few "methods" other than RSAREF that you could use to make this "universal". Also, would this act as a wrapper over PGP, or would it use the same concepts (and or code) to do the same things? >It seems to me that the benefits are pretty clear: Set up such an API >as a spec that can be implemented both inside and outside of the US and >it allows everybody to implement to one API. There's no good reason to >have a bazillion different crypto APIs if a generalized one can be >achieved. Agreed, it would be nice to have one API. As a developer though, I panic when I see "generic" API's. Usually, they are not as "black-box" as people would like to believe. What I mean is, usually they are not just as simple as "put in this input, and you will get this output." Also, are we talking about C code or C++ code? DOS? Windows? Are we talking multi-platform code that will work on all the major OS's? For a generic API, that's alot of code...I keep saying that....must mean something. I would be interested in seeing something like this implemented, but I question whether it will be a hit as an industry standard. Generic API's really haven't gone over well for things in the past. (Except the class libraries for major C++ compilers. MFC, OWL, etc.) The design has to be robust before you start coding. Anyone else have any comments? Brad >>>>>>>>>>>>>>>>>>>>>INTERNETWORKING THE DESKTOP<<<<<<<<<<<<<<<<<<<<<<< Brad Shantz bshantz(a)spry.com Software Engineer SPRY Inc. Direct #: (206)-442-8251 316 Occidental Ave. S. Main #: (206)-447-0300 Suite 316 Fax #: (206)-447-9008 Seattle, WA 98104 WWW URL: http://WWW.SPRY.COM ---------------------------------------------------------------------- PGP Public Key at: http://www-swiss.ai.mit.edu/~bal/pks-toplev.html Or email: pgp-public-keys(a)pgp.ai.mit.edu Subj: GET bshantz >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

3 2

Re: crypto email to France
by Rich Salz 17 Dec '03

17 Dec '03

Have your French office contact the American Consulate as a way of getting started. I believe the short and effective (albeit not 100% correct) answer is\ that digital privacy is not allowed unless you give the gov't the keys. /r$

1 0