December 2003 - cypherpunks-legacy

Fifth ACM Conference on Computer and Communications Security
by Gene Tsudik 17 Dec '03

17 Dec '03

This is the Call for Participation for the 5th ACM Conference on Computer and Communications Security that will take place in San Francisco Nov 2-5. Below please find the REGISTRATION form. The official conference homepage is at: http://www.bell-labs.com/user/reiter/ccs5/ It includes, among other things, the conference program, information about invited talks, speakers and tutorials. ------------------------- cut here ---------------------------------- Fifth ACM Conference on Computer and Communications Security REGISTRATION FORM Name:_____________________________________________ Affiliation:_____________________________________________ Postal Address:_____________________________________________ _____________________________________________ _____________________________________________ Phone:_____________________________________________ Fax:_____________________________________________ Email:_____________________________________________ Note: Notification of receipt of registration form will be sent via email. Address information will be distributed to all attendees. Please mark the appropriate registration categories. Payment must be included and must be either by check in U.S. dollars, drawn on a U.S. bank and made payable to "ACM Conference on Computer and Communications Security", or by credit card. Dates are strictly enforced by postmark. Attendees who register for tutorials can attend any of the four half-day tutorials. However, to assist in planning, please indicate which tutorials you are likely to attend. Morning sessions (choose one): ___ Cryptography: Theory and Applications (Dan Boneh) ___ Programming Languages and Security (Martin Abadi, George Necula) Afternoon sessions (choose one): ___ Authentication protocol verification and analysis (Jon Millen) ___ Emerging models in electronic commerce (Doug Tygar) The following tutorial registration fees include admission to all tutorials, and must be paid in full if any tutorial is attended. Advance tutorial registration (on or before October 1, 1998) ___ ................................................................$300.00 ___ Full-time Student...............................................$100.00 Late tutorial registration (after October 1, 1998) ___ ................................................................$395.00 ___ Full-time Student...............................................$100.00 Conference registration includes admission to the regular conference programs (but not the tutorials), conference proceedings, continental breakfast, lunch, and reception/dinner. Advance conference registration (on or before October 1, 1998) ___ Member, ACM or ACM SIGSAC (Member #__________, required)........$315.00 ___ Non-Member......................................................$390.00 ___ Full-time Student...............................................$100.00 Late conference registration (after October 1, 1998) ___ Member, ACM or ACM SIGSAC (Member #__________, required)........$375.00 ___ Non-Member......................................................$465.00 ___ Full-time Student...............................................$100.00 Do you have any special requirements?_________________________________________ Please indicate your method of payment by checking the appropriate box: [ ] Check in U.S. funds drawn on a U.S. bank (PLEASE ENCLOSE WITH THIS FORM) Credit card authorization: (Charges will appear on your statement as made by ACM. Note: your credit card number will be processed by the ACM.) Visa MasterCard American Express Diners Club [ ] [ ] [ ] [ ] Credit Card Number:_________________________________________________________ Card Holder Name:______________________________Expiration Date:_____________ Mail registration to: Or Email this form (CREDIT CARD Li Gong REGISTRATIONS ONLY) to: Sun Microsystems li.gong(a)sun.com with the subject MS UCUP02-102 ACM CCS registration 901 San Antonio Road Palo Alto, CA 94303-4900, USA >>>>SORRY, NO REFUNDS.<<<< Hotel Reservations - The Fairmont Hotel, San Francisco ====================================================== The legendary Fairmont Hotel in San Francisco is situated atop the exclusive Nob Hill area, with a panoramic view of the City and San Francisco Bay. Nearby, cable cars stop to carry guests to Union Square and the Financial District as well as nearby Chinatown, Ghirardelli Square and Fisherman's Wharf. Hotel reservations must be made under the group name "Association of Computing Machinery/ACM CCS". The special group rate is Main Building: $155 single and $175 double occupancy Tower/Bay View: $185 single and $205 double occupancy There is an additional 14% tax. These rates are guaranteed for the period of the conference only. The cut-off date for reservations is Thursday, October 8, 1998. Reservations made after this date will be accepted on a space available basis, but due to the busy season, reservations should be made as early as possible. Reservations must be guaranteed by a credit card or it must be accompanied by an advance deposit for the first night. You may cancel your individual reservations up to 24 hours prior to arrival, after which your deposit becomes non-refundable. Please be advised the check-in time is after 3:00 p.m.; check-out is 1:00 p.m. For reservations and information, contact: The Fairmont Hotel 950 Mason Street San Francisco, CA 94108 Tel: +1 415-772-5000 +1 800-527-4727 Transportation from the San Francisco International Airport to the hotel can be via taxi, which takes about 30 minutes and costs about $30, or via shuttle at a cost of around $12. Shuttle information can be found at the airport. =============================================================================

1 0

Re: ArcotSign
by Anonymous 17 Dec '03

17 Dec '03

Greg Broiles writes: > I'm certainly not a cryptographer, but I'm somewhat at a loss in trying to > understand the purpose of using public-key (or asymmetric key) > cryptography within a policy/technology system which won't allow the use > of the strengths of asymmetric key crypto. As I understand the paper you > reference above, to implement this system the public key must be kept > confidential, and signed documents must also be kept confidential, or the > system of the security as a whole is at risk. With those constraints, why > bother with the overhead (computationally/technically/legally) of > asymmetric key crypto at all? Based on http://www.arcot.com/camo2.html, the idea is to defend against an attacker who manages to steal a copy of the secret key file, and who then tries to guess the passphrase which protects it. The file data is encrypted in an unstructured generic manner so that all decryptions look like random data, even the correct one. This gives the attacker no information about when he has guessed the correct passphrase. For this to work, the public key has to be kept secret(!). Otherwise the right passphrase could be discovered by testing the decrypted private key against the public key. Arcot suggests that this would be appropriate for an environment where only one or a few trusted servers need to authenticate users. These servers would be the only ones which have copies of the public keys. (It is not necessary that signed documents be kept confidential, however a randomized signing algorithm must be used.) As Greg points out, much the same could be accomplished simply by having the servers share secret 3DES keys with their users, each user having his own private 3DES key. The users could encrypt messages using their 3DES key and the server would decrypt using the appropriate key, which would also serve to authenticate the user. The Arcot people suggest that an advantage over this scheme is that servers don't have to store information on all clients. But much the same thing could be done with symmetric cryptography. In the Arcot system, the client sends his public key certificate, encrypted to the server, along with his request. The server receives the cert and uses it to verify/decrypt the message. With symmetric cryptography, the client could have the shared 3DES key encrypted using the server's public key, and send that along with his message in a similar way. The confusing thing about the Arcot system is this: how sensitive is the public key? Is it as sensitive as a shared secret key? Superficially not, since in order to exploit the public key you also have to steal the private key file and then guess the passphrase. But on the other hand, if this is more than security through obscurity, you have to treat it in many ways as equally sensitive. Users of the Arcot system, believing that they are safe because their public keys are secret, may become casual about revealing their private key files and choosing easy to guess passphrases. They might even send the files around via insecure channels. With this kind of usage, the public key does become just as sensitive as a shared secret key would be. In that case, not only the servers, but all parts of the PKI must be brought inside the trust boundary. They are all holding material which, if revealed, would compromise the security around which the system is built. You end up with trust relationships more similar to those in a system like Kerberos than in a normal PKI. > Is it really necessary/useful to call the scheme "software smart cards"? > If it were called "An improved system for user authentication", I don't > think it would make people nearly so suspicious. From my perspective, one > of the advantages of smart card technology is that I can carry my > authentication material with me; a system which puts it on my hard disk is > less attractive. Floppies are portable, but not durable. The analogy with smart cards is that these cards protect your private key. With a perfect smart card, an attacker can't do any better than chance guessing of your private key. With the Arcot system, the same is true. Decrypting the private key file gives no information about its content, because pure random data is encrypted. Therefore with their system the attacker also can't do better than chance guessing. However this ignores the cost of the system, discarding many of the advantages of public key cryptography. You don't have to do that if you use smart cards. > I didn't understand the relationship between this scheme and Rivest's > chaffing and winnowing which you note was cited as a reference in the SSC > paper - would you (or someone else) mind explaining the connection? Yes, this seems obscure.

2 1

Fwd: RE: HOAX: I don't care if this is real or not! But forwarding is not hard for me if I help
by Chiu Ngan 17 Dec '03

17 Dec '03

>From ptrei(a)securitydynamics.com Wed Sep 16 06:49:03 1998 >Received: from mail.securitydynamics.com by tholian.securitydynamics.com > via smtpd (for mail.hotmail.com [209.1.112.253]) with SMTP; 16 Sep 1998 13:48:16 UT >Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id JAA08933; Wed, 16 Sep 1998 09:54:39 -0400 (EDT) >Received: by exna01.securitydynamics.com with Internet Mail Service (5.0.1460.8) > id <RT690391>; Wed, 16 Sep 1998 09:52:43 -0400 >Message-ID: <D104150098E6D111B7830000F8D90AE824064B(a)exna02.securitydynamics.com> >From: "Trei, Peter" <ptrei(a)securitydynamics.com> >To: "'Chiu Ngan'" <simpsonngan(a)hotmail.com>, dueli(a)hotmail.com, > centrebet(a)centrebet.com.au, contact(a)unsw.edu.au, Declan(a)well.com, > Dodwellleung(a)hotmail.com, dlin(a)gpu.srv.ualberta.ca, > dorngan(a)hkstar.com.hk, cypherpunks(a)toad.com, cj2802(a)singnet.com.sg, > parsley(a)unforgettable.com, S.Lundy(a)unsw.edu.au, accounts(a)magna.com.au, > n.harding(a)unsw.edu.au, philiph(a)magna.com.au, ulf(a)fitug.de, > leevv(a)hotmail.com, vanessa.ho(a)mailexcite.com >Subject: RE: HOAX: I don't care if this is real or not! But forwarding is > not hard for me if I help >Date: Wed, 16 Sep 1998 09:50:23 -0400 >MIME-Version: 1.0 >X-Mailer: Internet Mail Service (5.0.1460.8) >Content-Type: text/plain > >You should care. Not checking on such obvious >hoaxes makes you look like an idiot. It took >me less than 30 seconds to establish that this >is yet another urban legend. Check: > >http://www.inform.umd.edu/mdk-12/help/xhoax.html#liver > > >Chiu Ngan [simpsonngan(a)hotmail.com] forwarded: >> >>>>Hello, my name is David "Darren" Bucklew. I live in >> >>>>Pittsburgh PA where I attend Bethel Park High School >> >>>>and participate in many sports. I have severe >> >>>>ostriopliosis of the liver. (My liver is extremely >> >>>>inflamed). >> >>>>Modern Science has yet to find a cure. Valley >> >>>>Childrens hospital >> >>>>> has agreed to donate 7 cents to the National >> >>>>Diesese Society for every name >> >>>> on this letter.Please send it around as much as you >> >>>>can. >> >>>>Thank you, >> >>>>Darren >> >>>> >> >>>>PS: For those of you who dont take 5 minutes to do >> >>>>this, what goes around comes around. You can help >> >>>>sick people, and it costs you nothing,yet you are too >> >>>>lazy to do it? You will get what you deserve. >> > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Re[2]: ArcotSign (was Re: Does security depend on hardware?)
by jnbailly＠west.raytheon.com 17 Dec '03

17 Dec '03

Woah.... I hate to interject noise, but I have to comment. Maybe Bruce's reply WAS a bit curt and not terribly helpful. But it's better to just let it drop, and not resort to criticizing typos. I'm a member of this list in the hopes that I'll learn something. While it's true that I didn't learn anything from Bruce's reply, I don't think anyone gains anything from grammar/spelling corrections! *smile* Jacob ______________________________ Reply Separator _________________________________ Subject: Re: ArcotSign (was Re: Does security depend on hardware?) Author: proff(a)iq.org at mime Date: 9/22/98 10:40 AM > >the legitimate user has, excepting the 'remembered secret'. Or is > >there anything wrong with my logic? > > Yes. There is something wrong with you logic. > > Bruce > ********************************************************************** > Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 There's something wrong with you grammer. Cheers, Julian. RFC-822-headers: Received: from CONVERSION-DAEMON by mail.hac.com (PMDF V5.1-12 #26580) id <0EZP00401AHMT4(a)mail.hac.com> for "jacob n bailly"@mime.mail.hac.com; Tue, 22 Sep 1998 12:37:00 -0700 (PDT) Received: from PROCESS-DAEMON by mail.hac.com (PMDF V5.1-12 #26580) id <0EZP00401AHJSC(a)mail.hac.com> for "jacob n bailly"@mime.mail.hac.com; Tue, 22 Sep 1998 12:36:58 -0700 (PDT) Received: from fw-tu05.hac.com by mail.hac.com (PMDF V5.1-12 #26580) with ESMTP id <0EZP0028FAHI2D(a)mail.hac.com> for "jacob n bailly"@mime.mail.hac.com; Tue, 22 Sep 1998 12:36:56 -0700 (PDT) Received: from toad.com ([140.174.2.1]) by fw-tu05.hac.com (8.9.0/8.9.0) with ESMTP id MAA16615 for <jnbailly(a)west.raytheon.com>; Tue, 22 Sep 1998 12:38:01 -0700 (MST) Received: (from majordom@localhost) by toad.com (8.7.5/8.7.3) id KAA03863 for coderpunks-outgoing; Tue, 22 Sep 1998 10:40:19 -0700 (PDT) Received: from iq.org (proff(a)frame-gw.iq.org [203.4.184.233]) by toad.com (8.7.5/8.7.3) with SMTP id KAA03857 for <coderpunks(a)toad.com>; Tue, 22 Sep 1998 10:40:13 -0700 (PDT) Received: (qmail 17488 invoked by uid 110); Tue, 22 Sep 1998 17:40:08 +0000 Date: Wed, 23 Sep 1998 03:40:08 +1000 (EST) From: proff(a)iq.org Subject: Re: ArcotSign (was Re: Does security depend on hardware?) In-reply-to: <4.0.2.19980922114142.00956610(a)mail.visi.com> Sender: owner-coderpunks(a)toad.com Message-id: <19980922174008.17487.qmail(a)iq.org> MIME-version: 1.0 X-Mailer: ELM [version 2.4ME+ PL28 (25)] Content-transfer-encoding: 7BIT Precedence: bulk

1 0

Child Bicycle Safety Site
by jal＠jb.com 17 Dec '03

17 Dec '03

Word has it that you ride a bicycle - and that's why you've received this piece of email. --------- You should visit this site if you ride a bike AND have a child: http://www.springfield-or.com/familytrends Tell someone else who rides with a child what you've seen. --------- If you wish to be removed from future mailings, please reply with the word "Remove" in the subject line. Thank you.

1 0

Re: Stego-empty hard drives... (fwd)
by Brian B. Riley 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- On 9/22/98 3:48 PM, Jim Choate (ravage(a)einstein.ssz.com) passed this wisdom: >When you're at that level you don't carry the data across the line >you get some Johnnie Mnemonic to do it for you or put it in a >diplomatic pouch... I think the real answer here, and totally in keeping with the KISS rule, has already been suggested. If you have sensitive data you keep it on a PCMCIA hard drive card and remove it when not in use (or a CD-R or a ZipDisk, though the PCMCIA hard drive does allow it to be a 'working' volume featuring speed and capacity that a Zip or a CD-R cannot offer). It can work as easily for a desktop as for a laptop. You can add to the security of this by using your platform of choice's flavor of Secure Drive, Cryptdisk, PGPDisk, etc. The ultimate stego is that the card is nowhere near the computer with the main hard drive and they don't bother looking beyond when the drive evaluation turns nothing up. If its trafficking in illicit data the "mule' shouldn't even be carrying a computer (or maybe only a Palm Pilot!) so the hounds have even less reason to be looking for comp[uter stuff on him. -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBNggY7j7r4fUXwraZAQG3swf8C3ypMG6EyI6t2I2LIpcwyV37Khv6Vm06 15HZ7rFOzrqwXG8RjDw4e99f5H76IG9FuDJUbUfJX0lS9aKtEaeeuSPUmtso8Au9 NrdTp3lHxMYJH9q+d8l1gVZWOnLQCjiJ7Ytd4LCmhmb3Ds58Sa41YoM71EFKZJkK AIBC2pmkRT1ido4uvtLc9qjPDf/jtLHVH17tMdBKCvn6R8jbLq4QHk6T0J9rJt1O +owC6R8YGpWjXPkIicsgfDD6qJiyyLLAMRX/1qWLVI+2CjeImhMsUGjafkq98x/B UU6bGq8B5m2aJmpVMqGFceuJe4mUTtqxLfYF/MlwLokib7ap8+EEZw== =A9fC -----END PGP SIGNATURE----- Brian B. Riley --> http://members.macconnect.com/~brianbr For PGP Keys <mailto:brianbr@together.net?subject=Get%20PGP%20Key> "First say to your self what you would be; then do what you have to do." Epictetus (35-135 A.D.)

1 0

Re: Stego-empty hard drives... (fwd)
by Brian B. Riley 17 Dec '03

17 Dec '03

On 9/22/98 1:43 PM, Jim Choate (ravage(a)einstein.ssz.com) passed this wisdom: >Forwarded message: > >> Date: Tue, 22 Sep 1998 11:07:34 -0500 >> From: Petro <petro(a)playboy.com> >> Subject: Re: Stego-empty hard drives... (fwd) > >> I don't know how hard this would be, but how about running a >> seperate memory check, and while those numbers are flashing on the screen, >> do the wait for imput? > >So hide the keyscan in the memory counter code. Would work externaly, would >probably not show up on TEMPEST. Since both the keyscan and the memory scan >are repetitive TEMPEST might have a problem telling them apart. Provided you >could get the keyscan in the same footprint as the mem check the BIOS >would not show up as anomolous in size. As long as they're not running >around doing checksums you'd be ok (I suspect). Don't most memory scans do a keyscan anyway? looking for an ESC to bypass the scan? So have it also check for something else to bring up your special routine. It should pass all but the most detailed signature analysis. Brian B. Riley --> http://members.macconnect.com/~brianbr For PGP Keys <mailto:brianbr@together.net?subject=Get%20PGP%20Key> "Give a man a fish and you have fed him for a day, but give him a case of dynamite and soon the village will be showered with mud and seaweed and unidentifiable chunks of fish." -Joe Chew

1 0

Re: Stego-empty hard drives... (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Subject: Re: Stego-empty hard drives... (fwd) > Date: Tue, 22 Sep 1998 18:04:28 -0400 > From: "Brian B. Riley" <brianbr(a)together.net> > Don't most memory scans do a keyscan anyway? looking for an ESC to > bypass the scan? Some do, some don't. A lot of new machines resolve those issues in the BIOS with a setting that allows you to choose between a couple of options at post. > So have it also check for something else to bring up > your special routine. It should pass all but the most detailed signature > analysis. Maybe, the fact that you've added an extra block of code in there to check for the additional keystroke would cause the cycle length of that section of ML to be slightly longer, probably no more than 30 - 40 clock cycles. If you're looking at the EM radiation that lengthening could show up. ____________________________________________________________________ The seeker is a finder. Ancient Persian Proverb The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage(a)ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------

1 0

CHALLENGE response (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

> Subject: CHALLENGE response (fwd) > The whole point of the CHALLENGE response went straight over his head, > didn't it? It didn't go over my head at all. What amazes me is that it took you this long to figure out that one could munge signatures. > We have here the first known case where a key was constructed ex post > facto to validate a signed message, in response to Adam Back's challenge. Um, I don't believe that is true. It may be the first time members of this list have managed it. > No longer can you assume that just because you posted a signed message > on a certain date, and you hold the public key which signed that message, > that you can later prove authorship. It challenges some of the implicit > assumptions which have been made in using public key cryptography. No, it challenges basic assumptions regarding the importance of identity. In no way does it effect the basic math of crypto, public or otherwise. And people wonder why I don't sign my messages... > And all Jim Choate can do is take issue with a snippet of Toto's ravings > which were included purely to illustrate the signature validity. He is > completely unaware of what is really happening. I've taken no issue with Toto or his ravings. Have a nice day. ____________________________________________________________________ The seeker is a finder. Ancient Persian Proverb The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage(a)ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------

2 1

advertisement
by befcorp＠mail.ios.net 17 Dec '03

17 Dec '03

561 540 4028 561 540 4028 E MAIL KING AND ASSOCIATES PUTS MONEY INTO YOUR POCKET!! OUR COMPANY HAS OVER 3 YEARS PROVEN E MAIL BLASTING EXPERIENCE! WORK SMARTER BY HAVING QUALIFIED PEOPLE PHONE YOU, ALREADY PREPARED TO BUY. PUT YOUR COLD CALLING DAYS TO AN END. TRY US OUT TODAY AND JUDGE THE RESULTS FOR YOURSELF! 10,000 E MAILS ARE ONLY $125.00 US. Do you only market your product or service geographically? Not a problem with E Mail King. We can target your e-mail broadcastes into the city of your choosing! FOR THOSE OF YOU WHO NEED MAILING CONTINOUSLY DONE, WE WILL E MAIL YOUR ADD TO 7500 DIFFERENT ADDRESSES DAILY MONDAY THROUGH FRIDAY MONTH AFTER MONTH FOR ONLY $250.00 PER MONTH. CALL TODAY FOR DETAILS ON THIS FANTASTIC OFFER!! IF YOU ALREADY HAVE YOUR OWN E MAIL SYSTEM, WHY NOT TRY OUR SUBCRIPTION SERVICE WHERE YOU WILL RECEIVE 50,000 FRESH GOOD E MAIL ADDRESSES EVERY MONTH FOR ONLY $90.00. ARE YOU INTERESTED IN BEING AN E MAIL KING RESELLER? PUT EVEN MORE MONEY INTO YOUR POCKET TODAY BY SIGNING UP WITH OUR PROGRAM TODAY!! IT DOES NOT COST ANYTHING TO JOIN!! We accept Visa, Mastercard or Cheque by Fax. James phone 561 540 4028 _________________________________________________________________ TO BE REMOVED FROM OUR LIST, email james456(a)indiasite.com and type in "remove" in the subject header or call (561)540 4028 our mailing address is EMAIL KING 1790 Bonhill Rd Mississauga Ontario Canada

1 0