December 2003 - cypherpunks-legacy

Re: GUI: PGP vs novices
by lbilling＠interserv.com 17 Dec '03

17 Dec '03

>The product works at the Windows Sockets layer, intercepting mail as it is >sent from the mail application to the SMTP host, and performing the above >crypto related functions based on text placed at the top of the mail message. [ Some Deleted ] >A major complication that I've come up against is installation. Somehow >I've got to provide a painless way of discovering the Winsock stack in use >on a machine, and installing my WINSOCK.DLL so that it gets loaded instead >of the real one (which my software then loads on its own and intercepts >calls to.) >This is really easy to do manually when one has knowledge of such things; it >is a major pain in the ass to come up with a way of doing this that doesn't >require the user to know anything about Windows Sockets or DLL's or path >variables, etc. There is also the problem that a number of applications (such as Internet in a Box) require there own Winsock to make connections to the Internet. If you replace the Ibox winsock with another, when you run the programs they will no longer call the dialer to dial into the Internet. I believe the same holds true for Trumpet. Wassail, Al Billings

1 0

Re: GUI: PGP vs novices
by Johnathan Corgan 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >There is also the problem that a number of applications (such as Internet in >a Box) require there own Winsock to make connections to the Internet. If you >replace the Ibox winsock with another, when you run the programs they will >no longer call the dialer to dial into the Internet. I believe the same >holds true for Trumpet. I only have familiarity with the commercial Netmanage Chameleon Winsock implementation. Someone else had let me know about this potential difficulty. Apparently some Winsock stacks only provide a WINSOCK.DLL for 3rd party compatibility, i.e., their own applications talk to proprietary hooks into their stack for performance or other reasons. Netmanage's products do both; they perform their network I/O through WINSOCK.DLL, but also use a variety of shared library functions supplied with the rest of the stack. In this case, my WINSOCK.DLL shim works fine. Remember, I'm not replacing a given implementation's DLL, just intercepting and passing through calls to it. So as long as a mail application uses exclusively standards based Windows Sockets API calls _to perform network I/O_, my product should work. YMMV, of course :) ======================================================================= Johnathan Corgan "Violence is the last refuge of the incompetent" jcorgan(a)netcom.com -Isaac Asimov PGP Public Key: http://www-swiss.ai.mit.edu/~bal/pks-toplev.html Or send email to: pgp-public-keys(a)pgp.ai.mit.edu Subj: GET jcorgan ======================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLvtW4k1Diok8GKihAQEjngP7BRUatySeVmJ2SvDLycMYtCTh5obyvAZ4 nLxhP69VUCs1LprfMVWIsL46WsS/neiVpf3Wor0T/kzLrb0s/0m3a8+GQhdz7te9 NRQbJGfJG57KR1yCBHMk2/HSDjVR0daCQVQCcJFTqw2aOXfWo6x20ZZqQvR1N2Ju U57UIG9BRG4= =Xm6z -----END PGP SIGNATURE-----

1 0

Norton encryption and privacy
by Greg Broiles 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This was posted to USENET several months ago. Diskreet is a PC-based device driver which creates a virtual encrypted partition on a normal hard disk partition. I don't know if they use the same algorithms in Norton Encrypt or not. Snooping in other people's files still sucks. ----- From: pgut1(a)cs.aukuni.ac.nz (Peter Gutmann) Newsgroups: sci.crypt,comp.security.misc Subject: Norton's [In]Diskreet: An update Followup-To: sci.crypt Date: 13 Jul 1994 17:21:57 GMT Organization: University of Auckland Lines: 96 Sender: pgut1(a)cs.aukuni.ac.nz (Peter Gutmann) Message-ID: <3017rl$8j4(a)ccu2.auckland.ac.nz> NNTP-Posting-Host: cs13.cs.aukuni.ac.nz X-Newsreader: NN version 6.5.0 #7 (NOV) Last November I picked apart part of the Diskreet encryption program and posted what I found to this group. By some miracle I had a bit of spare time this afternoon, so I've had another quick look at it. The result is some more information on the proprietary encryption algorithm and the file format it uses. First, a recap of what I presented last time: The key setup process is very badly done. The front-end gets a password in the range of 6..40 characters, and converts it to all-uppercase. Then it packs it into a struct along with a collection of other information and passes it to the DES library used by Diskreet. The first thing this does is take the password and reduce it to 64 bits by cyclically xor-ing the full-length password into an 8-byte buffer initially set to all zeroes, ie: for( index = 0; password[ index ]; index++ ) buffer[ index % 8 ] = password[ index ]; It then performs what looks like a standard DES key schedule with the 64-bit output from this operation. This creates 128 bytes of subkeys for encryption and 128 bytes of subkeys for decryption. These are either used for the proprietary encryption method or for DES encryption. Here's a rundown of the proprietary method: All operations are performed on 16-bit words. byteSwap() performs an endianness-reversal on a word. Chaining is performed by xor-ing in the previous ciphertext word. The keyTable is the 256-byte array of DES subkeys, treated as an array of words. data[ -1 ] = 0x1234; index = sectorNo % 128; index = keyTable[ index ] % 128; for( i = 0; i < SECTOR_SIZE / 2; i++ ) { value = keyTable[ index++ ] + data[ i ]; byteSwap( value ); value ^= data[ i - 1 ]; data[ i ] = value; index %= 128; } As can be seen, a known-plaintext attack will recover the (expanded) encryption key without too much trouble - it's just a repeated addition of a 128-word array to the data, with the previous word xor'd in for chaining purposes. The xor and byteSwap are basically nop's and can be stripped off without any problems, revealing the key stream used to encrypt the data. Since encryption is done by sectors, the same key data is used twice for each sectors. How do we perform a known-plaintext attack? It's quite simple actually, since Diskreet itself provides us with about as much known plaintext as we need. The file format is: General header BYTE[ 16 ] "ABCDEFGHENRIXYZ\0" char[ 13 ] fileName LONG fileDate BYTE fileAttributes LONG fileSize LONG file data start BYTE[ 16 ] 0 File data BYTE[ 32 ] 0 Padding to make it a multiple of 512 bytes Everything from the 16-byte magic value to the end of the file is encrypted in blocks of 512 bytes. The proprietary scheme will directly reveal its key stream on the 16-byte check value, the 16 bytes of zeroes at the start, and the 32 bytes (minimum) of zeroes at the end of the data. Interestingly enough, the presence of the 16-byte known plaintext right at the start would tend to confirm the rumours that that's one of the criteria for having an encryption program approved by the NSA. The plaintext also gives us the name of one of the programmers involved. In my previous posting I said: The encryption itself uses DES in CBC mode with a fixed IV. This means that, in combination with the tiny key space, it's possible to create a precomputed collection of plaintext/ciphertext pairs and "break" most encrypted files by reading the results out of a table. The 16-byte known plaintext makes this attack a certainty. In addition, if two pieces of data are encrypted with the same key, one with the proprietary method and one with DES, the DES key can be recovered from the proprietary-encrypted data and used to decrypt the DES-encrypted data. Again quoting from my previous posting: In summary, there may be a correct DES implementation in there somewhere, but it doesn't help much. [In]Diskreet will stop a casual browser, but won't give you any protection at all against any serious attack. Peter. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLvtYIH3YhjZY3fMNAQHeYAQAmNUJA9TfNQAJ+5jwbGDFbFtgjFVg1Gyn /RgAou3GuQvVRpmTqurVUWN8wzUCluj6ouU39ct2DEoyMHLFgkCdTcxDcSIS8Tpz yb9yPkI2Sr2uJ8dE5kuN29v0D3Nq4vW3a8jhRi2oJC3WbAaWYuoCQees8/wxfOfy 4bDPouwTBYc= =Rx5b -----END PGP SIGNATURE-----

1 0

Internet Service
by success＠network2.net 17 Dec '03

17 Dec '03

If you wish to be removed from future mailings, please reply with the subject "Remove" If we showed you how to receive FREE Unlimited Internet Access to the World Wide Web, 24 hours a day, 7 days a week, with super fast worldwide connectivity and included your own personal e-mail address and the hosting of your web site (up to 10 MB), along with Toll-Free technical support... Woul you be interested? If we told yuou the opportunity to receive FREE Unlimited Internet Access included excellent residual income potential... could you use the extra money? And providing all this came with an Unconditional 30-Day Money Back Guarantee to try our service... Would you take a test voyage? If you are like everyone else, the Answer is Yes! Please visit our web site to find out more... http://www.network2.net/~success

1 0

B-PGP: news/requests
by ddt＠lsd.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Note: I'm meta-prefixing this "B-PGP" to indicate the "Beginner-PGP" thread. At 10:37 am 12/21/94, bshantz(a)spry.com wrote: >It is my own personal opinion that in order for crypto to truly become >mainframe, the software manufacturers of internet connectivity packages must >integrate crypto into the applications. [elided] FYI, any of you who haven't heard should be pleased to know that Steve Dorner is working with Zig Fiedorowicz on integrating ViaCrypt PGP/Mac functions into Eudora (on the Mac, at least, which is a good starting point). This is a major step forward, since Eudora is so POPular :) and this could certainly increase sales of ViaCrypt's s/w as well. In the meantime, I'm looking at the AppleEvent scripts that have been made public and will make comments on them soon. Anyone who's up-to-date on current Mac or Windows version development (Hal Hildebrandt?) is encouraged to contact me, per Phil's request. I just want to make sure everyone gets what they need and that the left hand knows what the right hand is doing, etc. I'll set up an FTP directory "somewhere" for a central repository if anyone feels it's necessary (location to be announced elsewhere). BTW, I'm starting work on a Beginner's PGP-FAQ and would appreciate any question/answer pairs anyone would care to submit. Please keep them simple: they are aimed at an AOL-ish user level. The final document should be extremely non-technical, non-threatening and about three pages long maximum. In it, I will describe the History of the Entire Cryptographic World in 4000 words or less. :) I'm calling the 3-Minute Shakespeare Troupe next week for pointers on how to accomplish this... Speaking of AOL, does anyone know anyone on the current Internet development team there? I used to exchange email with some internet-oriented guys there back in '90-'91 but I wonder if anyone is in current contact - I'd like to discuss the possible integration of PGP into the AOL client software. That would effectively put PGP in a couple of million users hands PDQ. With all the bidness activity there of late, it seems to me there's a need that could be filled quite nicely. >In order to bring crypto to the masses, we have got to convince people that >it is necessary. We also must make it"second nature". It sure is nice to have >a menu option or a toolbar button that will encrypt plaintext automatically. >Key management and some of the "high tech" (I know, for us it's nothing, but >for my dad who just bought a computer and doesn't understand the difference >between click, double click, and drag, crypto is a really high tech thing >just in itself.) Notice Brad didn't even mention his MOM yet. I once tried to explain PGP to my Mom. "That's very nice, dear," was about the breadth of her reaction, but I still put a box on her desk and set her up with a key, even if she won't use it yet (ever? hey, she's a mom, Okay?). Now, if it was a real point-n-click maneuver, it might have a snowballs' chance in hell with her, but until then... >things of crypto should not be directly handled by the user. >(Optional >of course. On a privacy level, the user should have full control. Indeed. I'm hoping the upcoming versions of mainstream PGP (Mac/Win) will allow for a bit more modularity in the apps. I.e. it would be nice if you could "plug in" various functions, so that you could build up the app's features as a user gained more sophistication, but this may be way beyond the v3.0 scope. More on this idea later, as it more directly relates to system software extensions than PGP application stuff. >But give the user a break...if the software is secure..as such...so is the >user's privacy.) > >You will notice that this message is not signed. That's because in order to >sign it, I would need to save my message, hop out to a DOS box, PGP encrypt >it, hop back to my mail program and insert the encrypted mail as a text file. >That's enough to discourage the average user. This is pretty much what Tim >May was talking about when he discussed why he doesn't sign his messages. >It's not that he couldn't... it's just not practical for him. It's not >>really practical for me either, but I do it when I feel it's necessary. > >The only way to make crypto practical is to basicalloy hide the technical >side from the user and make it easy. Let me describe briefly for you all (and everyone is encouraged to type up a similarly brief log of what they do on their machines so we have a UI comparison table) what I deal with when I encrypt a msg on the Mac. Keep in mind that I have worked very hard to streamline the process as much as possible, and that this is before installing the AppleEvent scripts. It's not difficult for me, but for someone without a clue... well, they get two steps in, stare at the screen and eventually bag it. type msg body (in Eudora). select text copy to Mac clipboard (system) switch to PGP with macro Encrypt (or Sign) menu command [PGP reads the clipboard here, a wonderful improvement thanks to ...Zig?] enter passphrase [PGP outputs encrypted text to clipboard, wipes temp file] macro back to Eudora. paste clipboard back into msg body Now, all of this is easily scriptable: I once did it with a long complicated macro, but it was s l o w, so I bagged that idea - it didn't even use system level events. I'm hoping the new AE scripts will handle most of this, but it SHOULD all be done in the application layer by Eudora with direct calls to PGP in the bg (see above annc re Steve Dorner), which is the current direction. Let's hope ViaCrypt's new AE support will allow for this (Zig? hello?). IMPORTANT: Anyone currently working on an PGP versions is hereby requested to mail me regarding the coordination of development efforts. Mail Phil with questions about this. ALSO: There will/should be a group discussion at the upcoming physical meeting on the 14th which both Phil and I will be attending. Please bring your keys/laptops/floppies for signing. Over and out, dave ________________________________________________________________________ Speaking of "term limits," hasn't Rush Limbaugh gotten enough attention? -----BEGIN PGP SIGNATURE----- Version: 2.6ui iQCVAgUBLvtabKHBOF9KrwDlAQFYkAQAiKcjZx5iCzn0CLIBY5/TzVOY8sl7Jclo v6MSPdNdU3ONTBLtDlI3HbSnq/SqGyJxkgxex7aLaICwB+RUsE2TMnJ2PBXD1W0T 48eqQZT3IhT35gEfV3RQnYllIS4mhEWxzq8KFMPwdCjlNrF794TqZFgBadWZL+LR 4hXhnrTuB5A= =/bL0 -----END PGP SIGNATURE-----

1 0

CERN HTTPD proxy info
by Johnathan Corgan 17 Dec '03

17 Dec '03

Could someone please post the address/port for the HTTP proxy at CERN? Thanks, Johnathan

1 0

DDJ article on RC4
by nobody＠jpunix.com 17 Dec '03

17 Dec '03

Putting the Genie Back in the Bottle What had all the earmarkings of a major-league food fight sure didn't take long to dry up and blow away. Triggering the flap was an internet posting of source code that implemented the RC4 algorithm, an act that knocked on all kinds of legal doors - trade secrets, Internet-host liabilities, reverse engineering, shrink-wrap licensing, export control. You name it. The problem is that RC4, the block-cipher encryption algorithm at the heart of RSA Data Security cryptography, is protected as a trade secret. But some on the net say the online posting let the genie out of the bottle - RC4 was made public and available for anyone to use, RSA's claims notwithstanding. RSA counters that the company used trade-secret law simply to protect its intellectual property, and there's never really been any "secret" about the algorithm. Anyone willing to sign a nondisclosure agreement acknowledging RC4's trade-secret status could have ready access to the reference and source code. Among companies which have licensed RC4-based tools from RSA are Microsoft, Novell, Apple, and Lotus, all of which distribute RC4-based binary files in shrink-wrapped applications. You can imagine the furor when an unidentified person (or persons) used an anonymous remailer to post worldwide - first to a cryptographer mailing list, then to a newsgroup - source code that was supposedly RC4. Subsequent testing by programmers and cryptographers confirmed that the code was indeed compatible with "real" RSA RC4 code. RSA Data Security responded by calling in everyone from the U.S. Customs Service to the Federal Bureau of Investigation. In a strongly worded warning on the net, RSA said it considered the posting "a violation of law ... [and] ... a gross abuse of the Internet." If the person(s) who posted the source code had in fact signed an RSA nondisclosure agreement, the issue seems pretty clear-cut. They broke the law, not to mention RSA's trust. If, as some claim and RSA disputes, the code was reverse-engineered from object files in off-the-shelf software, then the law was probably broken - unless RSA and other vendors decide to test the strength of highly questionable and likely unenforceable shrink-wrap licenses that try to prohibit disassembly/decompilation. Of course, it just might be that some cryptographer derived the algorithm after examining the key, plaintext, and ciphertext. And there's even the chance, albeit unlikely, that a dumpster diver ran across discarded copies in RSA's corporate wastebasket. Questions concerning the legal status of copyrighted material that's made freely available (illicitly or otherwise) on the Internet also have to be tackled. Can Internet hosts be held accountable for an anonymous postings of protected material? And don't forget, RC4 isn't just any software - it's ENCRYPTION software. Is posting such software online worldwide the same as exporting it? If so, the State Department might have a thing or two to say. The end result is that RC4 code is available on ftp sites worldwide, ready and waiting for you to use it. But if you grab it off the net, can you use it without RSA's permission? For the time being, the answer probably depends on which lawyer you ask. Speculation aside, the RC4 controversy explains why many developers are protecting their intellectual property with patents instead of copyrights. Gray areas like RC4 would be black and white if RC4 had been patented. But then patenting would also mean that RC4 would have been public in the first place. The immediate impact may be on RC5, the next-generation version of RC4, which Ron Rivest describes in this issue. In part because of the RC4 controversy, Ron and RSA Data Security are considering patenting RC5, a departure from their original plans. At one point, RC5 code and reference was to be distributed free-of-charge for noncommercial use. Small businesses could license the material for $500, and large businesses, for $1000. All proceeds were to go to RSA Labs - not RSA's bottom line - to fund further R&D. This could still happen even if RSA patents RC5, but the licensing fees would be higher to offset the patent costs. Likewise, there could be some repercussion in terms of exporting RC4-based systems. For the past couple of years, vendors have been allowed to export software that uses RC4 short-key encryption. The State Department could change this since RC4 is no longer secret. As for the multitude of legal questions, nothing concrete will immediately come of the RC4 brouhaha, unless those responsible for posting the code are identified. Existing RC4-based systems weren't compromised and may have benefited, since we can now see that system backdoors don't exist. What we're left with are more questions, fewer answers, and the suspicion that one of these days a big shoe is going to fall on software and intellectual-property rights - one that won't make anyone completely happy. Johnathan Erickson editor-in-chief

2 1

Re: Attacking Norton Encrypt
by pstemari＠erinet.com 17 Dec '03

17 Dec '03

At 09:52 PM 12/23/94 IST, rishab(a)dxm.ernet.in wrote: > >Regarding the simple question about Norton Encrypt's security (and ignoring >the alt.relationship-counsellor interlude), I believe Norton uses DES (for >'maximum security' or a 'fast proprietary' method for convenience. I don't >think it has the usual errors (password stored in ciphertext etc), but a >brute force attack on DES is beyond the means of most Norton users IAC. Perhaps, but if the earlier post is accurate about it mapping UC to lc and only accepting 8 characters of password, you've gone from a 56 bit keyspace to a ~38 bit keyspace. A dictionary attack is certainly feasible--I don't recall what speeds have been achieved for brute-forcing DES lately. --Paul J. Ste. Marie

1 0

Re: Breaking into girlfriend's files
by Jonathon Fletcher 17 Dec '03

17 Dec '03

It seems a little strange that cypherpunks are arguing over whether or not to disclose information about a (supposedly) cryptographic product to a certain individual. Let's relate this this to other examples of restricting cryptographic information - can anyone think of any groups or organisations that do this ? Okay, now we've thought of a couple, lets compare reasons (left as exercise for the reader) for the restriction of this information and our opinions on those restrictions. Have I made my point ? Should we change the infamous slogan to: "Cyperpunks is watching you". Someone asked a techical question about cryptography, other list members answered it. Can we now get on with more relevant matter ? -Jon -- Jonathon Fletcher, j.fletcher(a)stirling.ac.uk

5 7

Comdex Disks?
by merriman＠metronet.com 17 Dec '03

17 Dec '03

Sorry to divert everyone from the other threads, but I happen to have some somewhat crypto-related question: Back some time ago, there was some discussion of giving away disks at Comdex in NY; by any chance, does anyone have a copy of the contents of what was on those disks? I'd like to be able to give away 'basic info' in easy-to-handle format :-) Thank for any help/pointers. We return you now to your regular mailing list..... Dave Merriman - - - - - - - - - - - - - - - - - - - - - - - - - - Finger merriman(a)fohnix.metronet.com for PGP public key and fingerprint. PGP encrypted Email welcome, encouraged, and preferred. "Those who make peaceful revolution impossible will make violent revolution inevitable." John F. Kennedy

2 1