December 2003 - cypherpunks-legacy

Re: Hash of plaintext as key?
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:56 AM 2/22/96 -0800, John Pettitt <jpp(a)software.net> wrote: >I have this application which encrypts software prior to distribution. I'd >like to pre-encrypt most of the data (individual files) and then just >encrypt all the individual file keys with a customer specific key at run >time. (This is mostly a CPU cycle saving thing). Depending on the security environment you're running in, this can be fine or can be dangerous; think about your threat models carefully. For some applications, it makes a lot of sense. It does give you a traffic analysis problem - Eavesdroppers can tell that you sent the same document to Alice, Bob, and Eve, but not Fred, in case this matters to you. You could strengthen it a bit by superencrypting the copy you send to the user with a very fast Snake-Oil algorithm, but Eve has the real document (and the version encrypted with the good algorithm), so she's got known plaintext for cracking messages sent to Alice and Bob if she wants. In a DES world, you might do almost-triple-DES by encrypting with two common keys up front and use DES with separate third keys for the final stage. With RC4 or RC5, that doesn't gain you much, since the difference between RC4/40 and RC4/256 is all in the key-scheduling phase, not the bulk part. >I thought I'd use the MD5 (or SHA) hash of the plaintext as the key. Plenty >of entropy in the entire plaintext, a different key for each file and if you >know the plaintext to calculate they key you don't need the key anyway! It doesn't really gain you anything; generating pseudo-random key bits isn't much work compared to encrypting the files or public-key encrypting the file keys to send to users, and there's no benefit other than getting some extra entropy bits (which you may want to do anyway to stir into your entropy pool in addition to using a random number source.) What it does risk, in case this threat matters, is that somebody who can guess the documents you might be encrypting can calculate their MD5s and trial decrypt. This lets them verify whether a given document is in the encrypted database, for instance. One of the NSA Rainbow Books discusses secure databases - maybe Purple or Gray? #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

1 0

SET spec available
by John Pettitt 17 Dec '03

17 Dec '03

The SET transaction spec is now available on www.visa.com (and presumably on www.mastercard.com although I didn't check). Highlights are: It cops out on the big one - how to identify card users in the first place to issue certificates. The MS/Visa 'credential' that looked like a certificate but wasn't has been replace by X.509 -- John Pettitt email: jpettitt(a)well.sf.ca.us (home) jpp(a)software.net (work)

1 0

Re: pcmcia
by geeman＠best.com 17 Dec '03

17 Dec '03

At 10:58 AM 2/22/96 +0000, you wrote: >I am just assuming that the Association (PCMCIA) has a way of distributing >specs, etc. You can call them in San Jose, CA @ 408 433 2273 $475.00 for non-members, paper only. $715, paper/CD both. >I also assume they have a web page and all that, maybe >even a citizen-unit subscribed to this mailing list who probably could >point us in the right direction. www.pc-card.com, I believe >I think PCMCIA cards offer a lot of >potential as wallets and general purpose privacy prophylaxis engines. Absolutely, and without doubt. They are coming. >I don't know anything about the technology, but the device drivers, et al, >could be publicly reviewed and recompiled on trusted machines, presumably, >and the device itself could be tested (I assume) with a publicly >available routine that once again one could install from source, etc. There are commercially available drivers, tested rigorously. Fortezza cards and s/w are very solid, as well as other cards derived from that type of technology. Fortezza cards are self-testing. > >how much do the slots cost to add on to pc's that don't already have them? >Is there a parallel interface, for instance, that can plug into a >printer port? SCM Microsystems, 408 370 4888 has a "Swap Box" product. I don't know the cost. >-- >PJ >------------------------------------------------------------------------ > >On Thu, 22 Feb 1996, Adam Shostack wrote: > >> P.J. Ponder wrote: >> >> | obligatory crypto comment: has anyone looked at the iPower card and >> | gotten one to play with? Where else could one get a PCMCIA card that was >> | programmable and had a little memory on it? How hard would it be to make >> | one - in other words, what could we get the cost down to for an >> | encrypting pcmcia card? there couldn't be much to it, really, could there? >> >> I got one, its very badly documented; theres some source in >> Visual basic for windoze. I haven't had time to track down real docs >> so I can do anything. Anyone know who I can call to get real >> documentation? >> >> Adam >> >> >> -- >> "It is seldom that liberty of any kind is lost all at once." >> -Hume >> > >

1 0

The "excrable" e$
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 3:02 AM 2/24/96, Timothy C. May wrote: >I can only hope that someone soon trademarks the stupid "e$" and thus >enjoins the rest of us from using it. Or, as Mr. May has said in the past, "the excrable" e$. ;-). >(On a serious note, yet another example that the American copyrighting and >patenting engine is overrevving.) Say "amen", somebody. Actually, *I* seem to be the unfortunate wretch who coined (ahem...) the term "e$", as it refers to a dollar digitally spent on the internet. My apologies to those spenders of yen, marks, and pounds. I hope I can take some solice in the notion that all money's fungible. :-). In addition, there's no reason not to use e¥, or e£, if people can read your character maps. One of the reasons I chose e$ is that I believe $ is way down deep in the ASCII character set, and thus most machines will display it. Ethnocentrism and potential trademark enfringements aside, a bit of pronounciation may be useful here: when I see "e$" alone in text, I say "e-money" (again, my apologies), and when I see "e$10.00", I say "ten e-dollars". Speaking of trademarks, I had hoped that by using "e$" everywhere that we could avoid such legal mechanations, in the same vein that various mathematical notation schemes cannot be copyrighted (I think). For the lawyers out there, is it possible to do the equivalent of a GNU GPL "copy-left" with a potential trademark like "e$"? If it is, I'd like to do that. Ubiquity is power, and all that, "excrable" symbols and all... <PlugMode-on> Anyone interested in discussing trends in, or the consequences (economic, social or otherwise) of *financial* cryptography on public networks, is cordially invited to subscribe to the e$ mail list. Send "subscribe e$" in the body of a message to majordomo(a)thumper.vmeng.com, and, after you've subscribed, introduce yourself! The list is unmoderated. <PlugMode-off> Cheers, Bob Hettinga (e$mpressario) ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "Reality is not optional." --Thomas Sowell The e$ Home Page: http://thumper.vmeng.com/pub/rah/

2 1

InterNIC Guardian Object Draft
by Eric Eden 17 Dec '03

17 Dec '03

We're distributing this to the Internet community for comments and suggestions. If you have any ideas for improving this draft please let us know. I apologize in advance for the length, but the authors are really interested in your thoughts. Thanks, Eric Eden erice(a)internic.net InterNIC Registration Services 703-736-0145 [ URL ftp://rs.internic.net/policy/internic/internic-gen-1.txt ] [ 2/96 ] Jasdip Singh Network Solutions Mark Kosters Network Solutions The InterNIC Guardian Object DRAFT Table of Contents 1. Introduction....................................................... 1 2. Main Features of a Guardian........................................ 1 3. Guardian Attributes................................................ 1 4. Registering the Guardian Attributes................................ 4 4.1 Using the New Contact Template.................................... 5 4.2 Using the Modified Registration Templates......................... 5 5. Linking Guardian Information to Existing Records................... 5 6. Notification....................................................... 6 7. Object Update Rules................................................ 6 7.1 Request from a Contact with Authentication Information............ 7 7.2 Request from a Contact without Authentication Information......... 7 7.3 Request from a Sender not listed as a Contact..................... 7 8. Object Use Rules................................................... 8 8.1 Request from a Contact............................................ 8 8.2 Request from a Sender not listed as a Contact..................... 8 9. Other Guardian Issues.............................................. 8 9.1 Number of Guardians per Object.................................... 8 9.2 Protecting Guardian Information................................... 9 9.3 Displaying Guardian Information................................... 9 10. Conclusion........................................................ 9 11. References........................................................ 9 12. Acknowledgements.................................................. 9 A. The Proposed Contact Template...................................... 10 B. The Proposed Link Template......................................... 12 C. The Proposed Notify Template....................................... 14 D. Object Update Rules................................................ 15 E. Object Use Rules................................................... 16 F. Examples........................................................... 17 F.1 How to Register a New Contact with Authentication Information..... 17 F.2 How to Link Guardian Information to Existing Records.............. 18 F.3 How to Update a Guarded Record.................................... 19 F.4 WHOIS Display of Guardian Information............................. 20 [Page i] 1. Introduction This document proposes a model to authorize changes made to the Objects (Domains, Networks, Autonomous System Numbers, and Hosts) registered with the InterNIC. The registration activity at the InterNIC has increased exponentially with the rapid growth of the Internet. In the absence of a formal authorization model, the likelihood of making malicious changes to the registered Objects has also increased and could have serious consequences at the affected sites. For example, an unauthorized update could lead a commercial organization to lose its presence on the Internet until that update is reversed. 2. Main Features of a Guardian - A Guardian is an Object that protects other Objects from unauthorized changes. It is basically a Contact with Authentication Information. - The different authorization schemes to authenticate a Guardian are MAIL-FROM, CRYPT-PW, and PGP. - The use of a Guardian is optional. - An Object may be guarded by multiple Guardians with each Guardian having an equal authority to make changes to the Object. 3. Guardian Attributes Currently, the InterNIC allows a registered Object to be updated if the request came from one of its Contacts. This model is weak due to potential mail spoofing. To allow for stronger authorization schemes, the proposed authorization model defines a new Object called Guardian. A Guardian is basically a Contact with Authentication Information. It inherits the attributes of a Contact Object and has the additional authentication attributes. The definition of a Guardian is derived from a Contact because a particular Contact (Administrative, Technical, or Billing) represents some form of holding of a registered Object and the holder of an Object is most likely to guard it also. [Page 1] The attributes of a Guardian are: Name Required Type Required Address Required Phone Required Fax Optional Email Required Notify Update Optional Notify Use Optional Auth Scheme Required * Auth Info Required * Public Optional * The Auth Scheme and Auth Info attributes are required only for a Guardian Object (a Contact with Authentication Information) and not for a Contact Object (a Contact without Authentication Information). Name, Type, Address, Phone, Fax, Email, Notify Update, and Notify Use are the attributes a Guardian inherits from a Contact Object. Auth Scheme, Auth Info, and Public are the additional authentication attributes of a Guardian. Name Name of a Guardian. Type Type of a Guardian. It can have values I (Individual) or R (Role Account). Address Postal address of a Guardian. Phone Phone number of a Guardian. Fax Fax number of a Guardian. Email Email address of a Guardian. [Page 2] Notify Update This attribute determines if and when a Guardian should be notified about the update of an Object the Guardian is responsible for. It can have values BEFORE-UPDATE, AFTER-UPDATE, and NOT-CARE. BEFORE-UPDATE The Guardian will be notified before updating the Object. AFTER-UPDATE The Guardian will be notified after updating the Object. AFTER-UPDATE is the default value. NOT-CARE The Guardian will not be notified about the Object update because it does not want to be notified. Currently, a Guardian's Notify Update attribute will be the same for all the Objects the Guardian is responsible for. In future, it will be defined on a per Object basis for each of the Objects a Guardian is guarding. Notify Use This attribute determines if and when a Guardian should be notified about the use of an Object the Guardian is responsible for. For example, a Guardian of a Host may be notified when someone else lists it as a DNS server for a Domain. It can have values BEFORE-USE, AFTER-USE, and NOT-CARE. BEFORE-USE The Guardian will be notified before using the Object. AFTER-USE The Guardian will be notified after using the Object. AFTER-USE is the default value. NOT-CARE The Guardian will not be notified about the Object use because it does not want to be notified. Currently, a Guardian's Notify Use attribute will be the same for all the Objects the Guardian is responsible for. In future, it will be defined on a per Object basis for each of the Objects a Guardian is guarding. Auth Scheme Authorization scheme used to authenticate a Guardian before updating the Object it is guarding. The proposed schemes in an increasing order of strength are MAIL-FROM, CRYPT-PW, and PGP [1]. MAIL-FROM MAIL-FROM will parse the FROM: field in the mail header of an update message and match it with the email address of the Guardian guarding the Object to be updated. MAIL-FROM is the default Auth Scheme. [Page 3] CRYPT-PW CRYPT-PW will encrypt the cleartext password supplied in an update message and match it with the encrypted password of the Guardian guarding the Object to be updated. Initially when a new Guardian is being registered or the authentication information is being added to an existing Contact, the encrypted password MUST be supplied. The Unix crypt(3) routine SHOULD be used to encrypt a cleartext password. PGP PGP stands for Pretty Good Privacy [2]. The sender will sign the update message with a Guardian's secret PGP key. The InterNIC will verify the received update message with the Guardian's public PGP key. How to register a Guardian's public PGP key with the InterNIC will be explained in another document. Auth Info Information for the selected authorization scheme. The authentication information stored in the database for a Guardian registered with the InterNIC is: MAIL-FROM Email address of a Guardian. CRYPT-PW Encrypted password of a Guardian. PGP Key ID of the public PGP key of a Guardian. Public Boolean indicating whether the authentication information for a Guardian will be public or not. Public means visible in WHOIS. It can have values Y (Yes) or N (No). The default value is Y. Note that the terms "Guardian" and "Contact with Authentication Information" are used interchangeably in the remaining document. 4. Registering the Guardian Attributes There will be two alternatives available to register or update the Guardian attributes: - Using the new Contact Template, or - Using the registration templates for Domains, Networks, Autonomous System Numbers (ASNs), and Hosts modified to include the authentication information for the Contacts. Note that registering a PGP-authenticated Guardian will be a two-step process because the Guardian will first have to register its public PGP key with the InterNIC and then report the key ID as Auth Info using one of the above methods. [Page 4] 4.1 Using the New Contact Template A new Contact Template is proposed to independently register or update a Contact with Authentication Information. Appendix A describes the new Contact Template and its use. 4.2 Using the Modified Registration Templates The registration templates for Domains, Networks, ASNs, and Hosts will be modified to include: a) The Authentication Information for the Contacts. b) The Authorization Section in the beginning of the template to authenticate the Guardian updating the Object. It SHOULD be filled only when the Object is being modified or deleted, and if the Object is being guarded. It has the following items: Auth Scheme Authorization scheme used to authenticate the Guardian updating the Object. It can have values MAIL-FROM, CRYPT-PW, or PGP. Auth Info Information for the selected authorization scheme. The different Auth Scheme and Auth Info combinations are: Auth Scheme Auth Info MAIL-FROM Ignored. The FROM: field in the mail header of an update message will be parsed to verify the Guardian. CRYPT-PW Cleartext password. PGP Ignored. The sender SHOULD sign the entire update message with the secret PGP key of the Guardian updating the Object and send it in cleartext to the InterNIC. 5. Linking Guardian Information to Existing Records There are two ways to link Guardian information to existing records: a) Once the authentication information is added to an existing Contact, all the database records the Contact is responsible for will be automatically guarded by that Contact and any subsequent update request from that Contact for one of those records will be first authenticated. This approach should be used carefully because here a Contact guards either all or none of its Objects. [Page 5] b) A new Link Template is proposed to do a wholesale linkage of Contacts with Authentication Information (Guardian Objects) to database records (Guarded Objects) in a single transaction. This approach is more flexible because the records that need to be guarded by a particular set of Guardians are listed explicitly in the Link Template. Appendix B describes the new Link Template and its use. 6. Notification The rules to update or use an Object will depend on when its Contacts are notified. There are two types of notification: Active Notification If the Notify Update attribute for a Contact of an Object is set to BEFORE-UPDATE, the Contact will be notified before updating the Object and the request will only be processed if an ACK (Acknowledgement) is received. If the Notify Use attribute for a Contact of an Object is set to BEFORE-USE, the Contact will be notified before using the Object and the request will only be processed if an ACK is received. Passive Notification If the Notify Update attribute for a Contact of an Object is set to AFTER-UPDATE, the Contact will be notified after the Object has been updated and the processed request will be revoked if a NAK (Negative Acknowledgement) is received. If the Notify Use attribute for a Contact of an Object is set to AFTER-USE, the Contact will be notified after the Object has been used and the processed request will be revoked if a NAK is received. An ACK or a NAK MUST be received within a certain time interval to be effective. Clearly, active notification is safer than passive notification. Appendix C describes the new Notify Template and its use. 7. Object Update Rules A request to update an Object could possibly come from a Contact with Authentication Information, a Contact without Authentication Information or a sender not listed as a Contact for the Object. [Page 6] The Object Update Rules for such requests are: 7.1 Request from a Contact with Authentication Information The request will be processed immediately with notification to all the Contacts with Notify Update attribute set to BEFORE-UPDATE or AFTER-UPDATE. 7.2 Request from a Contact without Authentication Information 7.2.1 Object has at least one Contact with Authentication Information All the Contacts with Authentication Information will be notified before processing the request. If the InterNIC receives an ACK first before the waiting time indicated on the Notify Template expires, the request will be processed. Otherwise, the request will NOT be processed. 7.2.2 Object has no Contacts with Authentication Information 7.2.2.1 Object has at least one of the other Contacts with Notify Update Attribute set to BEFORE-UPDATE All the other Contacts with Notify Update attribute set to BEFORE-UPDATE will be notified before processing the request. If the InterNIC receives an ACK first before the waiting time indicated on the Notify Template expires, the request will be processed. Otherwise, the request will NOT be processed. 7.2.2.2 Object has none of the other Contacts with Notify Update Attribute set to BEFORE-UPDATE The request will be processed immediately with notification to all the Contacts with Notify Update attribute set to AFTER-UPDATE. The Contacts with Notify Update attribute set to NOT-CARE will not be notified. 7.3 Request from a Sender not listed as a Contact All the Contacts will be notified before processing the request. If the InterNIC receives an ACK first before the waiting time indicated on the Notify Template expires, the request will be processed. Otherwise, the request will NOT be processed. If the request from a sender not listed as a Contact is rejected, the sender MUST present an evidence that the organization using the Object has approved it to update the Object. Another request from the same sender must be faxed to the InterNIC on the corporate letterhead and must contain the tracking number of the initial request. The sender could also present its contract with the organization using the Object. Appendix D gives a summary of the Object Update Rules. [Page 7] 8. Object Use Rules One of the more common registration problems is a Domain holder using without permission someone else's DNS servers or someone else's IP addresses to number its DNS servers. The Object Use Rules will help prevent such illegal use of Objects, particularly Hosts and Networks. A request to use an Object could possibly come from one of its Contacts or a sender not listed as a Contact for the Object. The Object Use Rules for such requests are: 8.1 Request from a Contact The request will be processed immediately with notification to all the Contacts with Notify Use attribute set to BEFORE-USE or AFTER-USE. 8.2 Request from a Sender not listed as a Contact 8.2.1 Object to be used has at least one Contact with Notify Use Attribute set to BEFORE-USE All the Contacts with Notify Use attribute set to BEFORE-USE will be notified before processing the request. If the InterNIC receives an ACK first before the waiting time indicated on the Notify Template expires, the request will be processed. Otherwise, the request will NOT be processed. 8.2.2 Object to be used has no Contact with Notify Use Attribute set to BEFORE-USE The request will be processed immediately with notification to all the Contacts with Notify Use attribute set to AFTER-USE. The Contacts with Notify Use attribute set to NOT-CARE will not be notified. Appendix E gives a summary of the Object Use Rules. 9. Other Guardian Issues 9.1 Number of Guardians per Object The number of Guardians for an Object will be equal to the number of its Contacts with Authentication Information. Each Guardian will have an equal authority to make changes to the Object. In future, multiple Contacts of the same type (for example, Technical) will be allowed for an Object. If an Object has no Contacts with Authentication Information, it will not be guarded at all. [Page 8] 9.2 Protecting Guardian Information By default, a Guardian will guard itself (that is, only the Guardian will have the authority to make changes to its information). However, a Guardian can be guarded by another Guardian. If a Guardian is guarding itself and needs to update its authentication information or scheme, the update message MUST contain the Guardian's old authentication information. Otherwise, the Guardian can not be authenticated before the update. For example, if a Guardian's Auth Scheme is MAIL-FROM, and it needs to either update its email address or change its Auth Scheme, the update message must come from its old email address. 9.3 Displaying Guardian Information The authentication information for a Guardian will be visible in WHOIS unless the Guardian chooses to keep it private. This information will be public by default because a Guarded Object should be protected by the inherent strength of the selected authorization scheme rather than by hiding the authorization information for its Guardian. The WHOIS display for a Guarded Object will be extended to indicate that the Object is being guarded. 10. Conclusion The increased market value of the Objects registered with the InterNIC, particularly Domains and Networks, has necessitated the need for more secure database transactions. This Guardian proposal will help solve most of the current, unauthorized Object update and use problems at the InterNIC. It balances operational expediency with stronger authorization by allowing the Contacts of an Object to select the appropriate level of security (MAIL-FROM, CRYPT-PW, or PGP) for the Object. 11. References [1] Karrenberg, D., Terpstra, M., "Authorisation and Notification of Changes in the RIPE Database", ripe-120, RIPE NCC, RIPE NCC. [2] Garfinkel, S., "PGP Pretty Good Privacy", O'Reilly & Associates, Inc. 12. Acknowledgements The authors thank the InterNIC staff for some very useful suggestions, especially Eric Eden, Tom Newell, Kim Hubbard, Duane Stone, and Carley Johnson. [Page 9] Appendix A The Proposed Contact Template [ URL ftp://rs.internic.net/templates/Contact-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Contact Version Number: 1.0 ************** Please see attached detailed instructions ************** Authorization 0a. Auth Scheme.............: 0b. Auth Info...............: 1. (N)ew (M)odify (D)elete.: Contact Information 2a. NIC Handle..............: 2b. Name....................: 2c. (I)ndividual (R)ole.....: 2d. Street Address..........: 2e. City....................: 2f. State...................: 2g. Postal Code.............: 2h. Country Code............: 2i. Phone Number............: 2j. Fax Number..............: 2k. E-Mailbox...............: Notify Information 3a. Notify Update...........: 3b. Notify Use..............: Authentication Information 4a. Auth Scheme.............: 4b. Auth Info...............: 4c. Public (Y/N)............: The Contact Template will be used to independently register or update a Contact (with or without Authentication Information). [Page 10] Items 0a-0b SHOULD be filled only when a Contact is being modified or deleted, and if the Contact is being guarded. These items contain the information to authenticate the Guardian updating the Contact. Item 0a is the authorization scheme for that Guardian. It can have values MAIL-FROM, CRYPT-PW, or PGP. Item 0b is the information for the selected authorization scheme. The different items 0a and 0b combinations are: Item 0a Item 0b MAIL-FROM Ignored. The FROM: field in the mail header of an update message will be parsed to verify the Guardian. CRYPT-PW Cleartext password. PGP Ignored. The sender SHOULD sign the entire update message with the secret PGP key of the Guardian updating the Contact and send it in cleartext to the InterNIC. Item 1 is the registration action type. It can have values N, M, or D. N registers a new Contact. M modifies the information for an existing Contact. D deletes an existing Contact if it is no longer linked to any Object. Items 2a-2k contain the basic information for a Contact. Item 2a is the NIC handle assigned to a Contact. Items 2b, 2c, 2d-2h, 2i, 2j, and 2k are respectively the Name, Type, Address, Phone, Fax, and Email attributes of a Contact. Items 3a-3b contain the notification information for a Contact. Items 3a and 3b are respectively the Notify Update and Notify Use attributes of a Contact. Items 4a-4c contain the authentication information for a Contact. These items are optional, and are required only if either the authentication information is being added to an existing Contact or a new Contact with Authentication Information is being registered. Items 4a, 4b, and 4c are respectively the Auth Scheme, Auth Info, and Public attributes of a Guardian. [Page 11] Appendix B The Proposed Link Template [ URL ftp://rs.internic.net/templates/link-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Link Version Number: 1.0 ************** Please see attached detailed instructions ************** 0. (N)ew (M)odify (D)elete.: Object 1a. Identifier..............: 1b. Type....................: 1c. Function................: Linked Object 2a. Identifier..............: 2b. Type....................: The Link Template will be used to do wholesale database changes in a single transaction. Some of the more commonly requested database changes are: a) Link or unlink Contacts (with or without Authentication Information) to or from existing Domains, Networks, ASNs, and Hosts. b) Link or unlink DNS servers to or from existing Domains and Networks. Item 0 is the registration action type. It can have values N, M, or D. N links the Objects (Contacts or DNS servers) in the Object Sections to the Objects (Domains, Networks, ASNs, and Hosts) in the Linked Object Sections. M modifies the linkage. D unlinks the Objects in the Object Sections from the Objects in the Linked Object Sections. Items 1a-1c contain information for an Object (Contact or DNS server) in the Object Section. Item 1a is the Identifier of the Object. Item 1b is the Type of the Object. Item 1c is optional and is required only if the Object is a Contact. It is the Function Type of a Contact. It can have values AC (Administrative Contact), TC (Technical Contact), or BC (Billing Contact). The Object Section SHOULD be copied for each Object (Contact or DNS server). Items 2a-2b contain information for an Object (Domain, Network, ASN, or Host) in the Linked Object Section. Item 2a is the Identifier of the Object. Item 2b is the Type of the Object. The Linked Object Section SHOULD be copied for each Object (Domain, Network, ASN, or Host). [Page 12] The different Identifiers and Types of the Objects are: Object Identifier Type Domain NIC Handle/Domain Name D Network NIC Handle/Network Name N ASN NIC Handle/AS Name A Host NIC Handle/Host Name H Contact NIC Handle I/R [Page 13] Appendix C The Proposed Notify Template [ URL ftp://rs.internic.net/templates/notify-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Notify Version Number: 1.0 ************** Please see attached detailed instructions ************** 0a. (A)ck (N)ak.....: 0b. Comments........: Object 1a. Identifier......: 1b. Type............: 1c. Tracking Number.: The Notify Template will be used to notify a Contact of an Object before or after updating or using the Object, and get its approval. The InterNIC will fill in the information for the requested Object update or use in the template (Items 1a-1c) and send it to a Contact of the Object for approval. The Contact will, in turn, fill in the ACK/NAK response in the template (Items 0a-0b) and send it back to the InterNIC. If no ACK or NAK is received within 4 days for an Object update request or 2 days for an Object use request, the InterNIC may assume an implicit ACK or NAK depending on the type of request. Items 0a-0b contain the response from a Contact. Item 0a is the ACK/NAK response. It can have values A (Ack) or N (Nak). Item 0b contains the comments from the Contact on the approval or disapproval of the request. Items 1a-1c contain information for the requested Object update or use. Item 1a is the Identifier of the Object. Item 1b is the Type of the Object. Item 1c is the Tracking Number of the request. The different Identifiers and Types of the Objects are: Object Identifier Type Domain NIC Handle/Domain Name D Network NIC Handle/Network Name N ASN NIC Handle/AS Name A Host NIC Handle/Host Name H Contact NIC Handle I/R [Page 14] Appendix D Object Update Rules IF Request from a Contact with Authentication Information Passive Notification to all the Contacts with Notify Update attribute set to BEFORE-UPDATE or AFTER-UPDATE after updating the Object ELSE IF Request from a Contact without Authentication Information IF Object has at least one Contact with Authentication Information Active Notification to these Contacts before updating the Object ELSE IF Object has at least one of the other Contacts with Notify Update attribute set to BEFORE-UPDATE Active Notification to these Contacts before updating the Object ELSE Passive Notification to all the Contacts with Notify Update attribute set to AFTER-UPDATE after updating the Object ENDIF ENDIF ELSE IF Request from a Sender not listed as a Contact Notification to all the Contacts before updating the Object IF the InterNIC receives an ACK Object updated ELSE IF the Sender faxes a copy of its contract with the Object Holder Object updated ELSE IF the Object Holder faxes the request on corporate letterhead Object updated ELSE Object not updated ENDIF ENDIF Active Notification: IF the InterNIC receives an ACK first within 4 days Object updated ELSE Object not updated ENDIF Passive Notification: IF the InterNIC receives a NAK first within 4 days Object update revoked ELSE OK ENDIF [Page 15] Appendix E Object Use Rules IF Request from a Contact Passive Notification to all the Contacts with Notify Use attribute set to BEFORE-USE or AFTER-USE after using the Object ELSE IF Request from a Sender not listed as a Contact IF Object has at least one Contact with Notify Use attribute set to BEFORE-USE Active Notification to these Contacts before using the Object ELSE Passive Notification to all the Contacts with Notify Update attribute set to AFTER-USE after using the Object ENDIF ENDIF Active Notification: IF the InterNIC receives an ACK first within 2 days Object used ELSE Object not used ENDIF Passive Notification: IF the InterNIC receives a NAK first within 2 days Object use revoked ELSE OK ENDIF [Page 16] Appendix F Examples F.1 How to Register a New Contact with Authentication Information [ URL ftp://rs.internic.net/templates/Contact-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Contact Version Number: 1.0 ************** Please see attached detailed instructions ************** Authorization 0a. Auth Scheme.............: 0b. Auth Info...............: 1. (N)ew (M)odify (D)elete.: N Contact Information 2a. NIC Handle..............: 2b. Name....................: Xary Y. Zmith 2c. (I)ndividual (R)ole.....: I 2d. Street Address..........: Fictitious Street 2e. City....................: Imaginary 2f. State...................: VA 2g. Postal Code.............: 22079 2h. Country Code............: US 2i. Phone Number............: 1-703-999-8484 2j. Fax Number..............: 1-703-999-8485 2k. E-Mailbox...............: xyz(a)internic.net Notify Information 3a. Notify Update...........: BEFORE-UPDATE 3b. Notify Use..............: AFTER-USE Authentication Information 4a. Auth Scheme.............: CRYPT-PW 4b. Auth Info...............: %.d!Hr3(a)rm.Gh 4c. Public (Y/N)............: Y Here, a new Contact Xary Y. Zmith is registered with CRYPT-PW as its Auth Scheme. The Contact will be notified before updating or after using an Object it is responsible for. The authentication information for the Contact will be visible in WHOIS. [Page 17] F.2 How to Link Guardian Information to Existing Records [ URL ftp://rs.internic.net/templates/link-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Link Version Number: 1.0 ************** Please see attached detailed instructions ************** 0. (N)ew (M)odify (D)elete.: N Object 1a. Identifier..............: XYZ10000 1b. Type....................: I 1c. Function................: TC Linked Object 2a. Identifier..............: HOST.EXAMPLE.COM 2b. Type....................: H In Example F.1, the new Contact is registered with NIC handle XYZ10000. Here, the Contact XYZ10000 is linked as Technical Contact to the Host HOST.EXAMPLE.COM. [Page 18] F.3 How to Update a Guarded Record [ URL ftp://rs.internic.net/templates/Contact-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Contact Version Number: 1.0 ************** Please see attached detailed instructions ************** Authorization 0a. Auth Scheme.............: CRYPT-PW 0b. Auth Info...............: Cleartext Password 1. (N)ew (M)odify (D)elete.: M Contact Information 2a. NIC Handle..............: XYZ10000 2b. Name....................: 2c. (I)ndividual (R)ole.....: 2d. Street Address..........: 2e. City....................: 2f. State...................: 2g. Postal Code.............: 2h. Country Code............: 2i. Phone Number............: 1-703-999-8486 2j. Fax Number..............: 2k. E-Mailbox...............: Notify Information 3a. Notify Update...........: 3b. Notify Use..............: Authentication Information 4a. Auth Scheme.............: 4b. Auth Info...............: 4c. Public (Y/N)............: Here, the authorization information in items 0a-0b is first verified and then the record for the Contact XYZ10000 is updated. [Page 19] F.4 WHOIS Display of Guardian Information Whois: XYZ10000 Zmith, Xary Y. (XYZ10000) xyz(a)INTERNIC.NET Fictitious Street Imaginary, VA 22079 (703) 999-8486 (703) 999-8485 Auth Scheme: CRYPT-PW %.d!Hr3(a)rm.Gh Record last updated on 18-Jan-96. Here, the WHOIS display of the Guardian XYZ10000 contains its authentication information because its Public attribute is set to Y. [Page 20]

3 3

Re: Internet shutdown Feb 29?
by sethf＠MIT.EDU 17 Dec '03

17 Dec '03

> This looks completely, totally, and insanely bogus, but I Yes. It would have made a good April Fool's joke. No reality to it whatsoever. > Anybody from MIT ever heard of "Kim Dereksen"? No such person listed as being employed at MIT. You can check how to use the MIT on-line directory by finger help(a)mit.edu There's also no "Interconnected Network Maintenance staff" at MIT, that I know about. > your users will be able to read it. Please pass this message on to other > sysops and Internet users as well. Thank you. This makes it a chain letter. NO! ================ Seth Finkelstein sethf(a)mit.edu

1 0

New WWW Page
by Computer Virus Help Desk 17 Dec '03

17 Dec '03

I'm pleased to announce the opening of a new Anti-Virus oriented Web Page. http://www.a1.com/cvhd This page allows the download of the latest versions of ALL the popular DOS, WINDOWS and WIN95 Anti-Virus Software as well as links to EVERY major Anti-Virus software developer or distributor in the world. On Line Virus Encylopedia, Anti-Virus Tutorials and other utilities are available as well. The page also contains VERY extensive links to Encryption, Privacy, Military, Intelligence, Government and Law Enforcement Web Pages. Look for the addition of a new "On Line" real-time Anonymous Pre-mailer with remailer chaining capabilities to be added in the very near future. Allen Taylor, Moderator, VIRUS_INFO SysOp, CVRC BBS, (317) 887-9568, Indianapolis, Indiana, USA http://www.a1.com/cvhd

1 0

Re: Puffer 2.0 Released
by Kent Briggs 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >>>>> Is PC1 a stream cipher implemented in a "clean room", by reference to an abstract specification of the algorithm implied by the Alleged-RC4 source code, that interoperates with RC4-40 ? <<<<< Yes, I wrote it in Pascal (Delphi) using only the English pseudo-code provided by Bruce Schneier in the 2nd edition of Applied Cryptography. I call my implementation PC1 to avoid any possible trademark hassles. The sample RC4 vector that the State Dept. sent me for my Commodity Jurisdiction request showed that my implementation is correct. And of course, there are no patents to worry about and I'm not under any non-disclosure agreements. RSADSI's government-sponsored monopoly on 40-bit exportable encryption is over. I generate a key by combining a 40-bit pseudo-random salt with 40-bits of secret key material. The secret key material is the lower 40-bits of a salted pass-phrase after running through a SHA-1 hash. All the specs and file formats are included with the documentation. Kent Puffer is available at http://execpc.com/~kbriggs - --- [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 iQBFAwUBMS5jYCoZzwIn1bdtAQF6dwF/XrD1BgPpNbvh1ZDq5bYg52q3PpYpBchj 3BbJgjS0FudNzkysl65vo4klEDEyHYb9 =9frt -----END PGP SIGNATURE-----

1 0

Alternative to e$
by jf_avon＠citenet.net 17 Dec '03

17 Dec '03

Why not use the name Electronic Cash Unit, abreviated ECU? :-) JFA **** OLD KEY: DO NOT USE ANYMORE UNLESS FOR VERIFYING SIGNATURES **** 1024 bits Key ID:57214AED 1995/10/04 Jean-Francois Avon <jf_avon(a)citenet.net> Key fingerprint = 84 96 76 AE EB 7C AB 15 88 47 87 B0 18 31 74 9F

1 0

Re: "Internet Security: Your Worst Nightmare"
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:56 AM 2/24/96, an44880(a)anon.penet.fi wrote: >Those were the words beaming on the cover of this week's _Information >Week_. The totally worthless article on internet security contained >this little gem: .... >Complete with a picture of Freeman standing in front of an American >flag. I haven't seen this article, but I wouldn't hold the cover photo of Freeman draped in the flag against him....I seem to recall a few Cypherpunks similarly draped in the flag in a magazine article! The photos used for stories are even more a matter of artistic choice than the editing of the text is. Magazines are competing for rack space with the likes of the several hundred other magazines, and covers are getting more and more garish and more freakish. (I've ranted about this on other occasions, so I won't here.) It's all about sensationalism. I take a jaundiced view of yellow journalism. --Tim May Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 - 1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Re: Conference report - resolving security workshop
by Bill Stewart 17 Dec '03

17 Dec '03

At 04:55 PM 2/22/96 -0800, Raph Levien <raph(a)c2.org> wrote: > The biggest problem with S/MIME is that the signed and encrypted >format reveals who made the signatures. Obviously, this has severe >consequences for anonymous mail. Believe it or not, a lot of people >care. For example, the car manufacturers do not wish to broadcast the >email addresses of their employees over the net. > One technical workaround is to do it the MOSS way - first, sign the >message, resulting in an intermediate S/MIME message, then encrypt >that into a second S/MIME message. I'd recommend that implementors >make provisions for such recursive formats; I think it's likely that >we'll see a lot of these on the Net. Recursive-capable formats are clearly the way to go; the difficult problem is deciding how many layers of recursion to do while decoding (e.g. all the way down, or one layer at a time asking the user for each round), which is largely a user-interface issue rather than a platform issue, though it also lets you build limited-purpose tools instead of an all-singing, all-dancing camel of a platform. Unfortunately, the formats being considered give you too much known plaintext to make triple-encryption a useful way around the 40-bit-key silliness. */MIME has MIME headers, PGP has the (expendable but present) ------BEGIN. A new MIME header like X: parameters where parameters are ignored would limit you to three bytes of known plaintext, which is at least a start. >The prevailing philosophy of the PGP people is that the PGP >application itself should not decode MIME formats - that should be the >job of a separate application. It seems to me that this is going >against the tradition, though. In the past, if you got a PGP message, >you just ran it through PGP. Now you won't be able to do that. The prevailing philosophy is also that we need to build an API toolkit so PGP components can be easily included into programs. This means that PGP will inherently no longer be able to decode all the PGP-based messages, which may have different layers of other material wrapped around them. PGP/MIME is probably one of the better excuses for doing so, as are improved keyring-handling applications. > Earlier, I mentioned that two and a half protocols survived the >day. The remaining one is MSP. It's actually not a bad protocol. Where can we find the new specs for MSP? > It was announced that there will be a free reference implementation >of MSP, available to US citizens. Will it be GAK-enabled? #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

2 1

consent
by amp 17 Dec '03

17 Dec '03

-- [ From: amp * EMC.Ver #2.3 ] -- -----BEGIN PGP SIGNED MESSAGE----- I'm not completely sure of the attribution here, as cypherpunks appears to be sending batches of messages to me with grunged From lines. VN> . How exactly is consent extractedH^H^H^H^H^H^ requested? "Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action." G. Washington. Consent is extracted by force of arms. VN> . When exactly is consent identified? I believe that the rulers of this country consider the lack of politicians hanging from town squares to indicate implied consent. VN> . How exactly is government applied to the consentees? VN> (caning, jailing, fines, etc.) And death. VN> . How exactly do consentors change methodologies when they VN> suddenly realize that they, too, can be subject to their own device? I'm not sure what you mean by this. If you are asking how the rulers react when they find themselves subject to their own evil devices, I would say that they generally attempt to change the rules. An example of this is that it is almost impossible to sue a federal officials because of the broad immunity to prosecution afforded by current federal law. VN> . Why should non-consenting citizens live with governing methods VN> which in fact conflict with the pursuit of those three human VN> virtues: life, liberty, happiness? Fear of the goverment monopoly of force? VN> Supposedly, government is devised for ruling the "unruly"; a matter VN> for definition and (dis)agreement which can provide endless hours VN> of amusement for authoritarians, especially in court. And those courts can be used to further browbeat the citizens through inconsistant rulings on vaguely written laws. I believe vague laws are one of america's great evils because of the uncertainty they bring. VN> I hear tell that many who are no longer amused are now learning the VN> many uses of encryption. Thus the list. And arming themselves with more lethal munitions as well. Interesting questions. I believe that there is a larger groundswell of resentment here and elsewhere than governments believe. Consider, when breaking federal law is this easy... #!/bin/perl -s-- -export-a-crypto-system-sig -RSA-3-lines-PERL $m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2%Sa 2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print pack('H*',$_)while read(STDIN,$m,($w=2*$d-1+length$n&~1)/2) Then something is _truely_ wrong with the laws. replies to amp(a)pobox.com please. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMS6lIodTfgZXlXydAQEgiAf/ZEqghXk424n4ybj/QXl6yZL21FWvjLJE 37IrvYslw6HLERd3t9k28LC4hUXvhm56c7of3YeUHKsrbTsZyydqrxLE4DaiRkCB mTTkChzvB+LH8V2q5PxMOW/YZQqzcyTnufVQKKHYy68RajLjUErLU5MSl9ICPgMh Kicx04xsueYGPcwD88m5v18uLJPf+LJTZhliqBehHI4Ta7BIi96VgF9lIXfx/GTS FeSru0EMYSn9S82WfnnsZX4sYeVHhvsxWPdRyeFOQHtlJ9hlH6/ehv+94Rzrh2yo s2AoUh/aUfVrZBboCiJCDF9E4gOX1PfsS/Dn9yKo/vW52/cbA1UPjQ== =SjfE -----END PGP SIGNATURE-----

1 0

Re: Cypherpunks vs. Coderpunks
by attila 17 Dec '03

17 Dec '03

** Reply to note from Perry E. Metzger <perry(a)piermont.com> 02/13/96 1:29pm -0500 [snip] = The thing that makes Cypherpunks worthwhile is that its a place where = you could, once, get news updates about GAK, information on the latest = research into cryptography, organize mass key crackings, discuss APIs, = talk a bit about the politics of cryptography, etc. = sounds like we're having the sme problems as "democracy" --it soon becomes irrelevant! example: I was out of town for 6 days: I returned to find 1056 messages in the sorted mailbox! yes: 1056 messages which it took close to an hour to delete almost 800 of them as irrelevant. some you can discard automatically depending on the author, some by content, etc. but I agree: it is clutter. = Now, we get anonymous posters putting up bits on corruption in the = DEA, sections of Tsutomu Shimomura's sex life, and other garbage. I = don't give a damn if you think "Perry's a whining asshole; no one = appointed him God", the stuff I'm mentioning is almost totally = irrelevant to the topic at hand. (I *still* see no relevance to the = late great Kevin Mitnick discussion, and frankly, I don't give a damn = if he's in jail.) I also really am not impressed enough with the = justification for why Jim Bell's "ideas" need to be discussed here. = well, it's probably worthwhile to announce the events, but not to comment ad infinitum on the gossip, the inferences, etc. --as you put it: the sex life of TS, particularly at the expense of one long term member. jim bell had the chance to publish his ideas --I read them --once. I may be an "idealistic anarchist," but they are anarchy after the fact of submission to a government. OK, they have been stated, but further discussion needs to move to another forum. auto-trash filter.... another major part of what I auto-trashed were two 50+ threads on some senseless topics which I have already forgotten. I suspect the poor snake was beaten to death by the BC Fat Lady.... = For some people without jobs (I won't name names) there is no problem = with this. However, some of us have trouble keeping up, and = unfortunately Cypherpunks has content that is key to our work and = interests. = THIS IS THE PROBLEM! Even if you do not have a fixed schedule, are not most of not data miners? It cost me over an hour to trim the message list from 1000+ to 200+. WE NEED SOME SELF-RESTRAINT. = Sadly, there isn't another place with the momentum where people are a = bit more polite and talk about the same information. = unfortunately, the more publicity we receive, the more extraneous nonsense will be copied or target to us as a group. = Yet. = well, I justify coderpunks since it breaks the ongoing technical discussions away from the mainstream cypherpunks. most of the information appears in cypherpunks itself, but if I must restrict my time, coderpunks comes first = Perry as you say, Perry: 'I don't give a damn if you think "Perry's a whining asshole; no one appointed him God"' I agree: 'I don't give a damn if they think "Attila's a whining asshole; no one appointed him God"' after all, as far as I know, I'm still "nobody" in the overall scheme, even with a Piled higher and Deeper! who _really_ cares what I think? -attila "Fools fear adversity, but the wise man listens only to his conscience; or in other words, "You've got exactly thirty seconds to get off my property before I start shooting, hippie." --Ching Chow cc: cypherpunks(a)toad.com

1 0

Re: TIS--Building in Big Brother for a Better Tommorrow
by jim bell 17 Dec '03

17 Dec '03

At 12:02 AM 2/23/96 -0800, Bill Frantz wrote: >At 11:16 PM 2/22/96 -0800, Timothy C. May wrote: >>And we should all remember, again, that basic observation: even if "key >>escrow" is needed to recover *stored* files, it sure ain't needed for >>*communications*!! > >If a key is being generated for two way communications, then it should be >generated via a protocol like Diffie-Hellman which leaves no recoverable >knowlege of the key outside the participants, and discarded when the >session is over of frequently, whichever occurs more often. This procedure >will reduce the incentive for rubber hose attacks to recover these keys. I noted long ago that one disadvantage with having a single, standardized encryption chip (like Clipper, even with the key-escrow un-enabled) is that the NSA has plenty of money in its budget to build a fake chip that can be installed during a black-bag job. True, if they could fake one chip they could fake 10, but it's harder to do and the demand for any single kind of chip might drop to one per year. Unfortunately, a sufficiently-complex FPLD would probably sub for anything if it were in the right package...

2 1

"E-Money" is trademarked
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

FYI, I learned tonight that Electronic Funds Clearinghouse, Inc., holds the trademark "E-Money" which is licensed to E-Money, Inc. a Delaware Corporation. See the Web page http://www.efunds.com I guess I will have to rename my E-Money mini-FAQ. Jim_Miller(a)suite.com

3 2

Re: REM_ote
by jf_avon＠citenet.net 17 Dec '03

17 Dec '03

Alex Strasheim <cp(a)proust.suba.com> wrote: >> Marianne Mueller, Java security engineer, also said the chances of such >> hacking occurring are "remote." > >This is the sort of bullshit that gets companies in trouble. Reminds me of this old saying: When you put your head in the sand, do realize what part of your anatomy is most visible to the rest of the world... :) JFA **** OLD KEY: DO NOT USE ANYMORE UNLESS FOR VERIFYING SIGNATURES **** 1024 bits Key ID:57214AED 1995/10/04 Jean-Francois Avon <jf_avon(a)citenet.net> Key fingerprint = 84 96 76 AE EB 7C AB 15 88 47 87 B0 18 31 74 9F

1 0

"Internet Security: Your Worst Nightmare"
by an44880＠anon.penet.fi 17 Dec '03

17 Dec '03

Those were the words beaming on the cover of this week's _Information Week_. The totally worthless article on internet security contained this little gem: Federal Law enforcement agencies, alarmed by the growing threat of Net-related security breaches and crimes, are stepping up their investigations of online intrusions. "We're aware that this is a serious problem for any industry using the Internet," says Jim Freeman, special agent in charge of the FBI's San Francisco office. "The ultimate solution will be through better technology such as encryption, but we will investigate any crimes in which a computer is used as an instrument of intrusion or fraud. Complete with a picture of Freeman standing in front of an American flag. --****ATTENTION****--****ATTENTION****--****ATTENTION****--***ATTENTION*** Your e-mail reply to this message WILL be *automatically* ANONYMIZED. Please, report inappropriate use to abuse(a)anon.penet.fi For information (incl. non-anon reply) write to help(a)anon.penet.fi If you have any problems, address them to admin(a)anon.penet.fi

1 0

Re: Internet Protest!
by Bill Stewart 17 Dec '03

17 Dec '03

At 08:13 AM 2/23/96 -0600, m5(a)dev.tivoli.com (Mike McNally) wrote: > Is anybody so seriously delusional >that they imagine poor Bill Clinton having to work his way through all >the mail with elm? It's really not that tough - g/Bill Of Rights/d They're already about half done ..... #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

1 0

Remember, RC4 is now PC1
by jamesd＠echeque.com 17 Dec '03

17 Dec '03

At 01:46 PM 2/24/96 GMT, aba(a)atlas.ex.ac.uk wrote: >I don't see any stigma attached with IPG admitting they have a PRNG >seeded with a key, and XORing the PRNG stream with the data - this is >exactly what RC4 does. >From now, instead of saying "RC4" let us say "PC1, (formerly known as RC4)" That will teach them to trademark names. We will forget their names. The net views intellectual property rights as damage and routes around them. Every time you say RC4 without saying "Trademark of some bunch of lawyer scum" you theoretically break the lawyer made law. So let us stop doing it. Serve them right. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

Re: [Off topic] Re: Easy Nuclear Detonator
by jim bell 17 Dec '03

17 Dec '03

At 08:05 PM 2/22/96 -0500, Black Unicorn wrote: >Actually, your design still is vulnerable to my objection, as my >objection was specifically to your intermediary chamber concept. > >Your intermediary chamber, if surrounding the blasting cap, is likely to >detonate to one side first, at a right angle to the axis of the chamber >to the explosive assembly. What I anticipated, to tell you the truth, was a long intermediary thin tube (again, 1 mm diameter for concreteness, just as an example) BETWEEN a chamber surrounding the cap, and the secondary chamber. (the secondary chamber would be carefully designed to spread the shock front evenly) I fully intended to avoid all of the possible consequences of weird explosive modes in common blasting caps. What really mystifies me is that you would think somebody who was intelligent enough to be capable of building a bomb could possibly be unaware of the strange behavior of common blasting caps? Do you think we're all stupid out here?!? Last time I talked to Dr. Edgerton in his lab (You _do_ know about Dr. Edgerton, don't you?!? EG+G?), in about 1978 or so, he showed me some interesting pictures he had taken of blasting caps exploding, and the weird patterns they made. Believe me, from that moment onwards I had no illusions about the predictability of the common blasting cap. BTW, the reason Edgerton paid a bit of attention to ME, as opposed to every other lowly undergrad at MIT, was the fact that I did something he had tried many times and failed to do: For my strobe laboratory project, I decided that I was going to photograph a popcorn kernel opening up at 10,000 frames per second. He called it "impossible": I called it a challenge. That is why I did the project. I showed him 11 frames taken a few weeks later. Dr. Edgerton was suitably impressed. >> >1> Interference from the milling shape and accuracy o f the openings to >> >the tubes containing the liquid explosive. >> >> Quantify, quantify. How much of a problem? > >Clever question given that I am without any information as to the exact >shape of your tubes, if they are bowled down towards the explosive >assembly, or what their exact width (excepting your vague 1mm figure) >might be. You make some guesses as to material, but these two are fairly >flimsy even by your own admission. I don't expect you to be able to "use ESP" and anticipate all the exact mistakes somebody could make. Rather, you should be willing to accept the principle, and explain how much inaccuracy is "too much," and try to give an example of an error that would produce an inaccuracy of this magnitude. So far you've done none of this. I have to conclude you were simply trolling, or intentionally spreading FUD (Fear, Uncertainty, and Doubt) without genuinely trying to get involved in an interesting hypthetical idea. BTW, while I do indeed consider this as purely hypothetical, on the offchance you're a FUDmeister from the government, you should be aware that _I'm_ fully aware that while the main form of radioactive emanation from Pu-239 is alphas which can be stopped by a piece of paper or a few inches of air, I am also fully aware that the decay produces a substantial quantity of gamma radiation (whose exact wavelengths and energies I can easily look up in my trusty CRC Handbook). So don't bother flying an airplane equipped with a gamma ray detector over my house; while I haven't the inclination to do the calculations, were it important to do so I'd calculate the minimum thickness of lead required to reduce the gamma intensity to below-background levels (using gamma-ray cross section tables and the appropriate equations), double or triple it, _and_ ensure that anything I did manage to acquire would be invisible to even a secretly-placed nearby detector at all times. And I'm also fully aware of ground-penetrating SAR (and the possibility of mobile variants) and JSTARS and terahertz radar, etc, so don't bother scanning. >All you need to realize to appreciate the problem is that if you do not >have a precisely milled end, with a precise depth into the compressing high >explosive outer face, you have differences in how and when the various >faces of the explosive assembly are going to initiate. If you make your >tubes narrow, it becomes very hard to mill the ends of your tubes, and if >you widen the tubes, it exagerates the distortive effect of >irregularities in the tube ends. But you should be able to estimate the magnitude of the errors. Given a certain detonation velocity, for example, and assuming some sort of localized slowdown/speedup to to this velocity, you should be able to estimate (even if only accurate to a factor of 2-3) the amount of error present at that particular junction. Again, the fact that you have never done even this rudimentary analysis is quite telling. You've revealed nothing that I wasn't aware of, and that was apparently quite intentional. >I'm not in the business of designing nuclear initiators. I expose poorly >thought out explosive engineering as a hobby. Your best solution is to >mill each tube exactly alike, right down the the degree of bend and slope >of arc as well as shape of either end. But you could have figured that >out without me spelling it our for you. More likely, I would have velocity-tested sample configurations down to 10 nsec accuracy, which would have revealed any unexpected error sources from temperature and/or pressure variation, as well as mechanical considerations such as bent tubing, etc... [stuff deleted] >But they don't. The timing problem is quite significant. Why do you >think high speed and superaccurate switches are so well guarded? There >isn't an easy grassroots substitute, if there were, the switches would be >fairly useless. Maybe that's the secret. I already anticipated this. If it's the government's motivation to keep "terrorists" from trying to build a bomb, then their first line of defense might be to make it appear more difficult than it really is. They also know that secrets which are actually turned into running, installed hardware eventually leak to the public, meaning that it might actually be better to keep THEIR bombs complicated, and to not use simplifying hardware. >> >Remember, kryonic switiches are necessary even when dealing with the >> >speeds of electric conductivity. The velocities of even hydrazine based >> >explosives are signigicantly lower. The margin for error is similarly lower. >> >> How low? Be specific. > >Again, I don't know what your dimentions are. Hydrazine explosives tend >to detonate around 8500-10000 m/s. The speed of transmission of electric >impulses through a given conductive medium is certainly much higher. Why do you keep mentioning "hydrazine explosives" when I didn't? Are you some sort of "one-trick pony"? > >> >Plutonium gun is still the easiest method for the home grown nuclear >> >device, even if it requires more fissile material. >> >> The "gun" design wasn't used with the plutonium, because IT WOULD NOT HAVE >> WORKED! "Fat Man," the bomb dropped on Nagasaki, used the implosion method. >> "Little Boy," the gun-method bomb, used U-235. Plutonium detonates far too >> rapidly to use the "gun" method. The >> scientists knew that in 1945. You seem to be at least 50 years behind the >> times. > >You are correct this time. My fault. Uranium should have been in there. >Typo on my part. Finally! He's able to admit a MISTAKE! >Hey, be my guest. If you had a critical mass worth of plutonium you're >playing around with the wrong list, and, I might add, wasting your time >with anything but the black market for the material. If I had some, or for that matter if I even wanted some, would I be advertising the fact on an "NSA-required-reading" list BEFORE I'd done all this work?

2 1

Not So REM_ote
by John Young 17 Dec '03

17 Dec '03

Responding to msg by karlton(a)netscape.com (Phil Karlton) on Fri, 23 Feb 8:19 PM >Marianne Mueller is a Sun employee, not a Netscape >employee. The original quote did not make that clear. Here's the full article. My snipping fed Alex's take, still, he got the right stink of Netscape's and Sun's deodorizing the loss of pucker, which might be sniffed of Phil Karlton's distancing from Marianne Mueller, eh, even though Jeff Truehaft is the true fart-waver. ---------- Wall Street Journal, February 23, 1996, p. B3. Netscape Will Issue Fix for Flaw Found In Browser System Mountain View, Calif. - Netscape Communications Corp. confirmed that Princeton University researchers found a potential security flaw in Netscape's popular Internet browser technology, but said the flaw was minor and that the company will issue a software fix for it next week. Edward Felten, an assistant professor of computer science at Princeton, posted a report on the Internet earlier this week describing the flaw in Netscape's Navigator 2.0, a product that enables the use of programs created with Java, Sun Microsystems Inc.'s hot programming language for the Internet. Java can be used to create "applets," small applications such as spreadsheets, that can be downloaded from the Internet's World Wide Web. Both Netscape's Navigator and Sun's Java have defenses designed to prevent Java applets from connecting with any computers except the ones they are summoned to by users and the ones they came from. But the Princeton team found a way to defeat those defenses, meaning that applets could theoretically be manuevered into other computers on a network. Applets aren't viruses, but in theory, they could be used to peruse confidential documents or other information. In trading on the Nasdaq Stock Market, Netscape fell $1.875 to $62, while Sun Microsystems jumped 7.8% to $51.875, up $3.75. Netscape product manager Jeff Treuhaft said exploiting the flaw would require extremely skilled hacking and many other unlikely advantages, such as intimate familiarity with the network being hacked. Marianne Mueller, a top Java security engineer, also said the chances of such hacking occurring are "remote," but said Sun also soon will issue a software fix that will plug the possible security leak. [End]

1 0

SGI Nabs Crayfish
by John Young 17 Dec '03

17 Dec '03

2-24-96. NYT: John Markoff reports that SGI will buy Cray Research. It notes Cray's last gasping, grasping at SGI's grab hand nabbing crawfish. An SGI/Cray super-gabfeast Monday.

1 0

fwd: Federal Internet Enforcement Policy
by rah＠shipwright.com 17 Dec '03

17 Dec '03

--- begin forwarded text X-Sender: oldbear(a)pop.tiac.net Mime-Version: 1.0 Date: Sat, 24 Feb 1996 17:56:31 -0500 To: rah(a)shipwright.com From: The Old Bear <oldbear(a)arctos.com> Subject: fwd: Federal Internet Enforcement Policy --- Forwarded message follows --- The "Federal Internet Indecency Crawler" has determined your Newsgroup or Web Site posting to be in violation of the "Exxxon Communications Indecency Act of 1996". In an effort to comply with the "Federal Paperwork Reduction Act" you are hereby directed to complete the proper arrest warrant paperwork and submit same to the Federal Court in your district, then obtain a valid copy of the approved arrest warrant and serve said warrant upon yourself. To properly initiate this procedure, you are required to submit Form A-16844787033 -83259 (rev.02) in triplicate, which may be obtained from the US Government printing office. After completion, send the original to the Federal Courthouse by certified mail with one copy mailed to your local FBI office. Please make certain to include all pertinent information, including the specific word, words or phrases that constituted the violation, together with your name, address, telephone number, social security number, and the policy number of any health insurance contracts in which you are currently enrolled. Also, please be reminded that as a citizen of the United States and a lawfully appointed officer of the Federal Court "for the purpose of serving the above arrest warrant only", you are exempted from any prohibitions regarding carrying of handguns, rifles, shotguns or any other type of guns or assault weapons while in the act of serving said warrant. However, please be advised that this provision does not apply to you as the recipient of Federal arrest warrants, and as such your constitutionally protected right to bear arms is hereby waived in this instance. It is important that you obtain your signature, thus showing the warrant was properly executed. Kindly note any undue resistance encountered in the appropriate space provided. Because of the large amount of court resources which must be diverted from other judicial efforts in order to accommodate the new "Exxxon Communications Indecency Act", the Democratic and Republican National Parties have made the following kind offer to assist us in enforcement of these new policies. As an alternative to the above process, you may at your option, send a contribution of not less than $100 to the Clinton Presidential Campaign Committee or to the Republican Presidential Nomination Committee. If you should choose one of these alternatives, it will not be necessary to obtain and complete the paperwork outlined above, nor will it be necessary to contact the Federal Court or your local FBI office. Simply copy the Newsgroup post in question or the URL and header information from your web page, and mail to either party committee, with your cashier's check or money order for $100 or more in US funds. In addition to relieving you of the responsibility of filing legal paperwork with the court and undergoing a traumatic arrest procedure, you will have the comfort of knowing that you have contributed in a meaningful way to the political process of your country. In addition, we are authorized (by Senator Exxxon himself) to inform you that after receiving your contribution of $100 or more, we will send you a special alpha- numerical code which, when placed in your header information, will prevent the "Federal Internet Indecency Crawler" from recording your indecency violations until after the November election. Remember, because of the "Exxxon Communications Indecency Act" constitutionally protected free speech is now in limited quantity. So, don't pass up this golden opportunity to avail yourself of unlimited free expression for the next eight months. This may be your last opportunity to do so! 127-A/4 rev. --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "Reality is not optional." --Thomas Sowell The e$ Home Page: http://thumper.vmeng.com/pub/rah/

1 0

S/MIME outside the US?
by volley＠lls.se 17 Dec '03

17 Dec '03

(I'm doing some research on different security standards, as I'm about to write an email/news program. Have been reading this list for quite a while, and it's time to delurk.) This is a quote from the S/MIME FAQ, as found on RSA's WWW server: "S/MIME recommends three symmetric encryption algorithms: DES, Triple-DES, and RC2. The adjustable keysize of the RC2 algorithm makes it especially useful for applications intended for export outside the U.S. RSA is the required public-key algorithm." If I got things right, DES is "exportable" as long as the keysize is kept under a certain size, which is too small to be really secure? If that's the case, I guess RC2 is the last resort? Is it good enough, or do I have to leave out S/MIME support, and just communicate with people outside the U.S or something? IMHO, these export restrictions on cryptography are completely insane. Is there *any* way to bypass them (except for breaking the law)? -- volley(a)lls.se

2 1

Re: Internet Privacy Guaranteed ad (POTP Jr.)
by aba＠atlas.ex.ac.uk 17 Dec '03

17 Dec '03

Perry Metzger <perry(a)piermont.com> writes: > Dan Bailey writes: > > My suggestion > > is to post the OTP-expansion algorithm to sci.crypt. > > Call it what it is -- a pseudo-random number generator, at best. As I think this is the crux of the problem - they are simply misnaming their proprietry algorithm. I don't see any stigma attached with IPG admitting they have a PRNG seeded with a key, and XORing the PRNG stream with the data - this is exactly what RC4 does. But of course RC4 (now) has the advantage of open review, and before that it had the advantage of Ron Rivests reputation associated with it. Simply change all the literature to replace "OTP" with "PRNG", or "seed" in appropriate places. So, submitting your PRNG for open peer review would be a good start. But I don't think the fact that IPG generates the keys for their clients is good. I don't see this as a viable key distribution mechanism. But you *really* must stop equating your system with a one time pad, it absolutely is NOT a OTP. > you likely know (but the IPG folks don't seem to care) you can't > "expand" a one time pad. One time means ONE TIME. Look at how the NSA > broke the Venona intercepts of of even two-time use of keying material. exactly. I do hope IPG will take the trouble to consider comments such as this, and Perrys comments above, if they are at all serious about their system every gaining any reputation. Adam

1 0