December 2003 - cypherpunks-legacy

Re: Patents to be placed in PD
by L. Todd Masco 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- A number of people have asked me what SKIP is. IBM's patent covered modular key management in a manner that isn't clear to me. SKIP is Simple Key management for Internet Protocols: it's an elegant key management system that uses Diffie-Hellman public keys (Aziz notes that any DH-like scheme will work). The IPsec folks wanted (or just were considering it?) to use it in their secure IP work, but were balking at the patent status. Here's how to get the draft (I don't understand it well enough yet to do it justice in a summary) : - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Protocol Security Protocol Working Group of the IETF. Title : Simple Key-Management For Internet Protocols (SKIP) Author(s) : A. Aziz Filename : draft-ietf-ipsec-aziz-skip-00.txt Pages : 17 Date : 10/26/1994 There are occasions where it is advantageous to put authenticity and privacy features at the network layer. The vast majority of the privacy and authentication protocols in the literature deal with session oriented key-management schemes. However, many of the commonly used network layer protocols (e.g IP and IPv6) are session-less datagram oriented protocols. We describe a key-management scheme that is particularly well suited for use in conjunction with a session-less datagram protocol like IP or IPv6. We also describe a simple extension of this protocol to provide scalable group key-management for Internet multicasting protocols. SKIP is designed to be plugged into the IP Security Protocol (IPSP) or IPv6. This draft describes how to use SKIP in the context of the IPSP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-ipsec-aziz-skip-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv(a)ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-aziz-skip-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts(a)cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv(a)ds.internic.net" Content-Type: text/plain Content-ID: <19941026102713.I-D(a)CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-aziz-skip-00.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-aziz-skip-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941026102713.I-D(a)CNRI.Reston.VA.US> - --OtherAccess-- - --NextPart-- - --- [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 iQBFAwUBLuS0XioZzwIn1bdtAQHJzQGA0MVuRr2weN8u058zZD0wzkjTtYadtYiH Ybgztk2dRevg44wvwYSHOgn6+qFYh7Pa =M7Om -----END PGP SIGNATURE-----

2 1

MacPGP
by norm＠netcom.com 17 Dec '03

17 Dec '03

Does anyone know of a manual for the Mac PGP 2.6? I can find the functions that I need in the command line interface manual but then it is unclear how to get excatly that function thru menu selections. The command R function reads commands from a file. It is awkward and keeps warning you that it is buggy. I can imagine writing such a manual but before I know the answers it would be inaccurate and after I know the answers it would seem superflous.

1 0

Ride to CP meeting request
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

If anyone is headed to this month's meeting from San Francisco and has a seat they'd like to let me occupy, please email me. -carless in SF

1 0

Ho, Ho, Ho
by gnu 17 Dec '03

17 Dec '03

Forwarded-by: Mike Godwin <mnemonic(a)eff.org> From: "Eugene Volokh" <VOLOKH(a)law.ucla.edu> You'd better watch out, You'd better not cry, You'd better not pout; I'm telling you why. Santa Claus is tapping Your phone. He's bugging your room, He's reading your mail, He's keeping a file And running a tail. Santa Claus is tapping Your phone. He hears you in the bedroom, Surveills you out of doors, And if that doesn't get the goods, Then he'll use provocateurs. So--you mustn't assume That you are secure. On Christmas Eve He'll kick in your door. Santa Claus is tapping Your phone. [Supposedly written for and sung at a US Department of Justice, Office of Legal Counsel Christmas party during the Carter administration.] -- Eugene Volokh, UCLA Law

1 0

core dumps with pgp-elm
by shawn leas 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Anybody else get this problem?? I've tried all sorts of different things. Compiles fine, runs fine w/out pgp options, but crashes like a stone when I use them. Segmentation violation. That sucks! -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLuTgGaZRyOzqm29xAQHIsgP9Hw2Wq84gOZ3sCx0qzVQAYY9JimC1/avD 6YMFEL3cRv0KhVeFV1gNKB7DC1wmypstoVTgcy9xiGZdxXvzQ6/dmrqmpWzt2+Fi GscQMUVHNfi18pX5X+8gjbZpDfD28tc6XW1gPDP5150n1pngTUQ7HXMcqJIxklj3 DmcP3W3+qAo= =YO8U -----END PGP SIGNATURE-----

1 0

RE: MMB question
by John Young 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Responding to msg by cactus(a)hks.net ("L. Todd Masco") on Tue, 6 Dec 1:23 PM >And: are the errata available on-line anywhere? Sounds >like a very >worthwhile thing to have. Applied Cryptography states on the inner flyleaf: Errata -- A list of the errors found in this book along with corresponding corrections is updated periodically. For the most recent electronic version, send email to: schneier(a)chinet.com For the most recent printed version, send a stamped, self-addressed envelope to: AC Corrections Counterpane Systems 730 Fair Oaks Avenue Oak Park, IL 60302 Readers are encouraged to distribute electronic or printed versions of this list to other readers of this book. - --- [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 iQBFAwUBLuTiJyoZzwIn1bdtAQGIBAGA2HKGp+3qSsythB5es+QE0lmxrEuc3kKs zMcBE+OoYdR+yofyFPKBxUGU1Z3w8ZQM =27st -----END PGP SIGNATURE-----

1 0

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

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- bshantz(a)spry.com writes: > 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? More or less. It doesn't need to implement everything straight off: the API itself just has to pass all the information that's necessary. > >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 Actually, I'm not talking about implementing the library in a multi-platform way. Once the API is specified, people could be found who would do the implementation for any given platform. I'd do a UNIX version that would straight off translate appropriate calls to RSAREF for RSA calls and implement IDEA. A friend of mine is interested in doing the PC version . > 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.) Encryption is a pretty straightforward process in the abstract: While such an API might not be well suited to hyper-fast stream methods, it would be Good Enough to have something that could be integrated into mail and news easily. News and mail are doing the same thing: a big part of the difficulty in getting integrated support is in the cumbersome interface to PGP and the percieved short horizon on PGP changes. If a unified API promised that a crypto API would stay put, I think more people would be hacking code. I'm not talking about implementing it all at once. In essence, a PGP engine that used these calls would be useful because people could implement MUAs and newsreaders (and perhaps web browsers) that easily integrated PGP encryption by linking with the newest version of the PGP distribution: and then, as newer methods and formats came along, all that would be required would be a relink to support new formats (another function, BTW, would be a guc_parse_format() that would determine the format of the input). > >(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? Only the spec itself need be exported, no crypto code or even hooks. RSAREF would have to be part of the RSA methods inside the US: outside, it would probably end up being the old PGP code that the current 2.6ui-style PGPs use. > 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. Certainly, some APIs are much better than others. The C stdlib, for example, is a pretty good API. Stdio does a very good job of abstracting concepts to calls that work across filesystems as different as VMS's RMS and MS-DOS filesystems. I'm talking about C -- not every platform supports C++. The OS isn't important: the API can be implemented independently. > 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. Frankly, I don't give a damn about it becoming an "idustry standard" if that means Microsoft, Lotus, etc. I have no interest in doing their work for them. I'm more interested in generating a "net-standard," something that people hacking code for themselves or for freely-distributable packages can use. It's a necessary step along the road to "crypto for the masses." - -- 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 iQBFAwUBLuTkJioZzwIn1bdtAQFEhwF7Bo0K7ZwWDlYtaB46B4kpwOM/jXY0pLrT Q/y84MBu6Z7nwt75X+r0Y93rpBon1QQh =VWmR -----END PGP SIGNATURE-----

1 0

Re: Dec. 10th Bay Area Cypherpunks Meeting
by L. McCarthy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- Ian Farquhar writes: > On Dec 5, 10:28pm, KT Kislitzin wrote: > > This month's Bay Area Cypherpunks Meeting will be held this Saturday, > There isn't a chance that this could either be taped or broadcast, is there? It would be really nice if someone could post minutes/notes from this. - -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBLuTh7Gf7YYibNzjpAQF6nQQAu0dzcPgRtte2N1mANQ8vCj/3R4WjJcLb YsjKuJcSG7ZRLE0ERk0EAR9XUPZuOhTWmMAu0BiTOaVmNkhFNARdv/IKxOrOAWU9 1Xqr5RtP4pJabfDWGND6UFtMpLimHMbdMcy8wHmMnm4XykZcQNG3PwMCymtSqQ3L zDEGiahe7ac= =AF6W - -----END PGP SIGNATURE----- - --- [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 iQBFAwUBLuTkYioZzwIn1bdtAQGl3AGA0N77HqZuchnssElxWGrDygPX4qLb3F1J Cd2dMlY5XYmAKCwyvocol+e5j/oQ3B/M =XLJD -----END PGP SIGNATURE-----

1 0

Re: GUCAPI (Grand Unified Crypto API)
by JEFF LICQUIA (CEI) 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > From: "L. Todd Masco" <cactus(a)hks.net> > 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. Here's a few random thoughts: Perhaps we could split the functions into groups according to the purpose of the group. Thus, key generation protocols would be in one group, encryption in another, decryption in another, file I/O routines in another, and so on. This would seem to encourage a more modular approach. It would provide an additional level of abstraction as well; you could implement higher-level actions in terms of lower-level ones. For example, you could implement "PGP-encrypt" in terms of calls to RSA-specific and IDEA-specific functions; from the point of view of the application, however, raw RSA and "PGP-style" encryption would look like two separate implementations of the same API. It could also facilitate certain other types of apps; for example, if we had a "key management" API and implementations of the API for PGP keys and PEM keys, we could easily construct an app that could PGP-encrypt with PEM keys and vice versa. Not to be an OO bigot or anything, but I would implement these as object groups, with the parents defining the API and the children implementing it. As an example, consider this "Key" hierarchy: Key / \ PubKey PrivKey - -> / / \ RSAKey DESKey IDEAKey / \ PGPKey PEMKey The arrow indicates the drawing line between definition and implementation classes. Note the common heritage of PGPKey and PEMKey with RSAKey; this could be used as a mechanism for converting between keys if RSAKey were implemented as a "raw" key, while PGPKey and PEMKey could include other key-specific baggage such as userIDs, attached certificates, etc. Supposedly, then, key management and other stuff could be made specific to the key type, but encrypting and decrypting could consist of a simple: Boolean RSAencrypt(char *message, RSAKey &key); (to use C++ language - substitute your own OOL if desired) and could then use either key format for its dirty work. Of course, this is simplistic, as the encryption engine itself would probably be an object also, etc., etc. There's some very rough ideas! They're in bad need of clarification; let 'em have it! -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLuTj6DER5KvPRd0NAQE2yAP/dqcaHUXa9UrGpGxWOg+8xs2/AhCh0TS6 0Cca76O6Ztc/vzEpBdz1iAMVa/N7DDybwTHR+wgTPjBEKoy1vqMjSPZpEk2Zwhpy 8EgQvGOHInJrMdlWssEZWn8Av1tSaYJtNrtDV2hTEB9pZSzhIi1T257gqjSrnHks mH3qT0tQTjg= =AXya -----END PGP SIGNATURE-----

1 0

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

17 Dec '03

JEFF LICQUIA (CEI) <JLICQUIA(a)mhc.uiuc.edu> writes: >Not to be an OO bigot or anything, but I would implement these as object >groups, with the parents defining the API and the children implementing >it. As an example, consider this "Key" hierarchy: > Key > / \ > PubKey PrivKey > / / \ > RSAKey DESKey IDEAKey > / \ > PGPKey PEMKey Great Idea!!! I hadn't pictured it this way. My first impresssion was completely wrong and I apologize. Now that I understand and have had a few minutes to think about this. It does look pretty good. Now, about shipping the spec outside the States. Not a problem. We just couldn't ship code or an executable outside the States. This really is a plausible idea. Brad >>>>>>>>>>>>>>>>>>>>>INTERNETWORKING THE DESKTOP<<<<<<<<<<<<<<<<<<<<<<< Brad Shantz bshantz(a)spry.com Senior 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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

1 0