December 2003 - cypherpunks-legacy

Re: Public Schools
by Adamsc＠io-online.com 17 Dec '03

17 Dec '03

On Sat, 28 Sep 1996 23:23:32 -0400 (EDT), themom wrote: >I have to agree with the final Quote....I am Good in math, chemistry and >computer science I am good in any Logical cource but I have trouble in >places liek " Creative Writing" I take all AP cources and make A's and >B every now and again in english...I have a 3.7 gpa but a LOW sat in the >grammar and english sections, 1100 in all I don't think colleges should >look at the subjects you dont plan to major in...I plan to major in >computer science when I go to college, so I dont think they should look >so much at say english, or biology. I get so frustrated in some of those >classes....BTW I am a Junior in highschool I recently graduated HS and am at the local community college preparing to transfer to a 4-year. Meaningless indicators as follows: 3.9GPA, 1490 SAT (800 Verbal 690 Math - I haven't had a math course since Trig/Precalc in my sophomore year - I was 2 years ahead but moved to 2 districts which didn't even have calculus) - which is up 120 points from my freshman year. Anyway, as far as what colleges look for, they do care about non-major classes but don't, obviously, weight them as highly. As far as the real world (i.e. employment) goes, many places realize you aren't going to learn much in 4 years. They want to see not that you have specific experience but that you know how to think and especially how to teach yourself. If you can show that you can adapt well to market changes you probably won't have to worry about work... # Chris Adams <adamsc(a)io-online.com> | http://www.io-online.com/adamsc/adamsc.htp # <cadams(a)acucobol.com> | send mail with subject "send PGPKEY" "That's our advantage at Microsoft; we set the standards and we can change them." --- Karen Hargrove, Microsoft (quoted in the Feb 1993 Unix Review editorial)

1 0

Re: Making Remailers Widespread [REMAILERS]
by Bill Stewart 17 Dec '03

17 Dec '03

There have been several good replies - thanks! >> Doing two-way remailers would be better, but that's still a hard problem, >> and I don't want to widely deploy shoddy two-way-remailers. >Unfortunately, one-way remailers have much fewer uses than two-way remailers, >any many of these uses are abusive. I agree, it's a problem; the return address seems to reduce abuse. But one-way remailers can be used to simulate many of the uses of two-way, especially with message-pool return methods (e.g. alt.anonymous.messages.) Doing two-way remailers well is hard - most of the methods around are ok for passive attacks, but may not resist subpoenas, rubber-hose, or crackers. It's especially hard if you want the remailer to be a no-brainer to install and operate, rather than one that requires expert support. Snow's one-shot reply block method is interesting, whether you do a public-key or secret-key approach (if you do public key, you obviously use the public half for the part that stays at the remailer.) It has the real advantage that compromising the remailer doesn't give you the reply information for past or current messages, so you can only compromise one message at a time, which is a big win over the one-key-per-remailer reply blocks. I think I like it. On the other hand, there are a host of potential problems: - Chaining is probably more difficult, at least return-chaining. - Individual True Believer remailer operators would usually resist cooperating with authorities to decrypt the reply block, but ad-hoc remailer operators who are just running a remailer because they haven't turned off the default feature that came with their Web Server will probably reveal the key, especially for Politically Incorrect material (definition depends on their individual politics, of course.) - A web form interface, filled out from a web anonymizer, doesn't give you a useful return address, so spammers can still abuse it. - You have to decide how much persistence to use for the reply block. One-shots are more secure, but aren't helpful for replies to web postings or other multiple-recipient communication, but timeouts have their own problems. >> - A centralized block list (e.g. http://www.remailer.net/block.txt) >> which all of the form-based remailers could load and reference would >> allow non-picky operators not to have to handle it themselves >A single centralized point of failure is bad. Maybe 4 or 5 redundant ones. >A blocking request sent to one will be replicated in the other automatically. Good point. A bit tough to implement in a no-brainer out-of-the-box remailer; you gain a bit by having the block list point to an address that's really a round-robin DNS spinner of some sort, but that still leaves you with centralization. >> [centralized blocking list; handshake with cookies ] >> - this is a bit messier for mailing lists, but we can ignore... > >We can't quite ignore... In the scheme you've just described, someone can >enter a blocking request via a Web page and give a submission request for >some mailing list, and the cookie will be e-mailed to the mailing list. Yeah. This makes it easy to block anonymous remailer input to (say) the cypherpunks mailing list, since _any_ mailing list user can block. Putting a never-block list at the blocking server is a possibility, and would require some announced policy for implementing it. >> - special-case for "postmaster", who may want to block >> all of foo.domain instead of just postmaster(a)foo.domain >> - special-special-case for postmasters of big sites, e.g. aol, netcom >> who we may want to ignore? >I don't think it's a good idea to suport blocking receivers in an entire >domain, like *(a)aol.com. Just say it's not supported. Blocking an entire domain like *(a)aol.com is mostly bad. Blocking an entire domain like *(a)myconsultingfirm.com is fine. Deciding the boundary between the two is, um, amusing :-) I'd probably set it such that ISPs don't get blocked, but non-ISPs do, though that might change if the administrator of aol.com asks five million users to submit individual blocking request. I suppose this means there's a volume question here :-) Having a don't-block list that individuals can subscribe to would help. >> - A sender-blocking list is harder, and may still take human attention >I don't think it's a good idea to support sender blocking at all. There are some spammers you'd like to stop quickly when a Spam Event is happening. There are broken email gateways that may need blocking. There are known abusers you might want stopped. And there are folks like president(a)whitehouse.gov who can be presumed to be forgeries :-) A sender-blocking list administered by the Remailer Cabal* would be a reasonable default for no-brainer remailers, and obviously it should be possible for remailer-admins to override or ignore if they want. >Would the receiver blocking list be available to everyone to view? That >sounds like a violation of privacy. Someone suggested on this list that >(assuming that the entires are addresses that match exactly, not regular >expressions), one can store hashes of addresses. That's worth doing, or at least thinking about seriously. The most interesting regular expressions are *@domain (which you can handle by keeping separate block lists for domains and full addresses (or a merged list that the using remailer checks both)) and *(a)*.domain and user(a)*.domain - e.g. alice(a)mailserver17.big-isp.com, which would successfully deliver mail to alice(a)big-isp.com. Perhaps the system needs to keep two hashes - hash(alice),hash(big-isp.com) and check subsets of the domain name? This is creeping featurism, but it may be the right way to go to set a good precedent. One unfortunate result of only using hashed names and not readable names is that it doesn't help the current remailer operators, since their existing code doesn't work that way. Keeping the file of real names encrypted and only distributing it to the Remailer Cabal seems leaky at best :-) - I'd expect to see it remailed to some public place just on principle. snow wrote: > Off the top of my head, the biggest problem is that you can't send > email to a web site (page). You can easily send it to a procmail program at a web site, though, which can take care of doing the right thing with it. Mark M.'s pointer to netcat is especially relevant for this. > Netcat can be used pretty easily to fetch URLs > (e.g. echo "GET /foobar.html HTTP/1.0" | nc www.webserver.com 80). [*The existence of the Remailer Cabal, viewed by some as a shadowy subversive conspiracy, and by others as Dedicated Public Servants has been repeatedly denied by anyone in a position to know. :-) ] # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # <A HREF="http://idiom.com/~wcs"> # You can get PGP software outside the US at ftp.ox.ac.uk/pub/crypto

3 2

[AP] Afghanistan
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

Afghanis publicly hanged their former president, Najibullah [no last name]. Other countries should follow their example. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

2 1

RE: Looking for Qualified Individual/Firm to Contract for Cryptanalysis
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

"geeman(a)best.com" <geeman(a)best.com> writes: > Huh? > Since when is (408) in San Diego? San Jose then. San something or other. Silicon Valley. I dislike California enough to view it as one undifferentiated nasty blob. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

1 0

Re: What about making re-mailers automatically chain?
by David E. Smith 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit To: gcg(a)pb.net, cypherpunks(a)toad.com Date: Sun Sep 29 04:06:38 1996 > Would it be a good idea to have a re-mailer "randomly" decide whether > to > send the mail to the destination or to another re-mailer. If all > re-mailers performed this way, not even the sender would know the path. > The chain could be short sometimes and long others. Granted, there is > a > possibility that every mailer decides to chain instead of sending the > message to the recip, but some clever counter tag could keep the number > of > links to a certain maximum. The "randomness" of this would aid in > traffic > analysis, and of course each mailer that decides to chain the mail > would > encrypt under the next mailer's pub key. Any thoughts? I dunno about that one. Even if the message itself is encrypted, every remailer has to have the address of the final recipient for your plan to work. And if you have cleartext for that message (oops!) then any remailer operator could read it. More traffic is of course a good thing, but I'm just kinda iffy on the concept. dave - ----- David E. Smith, P O Box 324, Cape Girardeau MO USA 63702 dsmith(a)prairienet.org http://www.prairienet.org/~dsmith send mail with subject of "send pgp-key" for my PGP public key "Madness takes its toll . . . please have exact change ready." -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMk48IzVTwUKWHSsJAQEMugf5AYs0epJSF5ukk5aKvttFXJTHnBzvCtQH aCgxJnnv6bQGQm2fu8Ot7C9UgFNE8NTHJaPHFAkR21/YgwvhUUNhbUrHgz5zZMJ1 oY3jJJgIyLJsyw/+bsHHQc9oDl5VBr+V8xVQBWNR45N0vHx6wWwH5ZjmhBHEfJcg 97CDvygXh6nYJKQplRJ49wYYT29PMg0dONrQSXtYcH5sAhtPEkTzgIKqg0O3MVen tGG11Vl+0ghK2RIwJCoWKMXsqmJexP06+5AdeOLwHsc0QmPkuweKMvWSkF1R0ubR chHFaGlmduT0zNyGB4gIiWl71DYA2EgGSbxOZaGtEa57gJ8tFHVl1g== =PVbP -----END PGP SIGNATURE-----

2 1

Cryptography..
by Erp 17 Dec '03

17 Dec '03

What is the maximum encryption allowed to be created. With export restrictions in mind, and without export restrictiosn in mind... Thanks... By WORLD and US standards please... much appreciated.. export from the US to elsewhere that is also.. reply asap is much appreciated

2 1

Re: Transforming variable-length to fixed keys
by pgut001＠cs.auckland.ac.nz 17 Dec '03

17 Dec '03

>If the speed of your key generation is an issue, you could do something like: > > key[] = { 0 }; > const int nhashes = 4; > typedef void (*hashfnptr)(byte*, byte*, int); > /* array of hash functions */ > hashfnptr hash[ nhashes ] = { md5, sha1, haval, ... }; > > state = hash[ 0 ]( algorithm, mode, parameters, userKey ); > > for count = 1 to iterations > for length = 1 to keyLength (in hash_output_size blocks) > /* selecting a hash function based on the state */ > state = hash[ state % nhashes ]( state ); > key[ length ] = hash[ state % nhashes]( state, userKey ); > >This provides more expense in hardware for the same expense in software, so >for the same CPU time you get more hardware expense, and could reduce the >iterations for the same security. > >`nhashes' determined by the number of digest algorithms you consider >trustworthy. > >(They need hardware for `nhashes' different digest algorithms). > >You need to do something about resolving the differing output and state sizes. Yeah, that's a particularly evil way of making things harder for people with keysearch engines. That's why in cryptlib when I'm doing something like key exchange I encrypt all the parameters (algorithm, mode, etc etc) along with the session key, so an attacker can't even tell what algorithm you're using[1]. I'd thought of adding some sort of "choose a random algorithm and mode" capability to cryptlib, but the user interface was too difficult to handle (finding a way to let the user specify "We want a choice of DES-CFB, IDEA-OFB, DES-EDE-CBC, or Blowfish-PCBC" is a bit of a pain). In the end I took the easy way out by adding an extended initialisation mode which allows the user to specify the algorithm if they want, but left the possibility of one-algorithm-per-round hashing alone. A problem with using one of a fixed selection of algorithms is that as you add new modes the selection changes, so you need to add more state information to the key which specifies the choice of algorithms, which starts to get messy. I'd still love to add this in some form to keep the NSA amused... perhaps a bit vector of allowable algorithms and modes passed to the setup function. Peter. [1] There's a story from IBM when they were testing a new IBM-internal encryption system for long-haul telecoms applications. They were playing around with bouncing encrypted transmissions off an IBM-owned satellite when they were contacted by the NSA who said "You're not using DES. Stop it".

2 1

PET_ard
by jya＠pipeline.com 17 Dec '03

17 Dec '03

Sci, 20 Sept 1996: "Redefining the Supercomputer" The word is petaflops, computer jargon for 1000 trillion computations per second. Think of it as a year's labor for a powerful workstation compressed into 30 seconds. Think of it, also, as 1000 times the speed of the current computing benchmark, a trillion operations a second -- teraflops -- which is on the verge of becoming a reality at Sandia National Laboratories after 5 years of effort. Now the federal government's high-performance computing program is aiming for a petaflops, and researchers are exploring new technologies, sketching new architectures, and pondering the software challenge of harnessing this staggering computational power. The NSA is a petaflops enthusiast, says a researcher, but "we're not allowed to think about their applications." ----- http://jya.com/petard.txt (20 kb) PET_ard

2 1

Re: [CRYPTO] (was: sig/noise ratio)
by paul＠fatmans.demon.co.uk 17 Dec '03

17 Dec '03

> > > > Items crypto related but missing the [CRYPTO] header could be > > reposted by well meaning souls. > > > > Other appropriate headers could of course be used. > > > > Brian Yeah, It`s sad that it`s got to this stage now but I support the idea anyway, I`ll start prefixing all my cryptographic code or technical postings with the headers. Datacomms Technologies web authoring and data security Paul Bradley, Paul(a)fatmans.demon.co.uk Paul(a)crypto.uk.eu.org, Paul(a)cryptography.uk.eu.org Http://www.cryptography.home.ml.org/ Email for PGP public key, ID: 5BBFAEB1 "Don`t forget to mount a scratch monkey"

1 0

Re: Mousepad RNG's?
by paul＠fatmans.demon.co.uk 17 Dec '03

17 Dec '03

> I just downloaded a copy of the beta version of Datafellows > Windows 3.1 SSH and it asked to move the mouse around to > generate some randomness. In reading Applied Crypto, it > mentioned that there is no such thing as generating > randomness from a personal computer unless something like > a Geiger counter is used. Is there any way to create a > fairly random sample from the mouse? Should one use lots > of jerky movements, or take ones time with it? What applied crypto would have said was that one cannot generate randomness on a computer without reference to an external source, a mouse is as good as any, the real problem is generating random numbers using PRNGs (Pseudo random number generators) which are algorithms that produce statistically random data that may be predictable, in the words of John Von Neumann "Anyone who considers aritmetic methods of generating random numbers is in a state of sin" In brief, a mouse output would be acceptable, just move the mouse any old way around the screen and the data will be random enough for your uses... Datacomms Technologies web authoring and data security Paul Bradley, Paul(a)fatmans.demon.co.uk Paul(a)crypto.uk.eu.org, Paul(a)cryptography.uk.eu.org Http://www.cryptography.home.ml.org/ Email for PGP public key, ID: 5BBFAEB1 "Don`t forget to mount a scratch monkey"

1 0