December 2003 - cypherpunks-legacy

CIAC Notes 94-05 (fwd)
by NetSurfer 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I checked my mail and didn't find this posted to the list, so I'll send an abbreviated snip w/pointers for you. Interesting info... - -NetSurfer #include <standard.disclaimer> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> == = = |James D. Wilson |V.PGP 2.7: 512/E12FCD 1994/03/17 > " " o " |P. O. Box 15432 | finger for full PGP key > " " / \ " |Honolulu, HI 96830 |====================================> \" "/ G \" |Serendipitous Solutions| Also NetSurfer(a)sersol.com > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - ---------- Forwarded message ---------- Date: Thu, 22 Dec 1994 16:30:38 -0800 From: VANLEHN(a)margay.llnl.gov To: jdwilson(a)gold.chem.hawaii.edu Subject: CIAC Notes 94-05 U.S. DOE's Computer Incident Advisory Capability ___ __ __ _ ___ __ __ __ __ __ / | /_\ / |\ | / \ | |_ /_ \___ __|__ / \ \___ | \| \__/ | |__ __/ Number 94-05 December 22, 1994 Welcome to the fifth issue of CIAC Notes, the United States Department of Energy's (DOE) Computer Incident Advisory Capability (CIAC) electronic publication for articles on relevant computer security topics. This "E-zine" is a service requested by our DOE and DOE contractor customers, and is open to subscription by anyone who can receive E-mail via the Internet. Hopefully we are giving you a gift of information to close out 1994. If you have topics you would like addressed or have feedback on this issue, please contact the editor, Allan L. Van Lehn, CIAC, (510) 422-8193 or send E-mail to ciac(a)llnl.gov. $-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$ $ Reference to any specific commercial product does not necessarily $ $ constitute or imply its endorsement, recommendation or favoring by $ $ CIAC, the University of California, or the United States Government.$ $-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$ TABLE OF CONTENTS Feature Articles How Trusting Can We Be? Internet Firewalls - Part 2 More On The Good Times Virus Hoax CIAC Plans To Have A Home Page In January Security Information Servers MAC / PC User PowerMAC Users Beware Data Physician Plus! 4.0E Available Novell Users OS/2 Systems Processing CLASSIFIED DATA CIAC Information Who Is CIAC? CIAC Bulletins Issued Recently Subscribing To CIAC Electronic Publications Accessing CIAC's Electronic Information Servers Publications Available From CIAC Contacting CIAC /snip/ >It is possible >to create a file that remaps keys when displayed on a PC/MS-DOS machine with >the ANSI.SYS driver loaded. However, this only works on PC/MS-DOS machines >with the text displayed on the screen in text mode. It would not work in >Windows or in most text editors or mailers. A key could be remapped to >produce any command sequence when pressed, for example DEL or FORMAT. >However, the command is not issued until the remapped key is pressed and the >command issued by the remapped key would be visible on the screen. You could >protect yourself by removing ANSI.SYS from the CONFIG.SYS file, but many DOS >programs use the functionality of ANSI.SYS to control screen functions and >colors. Windows programs are not effected by ANSI.SYS, though a DOS program >running in Windows would be. - ------------------------------ Security Information Servers Novell: http://www.novell.com/cgi-bin/ftpsearch.pl?QString=security Microsoft Windows: gopher://198.105.232.4:70/77%5Ckb%5Cperopsys%5Cwindows%5Cwindows.src?security gopher://198.105.232.4:70/77%5Ckb%5Cperopsys%5Cwindows%5Cwindows.src?patches FIRST's WWW server: http://www.first.org/first/ NIST/CSRC http://cs-www.ncsl.nist.gov Purdue Computer Emergency Response Team (PCERT) http://www.cs.purdue.edu/pcert/pcert.html NASA Automated Systems Incident Response Capability (NASIRC) (this is accessible to *.nasa.gov systems only, but it can be accessed though the FIRST server or you can contact NASIRC to be added to their hosts.allow file) http://nasirc.nasa.gov/NASIRC_home.html Naval Computer Incident Response Team (NAVCIRT) http://infosec.nosc.mil/niseeast/navcirt.html Australian Computer Emergency Response Team (AUSCERT) http://www.auscert.org.au (Proposed to be up in a couple of weeks) http://www.uq.oz.au/pcc/services/sert/home.html (Currently active) DFN-CERT German Home Page - http://www.cert.dfn.de/ English Home Page - http://www.cert.dfn.de/eng/ Computer Emergency Response Team (CERT) http://www.sei.cmu.edu/SEI/programs/cert.html Veterans Health Administration (VHA) http://www.va.gov Small Business Administration (SBA) http://www.sbaonline.gov/ If you know of others, please send mail to ciac(a)llnl.gov. /snip/ - ------------------------------ Data Physician Plus! 4.0E Available All DOE sites should now have Data Physician Plus! 4.0E for use on IMBpc compatable systems. Contact your site CPPM if you have not obtained an update. This version does provide protection from the KAOS4 and One_half viruses (see CIAC Bulletin E-32 for further information on KAOS4 and E-34 for information on One_half). - ------------------------------ Novell NetWare Users CIAC is receiving more and more calls from our DOE clients asking for information on minimizing the risks associated with installing NetWare and in further connecting these LANs to the Internet. To supplement our own experiences CIAC is interested in partnering with other experts to create a comprehensive package of information that could be made available to all sites. If you have Novell NetWare expertise and would like to be a CIAC associate, please send a note to ciac(a)llnl.gov. - ------------------------------ OS/2 Systems Processing CLASSIFIED DATA by Rollo D. Rogers [rogers(a)cod.nosc.mil] SECURITY SAFEGUARDS FOR PROCESSING CLASSIFIED INFO ON A COMPUTER RUNNING OS/2 V2.1 [note: some sites may not allow internal hard disks for classified systems. ed] - ------------------------------ CIAC INFORMATION - ------------------------------ Who is CIAC? CIAC is the U.S. Department of Energy's Computer Incident Advisory Capability. Established in 1989, shortly after the Internet Worm, CIAC provides various computer security services free of charge to employees and contractors of the DOE, such as: o Incident Handling Consulting o Computer Security Information o On-site Workshops CIAC is located at Lawrence Livermore National Laboratory in Livermore, California, and is a part of its Computer Security Technology Center. CIAC is also a founding member of FIRST, the Forum of Incident Response and Security Teams, a global organization established to foster cooperation and coordination among computer security teams worldwide. Further information can be found at http://www.first.org/first/ - ------------------------------ CIAC Bulletins Issued recently CIAC issues two categories of computer security announcements: the information bulletin and the advisory notice. Information bulletins describe security vulnerabilities and recommend countermeasures. Advisory notices are more imperative, urging prompt action for actively exploited vulnerabilities. Advisory notices are delivered as quickly as possible via E-mail and FAX. F-01 Advisory SGI IRIX serial_ports Vulnerability Oct. 4, 1994, 1600 PDT F-02 Bulletin Summary of HP Security Bulletins Nov. 17, 1994, 1300 PDT F-03 Bulletin Restricted Distribution F-04 Bulletin Security Vulnerabilities in DECnet/OSI for OpenVMS Nov. 28, 1994, 0900 PDT F-05 Bulletin SCO Unix at, login, prwarn, sadc, and pt_chmod Patches Available Dec. 06, 1994, 0800 PDT F-06 Bulletin Novell UnixWare sadc, urestore, and suic_exec Vulnerabilities Dec. 14, 1994, 0800 PDT - ------------------------------ Contacting CIAC DOE and DOE contractor sites that require additional assistance or wish to report a vulnerability: call CIAC at 510-422-8193, fax messages to 510-423-8002 or send E-mail to ciac(a)llnl.gov. ------------------- A - T - T - E - N - T - I - O - N --------------------- | For emergencies and off-hour assistance, CIAC is available 24-hours a day | | to DOE and DOE contractors via an integrated voicemail and SKYPAGE number.| | To use this service, dial 1-510-422-8193 or 1-800-759-7243 (SKYPAGE). The | | primary SKYPAGE PIN number, 8550070 is for the CIAC duty person. A second | | PIN, 8550074 is for the CIAC Project Leader. Keep these numbers handy. | --------------------------------------------------------------------------- - ------------------------------ CIAC's Electronic Publications Previous CIAC Bulletins and other information are available via anonymous FTP from ciac.llnl.gov. CIAC has several self-subscribing mailing lists for electronic publications: 1. CIAC-BULLETIN for Advisories, highest priority -time critical information and Bulletins, important computer security information; 2. CIAC-NOTES for Notes, a collection of computer security articles; 3. SPI-ANNOUNCE for official news about Security Profile Inspector (SPI) software updates, new features, distribution and availability; 4. SPI-NOTES, for discussion of problems and solutions regarding the use of SPI products. Our mailing lists are managed by a public domain software package called ListProcessor, which ignores E-mail header subject lines. To subscribe (add yourself) to one of our mailing lists, send requests of the following form: subscribe list-name LastName, FirstName PhoneNumber as the E-mail message body, substituting CIAC-BULLETIN, CIAC-NOTES, SPI-ANNOUNCE or SPI-NOTES for list-name and valid information for LastName FirstName and PhoneNumber. Send to: ciac-listproc(a)llnl.gov (not to: ciac(a)llnl.gov) e.g., subscribe ciac-notes O'Hara, Scarlett W. 404-555-1212 x36 subscribe ciac-bulletin O'Hara, Scarlett W. 404-555-1212 x36 You will receive an acknowledgment containing address, initial PIN, and information on how to change either of them, cancel your subscription, or get help. To subscribe an address which is a distribution list, first subscribe the person responsible for your distribution list. You will receive an acknowledgment (as described above). Change the address to the distribution list by sending a second E-mail request. As the body of this message, send the following request, substituting valid information for list-name, PIN, and address of the distribution list:. Send E-mail to ciac-listproc(a)llnl.gov: set list-name address PIN distribution_list_address e.g., set ciac-notes address 001860 rE-mailer(a)tara.georgia.orb To be removed from this mailing list, send the following request: unsubscribe list-name For more information, send the following request: help If you have any questions about this list, you may contact the list's owner: listmanager(a)cheetah.llnl.gov. - ------------------------------ Accessing CIAC's Electronic Information Servers CIAC operates a security information server for anonymous FTP at ciac.llnl.gov which contains all of the publicly available CIAC, CERT/cc, NIST, and DDN bulletins, virus descriptions, the virus-l moderated virus bulletin board, copies of public domain and shareware virus detection/protection software, copies of useful public domain and shareware utility programs, and patch files for some operating systems. Use FTP to access it either by name or IP address (128.115.19.53). The operation and prompt will depend on which vendor's FTP you are running. Usually, you must first log in before you can list directory contents and transfer files. Use "FTP" or "anonymous" for Name or Foreign username unless given a general prompt such as ciac.llnl.gov> or FTP>. In that case, enter the keyword "user" or "login" before "FTP" or "anonymous" (e.g., user FTP). Use your Internet E-mail address for the Password. Once logged in you may type a question mark to find out what key-words are recognized. The file 0-index.txt (in the top level directory /FTP) is a document explaining the directory structure for downloadable files. The file whatsnew.txt (in directory /FTP/pub/ciac) contains a list of the new files placed in the archive. Use the command get [for single files] or mget [for multiple files] to download one or more files to your own machine. - ------------------------------ Publications Available from CIAC CIAC prepares publications on a variety of computer security related topics, the CIAC 2300 series. Many of these will be updated as needed to keep the information current. We welcome suggestions for topics that you feel would be valuable. We also make available some documents from other sources. In the table below, column E is for electronic documents available via CIAC's servers (see above). Column P is for printed documents, for those who do not have Internet or telephone-modem access. If neither column is checked, the document is soon to be released. The electronic formats are: *.txt for ASCII, *.ps for PostScript(tm), *.hqx for bin-hexed Microsoft Word, *.wp5 for PC Word Perfect v5.0. No. E P TITLE 2300 x x Abstracts of the CIAC-2300 Series Documents 2301 x x Computer Virus Information Update 2302 Accessing The CIAC Computer Security Archives 2303 x x The Console Password Feature for DEC Workstations 2304 Data Security Vulnerabilities of Facsimile Machines and Digital Copiers 2305 Unix Incident Guide: How To Detect A Unix Intrusion 2308 Securing Internet Information Servers CIAC x Incident Handling Guidelines LLNL x User Accountability Statement, E. Eugene Schultz, Jr. SRI x Improving the Security of your Unix System, David A. Curry LLNL x Incident Handling Primer, Russell L. Brand ORNL x Terminal Servers and Network Security, Curtis E. Bemis & Lynn Hyman To obtain further information, contact Allan L. Van Lehn, CIAC, 510-422-8193 or send E-mail to ciac(a)llnl.gov. - ------------------------------ This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. - ------------------------------ End of CIAC Notes Number 94-05 94_12_22 **************************************** - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLvsP8CoZzwIn1bdtAQFmbgGAve2RmZmmVy+AtvHhLtdKBy/B5/7eyNDe h+eaysT6l7JUIX1x18BwM574UH+ibzYB =BnIF -----END PGP SIGNATURE-----

1 0

Re: Is it possible to break Norton Encrypt??
by foodie＠netcom.com 17 Dec '03

17 Dec '03

Bear with me, all. I am on my first cup of coffee. At 9:40 AM 12/23/94, Eric Hughes wrote: >Does anybody here know jack about Norton Encrypt? Well, I do have qualms about this, but I am assuming/hoping the original poster doesn't know what they are doing and wanted an answer like "Look in resource #164, dood" (call me a bleeding heart). Norton Encrypt for the Mac does have major problems. Key handling is botched such that the keyspace is significantly less than the full 56 bits specified, through what looks like a combination of inept implementation and perhaps outright bugs. I don't remember all the details, but I think NE converts to all lower case or some such, and discards anything past 8 characters of passphrase. There is a file on one of the crypto sites about NE. I would direct anyone interested to dig around some. -j, whose next pasttime this morning is helping con artists swindle old folks. >Eric -- On the internet, nobody knows you're a deity. __________________________________________________________ foodie(a)netcom.com

1 0

export adventure
by Matt Blaze 17 Dec '03

17 Dec '03

Some of you may recall that about a month ago I posted the long and tortured story of my efforts to obtain a tempory export license for a so-called "exportable" telephone security device. I promised to report on what actually happened when I tried to go in and out of the country with the thing. Well, I just got back. I'm in the process of writing up the details, and I'll post a full account in the next few days, but the bottom line is that I've come to the conclusion that Kafka must have been trying to export something under one of these licenses when he wrote "The Trial". (Nothing bad happened, mind you, just a twistied maze of essential bureaucratic processes each more arcane than the last and all well beyond the grasp of humble travelers such as I). -matt

1 0

Attacking Norton Encrypt
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

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. ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "In between the breaths is rishab(a)dxm.ernet.in the space where we live" rishab(a)arbornet.org - Lawrence Durrell Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

2 1

Why I have a 512 bit PGP key
by Matt Blaze 17 Dec '03

17 Dec '03

A while back, I generated a PGP key pair for use on my machine at work, a Sun SparcStation sitting on the reasonably-well-protected- from-outside-attack AT&T internal research network. I selected a key length of 512 bits. My number theory friends tell me that this is weak by modern standards; cracking my key would probably require within an order of magnitude of the total computational effort expended in the recent attack on RSA-129. I even volunteered my key as a ``target'' for the next such attack. Still, I'm happy with my choice, or rather, I've got so many other security things to worry about that compromise of my private mail based on cryptanalysis of my dinky little public key to obtain my private key is the last thing on my mind. In fact, I kind of like it that my key doesn't advertise pretensions of high theoretical security when, in fact, there is very little at all in practice. The first problem, of course, is secret storage. Modern networked computers are awful at storing secrets. (This, after all, is one of the problems that crypto software like PGP aims to solve). I suspect my situation is reasonably typical, if not better than most. My computer at work sits on my desk (in my locked office), has its own local disk, only I know the root password, I try to keep up with the latest security patches, and I keep most of my files in encrypted form under CFS. I'm the only regular user of my workstation, and while I'm at work I access it directly from the console. The network to which it is attached is AT&T's ``R&D Internet'', the same one that sits behind the firewall described in Cheswick and Bellovin's great new book. I probably have at least average system administration and general computer security skills, and I'm reasonably good about practicing what I preach. Sounds like a pretty secure machine from which to run PGP, right? I don't think so. While my machine's operating system is pretty self-sufficient, my own home directory sits on a remote file server administered by people who are good at and have time to perform essential services for me like taking backups. This means that, no matter how hard I try, it's impossible for me to be sure that none of my files have been tampered with. We use off-the-shelf NFS, which means that for all practical purposes anyone with access inside the firewall (that's about 50k people in my case) can replace any of my files. Furthermore, even though my office has a lock, I'm not the only person in the world with the key (Bell Labs escrows office keys, after all), and I've managed to pick the lock once or twice on days when I left my key at home. I really have no idea where my machine has been or what software I'm typing at when I run PGP. So where should I store my private key? Well, I could, as some have suggested, keep it on a floppy disk that I carry around with me everywhere I go, but first of all, that's too inconvenient. It also sounds dangerous in practice. A floppy disk is about the size of a US passport, and I've already lost two of those. That means I'd have to replicate the key somehow anyway, so I might as well rely on the reasonably well established backup procedure that protects me from loss of the rest of the files in my home directory. For all practical purposes, I have to assume that my secret key file is public. That leaves the passphrase to protect the secret key. According to Shannon, English text contains just over 1 bit per letter of real information. Even if we assume twice that to account for the added twists and turns of phrase I'm inclined to add to a passphrase, I just can't remember (or type) a phrase with anywhere near enough entropy to approach the level needed to do justice to even a little 512 bit RSA key. I think the simplest cryptanalytic attack against me would be to go after the passphrase-based encryption of the secret key file. (You'd need a way to enumerate the most likely keys based on a hashed passphrase, which is a problem not yet well studied in the unclassified literature. I suspect a solution not out of reach of a determined adversary, however). An even simpler attack would be to break in to my machine and replace my copy of PGP (or my kernel, or my shell, or whatever) with one that records the passphrase as I type it. (No, I don't leave this as an exercise to the reader!) The next problem is with PGP itself. While I haven't looked carefully, it seems to be a well-engineered program, and it has a number of design features that I admire. However, I think the basic model it implements sits at two high a level, making it inherently unreliable for really sensitive traffic. It's just too hard to use. (Most of the problems could be fixed by pushing things to a lower level, and I understand a number of people are working on this). In particular, I'm have to have too much involvement in each PGP operation, and it's just too easy for me to do stupid things like: - encrypting messages with the wrong public key - sending the cleartext file instead of the ciphertext file - leaving the cleartext file around in an unprotected file system - including the passphrase in the message (especially when your fingers are so used to typing it all the time...) - forgetting to use PGP at all - typing a passphrase over a network connection (especially easy when you've got several windows open on several machines). Systems that use hardware keys (smartcards, etc) are less vulnerable to this I've done each of these dumb things at least once, and probably others too. Don't get me wrong - I advocate the use of strong encryption as much as the next nerd. I'm just concerned about focusing so narrowly that we lose sight of the larger security picture. Perry Metzger once made reference to cryptographic "size queens" who worry about key size and nothing else - it's a phrase that rings true. There's something to be said for systems that chose their security parameters provide about the same strength everywhere. DES is a good example - a 128 bit key DES could be made that is no less secure than the current 56 bit version - by a few bits. The engineering triumph is that the "advertised" DES security parameter - the key size - tells close to the truth about the overall security of the system. (Of course, in RSA-based systems, there's an added variable - advances in factoring - that may make it prudent to include a significant margin for error, especially for keys that must retain their strength over time). I have a 1024 bit key at home. -matt -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.1 mQBNAitm4zgAAAECANYaL7K5Ca5B4Sq3udKKkFasQNrgfKGoWRUjwB/10lAFVrhN aKz/b6iJXFxZ6g+YlCvdQTu/EUO6JkBihshIRgEABRG0D21hYkBiaWcuYXR0LmNv bbQhbWF0dCBibGF6ZSA8bWFiQHJlc2VhcmNoLmF0dC5jb20+iQCVAgUQLIG7Ga1S SlGFGX+1AQEt7QQAtwhDbN/799e763LrbhB5ItoR1r2ud+nWBZi0S64OVnVkLjnd zVwMouPiaiEs/ORWQfoVPmME6fMYlUeh+uLonSDymjzosWyU6yJRs8lcAy2MMBR+ De00mHk8+nDAuY0j4udH2oqvd6V6IEgsN8bQeme8CkNj3uULmzNMrYtns7aJAJUC BRAr3LtEs25wSZyVhQ8BAXQwA/wIxBaxEM/DER96N6o00qzzJog8nbKGH2S4achc P0/96N9FXgnnoKybARfG+ZfliuuMRyt40MIkg1/Z5PzLg0m5dVzXgkYv7B98bI+8 dVuzENJRzBbbmSDemcTaF2KWdtW7U66xFSP6S86RDOuQHzg6uCi2tmoJhvdWroWz VVxGj4kAlQIFECtzeqp9h9s63RlgUQEB8UoD/ilKx2sUFzQwkM3DSRQZun5FoR1N ujmt710NHkn3BFcRcBAU1o6VEHg0MlQXYEDk16YnhUEZDy0QuMrxXWcLee1UP2jl k0+ezNP5NMsSMt7HVjGJ+xi+exc6+Clyl/WjSEhpears1kBWAI12eVbO1uI/uGr5 vksZqkPoT8a1WaumiQCNAgUQK21uiULwpfyXKdSbAQFErAO/TsSmabCpT4Uzi/zQ 14yBiDqwatj8mhaE60nG8wiqQv4W4hmDXjrxGRr0LQNM3eBLCkoEpKIDmL1RuwtB Z4AUsqoJTC2Yq46KnSznfqgY0F+C4kSptxo0p1KJ79FKFlW9dyTKVBB1WOBzbsw1 Kx/oog+DmUH0VIbYiQCVAgUQK21W3FTdX6I8ZiRnAQHErAP+P+WalKGRrgM/v8pp o4YKYmXxjsLUx89WJXMkxkoSzB7/ny7ITHo9i42qR+aXlsa+gqxdwRDrpI6k9FFF AhZ8s/bdZKpnXOJOjaj4P5LRbYem2VOZ8e9omXhHfz7a7NRUTimLA/q6lphy3Ulp byrua5Q8BkzQzI3RgbKEPshuOjeJAJUCBRArZuU6hr7UV33/hTMBATvGA/42wy/x BEVb5bOQiFTpEuB80Df53zt+b4TmfeueMMiDvvj7A5joLk7X/7x6HaBxHN/thbd6 S9NncWJfvy/PMnsQEmKarn45kwn/2xxDu2Po7pUN6Uj9DyA9uY+ilzqfk7ZA3RwH cbZA0Qv6LDNbapJXgFANwOC1tRB6yLtSG3T0iw== =V30c -----END PGP PUBLIC KEY BLOCK-----

1 0

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

Re: Breaking into girlfriend's files
by L. McCarthy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Black Unicorn writes: > If she gets burned using norton encrypt, perhaps she'll take the time to > learn about real encryption. (I assume Norton's is trash) > Short term privacy loss perhaps, but long term gain. This sounds to me rather like saying: "If the American public gets burned by accepting Skipjack as the crypto standard, perhaps they'll take the time to learn about real encryption." I prefer the version where the American public doesn't get burned in the first place. If Clipper has to be adopted before the public will learn about real encryption, why are we bothering to try to promote it now ? Shouldn't we be backing Clipper wholeheartedly, to teach 'em a lesson ? [...] > The more I think about the above, the more I wonder if those on the list > have conflicting goals, that is, absolute privacy by agreement. Are we > really that naive? I have ideals, yes. My deepest condolences if you don't have any. - -L. Futplex McCarthy - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLvpYDyoZzwIn1bdtAQFfsAF+I9d0c12vWtLp+be+ybiP7X9obidXqIBQ nnb5PkMVZYrms7gcJXgwBCH2irGzQrQ3 =Ssqh -----END PGP SIGNATURE-----

3 2

No privacy with DigiCash
by Hal 17 Dec '03

17 Dec '03

One of the reasons we want http redirectors is so we could buy things anonymously. There is not much point in anonymous digital cash when your web connections advertise who you are. But, the current ecash implementation from DigiCash doesn't allow this to work! When you buy something, the vendor has to know your machine name because he wants to connect back to your ecash wallet process. So even if you did connect via a redirector, your anonymity would be destroyed (or at least badly hurt) when you tell it your machine name so it can connect to you. This is a really bad way of doing it IMO because it seems to defeat one of the big selling points of DigiCash. Is there something I am overlooking, some way to buy things privately with DigiCash? Hal

3 3