December 2003 - cypherpunks-legacy

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

Announcing - The DigitaLiberty Forum
by root＠phantom.com 17 Dec '03

17 Dec '03

PLEASE RE-DISTRIBUTE THIS AS YOU SEE FIT Friends of Liberty, It is becoming increasingly apparent that the arrival of cyberspace is destined to engender a fundamental discontinuity in the course of human relations. This is a source of great optimism and opportunity for those of us who believe in freedom. Many of you who participate in the lively debates that take place in these forums have seen a number of activist organizations spring up claiming to represent the cause of freedom. And if you are like me you have cheered these groups on only to watch them get bogged down in a quagmire of realpolitics. It is a sad fact that the beast in Washington has evolved into a self-perpetuating engine expert at co-opting the principles of even the most ardent reformers. Slowly but surely all those who engage the system are ultimately absorbed into the mainstream miasma of majoritarianism. For example, what can be more discouraging than watching an organization that started out as a cyber-civil liberties group shift its focus to creating new forms of government entitlements while endorsing intrusive wiretap legislation because they didn't want to jeopardize their influence and prestige amongst the Washington power elite? Some of us believe we can seek ultimate redress at the polls. Many pundits have declared our recent national elections a watershed in politics, a turning point that represents the high water mark of big government. Nonsense. The names have changed, the chairs have been rearranged, but the game remains the same. The so-called "choices" we are presented with are false, hardly better than the mock one-party elections held by failed totalitarian regimes. There must be a better way. I would like to announce the formation of a new group - DigitaLiberty - that has chosen a different path. We intend to bypass the existing political process. We reject consensus building based on the calculus of compromise. Instead we plan to leave the past behind, much as our pioneering forefathers did when they set out to settle new lands. It is our mission to create the basis for a different kind of society. If you would like to join us I invite you to read the information below. Yours in freedom, Bill Frezza Co-founder, DigitaLiberty December 6, 1994 -------------------------------------------------------------------------- *** What is DigitaLiberty? DigitaLiberty is an advocacy group dedicated to the principled defense of freedom in cyberspace. We intend to conduct this defense not by engaging in traditional power politics but by setting an active, persuasive example - creating tangible opportunities for others to join us as we construct new global communities. We believe deeply in free markets and free minds and are convinced that we can construct a domain in which the uncoerced choices of individuals supplant the social compact politics of the tyranny of the majority. *** Is DigitaLiberty a political party or a lobbying group? Neither. DigitaLiberty does not seek to educate or influence politicians in the hope of obtaining legislation favorable to our constituents. We plan to make politicians and legislators irrelevant to the future of network based commerce, education, leisure, and social intercourse. DigitaLiberty does not seek to persuade a majority of the electorate to adopt views which can then be forced upon the minority. We hope to make majoritarianism irrelevant. We invite only like minded individuals to help us build the future according to our uncompromised shared values. *** What do you hope to accomplish? DigitaLiberty is not hopeful that widespread freedom will come to the physical world, at least not in our lifetime. Too many constituencies depend upon the largess and redistributive power of national governments and therefore oppose freedom and the individual responsibility it entails. But we do believe that liberty can and will prevail in the virtual domains we are building on the net and that national governments will be powerless to stop us. We believe that cyberspace will transcend national borders, national cultures, and national economies. We believe that no one will hold sovereignty over this new realm because coercive force is impotent in cyberspace. In keeping with the self-organizing nature of on-line societies we believe we will chose to invent new institutions to serve our varied economic and social purposes. DigitaLiberty intends to be in the forefront of the discovery and construction of these institutions. *** But what about the construction of the "Information Superhighway"? The fabric of cyberspace is rapidly being built by all manner of entities espousing the full range of political and economic philosophies. While political activity can certainly accelerate or retard the growth of the net in various places and times it cannot stop it nor can it effectively control how the net will be used. Our focus is not on the institutions that can and will impact the building of the physical "information highway" but on those that will shape life on the net as an ever increasing portion of our productive activities move there. *** What makes you think cyberspace will be so different? The United States of America was the only country in history ever to be built upon an idea. Unfortunately, this idea was lost as we slowly traded away our liberties in exchange for the false promise of security. DigitaLiberty believes that technology can set us free. The economies of the developed world are now making a major transition from an industrial base to an information base. As they do, the science of cryptology will finally and forever guarantee the unbreachable right of privacy, protecting individuals, groups, and corporations from the prying eyes and grasping hands of sovereigns. We will all be free to conduct our lives, and most importantly our economic relations, as we each see fit. Cyberspace is also infinitely extensible. There will be no brutal competition for lebensraum. Multiple virtual communities can exist side by side and without destructive conflict, each organized according to the principles of their members. We seek only to build one such community, a community based on individual liberty. Others are free to build communities based on other principles, even diametrically opposed principles. But they must do so without our coerced assistance. Effective communities will thrive and grow. Dysfunctional communities will wither and die. And for the first time in human history, rapacious societies will no longer have the power to make war on their neighbors nor can bankrupt communities take their neighbors down with them. *** What does this have to do with my real life? I can't eat data. I don't live in a computer. Yes, but imagine the ultimate impact of mankind's transition from an agrarian economy to an industrial economy to an information economy. Our founding fathers would have consider anyone insane who predicted that a nation of 250 million could feed itself with fewer than 3% of its citizens involved in agriculture. Similarly, economist and politicians trapped in the policies of the past lament our move from a manufacturing economy to a knowledge worker and service based economy. We see this as a cause to rejoice. The day will come when fewer than 5% of the citizens of a nation of 1 billion will be involved in manufacturing - if we still bother calling geographically defined entities "nations". What will the rest of us be doing? We will be providing each other with an exploding array of services and we will be creating, consuming, and exchanging information. Most of this will occur entirely within or be mediated at least in part by our activities in cyberspace. Many of us will earn a very good living on the net. Our race, our religion, our gender, our age, our physical appearance and limitations will all be irrelevant and undetectable. Hard working individuals from underdeveloped nations who in the past might have been forced to emigrate in search of economic freedom and opportunity can now build productive lives in cyberspace. And much if not all of the wealth we create that we do not transform into visible physical assets will be ours to keep and use, beyond the grasp of sovereigns. *** What is the purpose of this forum? The DigitaLiberty Forum is a place where like minded individuals can share their views, observations, and strategies related to the development of virtual communities based on freedom. It is a place where people can exchange information and advice about how they have developed extra-territorial business and social relationships - away from the influence and outside the jurisdiction of governments. It is a forum for the posting of essays, questions, and ideas on the topic of liberty. It is a place where we can meet and debate the forms that our new institutions might take and discuss the practical problems and responsibilities that freedom entail. In time as our technology matures some of us will move on to more ambitious projects, launch other programs, and begin our virtual migration from the swamp of coerced collectivism. Best of all, there will be no need to physically move to 'Galt's Gulch' or escape to a floating 'Freedonia'. We can all participate in this exodus without hastily quitting our jobs or disrupting our lives. And as a larger and larger portion of our economic and social activities move onto the net we will create a new society, open to all with the will to enter. This new world will be interleaved with the physical world in which we now live and yet will be separate. And free. Join us as we begin the journey. *** Who can join DigitaLiberty? The DigitaLiberty Forum is open to anyone that can honestly answer yes to the following two questions: 1) I renounce the use of coercive force as a tool of social or economic policy. 2) I do not derive the majority of my income from funds taken from taxpayers. *** How do I join DigitaLiberty? If you qualify, send a message to DigitaLiberty-request(a)phantom.com with the words "SUBSCRIBE" in the subject line and the message body as follows SUBSCRIBE DigitaLiberty <your name> And welcome to the future. ###

5 4

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 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

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

swIPe
by Alex Strasheim 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Has anything been happening with swIPe lately? I seem to remember reading a couple of months ago that the protocol was being revised (simplified?) and that a new RFC was going to be released soon. What's the status of the project now? == Alex Strasheim | finger astrashe(a)nyx.cs.du.edu alex(a)omaha.com | for my PGP 2.6.1. public key -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLuUFUREpP7+baaPtAQGKGQP/UN7bJfYOHIEdgV9uDnJLbJ00q4J/opLW KpDxF+yl4Nhld70YkMQ/xJ9CeGh0mrCNLz/O8nD4KLrJ87RnH2T1fMV6vdegEvxF CnDEOyRCSEa3kB3c1mkP5rtvW9PJF6GiqDkbaA86wa2usBkuv63mZjPc4EVLiZwY +0xew1PgMQs= =oHAW -----END PGP SIGNATURE-----

3 3