December 2003 - cypherpunks-legacy

RE: FLORIDA DRIVERS PERMITS AND A HELLO
by alano＠teleport.com 17 Dec '03

17 Dec '03

Date: Tue, 29 Aug 1995 12:06:42 -0700 To: cypherpunks(a)toad.com From: Alan Olsen <alano(a)teleport.com> Subject: Re: Florida Drivers Permits and a Hello At 01:47 PM 8/29/95 -0500, you wrote: >Alan Olsen writes >>They would not have to include an entire thumbprint. The actual code used >>to verify fingerprints is not very large. All that would be needed is >>enough information to ID into the "official" records and enough checksum >>type information to prevent alteration/counterfitting. Using magnetic media >>for this is a bit foolish as it can be changed/destroyed with the stroke of >>a magnet. I will not say by what means I would think should suit as a >>better encoding scheme because: 1) They are not using it and 2) I do not >>want to give them any ideas. > >What possible value could the LEAs get by having your thumbprint digitally >encoded on your driver's license? It's not like the average cop-on-the-beat >is qualified to lift a fingerprint and compare it. Even if he was, how >does it benefit that the fingerprint is on the license? > >This seems silly. I was pointing out that it was possible. I was not trying to make the point that there was any *USE* for such a thing. (Evidently some ID cards now carry such prints. California does, if memory serves me correctly.) Just because something is silly does not mean it will not be tried by someone in law enforcement. In fact, there seems to be a corelation between silly acts and law enforcement... (Or at least those making the rules about law enforcement.) And if you think it cannot get any worse, Pete "I want to seal the borders" Wilson has announced he is running for president. We will be getting a large number of silly laws and pronouncements if the American people are stupid enough to elect him to high office. > > | Visualize whirled keys! | alano(a)teleport.com | |"The moral PGP Diffie taught Zimmerman unites | Disclaimer: | |all mankind free in one-key-stenography-privacy!"| Ignore the man | | -- PGP 2.6.2 key available on request -- | behind the keyboard.| | http://www.teleport.com/~alano | <fnord> |

1 0

Toto UnMasked!!!
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

And in June, authorities in Cincinnati, Ohio, removed three toddlers from the feces-strewn bedroom they were locked into for up to 12 hours a day; their mother, Sandra Hacker, allegedly did not want them disturbing her while she was on the Internet. News of the Weird by Chuck Shephard

1 0

NIST KEY ESCROW MEETING
by remailer＠flame.alias.net 17 Dec '03

17 Dec '03

Date: Wed, 30 Aug 1995 07:51:07 +0200 To: cypherpunks(a)toad.com From: Flame Remailer <remailer(a)flame.alias.net> Subject: NIST Key Escrow meeting Subject: NIST Key Escrow Meeting Discussion Papers Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #1 Issues -- Export of Software Key Escrowed Encryption On August 17, 1995, the Administration announced its proposal to permit the ready export of software encryption provided that the products use algorithms with key space that does not exceed 64 bits and the key(s) required to decrypt messages/files are escrowed with approved escrow agents. Under the proposal, products will be reviewed to verify that they satisfy the criteria and, if so, they will be transferred to the Commodity Control List administered by the Department of Commerce where the products can be exported under a general license (in much the same way that 40-bit RC2/RC4 encryption is licensed today). We are working toward creating broadly stated criteria that are in the nature of performance specifications. To meet these criteria, encryption products will need to implement key escrow mechanisms that cannot be readily altered or bypassed so as to defeat the purposes of key escrowing. The criteria, when finalized and published, will state the objectives, but not the exact technical method(s), by which those objectives are satisfied. This is to provide software publishers the flexibility to design methods for meeting our stated objectives in a manner that is compatible with the design of their products. There are, therefore, a number of questions we must work together to answer in order to draft effective criteria. These questions are: * Avoiding multiple encryption -- How can the product be designed so as to prevent doubling (or tripling, etc.) the key space of the algorithm? * Disabling the key escrow mechanism -- How can products be made resistant to alteration that would disable or circumvent the key escrow mechanism? How can the "static patch" problem be avoided? How can this be tested? * Access to escrow information -- What mechanisms must be designed into encryption products to allow authorized access to escrowed keys? This likely includes the identity of the key escrow agent(s) and a serial number for the key escrow agent to use to identify the key(s)/component(s) necessary to decrypt the message. What other information will be necessary to be provided to the escrow agent to identify the necessary key(s)/component(s)? Are there other comparable viable approaches? * Non-escrowed use -- How can products be made so that they do not function with non-escrowed products (or tampered escrowed products)? How can this be tested? * Limiting surveillance -- How can products be designed so that information both sent and received by the user can be decrypted without release of keys of other users? * Practical Key Access -- How can mechanisms be designed so that repeated involvement of escrow agents is not required for decryption for multiple files/messages during the specified access period? * Assurance that keys are escrowed -- How can it be assured that key escrow products are indeed satisfactorily escrowed? For example, products could be required to be escrowed at time of manufacture or be made inoperable until properly escrowed. * Ability to re-escrow keys -- How can products be designed so that new keys can be escrowed at the user's discretion with a U.S. Government approved escrow agent? * Certified escrow agents -- Can products be designed so that only escrow agents certified by the U.S. government (domestic, or under suitable arrangements, foreign) are utilized? What should be the criteria for an acceptable U.S. escrow agent? -------------- With your input, we are hopeful that this effort will lead to definitive criteria, which will facilitate the development of exportable products and help minimize the time required to obtain export licenses. The Administration seeks to finalize such criteria and make formal conforming modifications to the export regulations before the end of 1995. Note: These issues will be discussed at the Key Escrow Issues Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at the National Institute of Standards and Technology (Gaithersburg, Maryland). The meeting will be open to the public, although seating is limited. Advance registration is requested, please contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e- mail: carlton(a)micf.nist.gov. 8/25/94 ----------------------------- Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #2 Discussion Issues: Desirable Characteristics for Key Escrow Agents In the government's recent announcement of its intent to allow the export of 64-bit software key escrow encryption products, one stipulation was that the keys would be escrowed with an approved key escrow agent.(*1) Exactly what qualifications/considerations are appropriate for approval as a key escrow agent have not been defined. Some of the issues which need to be discussed and resolved include the following: * What kinds of organizations should be excluded from consideration as approved key escrow agents? * What sort of legal agreement between the government and the key escrow agent is necessary to stipulate the responsibilities of the agent? Should this include the terms and conditions under which release of a key is required? * How will liability for unauthorized release of key be handled? * Should, for example, intentionally misreleasing or destroying a key be criminalized? Should this include other actions? * How can the government's needs for confidentiality of key release be handled? * Should approval of key escrow agents be tied to a public key infrastructure (for digital signatures and other purposes)? * What procedures need to be developed for the storage and safeguarding of keys? * What are the acceptable performance criteria (e.g., around- the-clock availability, accessibility, reliability, etc.) for approved key escrow agents? * Under what circumstances will key escrow agents in foreign countries be approved? * What process will be used to approve escrow agents? Costs/who pays? --------- (*1) "Approved," for the purposes of this discussion, means that the government (or its agent) has formally granted permission for an organization to hold keys for exportable encryption products. Note: These issues will be discussed at the Key Escrow Issues Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at the National Institute of Standards and Technology (Gaithersburg, Maryland). The meeting will be open to the public, although seating is limited. Advance registration is requested, please contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e-mail: carlton(a)micf.nist.gov.

1 0

RE: THE ILLEGAL MARKETS OF CYBERSPACE
by carolann＠censored.org 17 Dec '03

17 Dec '03

Date: Wed, 30 Aug 1995 02:48:43 -0500 To: cypherpunks(a)toad.com From: carolann(a)censored.org (Censored Girls Anonymous) Subject: Re: The illegal markets of cyberspace Thank you for the easy to understand concepts. Now where was that nobody(a)nobody.org key again? Love Always, Carol Anne....wondering if the Undernet was as good as the Blacknet? -- Member Internet Society - Certified BETSI Programmer - Webmistress *********************************************************************** Carol Anne Braddock (cab8) carolann(a)censored.org 206.42.112.96 My Homepage The Cyberdoc *********************************************************************** ------------------ PGP.ZIP Part [017/713] ------------------- M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M MF=O0H+*%(-S%&>S%+FS&<LS%3(Q&#W1"<]2%`H^;,]^1C$'HBN8PX$4SYAU^ MPGD<Q0ZLA0D+,`MCT!LA**4M[-JPAK9F?40!AJ,CW"'%DR#:'9?Q)3[%<DQ` ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/

1 0

[COMP.SECURITY.UNIX] ADVICE ON PASSWORD SECURITY GUIDELINES
by alano＠teleport.com 17 Dec '03

17 Dec '03

Date: Wed, 30 Aug 1995 20:55:24 -0700 To: cypherpunks(a)toad.com From: alano(a)teleport.com (Alan Olsen) (by way of Alan Olsen <alano(a)teleport.com Subject: [comp.security.unix] Advice on password security guidelines I found this on alt.humor.best-of.usenet. It seemed like something that would be appreciated here. (And it is not that far off topic.) Enjoy! ----------------------------------------------------------- In alt.humor.best-of-usenet, Artur Pioro <artur(a)thp2.if.uj.edu.pl> wrote: >From: Paul Ashton <paul(a)argo.demon.co.uk> >Newsgroups: comp.security.unix >Subject: Advice on password security guidelines >Hi, >my boss has asked me for comments and improvements on his new password >security policy. To me, it seems a bit severe. If anyone can offer any >additional suggestions please do, here goes... >For immediate issue: >Password changing guidelines V2.2b >Due to new security policies, the following guidelines have >been issued to assist in choosing new passwords. Please follow >them closely. >Passwords must conform to at least 21 of the following attributes. >1. Minimum length 8 characters >2. Not in any dictionary. >3. No word or phrase bearing any connection to the holder. >4. Containing no characters in the ASCII character set. >5. No characters typeable on a Sun type 5 keyboard >6. No subset of one character or more must have appeared on > Usenet news, /dev/mem, rand(3), or the King James bible (version 0.1alpha) >7. Must be quantum theoretically secure, i.e. must automatically change > if observed (to protect against net sniffing). >8. Binary representation must not contain any of the sequences 00 01 10 11, > commonly known about in hacker circles. >9. Be provably different from all other passwords on the internet. >10. Not be representable in any human language or written script. >11. Colour passwords must use a minimum 32 bit pallette. >12. Changed prior to every use. >13. Resistant to revelation under threat of physical violence. >14. Contain tissue samples of at least 3 vital organs. >15. Incontravertible by OJ Simpsons lawyers. >16. Undecodable by virtue of application of 0 way hash function. >17. Odourless, silent, invisible, tasteless, weightless, shapeless, lacking > form and inert. >18. Contain non-linear random S-boxes (without a backdoor). >19. Self-escrowable to enable authorities to capture kiddie-porn people > and baddies but not the goodies ("but we'll only decode it with a > court order, honest"). >20. Not decryptable by exhaustive application of possible one time pads. >Due to the severity of the restrictions, if the password is entered >incorrectly 3 times at login time, you will be asked if you would like to >pick a new one. >Please add guidelines to the above and adjust the minimum conformation >requirement, if applicable. >-- >Moderators accept or reject articles based solely on the criteria posted >in the Frequently Asked Questions. Article content is the responsibility >of the submittor. Submit articles to ahbou-sub(a)acpub.duke.edu. To write >to the moderators, send mail to ahbou-mod(a)acpub.duke.edu. | Spam is the Devil's toothpaste! | alano(a)teleport.com | |"It's only half a keyserver. I had to split the | Disclaimer: | |other half with the government man." - Black Art | Ignore the man | | -- PGP 2.6.2 key available on request -- | behind the keyboard.| | http://www.teleport.com/~alano | <fnord> |

1 0

The 1996 RSA Data Security Conference Proceedings
by Nobuki Nakatuji 17 Dec '03

17 Dec '03

Does anybody have The 1996 RSA Data Security Conference Proceedings? If You have it,Please send e-mail to me. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Get Your Site Noticed!!
by wgrip＠spica.net 17 Dec '03

17 Dec '03

Hello, Do you have a webpage that's just sitting there? Would you like more hits and visibility? Now you can promote your pages like the Pros! The WebSeek Promotion Spider puts your pages on the TOP of the Search Engines! Get your FREE Shareware Version today and see what this powerful program can do for your site!! For more info please respond to our Autoresponder at: mailto:inet@spica.net and say "Promo-Now" Resellers Needed! thanks, Web Promotions! ~~~~~~~~~~~~~~~~~~~~~~~ Note: You will not receive another message BUT we do utilize the Remove List at: remove(a)remove-me.com

1 0

Re: Mandatory key escrow bill text, backed by FBI
by Secret Squirrel 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Mike Duvos wrote: > This is blatantly unconstitutional and breaks new ground that the > government has never even dared hint at before. > The true agenda of the GAKers has finally been disclosed to the > American public. > Next they will want copies of all of our house keys for the > jackbooted thugs to hold, and emergency Assault Plungers in all our > umbrella stands ready for the cops to ram up the citizens' assholes. > This is not simply a proposed bill. It is an ACT OF WAR. > It is them or us. I pick us. How many divisions do we have? You have probably done more with the Eternity Service already than you can ever hope to do with weapons. Our strong points are ideas both those expressed as code and those expressed as English. Ideas catch on with other people and then they replicate. Ideas are hard to subvert. Ideas are what we are good at. Monty Cantsin Editor in Chief Smile Magazine http://www.neoism.org/squares/smile_index.html http://www.neoism.org/squares/cantsin_10.html -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBNBGbmJaWtjSmRH/5AQGmsQf/R4mQ4AiMsHS1PnwDzfX2i3a2Jad/g1tj zzNzgwEN8HaegZ1r2wT9/r874cMcVsziaHDH8YPfwRDU+LLAtGZ+OuzXbK+h8Qt7 z2XCNZ3pOcZV2/6i9t7ayWb3A7y4axzIFB9UT96hi0Z0SHaZM3y6zmiCPNfxLZDy 9b9SS0FF/HvBbBSzTtOovA9UtNpbKHgYjGyuxt06ySJu5ZLgnswNQSttDJP4LF2n E8e8h8/lnzJCX6VISuvyyEKzvmGcYsvfnxPVoG1h4knLTgkkuIssrFUzmakGKPPp SbhWdtv8FjBB5FvDisMhHijiqRn/bhd3G59vVkq5fBfWG7ffb3R2TQ== =WbQ0 -----END PGP SIGNATURE-----

1 0

O.J. ObCrypto: Fuhrman's Folly Fans Fakery Fears...
by monty.harder＠famend.com 17 Dec '03

17 Dec '03

From: monty.harder(a)famend.com (MONTY HARDER) Date: Wed, 30 Aug 95 23:50:00 -0500 Organization: The First Amendment BBS Regardless of whether Ito allows the tapes into evidence, the public has heard a LEO matter-of-factly discussing the fabrication of evidence against US citizens. We should take advantage of this, by connecting the Fuhrman/Good Ole Boys from BFART bit, and GACK. If my private key must be escrowed with Lawn Forcement Agencies, the very real possibility exists of a Fuhrman using it to forge evidence against me. In =any= Key Escrow arrangement (including the non- government variety preferred by 4 out of 5 Cypherpunks in a recent survey) there must be a division between encryption keys and signature keys. I recommend that anyone who will be using escrowed keys generate two pairs: First, the signature key, including in the userid some kind of [sig use] identifier (we should settle on a standard abbreviation for this) follower by the encryption key. This way, when a person gets your pubkeys, they get the encryption key =last=, which gets it searched first whenever they PGP -e... something. Whatever arrangements are made for escrowing my encryption key, =nobody= gets my signature key. If I am fired, quit, become brain damaged or dead, my key can never be used by anyone to implicate me in any criminal activity. Please don't mention to anyone the fact that my signature key can be used to send me something that even the escrow agents can't read.... * --- * Monster(a)FAmend.Com *

1 0

SSL and MIPS...
by cwe＠csli.stanford.edu 17 Dec '03

17 Dec '03

Date: Tue, 29 Aug 1995 23:03:59 -0700 From: Christian Wettergren <cwe(a)Csli.Stanford.EDU> Hi! How much computing power did we actually use, in terms of MIPS/FLOPS*hours? An unloaded SS10 that didn't swap went at approximately 16400 keys/s. How many MIPS is an SS10 approximately? How does different algoritms compare? DES, RC40, RSA512 etc? Or if I pose the question differently, what can you do with 30 GIPS for a day? /Christian

1 0