December 2003 - cypherpunks-legacy

digital signatures/copyright
by Brian D Williams 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- A question for Mike Godwin and other attorneys on the list: Could one make a case that the use of Digital signatures in messages imply's copyright retention by the author? Does digital signature=copyright or is it at least equivalent? Brian Williams Extropian Cypherpatriot "Cryptocosmology: Sufficently advanced comunication is indistinguishable from noise." --Steve Witham -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLU/2HdCcBnAsu2t1AQF15gP+IqS3o0gNeHng9BSqlk95KzmPwp3oo70p j2FVYHNOeUKgDSAAwvWr+p3/DOwTafSkJf4A5gW33NOKr0E9JZ4In349RAoueTku J94VMajT4i7yhOC8X41RPkVLlCltPDRo04SS8h5UFnEk/zFxiTkvXY9mpBcK3yUw vYY9pbmupSc= =KbXS -----END PGP SIGNATURE-----

2 1

New US keyserver now fully operational - pgp-public-keys@io.com
by pgpkeys＠wasabi.io.com 17 Dec '03

17 Dec '03

The US-based keyserver 'pgp-public-keys(a)io.com' is now open to the public. Come one, come all! Here is the current file as returned by 'Subject: help'. This site is a PGP key server SLAVE site. It behaves very similarly to the European PGP master sites, but there are a few small differences which will be noted below. The most noticable difference is that it answers your requests immediately instead of waiting for a daily batch job to run :-) The particular installation at io.com does *not* log the details of requests for keys, however the fact that you have sent mail to the key server at all is logged in the daily sendmail logs. These logs will be erased automatically after one week. PGP Public Keyservers --------------------- There are PGP public key servers which allow one to exchange public keys running through the Internet and UUCP mail systems. This service is NOT supported in any way whatsoever by the schools or organizations on which these servers run. It is here only to help transfer keys between PGP users. It does NOT attempt to guarantee that a key is a valid key; use the signators on a key for that kind of security. This service can be discontinued at any time without prior notification. Each keyserver processes requests in the form of mail messages. The commands for the server are entered on the Subject: line. To: pgp-public-keys(a)io.com From: johndoe(a)some.site.edu Subject: help Sending your key to ONE server is enough. After it processes your key, it will forward your add request to other servers automagically. For example, to add your key to the keyserver, or to update your key if it is already there, send a message similar to the following to any server: To: pgp-public-keys(a)io.com From: johndoe(a)some.site.edu Subject: add -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 <blah blah blah> -----END PGP PUBLIC KEY BLOCK----- COMPROMISED KEYS: Create a Key Revocation Certificate (read the PGP docs on how to do that) and mail your key to the server once again, with the ADD command. Valid commands are: Command Message body contains ---------------------- ------------------------------------------------- ADD Your PGP public key (key to add is body of msg) *** Note: your update is forwarded to a master server and may take a few days to reappear INDEX List all PGP keys the server knows about (-kv) VERBOSE INDEX List all PGP keys, verbose format (-kvv) GET Get the whole public key ring GET 0xA1B2C3 Get a single key by Key ID *** Note: the master servers allow you to omit the 0x in front of the Key ID. The slave servers do not. GET userid Get a single key by User ID MGET substr List all keys which match "substr" *** Note: this is different from the master servers which return the keys themselves, not just a listing of their Key IDs. Also the master servers accept a wild-card expression; at the moment we do not. LAST days Get the keys updated in the last `days' days *** Note: not yet implemented ------------------------------------------------------------------------ Examples for the MGET command: MGET michael Lists all keys which have "michael" in them MGET @iastate.edu Lists all keys which contain "@iastate.edu" Check the Usenet newsgroup alt.security.pgp for updates to this system and for new sites. Based on a document originally by Michael <explorer(a)iastate.edu>

2 1

No Subject
by bob＠USCWS4.gat.com 17 Dec '03

17 Dec '03

unsubscribe bob(a)USCWS4.gat.com

1 0

Re: New Remailer Up.
by nobody＠qwerty.org 17 Dec '03

17 Dec '03

Jon wrote, " Aside from traffic obscuring random messages, a forced, random delay and a medium sized load of traffic seem to be the best ways to defeat the use ..." How LONG should the such a random delay BE, at max? I am not willing to add more than 10-15 minutes, max. Is this worth it then? Hours is just too primitive when it comes to electronic communications. Even minutes! -Xenon

1 0

test
by Joseph Reagle Jr. 17 Dec '03

17 Dec '03

Regards, Joseph M. Reagle Jr. | reagle(a)umbc.edu | It's celluar peptide cake with mint frosting! jreagl1(a)umbc8.umbc.edu | -- Worf

1 0

Re: digital signatures/copyright
by smb＠research.att.com 17 Dec '03

17 Dec '03

It's worth noting that U.S. copyright law makes explicit provision for copyrighting anonymous works.

1 0

unsubscribe
by DBS5112＠ibm.MtSAC.edu 17 Dec '03

17 Dec '03

(mailing to cypherpunks-request(a)toad.com doesn't seem to work)... please unsubscribe me from the list... thanxs

1 0

anonymous mail
by nobody＠pmantis.berkeley.edu 17 Dec '03

17 Dec '03

There's a jerk that's been mail-bombing me, and I can't do anything because he's root at his site. Would it be ethical to use a remailer to bomb him back? Or maybe I shoudl simply fakemail a message to alt.fan.rush-limbaugh(a)anon.penet.fi with his name and have the contents say something like 'Limbaugh sucks', or post to alt.sex.wanted with the subject 'SWF virgin seeks man for first time'. Any ideas on how to get someone back, or at least make life annoying?

2 1

RE: fwd: Canadian gov't eavesdropping
by fnerd＠smds.com 17 Dec '03

17 Dec '03

Mike Markley says- > I'd be curious to see how they are going to do voice recognition on > random conversations. Unless I am very sadly out of date you need to > teach the pattern matcher individual voices. I remember a story from a conference in the sixties where someone wanted to prove the point that it's much easier to make a recognizer for all voices if you're only looking for a certain word. So he built a "watermelon" box. He sits this up on the podium with him and gives his talk, which naturally at some point gets to... "...a single word, for instance 'watermelon.'" *beep!* Then later there's a Q&A period, of course... A: Please step up to the microphone... Q: You mean all this thing does is recognize the word "watermelon," *beep!* and that it can recognize the word "watermelon" *beep!* no matter who says it? A: That's right, it's an any-speaker, "watermelon" *beep!* recognizer. Q2: Why the word... "watermelon" *beep!* exactly? ... -fnerd *BZZZT! AAAAARRRRROOOOGAH!* quote me - - cryptocosmology- sufficiently advanced communication is indistinguishable from noise - god is in the least significant bits -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE-----

1 0

Notes on key escrow meeting with NSA
by Matt Blaze 17 Dec '03

17 Dec '03

A group from NSA and FBI met the other day with a group of us at Bell Labs to discuss the key escrow proposal. They were surprisingly forthcoming and open to discussion and debate, and were willing to at least listen to hard questions. They didn't object when asked if we could summarize what we learned to the net. Incidentally, the people at the meeting seemed to base a large part of their understanding of public opinion on Usenet postings. Postings to sci.crypt and talk.politics.crypto seem to actually have an influence on our government. A number of things came out at the meeting that we didn't previously know or that clarified previously released information. What follows is a rough summary; needless to say, nothing here should be taken as gospel, or representing the official positions of anybody. Also, nothing here should be taken as an endorsement of key escrow, clipper, or anything else by the authors; we're just reporting. These notes are based on the collective memory of Steve Bellovin, Matt Blaze, Jack Lacy, and Mike Reiter; there may be errors or misunderstandings. Please forgive the rough style. Note also the use of "~ ~" for 'approximate quotes' (a marvelous Whit Diffie-ism). NSA's stated goals and motives for all this: * DES is at the end of its useful life * Sensitive, unclassified government data needs protection * This should be made available to US Citizens * US business data abroad especially needs protection * The new technology should not preclude law enforcement access They indicated that the thinking was not that criminals would use key escrowed crypto, but that they should not field a system that criminals could easily use against them. The existence of key escrow would deter them from using crypto in the first place. The FBI representative said that they expect to catch "~only the stupid criminals~" through the escrow system. Another stated reason for key escrow is that they do not think that even government-spec crypto devices can be kept physically secure. They do expect enough to be diverted to the black market that they feel they need a response. NSA's emphasis was on the foreign black market... There seems to be a desire to manipulate the market, by having the fixed cost of key escrow cryptography amortized over the government market. Any private sector devices would have to sell a much larger number of units to compete on price. (This was somewhere between an implication and an explicit statement on their part.) When asked about cryptography in software, "~...if you want US government cryptography, you must do it with hardware~". Clipper chips should be available (to product vendors) in June. You can't just buy loose chips - they have to be installed in approved products. Your application interface has to be approved by NIST for you to get your hands on the chips. An interesting point came up about the reverse-engineering resistance of the chips: they are designed to resist reverse engineering the data in the chip without destroying the chip. It is not clear (from the information presented at the meeting) whether the chips are equally resistant to destructive reverse-engineering to learn the skipjack algorithm. They said the algorithm was patented, but they may have been joking. ("~And if that doesn't scare you enough, we'll turn the patent over to PKP.~") The resistance to reverse engineering is not considered absolute by NSA. They do feel that "~it would require the resources of a national laboratory, and anyone with that much money can design their own cryptosystem that's just as strong.~" They repeated several times that there are "~no plans to regulate the use of alternate encryption within the US by US citizens.~" They also indicated they "~weren't naive~" and didn't think that they could if they wanted to. There were 919 authorized wiretaps, and 10,000 pen register monitors, in 1992. They do not have any figures yet on how often cryptography was used to frustrate wiretaps. They do not yet have a production version of the "decoder" box used by law enforcement. Initially, the family key will be split (by the same XOR method) and handled by two different people in the athorized agencies. There is presently only one family key. The specifications of the escrow exploitation mechanism are not yet final, either; they are considering the possibility of having the central site strip off the outer layers of encryption, and only sending the session key back to the decoder box. The escrow authorities will NOT require presentation of a court order prior to releasing the keys. Instead, the agency will fill out a form certifying that they have a legal authorization. This is also backed up with a separate confirmation from the prosecutor's office. The escrow agencies will supply any key requested and will not themselves verify that the keys requested are associated with the particular court order. The NSA did not answer a question as to whether the national security community would obtain keys from the same escrow mechanism for their (legally authorized) intelligence gathering or whether some other mechanism would exist for them to get the keys. The masks for the Clipper/Capstone chip are unclassified (but are protected by trade secret) and the chips can be produced in an unclassified foundry. Part of the programming in the secure vault includes "~installing part of the Skipjack algorithm.~" Later discussion indicated that the part of the algorithm installed in the secure vault are the "S-tables", suggesting that perhaps unprogrammed Clipper chips can be programmed to implement other 80-bit key, 32 round ciphers. The Capstone chip includes an ARM-6 RISC processor that can be used for other things when no cryptographic functions are performed. In particular, it can be used by vendors as their own on-board processor. The I/O to the processor is shut off when a crypto operation is in progress. They passed around a Tessera PCMCIA (type 1) card. These cards contain a Capstone chip and can be used by general purpose PC applications. The cards themselves might not be export controlled. (Unfortunately, they took the sample card back with them...) The card will digitally sign a challenge from the host, so you can't substitute a bogus card. The cards have non-volatile onboard storage for users' secret keys and for the public keys of a certifying authority. They are building a library/API for Tessera, called Catapult, that will provide an interface suitable for many different applications. They have prototype email and ftp applications that already uses it. They intend to eventually give away source code for this library. They responded favorably to the suggestion that they put it up for anonymous ftp. Applications (which can use the library and which the NSA approves for government use) will be responsible for managing the LEAF field. Note that they intend to apply key escrowed Skipjack to other applications, including mail and file encryption. The LEAF would be included in such places as the mail header or the file attributes. This implies that it is possible to omit sending the LEAF -- but the decrypt chip won't work right if it doesn't get one. When asked, they indicated that it might be possible wire up a pair of Clipper/Capstone chips to not transmit the LEAF field, but that the way to do this is "~not obvious from the interface we give you~" and "~you'd have to be careful not to make mistakes~". They gave a lot of attention to obvious ways to get around the LEAF. The unit key is generated via Skipjack itself, from random seeds provided by the two escrow agencies (approximately monthly, though that isn't certain yet). They say they prefer a software generation process because its correct behavior is auditable. Capstone (but not Clipper) could be configured to allow independent loading of the two key halves, in separate facilities. "~It's your money [meaning American taxpayers].~" The LEAF field contains 80 bits for the traffic key, encrypted via the unit key in "~a unique mode <grin>~", 32 bits for the unit id, and a 16 bit checksum of some sort. (We didn't waste our breath asking what the checksum algorithm was.) This is all encrypted under the family key using "~another mode <grin>~". They expressed a great deal of willingness to make any sort of reasonable changes that vendors needed for their products. They are trying *very* hard to get Skipjack and key escrow into lots of products.

2 1