December 2003 - cypherpunks-legacy

CIA Admits Timothy C. May Son of Sam! Pix at eleven!
by Clark Reynard 17 Dec '03

17 Dec '03

[ASCII crap straight from Fidonet deleted.] [Obligatory obscenity deleted, as I have not the time to flame this moron.] [Obligatory crypto reference: I hear the CIA has new cybernetic cryptography hardware; they're experimenting with cyborging, and evidently they stole this poor fool's brain; for obvious reasons, the experiment failed and we can conclude the existence of a vast CIA coverup by the total lack of public denials of the conspiracy. Another telling point is that there is absolutely no evidence of a conspiracy, which attests to the great skill with which they covered it up. In addition, Timothy C. May, if his middle name is in fact Cornelius, despite his lack of trying to hide this obvious clue; is obviously at the helm of the conspiracy to present himself as a countercultural figure, when in fact the letters of his name, when added in strict numerical order and with vast compilations of material only known to the devout studier of Sumerian metaphysics; in fact equals the hideous number 93985676! 93985676, as any fool knows, is the Number of the Beast when read as Hittite cuneiform writing! Obviously, as someone of my great knowledge can tell at a glance, Timothy May, the CIA and the so-called "cypherpunks," now revealed to be, in actuality Satanpunks, devoted to the overthrow of Mom, Apple Pie, and Everything Decent. May they burn in everlasting Hell for their blasphemous, devious, internetworked conspiracy of hatred, and may they pay for their perfidy in multilevelled torture chambers filled with mud, stinging acid and vipers! Now you'll pardon me. I must go. I hear a knock at the door, and it could be the dreaded Eric Hughes himself, who is STEALING MY THOUGHTS with MICROWAVES!] ---- Robert W. F. Clark PGP Key Available Upon Request rclark(a)nyx.cs.du.edu clark(a)metal.psu.edu

1 0

Re: Destroying data
by nfe＠scf.nmsu.edu 17 Dec '03

17 Dec '03

Philippe D. Nave, Jr. writes: >Thermite grenades are pretty simple; ... NOT! Anyone really wanting to try this should hang out on rec.pyrotechnics for awhile, but for the truely foolhardy here are some tips and thoughts: 1) Thermite is extreamly hard to ignite, so requires an igniter. Most home made igniters are extreamly unstable (do you really want the thing off accidently (bump it, static charge, RF energy, etc)? 2) 50:50 mix of AL and iron oxide will probably work, but best to look up a really ballenced % for the best mix. btw: was that by volume or weight?, there is a slight difference :) 3) in general, the finer the powder, the better. ball mill it if you can. 4) iron oxide has this strainge tendency to hold magnetic charges, do you REALLY want that near your HD? 5) for best results, the thermite charge should achive a completly molten state before the slag begins it's decent to the target, otherwise it waste's part of it's payload. The best homebrew way to do this is by making a cylinder of firebrick dust (hard or soft) and high temp epoxy (ceramics are also good), with a quarter sixe hole in the bottom. umm that's like a cylinder with one end cap'd, maybe 4-8" on diameter. cover the hole in the bottom with a thick piece of sheet metal, or copper, or something. Attach some sticks, or rebar, etc to form legs and offset about 1.5 to 3 inches for better penetration. (probably not necessary for electronic equipment) 6) on loading - best done near where you want to use it - alot of moving/ shaking will tend to make the heavier iron oxide settle to the bottom and you won't get as good of a burn. 7) don't tamp it! - it needs that O2 between the flakes of powder. Now that you all know more than you really wanted to about thermite, does anyone know of a good recipe for a magnetic bomb? - you know, something with abit of oomph! ? -n

2 1

S. Boxx == L. Detwiler
by paul＠poboy.b17c.ingr.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- It should be evident; at least I'm convinced. The recent discussion on programs to automatically search for similarities in texts of different authors led me to think back on the collected works of Detwiler and Boxx. This is not sufficient evidence to stand up in court (or in the RISKS Digest), but I offer it for your consideration. There are some unique and characteristic signatures in material from both authors: - writing style: frequency of use of $10 words excessive use of modifiers excessive use of parenthetical phrases - lack of periods between initials and names (e.g. "T.C.May") - consistent use of initials instead of names (see above; no other entity on this list that I recall does so.) - ADJECTIVES and ADVERBS are capitalized for emphasis So, L.Detwiler: are you the snake, or just a tentacle? Of course, maybe S. Boxx is just Eric pretending to be Tim, who is pretending to be you. Or, maybe it's those damn Libertarian Nazi abortionists. I don't know. Wishing the coffee house had a bouncer, - -Paul - -- Paul Robichaux, KD4JZG | Caution: cutting edge is sharp. Avoid contact. Intergraph Federal Systems | Be a cryptography user - ask me how. ** Of course I don't speak for Intergraph. ** -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLOeQtyA78To+806NAQE54wQAo3GRAhtt8Ls9lr5U1KHfrw2+by7DziEQ XtcQb2edMnMuwkiY37sz2DrLO2dRX0+SCx7AJv/V5gOoV1c8UlUE1fDhwp5g6pKK +mCmXR+TrbgxDzD+QZ5INiFV4n1oSvmFGi5+/hKOnhyDyl6gH/w2RTxpX2rkRn4z idR028mIKZs= =jldp -----END PGP SIGNATURE-----

1 0

Key Servers
by an41418＠anon.penet.fi 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I don't see what you mean by key servers for only true names. How do you know that a true name isn't just a false identity created with a real account on some system? How do you differentiate a true name from a unix account? Wonderer -----BEGIN PGP SIGNATURE----- Version: 2.3 iQBVAgUBLOeQFx1kTJuroDD9AQFxbQH/f7Y4uj4xn2eeWFoTmu8Aahp2FxG+7ShV uAvvRpUWkE2Ay9MdB4lKCSjNv5cO92DwbcWRoZgbI7hPJGAe7za37A== =IBrC -----END PGP SIGNATURE----- ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

3 2

Re: Destroying data
by Jef Poskanzer 17 Dec '03

17 Dec '03

>1) Thermite is extreamly hard to ignite, so requires an igniter. Most > home made igniters are extreamly unstable (do you really want the thing > off accidently (bump it, static charge, RF energy, etc)? KNO3+sugar works fine. >2) 50:50 mix of AL and iron oxide will probably work, but best to look up > a really ballenced % for the best mix. btw: was that by volume or > weight?, there is a slight difference :) By weight. >3) in general, the finer the powder, the better. ball mill it if you can. The iron oxide you get from ceramics supply places is plenty fine enough. DO NOT ball mill the aluminum, it can explode. If you're not a minor, chem supply places should be willing to sell you 200-mesh Al, which works fine. >7) don't tamp it! - it needs that O2 between the flakes of powder. Not as far as I know. Personally I'd rather use some sort of cryptographic file system, with the key stored in volatile memory. Connect the power switch to your perimeter sensors and you're safe. Thermite sounds macho but the reality is messy and dangerous. Do you really want to risk a false alarm? --- Jef

3 2

mailing software
by walter kehowski 17 Dec '03

17 Dec '03

Cypherpunks, Could someone send to me a list of software that expedites the processing of large amounts of e-mail? I'm on a next computer now and the browser, sorting, and mailboxes are very convenient. I won't always be using the next, though, and I'd like to start learning what the options are. Thanks, Walter A. Kehowski <wak(a)next0.math.pitt.edu>

1 0

Re: LD Admits he is S.Boxx (oops!)
by cfrye＠ciis.mitre.org 17 Dec '03

17 Dec '03

Kudos to Mike Ingle for his diligent record keeping and powers of observation. As much as I like the computational solution for these problems, there's no substitute for documenting a mistake that blows somebody's cover. Curtis D. Frye cfrye(a)ciis.mitre.org "If you think I speak for MITRE, I'll tell you how much they pay me and make you feel foolish."

3 2

"Root Canal" questions
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

In article <00541.2835966052.614(a)washofc.cpsr.org> dsobel(a)washofc.cpsr.org writes: > "Root Canal" questions > BTW, anyone have ideas about that name!? Having just been through this procedure (UK National Health, $70), I can tell you - It's all about *Deep Drilling*. Presumably for data, in this case. And it hurts. G -- Personal mail to gtoal(a)gtoal.com (I read it in the evenings) Business mail to gtoal(a)an-teallach.com (Be careful with the spelling!) Faxes to An Teallach Limited: +44 31 662 4678 Voice: +44 31 668 1550 x212

2 1

DC-Nets
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Jim McCoy has asked me about the DC-Nets references I have cited. Here they are. The seminal Chaum articles are not cited--the main one has been posted to this List more than once. Clearly the Eurocrypt '89 book is the one to get. If your library does not carry it, Springer-Verlag (1-800-SPRINGE) can ship it (and please don't write to me asking for the ISBN!). Also, "Computer Literacy Bookstore" in Sunnyvale (408 area code) usually has a bunch of these Proceedings in various years and can also ship. Disruption is the main problem addressed in these papers. Given the malicious disruption we've seen on our List lately, it is of course a very real problem. Even more so if and when DC-Nets get deployed and some agents/entities seek to automate the disruption process (a likely prospect, given the way they work). A reminder to you all, even though I am not myself working on DC-Nets (trying to program them in Mathematica is pointless, I think), that there are several groups currently interested in DC-Nets: * Jim McCoy and the Austing group (I think they run the DC-Net mailing list...I'm on too many mailing lists, so I skipped this one) * Henry Strickland (Strick) is interested, has plans, and is putting together his crypto toolkit in TCL. * Yanek Martinson, of whom little has been hear lately, was once hot on doing this, and even got a basic DC-Net running. Anyway, here are some important references: - J. N. E. Bos and H den Boer, "Detecting Disrupters in the DC Protocol," Eurocrypt '89, pp. 320327. - M. Waidner and B. Pfitzmann. "The Dining Cryptographers in the Disco," Eurocrypt '89, p. 690. - A. Pfitzmann and M. Waidner, "Networks without User Observability," Computers and Security 6 (No 2, April 1987), pp. 158-166. - B. Pfitzmann and A. Pfitzmann, "How to Break the Direct RSA-Implementation of Mixes," Eurocrypt '89, pp. 373-381. (In case you're curious, the Pfitzmanns are husband and wife.) - J. N. E. Bos, "Disruption and Synchronization in Untraceable Sending," in "Practical Privacy," the 1992 Ph.D. thesis of Bos. Technische Universiteit Eindhoven (Netherlands). (This little book is not published, in purchasable form. The relevant chapter was included in the Xeroxed handout at the first Cypherpunks meeting. You might be able to get the book by contacting Eindhoven directly.) --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. Note: I put time and money into writing this posting. I hope you enjoy it.

1 0

Portable crypto code
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

One thing that frustrates me is the difficulty of easily providing implementations of cryptographic algorithms that would be useful on a wide range of machines. A lot of these algorithms are really simple, almost trivial. Yet to write programs to implement them takes pages and pages of code, and making them portable so that people on PC's, Mac's, and Unix machines can use them is almost impossible. Take the simple Chaum cash we have discussed here a few times. The user picks a random x and a random r, calculates r^3*f(x) where f is some one-way function, and sends it to the bank. The bank takes the cube root and sends it back, then the user divides by r. That's pretty simple. Yet to actually implement software to perform these steps raises a host of complications. First, we want to choose a "random" x and r in the range 0..m-1, where m is the bank's public key modulus. But we want these to be strong, unguessable random numbers. We need an unpredictable RNG, and we need to seed it. There are various URNG's that are provably as strong as breaking factoring, discrete logarithms, and such, so these would have to be implemented (as before, most are conceptually trivial). Or you could run DES or IDEA in a feedback mode and take bits from there, for a little less security but more speed. For seeding the RNG you could do like PGP does and retain random numbers from earlier runs, mixing in new randomness when feasible; you could do like RIPEM and scan disk partitions hoping for randomness (I think RIPEM has a lot of other ways of looking for entropy); you could use hardware features like /dev/audio or the free-running, high-speed timers some PC's have; you can get the user to click the mouse or type keys at random. OK, we've got our random numbers. Now we want a one-way function. Again, there are several choices: MD4 and MD5 from RSA; the Secure Hash Standard NIST is pushing; Ralph Merkle's (I forget the name); others based on conventional ciphers like DES or IDEA. Implementations of these are probably available, but portability is a question mark. Now we need a multi-precision math package. We may have needed one for the URNG, too. There are a lot of libraries available in source code for these, but not many of them will work with 16-bit ints, and are tested on DOS and Mac's as well as Unix. Finally, to send the data around, we may want to convert to and from ASCII, and once again there are a lot of choices, but perhaps not too many portable libraries. I suppose RFC1113 and MIME, which are similar but not quite identical, would be the encodings of choice. The point I'm getting to is that it would be nice if all this were done ONCE, and a library made and tested which would work on a wide range of machines. Entry points for one-way functions, multi-precision arithmetic, unpredictable random numbers, conventional encryption, and ascii conversions could all be provided. Multiple alternatives would be supported as much as possible and it should not be difficult to add more as time goes on. Once you had such a library, it would be possible to add a user interface to allow interactive use of the routines. It could be as simple as the Unix "bc" program where you can say "x = y*z" to do arithmetic, or perhaps "x = md5(y)" to call a one-way function. Or the library could perhaps be linked into perl or some other high-level program (does mathematica have hooks for compiled user code?). The nice thing is that since most of the compute time is spent doing the MP arithmetic in these algorithms, an interpreted system which calls compiled libraries can be as efficient as a purely compiled program. I know that others here have made similar proposals in the past, but I have not heard of many results. I'd like to hear more about whether these efforts have produced anything that could be incorporated. It would also be good to hear suggestions for specific existing packages that would meet the portability requirements. I've looked at a couple of MP packages from ripem.msu.edu but so far I haven't had much luck running them under DOS. Perhaps a project like this could allow progress to be made more easily toward cypherpunk goals. By providing a toolkit to programers newly interested in cryptography people will be able to try out ideas more easily without having to re-invent the wheel each time. Let me know if you would be interested in participating in this effort. Hopefully a lot of the pieces already exist and it will just be a matter of pulling them together. Hal Finney hfinney(a)shell.portal.com

3 2