- cypherpunks-legacy - lists.cpunks.org

Re: Alternic.net (was domain zapping)
by jfricker＠vertexgroup.com 17 Dec '03

17 Dec '03

At 05:54 AM 6/26/96 -0400, you wrote: > >William Knowles writes: >> With all the talk about InterNIC zapping domains, there should be >> some talk about other registries, Alternic.net : http://www.alternic.net >> is offering an alpha test for registering new TLD's and the prices >> are considerably less expensive than the Internic. > <snip crap> > >They can offer to sell you anything they like, of course, and you can >pay them, but you don't get anything at all for the money. Domains >registered with them don't appear in the real DNS. > >.pm Perry, What constitutes "real DNS"? DNS server administrators need only add one line to their named.boot file to resolve .nic hosts. secondary nic 204.94.42.1 db.nic It's that easy! The concept of centralized name resolutions is flawed and only exists out of habit. J.

3 2

Degaussing a pile of 5.25" media
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

I have 3 bags full of 5.25" diskettes (in NYC). Can someone please let me use their degausser before I get rid of them? (Anyone who wants them after they're degaussed is welcome to them :-) --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

2 1

Re: Encrypted lists and ease of use
by E. Allen Smith 17 Dec '03

17 Dec '03

Where was the information on PGPdomo? That would seem appropriate for the input end, at least. -Allen From: IN%"scs(a)lokkur.dexter.mi.us" 26-SEP-1996 17:26:10.69 Subj: Encrypted lists and ease of use I'm considering sending someone off to work on a project, but wanted to sanity-check the idea and see if someone already has something similar. Recently I've been involved in a number of small (30 people or less) mailing lists which occasionally use PGP for encrypted mail. The hassle comes when one is encrypting a message to the list. With people coming and going, remembering who is on what list is impossible. We're always having to go back and re-send to someone who was left off of the encryption list. What I propose to do is have a second list, list-encrypted@host, for every list@host. Any mail sent to the list simply goes out in plaintext. List-encrypted is encrypted for everyone on list, then sent to the list with appropriate additional headers. To secure the mail as it travels from the sender to list-encrypted, we want to establish a public key for list-encrypted. All mail to the list *must* travel with the public key or be rejected. When mail arrives at list-encrypted, a deamon will process it. The daemon knows the secret key for -encrypted, and has a list of who is on what list. The daemon strips the -encrypted address, encrypts the message for all on the list. If there are other people on the To: or Cc: fields, the deamon will encrypt for them as well. If any of this fails, the message is sent to as many as possible and notification failure goes back to the original sender indicating who the failures were. The daemon then forwards it to the list real list. It preserves the From: field, but changs `To: list-encrypted' into simply `To: list.' Comments? Generally useful? Beta volunteers? :-) -- "Yea, the heavens shall open and the NP-complete solution given forth. ATT executives shall give birth to two-headed operating systems, and copyrights shall be expunged. The voice of the GNU shall be heard, but the faithless will be without transceivers." -- me

4 4

generating hash.curve in eliptic.src
by Mike Rosing 17 Dec '03

17 Dec '03

Among other comments, it was pointed out that I had not included "hash.curve". To generate this file I did the following main() { POINT point; CURVE curve; init_opt_math(); init_rand(); rand_curv_pnt(point,curve); save_curve("hash.curve",curve,point); close_rand(); } This was done during development and I forgot about it. A simpler patch is to fix an error finding the file with a call to rand_curv_pnt to generate it. Kind of interesting that way for hashing your secret key. If everyone uses a different curve to generate their secret key, access to the machine is necessary to even begin to think about cracking any pass phrase. Don't know if actually adds any security, but it is an interesting concept. As for why I didn't put up a tar file, no particular reason. It's source for a particular machine (MachTen on a Mac) and I figured every C compiler is different so some hacking will be required by anyone interested. Once more bugs are fixed such as the one above, I'll put it up in a more easily compilable form. And thanks for the comments so far. I'll do my best to keep up with them. Patience, persistence, truth, Dr. mike

1 0

Re: Can GAK be made "not interoperable" with PGP?
by Hal 17 Dec '03

17 Dec '03

From: Duncan Frissell <frissell(a)panix.com> > At 10:26 AM 9/13/95 -0700, Timothy C. May wrote: > > >But is this even possible, to make a GAK system "not interoperable" with, > >say, PGP? > > > >Unless the GAK system has some sort of entropy analyzer, and can recognize > >high-entropy sources which it presumes to be encrypted data (*), one can of > >course PGP-encrypt a text file and then GAK the resulting file. > > I took it to mean that they were saying that an approved program on one end > of a communication exchange could not exchange encrypted messages or > established an encrypted session of some kind with an un approved program on > the other end. Not trying to outlaw superencryption (PGP on both ends using > a GAKed channel) but GAK on one end working with an unapproved system on the > other end. A ringer GAK-work-alike that would defeat the intent of GAK. Yes, I think this was the idea of the original "software key escrow" proposal, from TIS as I recall. The sender would encode the session key with a government public key but there was some trick by which the receiver would verify that the session key was in fact encoded correctly and refuse to operate if it was wrong. So any attempt to corrupt or remove the LEAF would be detected if you were talking to a compliant receiver. That is part of why Matt Blaze's Clipper attacks were so significant, because they went to the heart of this requirement. It was always clear that you could superencrypt with Clipper, but Matt found a way in which you could send a LEAF which would be accepted by a regular Clipper phone but which had bogus data for law enforcement. So this defeated the requirement of not interoperating with rogues. Hal

1 0

Remailer message bundling
by tk＠ai.mit.edu 17 Dec '03

17 Dec '03

If each remailer encrypts outgoing traffic with its (immediate) recipient forwarder's public key, then several outgoing messages headed in the same direction can be bundled together, obfuscating further the message identities. No need to have 1 message in ==> 1 message out, with or without delay, reordering, or whatever. But maybe everyone already thought of this.

1 0

Dallas Morning News article
by Phil Karn 17 Dec '03

17 Dec '03

Dallas Morning News, July 23, 1994, Page 5F Cryptography tests rights of electronic word Tom Steinert-Threlkeld Cybertalk The electronic word appears to have fewer rights than the printed word. At least that could be the conclusion drawn from an unusual case emerging from the Bureau of Politico-Military Affairs in the U.S. State Department's Office of Defense Trade Controls. There, a book about encryption techniques has won an export license, but a computer disk containing the same information has not. The book in question is titled "Applied Cryptography", an attempt by data security consultant Bruce Schneier to translate 20 years of academic research in scrambling computer traffic "into terms understandable by mere mortals." In so doing, Mr. Schneier hopes to do "more to further the spread of cryptography around the globe than any single (encryption) product could." So far, his publishers, John Wiley & Sons, believe the 600-page tome has been doing almost that. Since its release in November, almost 15,000 copies of the book have been sold. Of that, between 1,500 and 2,000 have been to programmers and other interested parties abroad. Those foreign sales are possible because the book did not have to get an export license. Such controls are used by the State Department to guard against the spread of cryptographic methods that could be too difficult to break, posing a threat to national security. The book contains what Mr. Schneier estimates is about 100 pages of algorithms, hash functions and other lines of computer code that can be used to encrypt messages. But the Office of Defense Trade Controls in March rendered the opinion that the book "is not subject to the licensing jurisdiction of the Department of State since the item is in the public domain." No so with two disks containing the same "source" code. In a May 11 letter, office director William B. Robinson designated the disks as an article "under category XIII(b)(1) of the United States Munitions List." As such, the author would require an export license for the disks. The code itself was not a finished product. It would have to be "compiled" into an executable program before it actually could be used to disguise any data on a computer network. The code was also exactly the same as appeared in the book, or at least as nearly as possible, given the transfer to a magnetic disk. But that appeared to be enough of a difference for the State Department. Mr. Robinson stated, "The text files on the subject disk are not an exact representation of what is found in 'Applied Cryptography'. Each source code listing...has the capability of being easily compiled into an executable subroutine." A State Department official Friday translated the distinction this way: "The difference with the code in the book is you have to type it all in and correct all the errors" before it is usable by a computer programmer. The "value added" by putting the code on the disk is that it is already typed in. "That was the determination we made", the official said. Practically speaking, the distinction escapes the author, Mr. Schneier. Once one overseas programmer types in the code and corrects the errors, hundreds of copies can be easily made and shipped to any country. For the programmer who is too lazy to type, the book's pages even can be scanned in. "What do we think? Foreigners can't type? Or is the worldwide scanning industry influencing this decision?" he asks. Others see larger, constitutional questions. "They're trying to say electronic words have less protection than written words," said David Banisar, policy analyst with the Electronic Privacy Information Center in Washington, D.C. "That's not a proposition that I think any court will support." As more and more words -- from book, magazine and newspaper publishers, for instance -- become electronic, the issue could become critical. "When all words are electronic, they won't be able to be protected under the First Amendment" if this difference between words on a paper medium and words on a digital medium gains footing, he said. Phil Karn, an engineer and ally of Mr. Schneier, however, is appealing the stand on the disks. The State Department's view also is not the final law of the land. "It seems like kind of a foolish distinction and one which in any case is ultimately doomed to failure," said Internet Society executive director Anthony Rutkowski. The different rulings on the book and the disk are "utterly stupid, but that's the way bureaucracies work." Mr. Robinson and the trade control office's deputy director, Rose Brancaniello, declined to comment. Another officer, Tom Denner, said comment was prohibited by confidentiality provisions contained in section 38(e) of the Arms Export Control Act. ------ CyberTalk appears every other Saturday, discussing people, places and problems populating the world of computer communications known as cyberspace. Tom Steinert-Threlkeld can be reached at the Internet address, tomhyphen(a)onramp.net; at America Online, tomhyphen; or at Prodigy, trfj19a.

1 0

Cyphers Out There?
by an114＠vox.hacktic.nl 17 Dec '03

17 Dec '03

:: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.6 hEwCTL2DNtw2i0EBAf4joQKrL2wlyfeRCIHGKaIlSnDhfNdSJ3+MPylu1fix0TIr E//Iw3Z9H2rdbVkJ4gyMQrE7kZzpquyys5ia4031pgAAAjb/CvnS8B2ZX0gpx+dh 8+7dS7i0vbwOePbd/6RIMaemyQhc98npIqQqWodr7z4a+hPp9PyBw5tVPa9N29CF 5b/X50eaeK9vuUVAp1qAB247LsqmQ+nWlFtVXlcy2M3AqZFG0KwvGCg1FLcrSIKj 4gEbp+qD42cetTBe3HFY45Xie1tcEVrTblpibIKZ41NgKcGdRJ8s+ivv/tKu+bDh pftPmiJjqIM1hpOtDqAQvlocP/j4RmxrZFCkdtmczAOKPhG0F6B4tmW/GKY7Kfdk 7vfhrMF6+8sAQSXLSp8xSCpjSGT/RsZKRNOLFK8E6QGCk5MToV5FBtCUd7sVSY7H t+GEsVT4KgLq1jdGGwrsegB99K4ttQ0rYxPn5xQUgUNt6ekOK3v2mfUHQbuY2rdf OTN+RHGRiFI8oplVYVUQGo0q/Ghl7P56TSxVZTHTrxRbFDc/xcnflQHsrVHS/9KC xxP3xuZTrCJaXrZEi8xZ2h/gyQB7xT7VdNvFm4KpFapkt9UP510+4YmyN06SSMq7 zSX4lmcihnf1FGt0A3Q5KOjUjzXz4V4xD9BYtC2Tg+Bp+QtVfJTVhSJ8u8tGs0cB LMSHkj5H2RocbhMhpnmm5Lqnwp+UgUWbH2cVNnx51DbAlOt1NrwetjXs75YZbtfw JBgLj2AOfAi5txky+4xZx/S2uSyrwe0OSFTsBXoSonSSRMjkBPjJ/H0d1XU715oN RSxlTlFIlS8GnUlaiq+eYhHp3sbZILS57A== =YwyP -----END PGP MESSAGE----- -------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)vox.hacktic.nl Please report any problems, inappropriate use etc. to admin(a)vox.hacktic.nl Direct replies to the sender of this message are -not- anonymised <YuK>

1 0

RE: (none)
by Jeff Gostin 17 Dec '03

17 Dec '03

Blanc Weber <blancw(a)microsoft.com> writes: > I really meant to ask 'where cypherpunks'. It had been a whole day & > more without the hordes messages and my day seemed empty, without code > or purpose, lacking controversy & jibber jabber. Actually, my response was more of a joke... More than a few people commented on the fact that WHO CYPHERPUNKS is the 'domo command to get a list of subscribers. Your name looked familiar from the list, so I decided to gamble a joke. Guess the joke's on me, eh? :-) --Jeff -- ====== ====== +----------------jgostin(a)eternal.pha.pa.us----------------+ == == | The new, improved, environmentally safe, bigger, better,| == == -= | faster, hypo-allergenic, AND politically correct .sig. | ==== ====== | Now with a new fresh lemon scent! | PGP Key Available +---------------------------------------------------------+

1 0

Re: RemailerNet
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <9408062108.AA18761(a)snark.imsi.com> perry(a)imsi.com writes: > > Jim Dixon says: > > You can send from a very large network and forge your TCP/IP or > > (more difficult) Ethernet source address. But I can sit on the same > > network, build a table relating TCP/IP to ethernet (or whatever) > > addresses, and filter out messages that should not be there. There > > are commerical packages that do this sort of thing. > > Huh? > > If you are sitting on a network in England, which you appear to be, I > defy you to record anything at all about the ethernet addresses of the > machines that originated this message. [etc] Forgive my casual use of the English language. "A may send from a very large network and forge his or her TCP/IP or Ethernet source address. But if B is on the same network, he or she can build a table ..." The size of the source network is related to the difficulty of determining which machine is forging addresses. If you are ... sorry, one is on a large network, forgery without detection is much easier. Assuming idiocy on the part of correspondents may make for easy and fast responses, but it injects an undue amount of noise. -- Jim Dixon

1 0