- cypherpunks-legacy - lists.cpunks.org

Instant Internet
by Tim Philp 17 Dec '03

17 Dec '03

Has anyone had any experience with Instant Internt - a networking/firewall program? I have a client who is interested in this software and is concerned about security. I have little info other than sales noise and I would like an opinion from someone who has actually used it. Thanks Tim Philp =================================== For PGP Public Key, Send E-mail to: pgp-public-keys(a)swissnet.ai.mit.edu In Subject line type: GET PHILP ===================================

1 0

ViaCrypt PGP 4.0 for Windows shipping
by Alan Olsen 17 Dec '03

17 Dec '03

I have not seen this here yet, so sorry if you have seen it... ViaCrypt is claiming that they are now shipping the Windows version of their PGP 4.0. (I tend to not believe marketing claims until I hear from people who actually have it.) Does anyone know if there are plans for this version to be interoperable with PGP 3.0? Furthermore, has anyone tried the new version? --- Alan Olsen -- alano(a)teleport.com -- Contract Web Design & Instruction `finger -l alano(a)teleport.com` for PGP 2.6.2 key http://www.teleport.com/~alano/ "We had to destroy the Internet in order to save it." - Sen. Exon

5 4

Re: So, what crypto legislation (if any) is necessary?
by liberty＠gate.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Tim May wrote: [...] >> However, what if Joe is _also_ one's >> lawyer? Does attorney-client privilege apply here? Perhaps.... and Professor Froomkin responded: >NO IT DOES NOT. Basic rule of thumb: your lawyer can't be used to hide >papers someone else can't hide. Ok, at the margin it gets tricky, but >bascially the privilege is not going to stretch to your key. Professor Froomkin is right (IMO) but I think that the way he puts this understates the size of the margin when it comes to cryptokeys. If I were a US Attorney, I would bide my time and pick a hard case, involving lots of potentially incriminating (and therefore tempting) encrypted files, an available key, and (at least) two horsemen. The unavailability of the key can then be presented as a "technicality," allowing a bad guy to possibly get off. After I get some precedent it can then be streched over those inconvenient provisions in the Bill of Rights. This is how "hard cases make bad law." >> solution is also fully legal at this time: use only offshore key storage. >> A >> U.S. subpoena to Vince's Offshore Key Repository will carry no weight in >> Anguilla. (Can I be compelled to ask Vince to send my key? Sure. But Vince >> and I could have a stipulation that such "duress requests" will not be >> honored, no matter how loudly I squawk.) > >An interesting issue, likely to be addressed in future judicial >assistence treaties... I agree, but if I were sitting at Anguilla's side of the table (I won't be, and I have no idea what they will do) this point would be a *very* expensive one. Anguilla and other tax-haven countries have little to gain and much to lose by becoming less friendly to the financial privacy of the Vince Cates of this world. JMR Regards, Jim Ray <liberty(a)gate.net> "Isn't it true that the exponential and incredible growth of the Internet came about because the government kept their hands off of it?" -- Judge Stewart Dalzell. _______________________________________________________________________ PGP key Fingerprint 51 5D A2 C3 92 2C 56 BE 53 2D 9C A1 B3 50 C9 C8 Public Key id. # E9BD6D35 -- http://www.shopmiami.com/prs/jimray _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Freedom isn't Freeh. iQCVAwUBMVf2321lp8bpvW01AQGJnQP8DAhTpnU2memnJta0muU1K2d0N7nhgCwK FCR0R5N6VCJbYu4rXovTlSXevWOkCOPasbZ6DKCzDGHFzQc9KUyc1FCbB4tlYqCr taGXcNKkYafQYF9VBGxUcuOhCb04TvOV1r3+QGqQ7OFvNJppF1YEsUBaO3MclFGW nDetMEwEtJI= =Mu5a -----END PGP SIGNATURE-----

1 0

N$ SSL vs M$ PCT
by rah＠shipwright.com 17 Dec '03

17 Dec '03

--- begin forwarded text From: "John Hemming CEO MarketNet" <JohnHemming(a)mkn.co.uk> Date: Sun, 01 Oct 1995 20:36:31 PM PDT To: www-buyinfo(a)allegra.att.com Mime-Version: 1.0 Subject: N$ SSL vs M$ PCT Having found that Micro$oft have produced a standards document about their alternative to SSL I was interested in comparing it to that written by Net$cape. The big question in my view is why did they produce a new proposal is it: a) Because they have found major flaws in the SSL protocol and wish to correct these (note the protocol not the implementation) or is it b) Because M$ want to "own" the Internet Security Software market and take the initiative off N$ who, notwithstanding their problems with implementation, have produced a working system. My personal view is that b) is the case. Comparison I have compared SSL V3 <draft-hickman-netscape-sl-01.txt> (available at www.netscape.com) PCT http://www.microsoft.com/windows/ie/pct.htm <draft-microsoft-PCT-91.txt> Both have status of Internet Draft. I have implemented SSL V2 in a browser (ftp://193.119.26.70/mktnet/pub/horse.zip) and a server (https://alpha.mkn.co.uk/) I have not implemented and do not intend implementing PCT Both SSL V3 and PCT now involve a vast number of different alternatives for Ciphers most of these alternatives do not help in any practical sense and I have not compared the lists. PCT allows for supporting SSL as well by using a bit in the SSL version number to indicate PCT. This means that servers can support both protocols. Clients cannot as the first message is sent by the client and there is no provision for SSL/PCT negotiation. Both PCT and SSL start with an initial session (GET or POST in wwwland) which establishes a master key and allow continuations of that key in later sessions. M$ use the following arguments in support of PCT: 1. it is simpler. PCT uses longer messages with more fields in them. It cuts out the final SERVER-FINISHED and CLIENT-FINISHED messages. It puts some of the data in SSL into other records. I quite like the verification in the CLIENT-FINISHED message which means that bad implementatations crash out at that point rather than putting rubbish into the higher level protocol. However, I consider that in essence there is no real difference. I, therefore, disagree with M$. 2. Message authentication uses different keys to the encryption keys. How this helps, apart from making implementation harder, I cannot quite fathom. We should not be using this secure channel protocol for proper message authentication only. The MAC (Message Authentication Code) is not what I would use for authentication from a legal and contractual background. I prefer Digitally Signed Instructions. 3. They say there is a security hole in SSL's client authentication. When the initial session establishing a session key uses (for example) 40 bit encryption. It does mean that subsequent sessions are also essentially just as insecure. This is the case for PCT and SSL. However, client authentication in SSL uses a digital signature using the client's private key. To get hold of this requires something more than simply being man in the middle. I think M$ are well out of order on this one. 4. They introduce a verify prelude field to make sure that the cipher type and other negotiations have not been tampered with. I suppose this is a fair if disingenuous point. If a "man in the middle" is tampering with your negotiations to make sure that you use a low level of encryption so that it can be cracked then your implementations should not be using such crippleware and cypherpunks will have cracked it ages ago. There is a point that should be made that servers and clients should really indicate the encryption cipher being used. Both my client and server do. So in essence M$ make 4 arguments. Two are IMHO wrong. One is irrelevant from a commercial perspective and the other one does not matter. In the end N$'s version is working. M$ are probably coding like mad. The final formula to determine the result may be if (M$>N$) SSL+=PCT; where M$ and N$ are measured in US Dollars. (MarketN£t is a UK company independent of both M$ and N$ although N$ were helpful in debugging the interoperability of my early essays into SSL for which I am grateful.) --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

Re: So, what crypto legislation (if any) is necessary? (Was List O' , shame)
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 9:20 PM 3/25/96 -0800, Simon Spero wrote: >On Mon, 25 Mar 1996, Bill Frantz wrote: > >> At 1:32 PM 3/25/96 -0500, Black Unicorn wrote: >> to type them. Since storage was limited, and old messages were purged from >> the system it also had the effect that anti-trust discovery would have >> nothing to discover. > >Hmmm - that's another issue; what about diffie hellman with ephemeral >keys? Once the transaction is complete, unless you keep a copy of the key, >even you can't decrypt that session. Would a law requiring you to keep a >copy of the keys be important. It would have the advantage of allowing >a sub-poena to be more restrictive than "just hand over your private >key", but it's a pretty heavy (undue?) burden. With PGP at least, it should be possible to hand over the IDEA key required to decrypt each message in question without having to hand over your private key. Since the court would have your public key, they could verify that the IDEA key you gave them was indeed the correct key. Of course if they are using the subpoena to intimidate you, then they will insist on the private key. N.B. The IBM voice system mentioned above (and the attribution should be to me, and not Black Unicorn) did not use any crypto. Bill ------------------------------------------------------------------------ Bill Frantz | The CDA means | Periwinkle -- Computer Consulting (408)356-8506 | lost jobs and | 16345 Englewood Ave. frantz(a)netcom.com | dead teenagers | Los Gatos, CA 95032, USA

1 0

No Subject
by anon-remailer＠utopia.hacktic.nl 17 Dec '03

17 Dec '03

Subject: HP ships full DCE internationally As I sit, somewhere not in North America, I can see a CD-Rom from Hewlett-Packard, which I've had since last year. Recently I received the following letter. I've attempted to retype its contents accurately. ---------8<--------8<--------8<--------8<--------8<--------8<--------8< [HP Logo] Hewlett-Packard Company Software and Information Delivery Operation, SST 690 East Middlefield Road Mountain View, California 94043 415/968-9200 Dear HP-UX Support Customer, Hewlett-Packard has uncovered a bundling problem in the DCE-Core fileset that is on the October HP-UX Application Release 10.0 s700/800 Application CDs. These products were bundled such that they are not compliant with U.S. Government export regulations. The part numbers for the affected CDs and products are listed below. If you have updated your systems using these CDs or for the products listed on the October HP-UX Application Release Media, please update your system with the enclosed January HP-UX Application Release 10.0 s700/800 Application media, and destroy the October media. If you have not updated your systems with this media, please just destroy the October Application Release media and use the new enclosed Application media. If you require a replacement for the October HP-UX 10.0 s700/800 Application CD that has this bundling problem corrected, please contact your local support office to request shipment of the new CD. Hewlett-Packard apologises for any inconvenience you may experience due to this bundling issue. Sincerely [signed] Charles Henderson Software Information and Delivery Operations CD PART NUMBERS --------------- 24998-11710 SE application s700 10/95 24998-11711 SE application s800 10/95 B3782-10054 Trade application s700 10/95 B3920-13614 Trade application s800 10/95 PRODUCT NUMBERS --------------- 10.01 800 B3191A DCE CORE SRV MEDIA/DOCU INTL 10.01 800 B5162AA DCE 9000 Executive Client 10.01 800 B3519AA DCE QUICK START KIT INTL S800 10.01 800 B3923AA CICS/9000 Bundle Media & Manuals, Int'l 10.01 700 B2921A DCE Core Services International 10.01 700 B5162AA DCE 9000 Executive Client S700 10.01 700 B3519AA DCE Quickstart 700 Bndl Int'l Document P/N: 5964-5231 ---------8<--------8<--------8<--------8<--------8<--------8<--------8< Excuse me, I just have to go and destroy that CD :-)

1 0

trouble with idea.c from cryptl99.zip
by Jack Mott 17 Dec '03

17 Dec '03

Hey, I downloaded the crypto lib 'cryptl99.zip' from one of the crypto web sites, I got IDEA.C to compile, but it doesn't seem to encrypt. The test code that comes with it shows the sub-key groupings, then it does this X 0 1 2 3 4 5 6 7 Y 0 1 2 3 4 5 6 7 Z 0 1 2 3 4 5 6 7 It looks like X should be the plaintext, Y the ciphertext, then Z the plaintext again from the code, but it isn't working. If anyone knows the source code I am talking about let me know what is wrong. Here is what the main piece looks like: printf("\n Encrypting %d bytes (%ld blocks)...", BLOCKS*16, BLOCKS); fflush(stdout); start = clock(); memcpy(YY, XX, 8); for (l = 0; l < BLOCKS; l++) ideaCipher(YY, YY, EK); /* repeated encryption */ memcpy(ZZ, YY, 8); for (l = 0; l < BLOCKS; l++) ideaCipher(ZZ, ZZ, DK); /* repeated decryption */ end = clock() - start; l = end / (CLOCKS_PER_SEC/1000) + 1; i = l/1000; j = l%1000; l = 4; // (16 * BLOCKS * (CLOCKS_PER_SEC/1000)) / (end/1000); printf("%d.%03d seconds = %ld bytes per second\n", i, j, l); printf("\nX %3u %3u %3u %3u %3u %3u %3u %3u\n", XX[0], XX[1], XX[2], XX[3], XX[4], XX[5], XX[6], XX[7]); printf("\nY %3u %3u %3u %3u %3u %3u %3u %3u\n", YY[0], YY[1], YY[2], YY[3], YY[4], YY[5], YY[6], YY[7]); printf("\nZ %3u %3u %3u %3u %3u %3u %3u %3u\n", ZZ[0], ZZ[1], ZZ[2], ZZ[3], ZZ[4], ZZ[5], ZZ[6], ZZ[7]); from this, Y should be encrypted, but it isn't! Thanks in advance for any help. -- thecrow(a)iconn.net "It can't rain all the time"

1 0

RE: ITAR double standards?
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 6:13 AM 3/26/96, blanc wrote: >From: Timothy C. May > >I think there's been ample evidence that the ITARs are often used to harass >U.S. companies that "won't play ball," that refuse to go along with certain >governmental policies. (Part of the think we libertarians hate about Big >Government and Lots of Laws is that government can use selective >enforcement an another lever of power. As a felon, I am acutely aware of >this power.) >............................................................................ > >You're a felon? For real? > Yes. --Tim THE X-ON CONGRESS: INDECENT COMMENT ON AN INDECENT SUBJECT, by Steve Russell, American Reporter Correspondent....You motherfuckers in Congress have dropped over the edge of the earth this time... "the sorriest bunch of cocksuckers ever to sell out the First Amendment" or suggesting that "the only reason to run for Congress these days is to suck the lobbyists' dicks and fuck the people who sent you there," ....any more than I care for the language you shitheads have forced me to use in this essay...Let's talk about this fucking indecent language bullshit.

1 0

Re: So, what crypto legislation (if any) is necessary?
by Duncan Frissell 17 Dec '03

17 Dec '03

At 09:46 PM 3/25/96 -0500, Michael Froomkin wrote: >An interesting issue, likely to be addressed in future judicial >assistence treaties... > However, future judicial assistance treaties are meaningless if you store your keys anonymously (domestically or internationally) so that even the keeper doesn't know he has them or exactly where they are in his pile of keys. In general, I think that we should attack government key escrow on economic efficiency grounds by pointing out that it is unlikely that "socialized key escrow" would do as good a job as private enterprise key escrow. The Stalinist method of industrial production, is well known for its inefficiencies and similar inefficiencies attach to government key escrow. In fact, I suppose that government operation of the identification system (drivers' licenses, passports, etc.) in general is also horribly inefficient and should be attacked on efficiency grounds. DCF

2 1

Re: About Triple DES ......
by Bill Stewart 17 Dec '03

17 Dec '03

At 02:24 PM 3/26/96 -0600, you wrote: > Please let me know if TRIPLE DES is regulated by the same rules than >the others criptography systems in USA. > We want to use it here in National Autonomous University of Mexico, so >we don't want to get jailed. I don't know about Mexican law. US persons are not supposed to export it without government permission, but that's not very relevant. Mexican law may or may not restrict import or use of crypto; better check with someone local. (I haven't heard anything saying that it _does_ restrict it - I just don't know either way.) > In case we can use it somebody knows where can i get the source code ?? That part's easy - DES source is available on ftp.ox.ac.uk, and also on ftp.dsi.unimi.it and ftp.funet.fi. There may be specific triple-DES code there, but if not, triple DES is just Encrypt(Key1, Decrypt(Key2, Encrypt(Key3, Message))) so you can easily write a subroutine to do that. #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com, +1-415-442-2215 pager 408-787-1281 1995: Chat rooms, espresso, and Linux 1996: Exon, melatonin, and Java.

2 1