December 2003 - cypherpunks-legacy

Re: video as a source of public randomness
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:08 PM 11/3/95, Perry E. Metzger wrote: >Timothy C. May writes: >> I don't plan to belabor this point. Radioactive decay sources are >> certainly fine, though not likely to be purchased by most people. > >Video digitzation equipment connected to TV tuners turned to dead air, >your suggestion, are equally unlikely to be purchased by most ^^^^^^^^^^^^^^^^ >people. The geiger counters are very simple and cheap, too. It is not correct to call this my "suggestion." I was responding to a previous post by Andrew Isaacson who said: "How useful would it be to use a video stream as a source of random input to something like /dev/random? I'm thinking along the lines of a Connectix QuickCam (sp?) or the cool videocam that comes with the Indy...." I was commenting on the sources of randomness, such as atmospheric RF variations, antenna configuration, tuner sensitivity, amplifier noise, etc., that would make prediction of snow bits very difficult. As to suggesting setting the tuner to dead air, this was just one facet of the discussion. I have no brief with any of the proposed schemes: nearly any are better than what we have now, if widely deployed and suitable used. --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

2 1

Credentials Without Identity
by tcmay＠got.net 17 Dec '03

17 Dec '03

Rich Graves makes some very good points, but he said something I want to riff on. (And as a measure of how apologetic some folks are getting about discussing anything not on Perry's List of Approved Topics, Rich unfortunately labeled his post "[ID point semi-off-topic]..." In fact, the issue of credentials and identity is NOT off-topic, not even semi-off-topic. It is central to the themes of our list. I urge all to read Chaum's seminal work on "credentials without identity.") At 1:05 AM 11/5/95, Rich Graves wrote: >Proving legal residency requires a combination of two documents, one each >from specified lists. Most commonly a driver's license, green card (which >is actually pink), or birth certificate from list A, and a social >security card from list B. > >Chris Hibbert's SSN FAQ talks a little bit about how this works, and why >it's a Good Thing. Basically, for privacy and security reasons, it is a >very good idea to separate the issues of identity and authorization. > >I don't care how securely you can authenticate who I am -- by PGP, retinal >scan, whatever. I do not want a single digitizable token to be the key to >my identity. Even if that identity cannot be forged (and everything can be >forged), it can be used to track me, by the government, by the Direct >Marketing Association, by the private investigators of certain wacky .... Chris's (or Chris') points are admirable, but getting more and more irrelevant by the day. The notion of unlinking identity and authorization by separate pieces of identification is another form of "security through obscurity." The two forms of credentials can be linked in data bases. Just because one piece of ID has citizenship or voting status and another has other stuff is meaningless, provided the ID forms can be linked. As they can, in multiple ways. The credit tracking agencies can do this trivially, with names, social security numbers, driver's license numbers, addresses, phone numbers, etc. All are pointers into the cloud of numbers that constitutes one's dossier. Happily, Chaum's work on "credentials without identity," based essentially on the kind of "blinding" used in digital cash (with some differences, of course), allows for one to display a credential showing one is old enough to enter a bar or library (in 2005), without revealing a name (which is just another credential). --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

4 3

Re: consumer products that make nice sources
by mhkohne＠discordia.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 10:34 PM 11/3/95, Timothy C. May wrote: >At 5:46 PM 11/3/95, Brad Dolan wrote: > >>The tag on my Montana Sunshine Radon Mine radon pillow is a little blurred >>I think the following is the right phone number. >> >>Sunshine Mine is an amusing concept. People pay money to go breathe radon >>there, while others are spending much money avoiding radon. >> >>Anyway, the pillows make nice sources and good conversation pieces. > >I'd say they make poor sources. Far too large. A smaller source has better >access to the detector without adding much to the overall background the >user is exposed to. (I'm not saying low-level uranium or thorium sources >are much of a hazard, but the fluence presented at the detector is very low >for such an extended source.) If it's a cheap source of higher-than-background radiation, try a smoke detector. They are getting darn cheap these days, and my First Alert Model 83R says it contains 1.0 Microcurie of Americium 241. This should raise the count rate significantly over background. And if one isn't enough, you could always get several, remove the module with the radioactive materials in it (it's a sort of black cylinder in mine) from several, and put them all in a box with the radiation detector. As I remember, I bought 2 or three of these detectors in a single package for about $15 3 years ago. They should be quite cheap by now. Although, I don't think it has the same sort of humor value as the pillow. (What's that hooked to your computer Mike? It's a pillow Bob. Don't ask.) -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMJvmh4P3Pba7OSlRAQEDlwP8Cm4vryVejfJZoSd/amwFLxJZWYnPHNxS 3KCmw8jSKjFk4iF+wTvWAHbFIjjkKFGBLt6+BMbDt2eUM6R87mNay1nMASsCoweL syDr4D39XDUGF6sw7TDulLTW62u7JKaCIGoBQU5+uU4Qxs3YA4QVVR+sLi885ngt o0GEIeVgLw8= =hNXr -----END PGP SIGNATURE----- ---- Michael Kohne mhkohne(a)discordia.org or mhkohne(a)moberg.com "Quantum mechanics is your friend" Key fingerprint = EE 22 9D 9B 32 5E F1 37 D2 B3 DC 78 19 24 D1 E8

3 2

Re: FBI seeks huge wiretapping system
by James A. Donald 17 Dec '03

17 Dec '03

> What is very odd however is the FBI request for $500 million. > [to tap phones] What is odd about that? -- when I visited Cuba a couple of years ago it looked to me as if a major chunk of the GNP went into watching people. (I hear the situation has improved since then, perhaps thanks to their continuing bankruptcy.) At 12:09 PM 11/2/95 -0500, hallam(a)w3.org wrote: > When the NSA are being asked to comment on an export license they > are being asked "is this thing dangerous", not "should it be exported". > But when the response comes back to commerce "its dangerous" you can > hardly expect the person on the other end to put their neck out on the > line and risk allowing [...] This of course is the basic evil of government regulation: Bricks are dangerous. Two by fours are dangerous. Water is dangerous. Playgrounds are dangerous. Everything is dangerous, because everything could be used to cause harm, deliberately or accidentally. Therefore every action needs to be supervised, controlled, and directed by your wise and benevolent government, and any attempt to avoid the benevolent observation of the all seeing eye shows that you must be a child pornographer-terrorist-drug-trafficker-money-launderer. --------------------------------------------------------------------- | 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

2 1

Re: Telephone switch capacity -Reply
by James A. Donald 17 Dec '03

17 Dec '03

At 06:43 PM 11/3/95 -0800, Rich Graves wrote: > Of course the FBI doesn't have the staff to listen to all these lines, and > they need an individual court order to authorize each individual > interception, so this numbers game is a bit of a joke. This is false: The FBI is legally authorized to intercept phone lines by court order "or other lawful authority". >From the money it would seem that "other lawful authority" intercepts vastly exceed court ordered intercepts. You will recall the vast outcry in the liberal lapdog press when this vast new power was given to them -- You don't recall it?! Neither do I. This is one of the many vast extensions of government power that we see come down at a steadily increasing rate, to the accompaniment of total silence from a compliant and submissive mass media. > There is no controversy about the number of wiretaps that have been > authorized, except as manufactured by the Spotlight folks and other > conspiracy loons. If the only taps are court ordered wiretaps, it would seem we are paying about half a million to a million dollars per wire tap, which is a shade expensive even for government work. --------------------------------------------------------------------- | 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

Version 2 Elliptic Curve Crypto
by Mike Rosing 17 Dec '03

17 Dec '03

Howdy, I blew it the first time, but the correct elliptic.2.tar now sits on ftp.csua.berkeley.edu/pub/cypherpunks/ciphers. This version is twice as fast as eliptic.tar. A newer version of the elliptic.2.doc is being fixed right now, the only difference with what is posted is a correct reference to the CRYPTO '95 article on polynomial basis inversion. Enjoy. For a compiled version on Sun or under Borland C++ contact Steve Albrecht (eh(a)mcs.com) He is in the process of setting up macros to get this to compile under just about any unix system. He's also fixed quite a few bugs and is cleaning up a bunch of uninitialized data structures that I didn't notice. Last I heard it was working, so if you want to play on a specific platform, contact Steve directly. Hilarie Orman from U. Arizona (one of the authors of the CRYPTO '95 paper) thinks that calling elliptic curves "strong crypto" may be over selling it. I'm not enough of a mathematician to know how to argue, but it seems to me that almost perfect random output is about as close to strong crypto as one could get. Security thru obscurity doesn't work, elliptic curves are obscure and so far not studied to the same extent as RSA or DES. However, I'll make the claim that elliptic curves are "strong crypto" until proven otherwise. Along those lines, does any one have a classic text to encrypt for a plaintext/ciphertext challenge? I'll put something together and post it in the next few weeks. I'll use the symmetric encryption subroutine. If there is any interest, should I put out a public key challenge as well? Note, I ain't rich, so only token prizes (like $50 ecash and $50 real for each challenge). The point is to check if this is credable crypto, that's all. E-mail replies to cryptech(a)mcs.com. Thanks for reading this! Patience, persistence, truth, Dr. mike

1 0

Re: using pgp to make an otp
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:58 AM 11/5/95 -0500, amp <Alan.Pugh(a)internetMCI.COM> wrote: >i want a source of data for use as a otp. .... >i'd like to know if there was a reason not to use the output of pgp Either PGP is a strong enough cryptosystem that you don't need to use a one-time-pad, or it's not, in which case you need better randomness than PGP will give you (I doubt it), or you have special applications for which PGP is impractical (like decrypting small amounts of data on a very wimpy machine in an environment that you can easily distribute OTP keys (for using ONCE ONLY)). Or you're just doing it for fun. A OTP can give you provably secure cryptography, given that the pad is only used once, and has real randomness behind it. If it's only pseudo-random numbers (e.g. generated from some algorithm), then it's as crackable as the source of random numbers, and therefore no longer provably secure. And of course, if you use it more than once, or your pad distribution isn't secure, you lose. >i still need a program to make use of the otp i've produced, Two alternatives - spend 5 minutes writing it in a language you know well, or pick a language you don't know very well and use it as an excuse to learn the language. It's slightly more complex than "hello, world", since you need to input data from two files and use XOR. >what are the holes in this? why would it be unadvisable to do it? The big problem with OTPs (other than getting people to use the pads ONLY ONCE, since they're otherwise hosed) is shipping them around; the traditional method is guys with briefcases handcuffed to their arms.... >otoh, would it be a good basis for a otp? Large quantities of good random numbers are hard to find. Small quantities can come from dice or throwing darts at the stock market pages; the zener diode or radioactivity methods people have been discussing will produce larger quantities if you've got the equipment. If you've got one of those new radio-tuner boards for your PC, tuning it to an unused station might be quite decent, and we've just been discussing whether video is any good. With many of these sources, it's probably worth grinding the numbers through some sort of compression or encryption algorithm just to smudge over any periodicity or other structure to it. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: Telephone switch capacity
by Bill Stewart 17 Dec '03

17 Dec '03

> Please be aware that the current capacity of the >telephone system in the United States (and for that matter, >most of the developed world) is only capable of supporting >between 15 and 20 percent simultaneous telephone >conversations. If the FBI wishes to set up a system that is >capable of monitoring 1% of the total number of lines, that >equates to a ability to tap 5%, not 1% of all calls in progress. The FBI now says they only want to tap 1% of simultaneous capacity, not 1% of total number of lines. On the other hand, the actual utilization of the telephone network is also much lower than the number of lines - back when I was a voice-telephony geek, our estimates for busy-hour phone utilization were about 1/12 for residential and 1/6 for business (3 and 6 hundred call-seconds per hour); that was before widespread use of fax machines, modems, or LANs, so business utilization has probably increased. Equipped trunk capacity was typically enough to have a maximum of 1% blocking during busy hour, which means a certain amount of margin over average calls in progress, and switch capacity depends radically on technology - some kinds of switches are non-blocking, while others have various capacity limits. "One Bell System - It Works!" #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: Video as a source of randomness
by Bill Stewart 17 Dec '03

17 Dec '03

>>How useful would it be to use a video stream as a source of random input >>to something like /dev/random? I'm thinking along the lines of a >>Connectix QuickCam (sp?) or the cool videocam that comes with the Indy. >>It seems to me that the picture recieved by a camera sitting atop a >>monitor would be quite unpredictable. (relatively) High bandwith, too. Depends on what the camera's looking at - the first frame you grab may have a lot of entropy, but if there's nothing much going on in the room, one frame's going to look a lot like the next. Of course, pointing the camera at your keyboard and taking a video of you typing in lots of random numbers will probably produce better randomness than just timing the keys while you do so... But do move it away before typing in your passphrase... Pointing the camera at a snowy TV or out the window or at a cat playing with catnip can generate much more randomness if you need it. Somebody was saying that of course not may computers will have video capture devices on them, but it was probably one of those parochial PC or Unix geeks who forget that Mac users get all the cool video/audio gear long before the rest of us :-) #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

3 2

/dev/random - using up entropy?
by Bill Stewart 17 Dec '03

17 Dec '03

The discussions of what to do when /dev/random has handed out all of its available entropy have assumed that entropy gets used up; I'd like to propose that maybe it doesn't, at least in the computational-complexity sense that says that you don't have the computational power around to calculate the information inside /dev/random from the output, giving a sort of "computational entropy" that reflects not only the uncertainty you have because of randomness but also the uncertainty you have because of your computational limitations. Most of the designs I've seen look like this: A Reservoir of entropy R = R1....Rn, where n is large, 1024 or 4096 An input stream I = I1....Ik, which is mixed into R A mixing function F which is used to mix R <= F(R,I) for some chunk of I, possibly empty. A hash function H, typically MD5. An output O = O1...Om = H(R), and E gets mixed after every output. (These are capital-o, not zero...) The entropy E of the reservoir E before an output is -SUM(all X) p(X) log p(X) where X is an event R1=x1, R2=x2 ... Rn=Xn which is equal to n, assuming the Ri are iid equiprobable 0 or 1. After an output, the entropy is - SUM p(X | H(R)=O) log p(X|H(R)=O) which works out to n-m, since p(X) is zero if H(R)!=O, and 2**m/2**n if it does. So that says you use up m bits of entropy if you get m bits of good output. However, what I'd like to suggest is that you don't, from the perspective of a user who doesn't have direct access to the reservoir R of random bits. For that user, p(X|H(R)=O) is the same as p(X) or P(X|H(R)=O'), because the user is neither able to invert H, nor to enumerate all possible R, nor to calculate anything useful based on multiple outputs, since the reservoir R is shuffled between outputs; even a simple circular shift may be enough. This doesn't apply to the case where n is 32 or 48 and the hash function produces n-bit outputs, or even m<<n bit outputs, because that maybe be inverted or brute-forced, but it seems to apply for the case where n is sufficiently large and the hash is good. If the hash is simpler than MD5, it may apply anyway, since the hash produces far fewer bits than its input, as long as the hash and the mixing function don't give away any information about the reservoir between successive outputs. This would suggest that /dev/random ought to have a mode that says "give me output of whatever quality you have available", and that it ought to be OK to use it, as long as the reservoir has been seeded with sufficient high-entropy input to have decent randomness. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

3 2