- cypherpunks-legacy - lists.cpunks.org

government free reign on RSA -- from whence?
by ld231782＠longs.lance.colostate.edu 03 May '93

03 May '93

This is driving me crazy. I have asked many people that refer to the U.S. government's free reign on the use of patents in general and RSA technology in particular. There are a lot of very respectable and reputable specialists on this list and I hope they can answer my question. What *specifically* gives the government the *right* to use patents developed `with public money' without licensing, or the RSA patent in particular (if the two are not the same)? Court precedents? A specific law? `congressional hearings'? A condition of agreement to receive NSF funds? >what< ? This little tidbit of information has gotten tossed around so frequently and haphazardly (a bit like an Urban Legend) and it really deserves some sharp scrutiny, at least a bit more than I have ever seen, I suspect it might have some interesting implications to consider.

1 0

PATENT: RSADSI filings with the SEC
by Eric Hughes 03 May '93

03 May '93

RSADSI is a closely held California corporation. What filings are they required to make with the SEC for issues, dividends, etc.? Are these filings publicly available? Do they contain names? Perry, I know you're familiar with this; could you comment? Eric

1 0

Re: Voice Privacy
by Sy Verpunc 03 May '93

03 May '93

From: Jason Asbahr <Asbahr(a)uh.edu> I don't remember hearing this exact use of privacy-enhanced voice communication discussed on the list before, but I might not have been paying attention. :-) I started asking about this recently and discovered that a lot of people are interested in it and some of them are even doing something about it. The most promising group is an Internet Engineering Task Force working on a project called 'nevot' (network voice terminal) - I'll include the readme after this post. It's only drawback is that it doesn't handle completely-software low baud rates that'll work over the internet *on top of* v32bis modems running slip or ppp. I'm working with some folks to hack up a really low bandwidth scheme and when our experiments are successful (if...) we'll feed them back to these folks so that everyone can use it. If anyone here is working on low bandwidth digital voice, there's a mailing list on netphone{-request}(a)moink.nmsu.edu - its a low-volume list and really only for reporting what people are working on; chatty discussions would probably be better on comp.speech or sci.crypt. Remember that before we get crypto voice, we need non-crypto voice, so there's no real reason to discuss the basics in a crypto group. What do you think about encrypting voice communication in a non-real-time sense? Say I record a message (8-bit CODEC) on my NeXT or on a friend's PC Soundblaster and then encrypt/scramble the file in such a way that the resultant file is still audible. I can then leave that message on the recipient's answering machine or voice mail box for him to later record and decrypt on his computer. This method would make private voice communication more accessable, as it doesn't require real-time levels of performance. This is baically what the multi-media extentions to email are about - check up on MIME if you don't know about it. Email mechanisms are fine - the concept of a 'software answering machine' is seductive, but we don't need anything special when you can say 'mail -voice fred' and pick up a mike and talk into it... Graham. --------------- See also gaia.cs.umass.edu:~ftp/pub/nevot/* NEVOT - A network voice terminal (BETA RELEASE 1.3 03/25/93) (c) Henning Schulzrinne ============================================================= NOTE: The .nevotinit files from versions prior to 1.3 are incompatible with the current command language and should be deleted. DESCRIPTION: The network voice terminal (NEVOT) allows audio-capable workstations to participate in audio conferences across local and wide area networks. Features: - real-time protocols: - NVP (network voice protocol), as used by 'vat' (LBL) and VT (isi) - 'vat' native packet format and session protocol - RTP draft - versions for: - Sun SPARCstation (SunOS 4.1.x and Solaris 5.x) - SGI Indigo (4D Series) and - Personal DECstations [as soon as we can get the DEC audio library to work] - GUIs: - XView - Tk [in progress] - curses - dumb terminal - fully controllable by Tcl-based command language - can serve as gateway for protocol and encoding translation - network transport protocols: - TCP - unicast/multicast UDP - ST-II [currently inoperative] - several independent concurrent conferences, each with different encoding and compression - DES-based voice encryption (U.S. only) - audio encodings: - 64 kb/s (mu-law PCM) - 32 kb/s G.721 ADPCM (Sun only) - 32 kb/s Intel DVI - 24 kb/s G.723 APDCM (Sun only) - 13 kb/s GSM - 4.8 kb/s LPC codec - each site can use different audio encodings - playback and recording of AIFC and .snd audio files - extensive statistics and tracing facilities - arbitrary voice packet length, which may differ for each site - lost packet and silence substitution - setable audio buffer occupancy - configurable adjustment mechanisms for playout delay, VU meter, silence detector and automatic gain control - redefinable session identifier string with variable substitution DOCUMENTATION: A compressed PostScript file describing Nevot is available for anonymous ftp from gaia.cs.umass.edu, as file ~ftp/pub/nevot.ps.Z. INSTALLATION: The sources are available by anonymous ftp from gaia.cs.umass.edu, as file ~ftp/pub/nevot/nevot.tar.Z (compressed tar file). The platform- specific external libraries are contained in the directory pub/nevot/lib.$ARCH. These typically change rarely. ARCH can be either dec, sgi, or sun4. Precompiled binaries are available as well: nevot/bin.$ARCH/nevot.tar.Z For the precompiled binaries, you also need to retrieve the initialization file ~ftp/pub/nevot/nevotinit and rename it to .nevotinit in the directory from which you plan to start Nevot. Unpack the compressed tar files, then execute the shell script compile You may have to adjust parameters within the shell script to your local needs, e.g., the compiler name. You also have to install the tcl library (version 6.7 or later), either the binary version as mentioned above, or from sources to be found in sprite.berkeley.edu:tcl. In order to use the UDP multicast and/or ST-II facilities, you have to install the appropriate kernel modifications. Due to export restrictions, the DES encryption code is available only by e-mail from the author. If you do have the DES code, change the value of the symbol DES in the Makefiles to 1. To enable on-line help for the OpenWindows version, the environment variable HELPPATH should be set to include the source directory where the .info files are located (here, assumed to be /usr/local/nevot/xview): setenv HELPPATH ${HELPPATH}:/usr/local/nevot/xview OPERATION WITH SD: ------------------ sd is a session directory written by Van Jacobson, LBL, available for anonymous ftp at ftp.ee.lbl.gov. The nevot/sd directory contains a replacement for the sd start_audio procedure, which you can insert into your ~/.sd.tcl startup file. Make sure that the directory containing the Nevot binary is in your path. Use at your own risk (i.e., don't blame VJ if it doesn't work...). DIFFICULTIES: ------------- If you experience difficulties, check the problems.tex file in the doc directory. BUG REPORTS: This is a beta release. Please send all bug reports and suggestions to the author at hgschulz(a)cs.umass.edu. New releases will be announced through the rem-conf mailing list (to join the list, send a request to rem-conf-request(a)es.net) I would appreciate if you could let me know how you are using the software. [A version for the Personal DECstation and DECstations with the DEC audio hardware is currently under development.] COPYRIGHT: All sources and documentation (except those listed in the acknowledgements or otherwise identified) are (c) Henning Schulzrinne 1992, University of Massachusetts and AT&T Bell Laboratories. Do not redistribute this software, or integrate with other software, without preserving the copyright notice. All changes have to be clearly marked. You may modify the code as long as you provide me with a copy. ACKNOWLEDGEMENTS: The DES encryption module was developed by Steve Kent and John Linn of BBN Communications Corporation, Cambridge, MA and provided by Karen Seo of BBN. The audio library incorporating G.721 and G.723 audio compression was provided by Daniel Steinberg of Sun Microsystems. It may at some point be integrated into the regular Sun OS. The Intel/DVI ADPCM codec was slightly modified from sources by Jack Kansen (CWI) and is copyrighted 1992 by Stichting Mathematisch Centrum, Amsterdam, The Netherlands (used by permission). The ST-II API and kernel support was developed by Charlie Lynn at BBN. The ST-II API (\C{st2_api.h}) is copyrighted (c) 1991 by BBN Systems and Technologies, a division of Bolt Beranek and Newman, Inc. and used by permission. The UDP multicast kernel support was written by Steve Deering, Xerox Parc. Charlie Lynn (BBN) was helpful with some of the fine points of the ST-II API. The Tcl interpreter was developed by John Osterhout, University of California at Berkeley. The sources are copyright University of California and used by permission. Advice on porting \nevot\ to the Silicon Graphics platform and numerous bug fixes were provided by Andrew Cherenson (SGI). Michael Halle (MIT) figured out how to get Xview applications to display fonts at the design sizes. The VU meter is based on discussions with Gints Klimanis (SGI). The audio mixing (mix.c) and checksum code (checksum.c) was taken from the ISI voice terminal (VT), copyright June 1991 by the University of Southern California, by permission. The silence detector and the ST-II code are modified versions of the respective parts of VT. The \vat\ session and audio protocol were implemented based on descriptions provided by Van Jacobsen. The I/O flags interpreter (flags.c) is a modified version of software contributed to Berkeley by Chris Torek. Copyright (c) 1990 by the Regents of the University of California; used by permission.

1 0

[comp.society.privacy fwd] Wiretaps without warrants
by Valerie Lambert 03 May '93

03 May '93

I wasn't sure if I should forward this or not... should I assume that most every cypherpunk with usenet access keeps an eye on comp.society.privacy? I found this article surprising; I wasn't even aware that there was any such bill in Congress. It seems that the FBI is busy chipping away at privacy on many fronts. So, how good is the argument that Clipper keys are held safely in escrow awaiting a warrant, if no warrant is required to gain a legal wiretap? ----- begin forwarded message ----- From: David Brierley <davidbri(a)lynx.dac.northeastern.edu> Newsgroups: comp.society.privacy Subject: Wiretaps without warrants Path: portal!uunet!computer-privacy-request Date: Wed, 28 Apr 1993 01:54:13 GMT Message-ID: <comp-privacy2.39.1(a)pica.army.mil> Organization: Division of Academic Computing, Northeastern University, Boston, MA. 02115 USA Sender: comp-privacy(a)pica.army.mil Approved: comp-privacy(a)pica.army.mil X-Submissions-To: comp-privacy(a)pica.army.mil X-Administrivia-To: comp-privacy-request(a)pica.army.mil X-Computer-Privacy-Digest: Volume 2, Issue 039, Message 1 of 7 Sorry to get this out so late, but better late than never. It is from the Boston Sunday Globe of April 11, 1993, page 16. ------------------------- New England Votes in Congress Roll Call Report Syndicate WASHINGTON - This is how New England members of Congress were recorded on major roll-call votes last week. ... TO EXPAND FBI PHONE ACCESS: By a vote of 367-6, the House sent the Senate a bill expanding the FBI's power to obtain, without court warrants, telephone records and conversations in investigations of international terrorism and espionage. The bill grants the FBI access in such investigations to information on unlisted numbers that phone companies cannot now divulge. It also enables FBI counterintelligence agents to obtain a broader range of telephone conversations involving suspected terrorists and spies. A yes vote was to pass the bill. Connecticut: Voting yes: Kennelly, Gejdenson, Shays, Franks, Johnson. Not voting: DeLauro. Maine: Voting yes: Andrews, Snowe. Massachusetts: Voting yes: Neal, Blute, Frank, Meehan, Torkildsen, Markey, Kennedy, Moakley, Studds. Not voting: Olver. New Hampshire: Voting yes: Swett. Not voting: Zeliff. Rhode Island: Voting yes: Machtley, Reed. Vermont: Not voting: Sanders. ... ----- end forwarded message ----- -- Valerie Lambert * valerie(a)biocad.com * 415/903-3923 * "The world hates change, yet it is the only thing that has brought progress." --Charles Kettering

1 0

ANON: hop.mail replacements random number generation in perl
by Stop the Big Brother CHip 03 May '93

03 May '93

#<application/x-pgp -----BEGIN PGP SIGNED MESSAGE----- Hi All, I am currently upgrading Hal's Remailer to work with SVR4(mail lock files as opposed to flock) and encryption of the message body. I am also looking at the implementation of the following design goals: * Definition and implementation of a cryptographic MIX protocol compatible with the present day remailers(or with minor script changes). Another area I am working at present on is a replacement for the present anon.mail and hop.mail in perl. Design goals for that companion script are: * Automatic generation of random hop routes for anonymous encrypted remailer return addressing blocks(function 2 from hop.mail) * Hop.mail mailing of files(Function 1) with auto route selection and generation. Other desirable properties of a automatic remailer route generation script would be: * An encrypted remailer would always be selected as the beginpoint and endpoint in a remailer random route selection. * Non-Encrypted but anonymous remailers can only be used as the linkage remailer between 2 encrypted remailer nodes. * The next remailer number generated must be different than the previous remailer number generated. * route generation scripts should generate n number of nested remailer blocks where n is greater 4 and less than 30. * remailer numbers may be used multiple times in the same route generation subject to the conditions listed above. * a random seed needs to be generated to prime the generator. * A MUCH better function than perl's rand is needed. For the curious I am implementing this on a Stock SVR4 system with MH 6.8(MIME). All scripts are being implemented in PERL (PL36). I am interested in critique, additional desirable design goals etc. - -- Parts of this .sig borrowed with permission from T.C.May. Perhaps it will indeed get me busted also. .......................................................................... Kelly Goen | Crypto Anarchy: encryption, digital money, kelly(a)netcom.com | anonymous networks, digital pseudonyms, zero Intelligence Systems | knowledge, reputations, information markets, Specialists Inc. | black markets, face banks, data havens, dark | tech, covert channels, shared secrets, | alt.whistleblowers, collapse of governments. Technical Monkeywrench | Public Key: PGP 2.2. | .......................................................................... PGP 2.2 Key available from PGP Keyservers on the Internet. pub 1024/1BA573 1992/09/09 kelly <kelly(a)netcom.com> Key fingerprint = EF 7A 38 99 22 84 E3 3B 90 2A DB 80 DC 65 DA 31 STOP THE WIRETAP CHIP(Clipper Chip)!! -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBK+RZyvgXinP2G6VzAQGugQP/VEkMHJdZCaJgw6aqIqUscFzqGX+AxNCR 5etQjwPimk+CEc1NPwB9IrgEZOnXFQannqb3T3ISAJdUZLfYkuqowQoz9fBhIT/4 GGpO1SQtDU2aMe9zR6RjdnGBditblURyUsA4Bgco9692BuqWmuvQ8QJ+MFOGJNHl dNBFw7JPXik= =UR/e -----END PGP SIGNATURE----- #

1 0

Voice Privacy
by Jason Asbahr 03 May '93

03 May '93

Greets, all... I don't remember hearing this exact use of privacy-enhanced voice communication discussed on the list before, but I might not have been paying attention. :-) What do you think about encrypting voice communication in a non-real-time sense? Say I record a message (8-bit CODEC) on my NeXT or on a friend's PC Soundblaster and then encrypt/scramble the file in such a way that the resultant file is still audible. I can then leave that message on the recipient's answering machine or voice mail box for him to later record and decrypt on his computer. This method would make private voice communication more accessable, as it doesn't require real-time levels of performance. Perhaps one of the PGP gurus could advise on how this sort of private communications could be accomplished. If PGP is used as the encryption tool, then making the encrypted file audible is not unlike making an encrypted file "readable" by turning it into mailable ASCII. It is probably important to consider that recording an "audio armored" encrypted voice message to an answering machine or voice mail box will introduce various kinds of distortion. Is anyone experienced with error-correction methods for audio transmissions? Jason Asbahr 116 E. Edgebrook #603 asbahr(a)uh.edu Houston, Texas 77034 next(a)tree.egr.uh.edu (NeXTmail) (713) 743-6995 voice asbahr(a)tree.egr.uh.edu (NeXTmail) UH NeXT Campus Consultant

1 0

Digital Cash
by simonm＠mindvox.phantom.com 02 May '93

02 May '93

Could someone mail or post some (preferably on-line) references to information re digital cash? Thx, I missed the discussion that was posted here. -- Simon (simonm(a)mindvox.phantom.com)

1 0

unsubscribe
by rmashlan＠mash.boulder.co.us 02 May '93

02 May '93

Please unsubscribe me -- | Robert Mashlan email = rmashlan(a)mash.boulder.co.us |

1 0

Re: Is Rush Limbaugh giving Clinton sh*t about wiretap chip?
by jcook＠pro-storm.metronet.com 02 May '93

02 May '93

WEll i work for a mojor airline and I would be happy to get you his homne mailing address if he has a frequent flyer number. ProLine: jcook@pro-storm Internet: jcook(a)pro-storm.cts.com UUCP: crash!pro-storm!jcook Bitnet: jcook%pro-storm.cts.com(a)nosc.mil

2 1

thanks
by jdblair＠nextsrv.cas.muohio.edu 02 May '93

02 May '93

Thanks for the quick and multiple responses to my questions. I also grabbed the cryptography FAQ off of sci.cryptography, and it has been helpful. -john.

1 0