- cypherpunks-legacy - lists.cpunks.org

NIST CSSPAB 6/4/93 Resoluti
by Dave Banisar 05 Jun '93

05 Jun '93

NIST CSSPAB 6/4/93 Resolutions NIST Crypto Resolutions Computer System Security and Privacy Advisory Board June 4, 1993 Resolution #1 At Mr. Kammer's request we have conducted two days of hearings. The clear message of the majority of input was that there are serious concerns regarding the Key Escrow Initiative and the Board concurs with these concerns. Many of these issues are still to be fully understood and more time is needed to achieving that understanding. Accordingly, this Board resolves to have an additional meeting in July 1993 in order to more completely respond to Mr. Kammer's request and to fulfill its statutory obligations under P.L. 100-235. The Board recommends that the inter-agency review take note of our input collected, our preliminary finding, and adjust the timetable to allow for resolution of the significant issues and problems raised. Attached to this resolution is a preliminary distillation of the serious concerns and problems. Resolution #2 Key escrowing encryption technology represents a dramatic change in the nation's information infrastructure. The full implications of this encryption technique are not fully understood at this time. Therefore, the Board recommends that key escrowing encryption technology not be deployed beyond current implementations planned within the Executive Branch, until the significant public policy and technical issues inherent with this encryption technique are fully understood. [Attachment to Resolution #1]] - A convincing statement of the problem that Clipper attempts to solve has not been provided. - Export and important controls over cryptographic products must be reviewed. Based upon data compiled from U.S. and international vendors, current controls are negatively impacting U.S. competitiveness in the world market and are not inhibiting the foreign production and use of cryptography (DES and RSA) - The Clipper/Capstone proposal does not address the needs of the software industry, which is a critical and significant component of the National Information Infrastructure and the U.S. economy. - Additional DES encryption alternatives and key management alternatives should be considered since there is a significant installed base. - The individuals reviewing the Skipjack algorithm and key management system must be given an appropriate time period and environment in which to perform a thorough review. This review must address the escrow protocol and chip implementation as well as the algorithm itself. - Sufficient information must be provided on the proposed key escrow scheme to allow it to be fully understood by the general public. It does not appear to be clearly defined at this time and, since it is an integral part of the security of the system, it appears to require further development and consideration of alternatives to the key escrow scheme (e.g., three "escrow" entities, one of which is a non-government agency, and a software based solution). - The economic implications for the Clipper/Capstone proposal have not been examined. These costs go beyond the vendor cost of the chip and include such factors as customer installation, maintenance, administration, chip replacement, integration and interfacing, government escrow systems costs, etc. - Legal issues raised by the proposal must be reviewed. - Congress, as well as the Administration, should play a role in the conduct and approval of the results of the review. ======================================================= NIST Resolutions on Key Escow Issues and Clipper provided by CPSR Washington office 666 Pennsylvania Ave., SE Suite 303 Washington, DC 20003 rotenberg(a)washofc.cpsr.org =======================================================

1 0

Procomm and encryption
by poier＠sfu.ca 05 Jun '93

05 Jun '93

This discussion of integrating encryption with a comm package made me remember: Procomm Plus 2.0 allows "hooks" to be assigned to meta-keys. I have the exact interface hook.c around here somewhere, if someone wants me to post it. Skye -- -----====> Skye Merlin Poier <====----- Undergrad in CMPT/MATH (Virtual Reality) |||| |||| email: poier(a)sfu.ca p-OO <--> OO-q THINK PGP Public Key available on finger \== ==/ ivel' or some such. I would like to make it clear that the 'tiring drivel' that I was referring to was MY post and not the letter from Hugh and I merely intended the note to serve as a warning to people not interested in the project. I see now that it is, indeed possible that this informal not may have been misunderstood and I hope that you will understand my real intent now and not hold it against me. I am truly greatful for the help that I have received on this effort and hope that we will have another product of guerilla programming soon. Again, sorry for the misunderstanding, especially to Hugh, and keep those suggestions coming, there is work to be done... -Ryan the Bit Wallah

2 1

Lobbying for Cryptoprivacy, non-U.S.
by jhart＠agora.rain.com 04 Jun '93

04 Jun '93

>I have shied away from any "political" action against Clipper because I am >unsure how a Canadian can help... Non-U.S. citizens can lobby hard to get all phones containing key-escrow (aka wiretap) chips banned in your country. You have a very good argument: do y'all want Yankee spooks listening in on your phone calls? Make sure the following specifics are included in the legislation: * Try to get key escrow banned *in general*, instead of just from foreign countries. In smaller countries this will be easier since its doubtful small governments can set up a spook/chip-maker axis to rival the NSA/Mykotronx/VLSI axis in the U.S. In fact probably only the U.S., cooperating major European countries and Japan have such a capability. * Be careful with the wording of the legislation; be sure to specify *key-escrow* and not any other forms of cryptography. * If political feasible the legislation should specifically encourage private, commercial forms of cryptography. Jim Hart jhart(a)agora.rain.com

5 4

Re: Term software develo
by gdale＠apple.com 04 Jun '93

04 Jun '93

>I've been thinking about what kind of an API could be negotiated >between terminal-program authors and encryption-mechanism authors. > >Suppose a terminal program looks for resources (using macintosh-like >terminology for a moment) of some type 'Encr', and load them. >It expects to find subroutines there, that the >cypherpunk can add to any conforming terminal emulator. >Something like this: > > resource #1: function initialize() -- grab resources > resource #2: function set_key(char key[8]) > resource #3: function encrypt(long block_no, char block[8]) > resource #4: function decrypt(long block_no, char block[8]) > resource #5: function finalize() -- shutdown, release resources > Woops, this is what I get by not reading all my mail before posting. I just posted the same suggestion with considerably less detail. Anyway, I second what henry says. ________________________________________________________________________ Geoff Dale -- insert standard disclaimers here -- gdale(a)apple.com "Mind your nerve ends, love bunch" -- Dr. Caligari

1 0

Crypto API (was: Software infrastructure)
by gdale＠apple.com 04 Jun '93

04 Jun '93

I was thinking about a crypto project I have on the backburner (actually it's just in the concept stage), a program to hide encrypted data in raster image files. I really don't want to muck with writing or porting an encryption package, I just want to do the part that sticks the data into the image. HERE'S THE BEEF: I think a lot of the various mail readers and what not would be likely to encorporate encryption, if only it were mind-bogglingly simple. An API (Application Programming Interface) could be proposed by cypherpunks or others. The same folks should probably provide at least one encryption library for use. It would be nice if this API allowed for multiple encryption schemes (user selectable), like the way Apple's Communications Toolbox allows users to switch between various connection protocols. I'm much too busy to embark on something like this (largely because I'm not a cypher expert), but if I can help convince somebody to do it, or to provide feedback on the interface, I'm available. ________________________________________________________________________ Geoff Dale -- insert standard disclaimers here -- gdale(a)apple.com "Mind your nerve ends, love bunch" -- Dr. Caligari

1 0

The "WARLOCK" Cipher
by tcmay＠netcom.com 04 Jun '93

04 Jun '93

Cypherdroids, Earlier today I commented on the advisability of posting new ciphers to this group, or to sci.crypt. (I haven't gotten my message yet, so I don't know if it went through.) By coincidence, a very long posting on sci.crypt has appeared, announcing a new matrix-based crypto system, called "WARLOCK" by its inventors. They provide an extensive introduction to the mathematics used and offer various analyses. This is a first step toward making their system worth analyzing. I suggest following the debate on this system will be educational. And perhaps their system will even survive to become a reasonable alternative. -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it.

2 1

Work the work!
by fergp＠sytex.com 04 Jun '93

04 Jun '93

-----BEGIN PGP SIGNED MESSAGE----- On Tue, 1 Jun 93 09:56:45 -0700, Eric Hughes <uunet!soda.berkeley.edu!hughes> wrote - > We are trying to build a sandbox, and the government is trying to > restrict the use of sand. We are indeed doing just this. Although the small minority of us compu-professionals are writing code, flailing congressmen, etc., it takes more than what is currently being acknowledged to get things changed. I will not, however, discontinue my diatribe with my elected representatives on the topic of our electronic rights to privacy under the first and fourth amendments. (I'm having too much fun doing something that I seriously, and perhaps foolishly, believe in.) Is there something going on with the EFF that we should know about? > That said, I also urge those who are writing code to continue. To > those of you not writing code, however, I say start talking to your > friends and neighbors and communities and newspapers. > Now. We are working on it. A vote of confidence towards crypto-freedom. Are we east-coast-niks welcome in this process? Is policy being drawn by a few EFF persona without consultation of the masses? Eric, before you say "Now,", you'd best detail us. I know what you mean, however, many of the crypto-warriors which may follow do not. It may be a good idea to _now_ place a broad policy statement. Cheers. -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLAwNs5RLcZSdHMBNAQFlRAP7BSpktDz4URB0rhWQ5mxb2UcJqEZHdp+2 It+Whxh1MzYTLFi0SfvZRQYjPEZO1wN2ac8bQyl2zOpi7viAg8X+AfEZACWooqUQ y8Dyddup15MNj/p53fJQhzKYaX4K4xD2h6WTWO1X8Q2SPHo0WV48Hu+uO8nyeoqD PJj0d/IHvg4= =6GvE -----END PGP SIGNATURE----- Paul Ferguson | The future is now. Network Integrator | History will tell the tale; Centreville, Virginia USA | We must endure and struggle fergp(a)sytex.com | to shape it. Stop the Wiretap (Clipper/Capstone) Chip.

4 4

HELP: pgp, .forward, mh
by Karl Barrus 04 Jun '93

04 Jun '93

Situation: I'd like mail that arrives at my other account to be encrypted and then forwarded to this account. I have spent a few hours trying various things and nothing seems to work. I've tried this as my .forward file: "| /myhome/pgp -fea barrus | mail elee9sf(a)menudo.uh.edu" but all that arrives at elee9sf is a blank message. I've tried "| /myhome/remail.script" where remail.script was a one-liner similar to the above. Nothing. Any suggestions? Note: 1) barrus(a)tree.egr.uh.edu is a NeXT account. Is NeXTSTEP just too different for this stuff to work? 2) I'm running pgp2.1 on tree.egr, and don't have the old docs anymore. Was the -f option not present? 3) Anybody have a makefile for NeXT so I can upgrade? I compiled 2.1 by hand editing some lines, but the task looks pretty daunting with 2.2. I tried 'make mach' but that didn't get very far. So, if that's impossible, how do I get my elee9sf account to do it? I use mh on menudo, and have tried to barrus(a)tree.egr.uh.edu | A "/path/pgp -fea barrus | /path/rvcstore +tonext" in my .maildelivery but that doesn't seem to fly either. Any suggestions? /-----------------------------------\ | Karl L. Barrus | | elee9sf(a)menudo.uh.edu | <- preferred address | barrus(a)tree.egr.uh.edu (NeXTMail) | \-----------------------------------/

2 1

RE: Term software develo
by Doug Porter 04 Jun '93

04 Jun '93

Eric Hughes says: > FOSSIL is . . . the only abstraction for serial communications the PC has . . . There are at least 7 versions of INT 14. Then there's Ungerman-Bass's old INT 6B as well as two flavors of its successor, NASI/NCSI. There are also many variants of COMx device drivers. These are all serial line abstractions for the PC. There are others. FOSSIL may be popular on BBSs, but NASI/NCSI is number one in the market. The oldest version of INT 14 is number two. Who was it said "The nice thing about standards is that there are so many to choose from"? :-) Doug

3 2

Re: Term software dev
by Doug Porter 04 Jun '93

04 Jun '93

Eric Hughes asks: > What are NASI/NCSI? Does it cost to use them? Is source available? It's an API originally developed by Network Products Corporation and based on an earlier spec from Ungerman-Bass. NPC used it in building an async comm server for LANs. NPC called the API "Network Communications Server Interface" or NCSI. Novell licensed the technology from NPC and renamed the API to "Novell Asynchronous Server Interface" or NASI. Other async server vendors picked up on it about then as a result of Novell's evangelism. Serial communications software packages from Crosstalk to Procomm to tiny niche products started to support it. Then because of the end user package support, the standard was used for different kinds of serial connections. For example, we (CyberCorp) built a NASI/NCSI interface for intelligent Digiboards a while back. I've never heard of anyone being charged to use the spec for whatever they like. At least part of the spec, the part promoted by Ungerman-Bass, seems to be in the public domain. We originally got the spec from Novell when we built a Netware compatible async server. I don't know of any free source code, but code for either end of the spec is only one or two thousand lines of C. Doug

1 0