December 2003 - cypherpunks-legacy

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

17 Dec '03

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). ____________________________________________________________________ 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

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

Re: ArcotSign (was Re: Does security depend on hardware?)
by Mike Stay 17 Dec '03

17 Dec '03

>>In that case please allow me to go back to a point raised by me >>previously. The user uses his 'remembered secret' (of fewer bits) >>through a public algorithm (including protocol) to retrieve from a >>pool the password (of more bits). If the attacker doesn't have the >>pool then everything looks fine. But if he manages to get the pool >>(a case someone mentioned in this thread) then he can obviously >>brute force offline, I believe, since he possesses now everything >>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 >101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 > Free crypto newsletter. See: http://www.counterpane.com According to the website, there's no pool of passwords. There's a truncated hash that will catch most mistakes, but is useless as a test criterion in a dictionary attack. If you get the user's "public" key, then you can do a dictionary attack. The user's "public" key isn't public, however; not even the user knows it. If I'm understanding it right, it's stored encrypted and the key is only given to a set of predefined servers. Prior relationship must exist; they admit that. -- Mike Stay Cryptographer / Programmer AccessData Corp. mailto:staym@accessdata.com

1 0

Arcot (fwd)
by Ryan Lackey 17 Dec '03

17 Dec '03

(originally to a bunch of places, but I misspelled "cypherpunks" in the headers...) (operating on generator power after hurricane georges struck Anguilla...) The way I see it, there are n separate issues here, which should be addressed separately. The following are my summaries of the issues, using the information I have available -- I have never seen any confidential Arcot data, so I'm operating entirely from public sources. It's entirely possible my data or assumptions are incorrect -- I'd be very happy to have someone correct me. 1) The Arcot system uses "software smartcard" repeatedly throughout its marketing literature, and says that it provides similar security to smartcards. However, even in the technical paper recently posted to the web by Arcot, it admits it does not provide resistance to a wide class of attacks, including the two Stefan Brands mentioned: * Resistance to monitoring attacks on the CPU * End users reverse-engineering the system I have issues with this use of the term "smartcard". In fact, this system has *none* of the desirable properties of a smartcard, as users can freely copy the authenticator. It is, at best, equivalent to an encrypted certificate on disk which can only be checked for validity online (no local checksums, no structure to the cert, just a raw random string). The phrase "two factor authentication", used throughout the marketing literature, is being used improperly -- two passwords (one remembered and one stored on disk, since the ArcotSign authenticator is just a string of data) do not two-factor authentication make, if two passwords (one remembered and one stored as an encrypted certificate on disk) do not two-factor make. It's an open point whether both systems or neither are two-factor, but it's pretty clear that the two are equivalent. 2) Scott Loftesness, the new CEO of DigiCash, proposed this system as potentially a viable alternative to hardware tamper resistance for electronic finance systems (DBS systems). The threat model for real electronic finance systems (including and especially DBS) is in fact substantially more serious, as recent Rabobank windows client attack demonstrates. Once your customers *can* have money stolen by a third party, it's up to you to prove they *haven't*, at least according to US and other law, for small customers. This means only institutions capable of absorbing massive fraud (in absolute terms) can field real electronic cash systems. This is primarily a debate about threat models for a specific application, rather than a technical one. 3) The system appears to use PKC for no reason -- it is a closed system, like Kerberos, and only limits itself by using PKC. Kerberos, developed by some list participants *years* ago, appears to solve every problem Arcot claims to solve. Additionally, Kerberos (in some form) is now being integrated into MS Windows NT, so it is widely available. 4) Bruce Schneier, one of the firm's technical advisors, says "it's not [sufficient for] online real estate [presumably meaning high value transactions with no recourse]", but that it is for "ninny net users in chat rooms". The apps Bruce Schneier seems to propose the Arcot system for ("systems like AOL" (read: porn sites on the WWW)) are more concerned with their users not being able to share passwords than anything else. For that application, simple IP-based security in addition to passwords is sufficient, or other means of ensuring an authenticator is linked to an individual. The Arcot system does not provide security from this issue (even though it is intended for closed networks, where such functionality would be highly possible). However, the firm's marketing information seems to be selling this to corporate web sites, for protecting high value corporate data. I find it highly unlikely any board of directors would consider their proprietary corporate data closer to "ninny net users in chat rooms" than something requiring real security. (Even people without real security requirements often want high security, or at least systems with no known limitations -- I use high-grade encryption to protect my credit card information, even though my liability is limited to $50, and many other users are unwilling to use 40-bit crypto to protect their credit card numbers.) 5) The point was raised that in a smartcard system, you don't know what you're signing. I agree completely. However, in a smartcard system, you can protect the *keys* to a far higher level than protecting the *use* of the keys when the key is physically present. This is a substantially lower level of risk, particularly if a security policy is included in the smart card, such as only disbursing a limited amount of money per unit time, or monitoring suspicious transactions, or handling user authentication through a strong external channel, such as a PIN reader attached directly to the smartcard reader. The earlier debate on smartcards vs. tamper-resistant computers with I/O leads me to believe that for electronic cash in reasonable value ranges (>$1000), you most likely want to go with *more* than a smartcard (as in, a tamper resistant computer), but certainly you don't want to go with *less*. For many applications, a combination of trusted time (on the smartcard) and a trusted smartcard (and perhaps location) would be sufficient -- a user could then be made to prove they were not in a certain location at a certain time when a transaction were made to absolve themselves of responsibility for it. 6) "Hardware is expensive" So is software. The cost of implementing any authentication mechanism, particularly in a closed system, is relatively constant -- passwords through cheap hardware -- as most of the cost is in administrative overhead, user training, etc. I'd far rather go with an $8 Dallas Semiconductor iButton plus $0-$100 software plus $400/user training/etc. cost than $0 hardware plus $x software plus the same user training cost. In many systems, hardware is *cheaper* in the long run, as users understand it better, are better at doing their own key management, etc. It is exactly for closed systems where hardware solutions *shine* compared to software, even if they provide the *same* security in absolute terms -- the hardware solution has lower life-cycle costs. For an open system, or one where you have minimal control over the users (such as AOL, or a porn WWW site, or whatever), the requirement that software be added to the local machine is usually prohibitively expensive. In that kind of application, all of the intelligence needs to go on the server -- an online password checking system, coupled with standard browser features like client certificates, is about the most you can expect, and even that is pushing it (until MIT did cert support for Lynx, many of my machines were unable to use certificates at all). 7) "The system is patent-pending." I do not see how the system is provably higher in security or any other worthwhile features than the following widely deployable, standard, free system: * online password checking of user passwords, optionally changing in some kind of one-time-pad system, passed through an SSL-encrypted link to the server, such that if a password guess attempts were made, the account could be locked out. * encrypted local certificates, encrypted with optionally a different passphrase, which do *not* need to be kept secret. This provides "two factor" authentication to the same extent as the Arcot system, is easy to implement using standard systems, and is conceptually simple. In the event that the Arcot system is no better than the above (which I believe), which is *not* patentable, I fail to see why the issue of whether Arcot's system can be patented is important. The only parts which could be patented (as far as I can tell) are accidental, not the essential functionality of quasi-two factor authentication with online password checking to prevent off-line attacks. 8) The various IP/patent/etc. issues A company could implement open standards based authentication, in an open way, publish papers on every detail of their system, etc. and still make quite a bit of money. They do this through the quality of their *software engineering*, not the quality of their idea. Ideas are expensive to create, and impossible to keep secret, even with patents. Once you come up with an idea, most of what gives it value is the review process itself, not the initial idea. That's why the valuable ideas I can think of, at least in crypto, have mainly come from universities and open research labs -- they can more cheaply be reviewed. Only the NSA has the resources to make an idea valuable and also keep it closed (and if you believe Payne, even they don't...) I understand that Arcot is a commercial company, and that it's trying to make money, but I don't think that actually counters any of the points presented above -- if anything, it makes them stronger, as Arcot has a strong desire to increase the value of its assets (the deliverable authentication system) much more so than a random hacker working on this as a curiosity.

1 0

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: Stego-empty hard drives... (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Tue, 22 Sep 1998 14:25:10 -0400 > From: Sunder <sunder(a)brainlink.com> > Subject: Re: Stego-empty hard drives... (fwd) > All stego methods are weak approaches at hiding data. We're not discussin stego, we're discussing hidden disk partitions, not hiding data in the lsb of of existing observable disk partitions or something similar. > Who the fuck is gonna run a tempest scanner on your notebook again? Let's Considering the cost of such a scanner (a few $10k/ea.) and assuming such masking technology were to become commen place I doubt if very many customs checkpoints at major transfer hubs wouldn't have them. > Why would you need to collect BIOSes? You only need to modify a single BIOS - > the one on >YOUR< notebook. The camouflage code would be a few hundred bytes > at most unless you do something overly elaborate. I suspect it would be several k actualy since it is going to have to include the encryption code, device drivers, wedgers, etc. > Disassemblers (debuggers) are fairly cheap. DOS and WIN95 come with a simple > one called debug. A disassembler isn't a a debugger. All a disassembler does is convert the hex to symbols (see frankenstein for an excellent design). > programming. You don't need to disasemble everything in the BIOS, you just > need to disable the checksum routine the bios uses on itself, and you need to > slightly modify the place that detects the size of the IDE drive to not go > beyond a certain number of pointers. So much for your few hundred bytes. > Further, PC bioses do support BIOS extensions, you generally wouldn't need to Um, usualy they support wedging via a jump table. This means that not only do you still have the original code you wedged out but you have the new code you've wedged in. A 2x penalty. > provide booting capabilities from SCSI disks. Of course it's a bit harder in a > notebook computer, but it too can be done. Nobody says it can't be done. > One thing all you fine folks are forgetting is that there are MANY MANY types > of notebooks out there. With only a few dozen BIOS'es driving the whole kit and kaboodle. > My money says that if they can't scan Mac's they also > won't be able to scan Sparc books, Alpha Books, Newtons, Palm Pilots, and many > WinCE palmtops either. Just buy something exotic. They're new, they will learn from their mistakes and it won't take long. After all, they have your tax dollars to use... ____________________________________________________________________ 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

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

17 Dec '03

Forwarded message: > Date: Tue, 22 Sep 1998 13:04:15 -0500 > From: Petro <petro(a)playboy.com> > Subject: Re: Stego-empty hard drives... (fwd) > At a certain threat level or level of "interest" in your affairs, > whether you can hide the fact that you are using crypto or not is going to > become irrelevant. 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... > If your opponent is using tempest, you are operating at that level. > Tempest is expensive, and I'd imagine would have to be calibrated not only > for each processor ([3-6]86, with all the variations (sx/dx, celeron, xenon > etc,) as well as the NEC. AMD. and Cyrix clones thereof, ARM & StrongARM > processors, PPC 601/3/4/G-3 processors, Motorola 68k processors, sparc > processors etc) but (if you are looking at what the POST & BIOS actually > does) for each BIOS AND OS. This is NOT an easy task, nor can it be done by > a Bozo operating a X-Ray machine at an airport. Consider that at any given time there are only a few hundred BIOS'es, made from a few dozen base images, driving all the machines out there. The number of companies that develop their own BIOS in toto for in-house products is next to nil (I know of none). What they do is buy a license and then re-write the sections they need to. The TEMPEST signal will be effected by speed, I see no reason to suspect that it's going to be processor dependant. Since the code gets executed in the same sequence in these shared BIOS there is going to be a shared footprint, which may get squeezed because of increased clock speed. Measuring that footprint at ranges of inches is nowhere near as expensive as trying to catch a monitor image from a block away. If you store those few thousand footprints and do a compare any bozo can in fact run the machine. Just sit and watch to see if the red light comes on and call your supervisor. ____________________________________________________________________ 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

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