December 2003 - cypherpunks-legacy

Any news on the crypto export bill?
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

The House Rules Committee was supposed to decide if the General Export Administration Act HR 3937 was going to be "open" or "closed". They were going to do this last Thursday. What did they decide? Or was the meeting postponed? Jim_Miller(a)suite.com

1 0

Unknown
by Random H0Z3R 17 Dec '03

17 Dec '03

============================================================================ SUBJECT: METHOD FOR UPDATING ENCRYPTION KEY INFORMATION IN COMMUNICATION UNITS SOURCE: MicroPatent via Fulfillment by INDIVIDUAL, Inc. DATE: July 6, 1994 INDEX: [2] ORDER NO: 402693# ---------------------------------------------------------------------------- MicroPatent via INDIVIDUAL, Inc. : Abstract: Within a communication system, an encryption controller receives unit identification information from a plurality of encrypting/decrypting communication units. For any individual communication unit, the encryption controller uses the unit identification associated with that transmitting communication unit to determine if it contains updated encryption key information. If the transmitting communication unit is not currently updated, a group call is used to send the current encryption key information to all communication units within the transmitting communication unit's group, thereby updating all active, non-current communication units. After a first predetermined period of time has elapsed, this process is allowed to repeat. Ex Claim Text: In a communication system that includes a plurality of communication units, an encryption controller, wherein the plurality of communication units includes a first set of communication units that are currently active and a second set of communication units that are currently inactive and wherein communication units of the plurality of communication units readily change from the first set of communication units to the second set of communication units and vice versa, a method for updating encryption key information to the plurality of communication units, the method comprises the steps of: a) transmitting, by a first communication unit in the first set of communication units, unit identification information to the encryption controller; b) when the unit identification information is received, determining, by the encryption controller, that the first communication unit does not have updated encryption key information; c) transmitting, by the encryption controller, updated encryption key information to the plurality of communication units, wherein only the first set of communication units are updated with the updated encryption key information; d) initiating, by the encryption controller, a predetermined wait period; e) changing, by a second communication unit, from the second set of communication units to the first set of communication units; f) after expiration of the predetermined wait period, receiving, by the encryption controller, unit identification information from the second communication unit; and g) when the unit identification information from the second communication unit is received, retransmitting, by the encryption controller, the updated key information to the plurality of communication units, wherein communication units that have changed from the second set of communication units to the first set of communication units are updated with the updated encryption key information. Patent Number: 5325432 Issue Date: 1994 06 28 Assignee: Motorola, Inc. Inventor(s): Gardeck, KevinCutts, Kevin M. If you require additional information on this patent, please call PatentQuery at 800-984-9800. [07-06-94 at 18:24 EDT, Copyright 1994, MicroPatent, File: m0701215.4pa]

2 1

Re: Counting bits
by Ian Farquhar 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Just for entertainment value, I clipped your function and compiled it >with Turbo C++ 1.01 in default (ANSI C) mode. Here's the .asm code >produced (comments and setup code edited for brevity) Both Sun C and GCC on a Sun SPARC system running 4.1.3 produced this code for each bit-count line (-O4 optimization used): L77042: andcc %o0,2,%g0 ; AND the bit bne,a L77044 ; branch/anull if zero inc %o5 ; increment bitcount L77044: This, I believe, is as optimized as it is possible to get on a uniprocessor machine. On both compilers, the routine size was 28 instructions total, and that would also be the maximum path length for the execution of this routine when passed an ASCII 255 value. A MIPS-based DECserver running Ultrix 7.1 produced this (again, -O4): $34: lb $11, 0($sp) ; Load the byte off the stack and $12, $11, 16 ; AND the bit beq $12, 0, $35 ; branch/anull if zero addu $3, $3, 1 ; increment bitcount $35: Total instruction count was 28. This is non-optimal, as there is no need to reload off the top of the stack on every line, and if so modified it would be equivalently efficient to the SPARC implementation. On a Cray Y-MP/EL running UNICOS 7.0.6 (-O3, which is equivalent to - -hinline3,scalar3,task3,vector3): L5 = P.* S7 2 ; Move 2 into S7 S0 S2&S7 ; S0 = S2 AND S7 JSZ L6 ; Jump to L6 if the bit was zero S7 1 ; Move 1 into S7 S1 S1+S7 ; Up the bitcount in S1 L6 = P.* ; 9 Note that the Cray C compiler (or indeed any C compiler I know of) is not yet capable of recognising the option of using the population count instruction here, because it is nearly impossible to determine what this particular routine is doing. Even so, the total instruction count is 80, which is somewhat excessive. The "Move 1 into S7" could probably be eliminated by using another scalar register, and I suspect (but don't have the manual here so I cannot confirm) that they'd be better not to reload the mask every line, but instead to load it once and shift. Additionally, you could probably vectorise this, but I doubt it would buy you much. Anyway, that's an analysis of three high end architectures on this code fragment. Personally I feel that a lookup table would be a MUCH more efficient implementation for most systems which lack population count, even for words up to 20 bits or so in size (depending on your storage requirements and latency at accessing main memory, of course). Enjoy. One of these days I will get back to my project of implementing crypto primatives in CAL, but I do not have the time right now. BTW, folks, playing around with this is fun. I still believe that either the SKIPJACK interim reports Cray-implementation timing figures were wrong, or the conditions under which the program was compiled was incorrect (most likely), or that SKIPJACK contains no s-boxes. Take your pick. Ian. -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLhukvdCZASdT8NoBAQHe/wQAzW/zmoiiAz9vswLO5kQcs6TSoAhIK7SM 1hTrvbXTbNwrnK2FyhC4nZaUPIjnZufOeCoQPs1DJNsCZ1q6Gx1nlVj/hTyBUxYr THQ9ZLOUFruSDa18enx4J1iSrliBeoGcV0CuGRxClNoFrDkYedzRS0nN+m/rq35W Vcsk0HFxq0g= =Wpri -----END PGP SIGNATURE-----

2 1

FW: Windows for Workgroups 3.11
by Blanc Weber 17 Dec '03

17 Dec '03

Below is the reply which I received internally on the question of whether WfW uses RSA: ---------- From: Michael Ginsberg To: Blanc Weber Cc: Cypherpunks Mailing List Redistribution Subject: RE: Windows for Workgroups 3.11 Date: Thursday, July 07, 1994 8:22AM [The following can be distributed outside of Microsoft, and redistributed thereafter, as long as it remains unaltered and is reproduced in it's entirety, including this header] In the Windows for Workgroups 3.11 fax enhancement, we provide the ability to send "email format" messages over fax. These are messages that do not lose their original format during faxing, so that they are still editable (ie: if you send a Microsoft Word document, the receiver gets an actual Microsoft Word document, not just printed pages). One feature of this format is that we allow security enhancements to be applied to the message before transmission. These enhancements are encryption (either secret key or public key) and signature (based on public key). I will describe a bit about how we implement these features. 1> Secret key encryption This is exposed to the user as password encryption. The user chooses a password (of as long a lenght as the user desires, composed of characters with ASCII values 1 through 255) and we hash it down to 64 bits. These 64 bits are used to encrypt the message (including all attachments, text, properties, etc) using RSA's RC4 algorithm. A header is then placed on the message with sufficient information for routing (subject, sender, receiver, time stamps, as well as a marker identifying the encryption type). The receiver enters the password to decrypt (the same as the encrypting password), and we verify that the password is correct by decrypting the message and seeing if it's valid (ie: has the right internal structure to be a mail message). 2> Public key encryption We allow the user to generate public/private key pairs. These key pairs are 512-bit RSA key pairs. The private part is stored encrypted (with the user's "fax security" password) on the user's hard drive, and the public part is stored in plain (binary form). The user exchanges his public keys with other users in various ways. If the user sends a fax with public key encryption, we first generate a random 64 bit number, and encrypt the message with RC4 using that number (similar to password encryption above). We then scatter the 64 bits in a 64 byte (randomly initialized) buffer and encrypt that buffer using RSA's RSA encryption scheme, using both the sender's private key and the recipient's public key. We then send the encrypted message and header containing routing information and the 64 byte block. The recipient performs a similar operation, using his private and the sender's public key to obtain the 64 bit "secret key", and then decrypting the message. 3> Digital signature While the above encryption schemes are performed on entire messages, we provide a method for digitally signing attachments. Microsoft Mail allows the entering of plain text into a message, as well as the embedding of entire files. It is these files which we sign. Signature is accomplished by computing a 128 bit hash of the file using RSA's MD5 message digest algorithm. This 128 bit hash is then embedded in a 64 byte buffer, and it is encrypted using the sender's private key. The buffer (along with some header information) is pre-pended to the document, and it's extension is changed to .aws, so that our applet to view signatures is called upon double clicking or "running" the signed document. Anyone receiving the document can see the validity of the signatures (by hashing themselves, and then decrypting the stored hash). If you sign a signed document, the signatures are cumulative, so multiple people can sign the same document. Signatures are either valid (hashes match), invalid (hashes differ), or unverifyable (you don't have the sender's public key). --Michael Ginsberg, Software Design Engineer, Microsoft Corporation. mikegins(a)microsoft.com

1 0

Re: TROJAN HORSE CALLED CHINON
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

SUBJECT: ALERT RAISED ON TROJAN HORSE CALLED CHINON SOURCE: Newsbytes via Fulfillment by INDIVIDUAL, Inc. Oh for fucks sake this is the last bloody straw. This story IS TWO YEARS OLD!!! And it's wrong. And like most of what you posted it's got bugger all to do with cypherpunks. If you want to be a one-man newsagency, Mr Nobody, set up your own fucking mailing list and stop bombing us with this much shite every day. Or start your own news group on usenet. It's not appropriate here - most of the stories you posted we knew about already. G *plonk* - nobody(a)c2.org goes into my killfile, whether anyone more interesting ever choses to post from there or not...

1 0

Re: Mastercard, Visa, Access, Barclaycard, Amex, JCB ...
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

At 9:24 AM 07/07/94 -0400, Richard Martin wrote: > I worked a few years in a pharmacy (credentials established) and so >noticed that most customers will take it as a personal affront if anything >more than this cursory attention is paid to their credit card. It's a >North American phenomenon I can attest to, though whether it's much >different from European attitudes I cannot judge until I work retail >on the other side of the pond. (Read, hopefully never. Retail, that is. I >would like to work in Europe at some point. But I'd rather not be selling >Aspirin.) A lot of people can ger really bitchy about 'not being trusted'. In the hotel I used to work in, if I even asked people to sign the back of an unsigned card they'd fly off the handle. "Sir, I *am* the acting manager..." > Out of some interest, what do the "swipe" card verification systems >do? How much information do they read from the card and pass down the >telephone line? How much information would a tap of such a transmission >reveal? At the least, they reveal card number, expiration date, transaction location, amount of purchase and (obviously) time of purchase. I suppose more could be on the card, but I am not sure what good that would be (if you have card number, any credit card company is gonna have much more data on you than will fit on a magnetic strip). I do wonder how many newer cash registers track purchase -> card number records, but I doubt this does to card issuers (well, at least not for free). But this discussion has less and less to do with crypto... -j -- "Blah Blah Blah" ___________________________________________________________________ Jamie Lawrence <jamiel(a)sybase.com>

1 0

Schneier Claims on Multiple Encryption
by kentborg＠world.std.com 17 Dec '03

17 Dec '03

In Applied Cryptography (at 8.2.5) Bruce Schneier says: "What about encrypting a block once with algorithm A and key K-a, and then again with algorythm B and key K-b? Aside from being susceptable to ... meet-in-the-middle attacks, there is no guarantee that the two algorythms will work together to increase security. There may be subtle interactions between the two algorithms which actually *decrease* security." Wait. If applying a different algorithm with an unrelated key might decrease security, then the TLAs could themselves apply another algorithm with their own unrelated key as an analysis technique, no? Kent's Hypothosis: Superencrypting different algorithms with unrelated keys can never weaken non-trivial algorithms. Stacking DES on top of IDEA on top of Ceasar can be no worse than the strongest of the the set--assuming the keys are unrelated and the attempted security is not through obscurity and the algorithms are not so confused as to be each other's analysis. -kb -- Kent Borg +1 (617) 776-6899 kentborg(a)world.std.com kentborg(a)aol.com Proud to claim 31:15 hours of TV viewing so far in 1994!

2 1

Re: Any news on the crypto export bill?
by jmdaluz＠kquest.com 17 Dec '03

17 Dec '03

Apologies if this appeared ealier on this list. ----- Begin Forwarded Message ----- From: "Shabbir J. Safdar" <shabbir(a)panix.com> Subject: URGENT: House Rules committee postpones vote until week of 7/11/94 Date: Wed, 6 Jul 1994 08:43:58 -0400 (EDT) Content-Length: 20437 Precedence: list To: eff-activists(a)eff.org (eff-activists mailing list) [updated July 6, 1994 with Rules Committee information, shabbir] [My apologies for the errors in the fax numbers. I still am unable to get the GPO to sell me an electronic copy of the Congressional Directory, so I end up playing "catchup". If you can help, let me know. I'll pay for the directory, I just can't navigate the gpo's terrible interface.. -Shabbir] [POTENTIAL ACTION SCHEDULED FOR THE WEEK OF JULY 11TH, 1994] [PLEASE CHECK THE "WHAT YOU CAN DO RIGHT NOW" SECTION!] ********************************************************************* DISTRIBUTE WIDELY ********************************************************************* Table of contents: Introduction & Alert Status of the bill What you can do right now List of legislators supporting HR 3937 (formerly HR 3627) List of legislators wavering on HR 3937 (formerly HR 3627) List of legislators opposing HR 3937 (formerly HR 3627) What is the Cantwell bill? ------------------------------------------------------------------------------- INTRODUCTION & ALERT Voters Telecomm Watch keeps scorecards on legislators' positions on legislation that affects telecommunications and civil liberties. If you have updates to a legislator's positions, from either: -public testimony, -reply letters from the legislator, -stated positions from their office, please send them to vtw(a)panix.com so they can be added to this list. General questions: vtw(a)panix.com Mailing List Requests: vtw-list-request(a)panix.com Press Contact: stc(a)panix.com Gopher URL: gopher://gopher.panix.com:70/1/1/vtw WWW URL: Be patient; we're working on it. :-) ------------------------------------------------------------------------------- STATUS OF THE BILL (updated 7/6/94) The Cantwell bill, that allows for fewer restrictions exports of cryptography, has an interesting history. It was rolled into the General Export Administration Act HR 3937. The House Foreign Affairs Committee passed the full strength version out of committee after open, public hearings. The House Intelligence Committee took the bill and gutted it after a day of closed, secret hearings. The gutted version is making its way to the House floor. There is a crucial stop-off point, however. The House Rules Committee planned to hold a hearing on 6/30/94 to determine if the bill can be amended on the House floor (an "open" bill) or not (a "closed" bill). *** The vote was put off, because in one member's words, "all the legislators *** went home early". This gives us more time to lobby! If they mark the bill as "open", then the Cantwell bill could be restored to its previous version, removing the language put in by the House Select Intelligence Committee which gutted it without a public hearing. YOUR LOBBYING HAS ALREADY WORKED! A constituent reported back to me that their legislator (Rep. Quillen) had taken a position on marking the bill as "open". In a land where legislators are loathe to offend, this is terrific! Call and urge your legislator to take a position in favor of "open"! This may be the last thing you can do for the cryptographic export legislation. Take the time to make a call! Chronology of the bill Jul 11, 94 House Rules Comm. reconvenes; possibly votes again this week Jun 30, 94 [*** vote postponed, perhaps till the week of 7/11/94] House Rules Comm. decides whether to allow amendments on the bill when it reaches the House floor Jun 14, 94 Gutted by the House Select Committee on Intelligence May 20, 94 Referred to the House Select Committee on Intelligence May 18, 94 Passed out of the House Foreign Affairs Committee on May 18 attached to HR 3937, the General Export Administration Act Dec 6, 93 Referred to the Subcommittee on Economic Policy, Trade and Nov 22, 93 Referred to the House Committee on Foreign Affairs. ------------------------------------------------------------------------------- WHAT YOU CAN DO RIGHT NOW Estimated time to do this good deed: Two minutes Show your support for HR 3937 (formerly HR 3627) by contacting a member of the House Rules Committee and ask them to mark the bill as "open" (allowing amendments) when it reaches the House floor. The phone numbers of the members of the House Rules Committee are listed below. Please pick one from your state and call them. If your state isn't listed please call the Chairman, Rep. Joe Moakley. Feel free to use the following sample communique: The Honorable ____________ address Washington DC, 20515 Dear Congressman or Congresswoman, Please mark the General Export Administration Act (HR 3937) as "open" (allowing amendments on the House floor). Recently the House Intelligence Committee removed several provisions of the General Export Administration Act, HR 3937, dealing with the export of cryptographic technology. The House Intelligence Committee did this in a closed, secret hearing which provided for no public input. The House Foreign Affairs Committee previously held an open hearing on the same issue and received a flood of people testifying in favor of the bill, which the committee then reported out in full. I urge you to allow the democratic process to take its course on the House floor and mark the bill as "open". Sincerely, _________________________________ Phone/Fax/Addresses of members of the House Rules Committee 103rd United States Congress, 1993-1994 All addresses are Washington, D.C. 20515 Dist ST Name, Address, and Party Phone Fax ==== == ======================== ============== ============== 9 MA Moakley, John Joseph (D) 1-202-225-8273 1-202-225-3984 235 Cannon UNSPECIFIED POSITION 3 SC Derrick, Butler (D) 1-202-225-5301 1-202-225-5383 221 Cannon UNSPECIFIED POSITION 24 CA Beilenson, Anthony (D) 1-202-225-5911 no reliable fax 2465 RHOB UNSPECIFIED POSITION 24 TX Frost, Martin (D) 1-202-225-3605 1-202-225-4951 2459 RHOB UNSPECIFIED POSITION 10 MI Bonior, David E. (D) 1-202-225-2106 1-202-226-1169 2207 RHOB UNSPECIFIED POSITION 3 OH Hall, Tony P. (D) 1-202-225-6465 1-202-225-9272 2264 RHOB UNSPECIFIED POSITION 5 MO Wheat, Alan (D) 1-202-225-4535 1-202-225-5990 2334 RHOB UNSPECIFIED POSITION 6 TN Gordon, Bart (R) 1-202-225-4231 1-202-225-6887 103 Cannon UNSPECIFIED POSITION 28 NY Slaughter, Louise M. (D) 1-202-225-3615 1-202-225-7822 2421 RHOB UNSPECIFIED POSITION 22 NY Solomon, Gerald B. (R) 1-202-225-5614 1-202-225-1168 2265 RHOB UNSPECIFIED POSITION 1 TN Quillen, James H. (R) 1-202-225-6356 1-202-225-7812 102 Cannon WILL VOTE FOR "OPEN" - CALL AND THANK HIM 28 CA Dreier, David (R) 1-202-225-2305 no reliable fax 411 Cannon UNSPECIFIED POSITION 14 FL Goss, Porter J. (R) 1-202-225-2536 1-202-225-6820 330 Cannon UNSPECIFIED POSITION ------------------------------------------------------------------------- LIST OF LEGISLATORS SUPPORTING CRYPTOGRAPHY EXPORT LEGISLATION The following legislators have formally registered support for cryptography export legislation. Call them with your cheers. All addresses are Washington, D.C. 20515 Dist ST Name, Address, and Party Phone Fax ==== == ======================== ============== ============== 1 WA Cantwell, Maria (D) 1-202-225-6311 1-202-225-2286 1520 LHOB HR 3627's sponsor; thank her for her work! 16 IL Manzullo, Donald (R) 1-202-225-5676 1-202-225-5284 506 Cannon Cosponsored HR 3627 on 11/22/93 3 UT Orton, William H. (D) 1-202-225-7751 1-202-226-1223 1122 LHOB Cosponsored HR 3627 on 03/22/94 3 OR Wyden, Ronald (D) 1-202-225-4811 1-202-225-8941 1111 LHOB Cosponsored HR 3627 on 03/22/94 16 CA Edwards, Donald (D) 1-202-225-3072 1-202-225-9460 2307 RHOB Cosponsored HR 3627 on 03/22/94 19 OH Fingerhut, Eric D. (D) 1-202-225-5731 1-202-225-9114 431 Cannon Cosponsored HR 3627 on 03/22/94 4 MA Frank, Barney (D) 1-202-225-5931 1-202-225-0182 2404 RHOB Cosponsored HR 3627 on 03/22/94 2 UT Shepherd, Karen (D) 1-202-225-3011 1-202-226-0354 414 Cannon Cosponsored HR 3627 on 03/22/94 3 WA Unsoeld, Jolene (D) 1-202-225-3536 1-202-225-9095 1527 LHOB Cosponsored HR 3627 on 03/22/94 19 FL Johnston II, Harry (D) 1-202-225-3001 1-202-225-8791 204 Cannon Cosponsored HR 3627 on 03/22/94 9 WA Kreidler, Mike (D) 1-202-225-8901 1-202-226-2361 1535 LHOB Cosponsored HR 3627 on 03/22/94 4 WA Inslee, Jay (D) 1-202-225-5816 1-202-226-1137 1431 LHOB Cosponsored HR 3627 on 03/22/94 7 WA McDermott, James A. (D) 1-202-225-3106 1-202-225-9212 1707 LHOB Cosponsored HR 3627 on 03/22/94 8 IN McCloskey, Frank (D) 1-202-225-4636 1-202-225-4688 306 Cannon Cosponsored HR 3627 on 03/22/94 14 CA Eshoo, Anna G. (D) 1-202-225-8104 1-202-225-8890 1505 LHOB Cosponsored HR 3627 on 03/22/94 10 NC Ballenger, Thomas C. (R) 1-202-225-2576 1-202-225-0316 2238 RHOB Cosponsored HR 3627 on 05/04/94 2 WA Swift, Al (D) 1-202-225-2605 1-202-225-2608 1502 LHOB Cosponsored HR 3627 on 05/04/94 ------------------------------------------------------------------------------- LIST OF LEGISLATORS WAVERING ON CRYPTOGRAPHY EXPORT LEGISLATION [Feel free to use the sample communique at the end of the FAQ when calling or writing a legislator.] 26 NY Hinchey, Maurice D. (D) 1-202-225-6335 1-202-226-0774 1313 LHOB Recently told a constituent that he is taking the Cantwell bill under consideration, but has "national security concerns" about allowing encryption to be exported outside the United States. 1 IA Leach, James (R) 1-202-225-6576 1-202-226-1278 2186 RHOB Has yet to answer a constituent letter with a stated position. 13 NY Molinari, Susan (D) 1-202-225-3371 1-202-226-1272 123 Cannon Has yet to answer a constituent letter with a stated position. (has taken inordinately long) 8 NY Nadler, Jerrold (D) 1-202-225-5635 1-202-225-6923 424 Cannon Met with lobbying constituent in April '94; no position taken yet 25 CA McKeon, Howard P. (R) 1-202-225-1956 1-202-226-0683 307 Cannon Responded to a constituent with a "non-position", May '94 Had a favorable meeting with a constituent and a VTW volunteer in May '94. ------------------------------------------------------------------------------- LIST OF LEGISLATORS OPPOSING CRYPTOGRAPHY EXPORT LEGISLATION [Feel free to use the sample communique at the end of the FAQ when calling or writing a legislator.] Dist ST Name, Address, and Party Phone Fax ==== == ======================== ============== ============== 5 AL Cramer Jr, Robert E. (D) 1-202-225-4801 1-202-225-4392 1318 LHOB FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 8 CA Pelosi, Nancy (D) 1-202-225-4965 1-202-225-8259 240 Cannon FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 32 CA Dixon, Julian C. (D) 1-202-225-7084 1-202-225-4091 2400 RHOB FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 40 CA Lewis, Jerry (R) 1-202-225-5861 1-202-225-6498 2312 RHOB FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 46 CA Dornan, Robert K. (R) 1-202-225-2965 no reliable fax 2402 RHOB FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 2 CO Skaggs, David E. (D) 1-202-225-2161 1-202-225-9127 1124 LHOB FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 10 FL Young, C. W. (R) 1-202-225-5961 1-202-225-9764 2407 RHOB FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 4 KS Glickman, Daniel (D) 1-202-225-6216 1-202-225-5398 2371 RHOB FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 1 NE Bereuter, Douglas (R) 1-202-225-4806 1-202-226-1148 2348 RHOB FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 9 NJ Torricelli, Robert (D) 1-202-224-5061 1-202-225-0843 2159 RHOB FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 3 NM Richardson, William (D) 1-202-225-6190 no reliable fax 2349 RHOB FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 1 NV Bilbray, James H. (D) 1-202-225-5965 1-202-225-8808 2431 RHOB FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 17 PA Gekas, George W. (R) 1-202-225-4315 1-202-225-8440 2410 RHOB FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 2 RI Reed, John F. (D) 1-202-225-2735 1-202-225-9580 1510 LHOB FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 14 TX Laughlin, Gregory H. (D) 1-202-225-2831 1-202-225-1108 236 Cannon FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 16 TX Coleman, Ronald D. (D) 1-202-225-4831 None 440 Cannon FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 19 TX Combest, Larry (R) 1-202-225-4005 1-202-225-9615 1511 LHOB FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 1 UT Hansen, James V. (R) 1-202-225-0453 1-202-225-5857 2466 RHOB FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. 6 WA Dicks, Norman D. (D) 1-202-225-5916 1-202-226-1176 2467 RHOB FAILED Cryptography exports: Voted to kill Rep. Cantwell's export provisions in the House Intelligence Committee on 6/15/94. ------------------------------------------------------------------------------- What is the Cantwell bill? The Cantwell bill would permit companies to export products with encryption technology in them. US companies are currently not permitted to export products (hardware or software) with this technology in them. What is encryption technology? Encryption technology, or cryptography, is the art of scrambling a conversation so that only the people communicating can decode it. Other people (such as eavesdroppers) cannot learn about the conversation. Where is cryptography being used? Cryptography is used to encrypt electronic mail to protect its confidentiality in transit. It's used by bank automatic teller machines to protect sensitive data (such as your account number, your Personal Identification Number, and your bank balance). It can be implemented into software (such as electronic mail programs and word processors) as well as hardware (such as telephones and "walkie-talkies") to ensure your privacy. Why is there a restriction on exporting products with technology in them? For many years the United States was a leading researcher in cryptography. High quality cryptographic technology was available only within the United States. The US government thought that if they did not let this technology be exported, foreign individuals would not be able to obtain it and use it against us (by keeping US intelligence agencies from eavesdropping on their communications) Since then, cryptography research has been published in international journals. Companies have been created throughout the world who export cryptographic technology from countries that do not have these restrictions. You can now buy the same, high-quality cryptographic technology from many international firms. Although the marketplace has changed, the regulations have not. Why should the regulations be changed? US companies compete in a global marketplace. Because of the export regulations, they often compete alongside products with superior cryptographic capabilities built into them. The result is that US companies build their products with an inferior encryption technology. The result of this is that you, as an American consumer, have great difficulty obtaining products with strong encryption in them. Because US products cannot compete against products with better privacy features, and because the laws are outdated, the regulations should be changed. The Cantwell bill fixes these regulations to more accurately resemble the current situation of the world marketplace. How can I help encourage more privacy-enhanced products and pass the Cantwell bill? Call or write your representative and ask them to support or cosponsor Rep. Cantwell's export provisions (formerly HR 3627) in the General Export Administration Act, HR 3937. You can base your letter on the sample communication below. SAMPLE LETTER OR PHONE CALL The Honorable ____________ address Washington DC, 20515 Dear Congressman or Congresswoman, As a citizen concerned for my privacy, as well as a supporter of American business, I urge you to cosponsor the Rep. Cantwell's cryptographic export provisions (formerly HR 3627) in the General Export Administration Act, HR 3937. The bill would allow US companies to produce and export products with cryptographic privacy-enhancing technology in them. These products are already available from firms throughout the world. US companies lose nearly $100 million per year in exports to them. By encouraging this industry, ordinary citizens like you and me would be able to purchase products with better privacy features. Please support or co-sponsor HR 3937. Sincerely, ___________________________________ ------------------------------------------------------------------------------- ----- End Forwarded Message ----- Jose M. daLuz KnowledgeQuest Online Research jmdaluz(a)kquest.com (508) 996-6101 (vox) (508) 996-6215 (fax)

1 0

Another detweiler testicle?
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

Have a look at postings by 'berzerk(a)xmission.com' in several groups including talk.politics.crypto - has every sign of being classic Detweiler. We'll know soon enough if he turns up here too, though he seems to be enjoying his 10 minutes of fame on usenet more nowadays since he discovered news.admin.policy et al. G

2 1

LAW STUDENTS?
by Sandy Sandfort 17 Dec '03

17 Dec '03

C'punks, If anyone on the Cypherpunks Channel is *currently* a law student, please contact me via private e-mail. I have an favor to ask of you. Thanks, S a n d y

1 0