December 2003 - cypherpunks-legacy

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

Re: using PGP only for digital signatures
by tcmay＠got.net 17 Dec '03

17 Dec '03

Pop Quiz: If you are a citizen of the U.S., prove it. At 11:33 PM 11/4/95, Simon Spero wrote: >On Sat, 4 Nov 1995, Derek Atkins wrote: > >> student from coming to the US. By allowing the student into the US, >> the gov't is implicitly giving them the right to use PGP within the >> US. > >This is kind of a risky policy to take. The general feeling I get that >allowing non green-card holders access to strong cryptography is sort of >decriminalised, in that the police aren't likely to break down your door >and have your AFS server accidentaly fall down stairs. However, it is >still against the law, and could be used against the university in other >unrelated circumstances. > >It seems that licences allowing foreign nationals access to cryptographic >software within the US are pretty easy to get, and especially for >something like PGP on a central machine. We really need to put this one to bed. As has been said several times recently, for the purposes of law, non-U.S. citizens who reside in the U.S are effectively "U.S. persons." Subject to U.S. law and generally having the same legal rights. (Can't vote. Can be drafted. Must pay taxes. Must have a SSN. Must obey traffic laws. Must not discriminate against the differently clued, etc.) All of the nonsense about wearing a "munitions shirt" in front of a "foreigner" seems to miss this essential point. Ditto for PGP use. Consider this: most people in the U.S. do not have a "credential" that shows them to be U.S. citizens. (Hint: most people in the U.S. do not have passports.) They have driver's licenses, which say nothing about citizenship (at least California and Virgina licenses do not). Social Security cards are the same. (Second hint: most people are hard-pressed to locate a birth certificate for themselves. Many people take the easy way out and simply buy a new one for the $25 a good one costs.) Therefore, there are few ways that citizenship can be "checked." Period. A foreigner who wishes to "prove" his non-U.S. status could, of course, show his green card. But this is different from proving citizenship. As to the USF--or was it SFSU?--student worried about "allowing" PGP to be used...I despair at this outlook. Why not simply ignore the issue, not "give" them PGP, but instead have a few pointers to where PGP may be gotten. As to the point about students impersonating faculty, if the faculty starts signing their messages (doubtful), then no one can impersonate _them_. (Except that it sounds like all this PGP stuff is to happen on campus computers, in which case there are several ways their private keys and passphrases can be snarfed.) The issue of a "credential" for faculty members, something that says "This person is a member of the Foo U. faculty," well, this is a different kettle of fish; such credentials are not part of the PGP system, though webs of trust could in principle be used in a klugey kind of way. --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."

3 2

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

17 Dec '03

At 11:51 PM 11/4/95, Bill Stewart wrote: >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. Which would make that "dev/cat," right? --Klaus!

1 0

Re: on topic!!
by Bill Stewart 17 Dec '03

17 Dec '03

At 02:17 PM 11/4/95 -0800, VZNuri wrote: >if there were two key elements here, these conversations would probably >largely go away (instead of continually reappear) >- an unambiguous charter >- an active moderator > >unfortunately I suspect that a moderator does exist but he "prefers >to remain anonymous" ("pseudonymous"?). imho that is precisely >how *not* to succeed as a moderator. As an alternative, there was the Cypherwonks list, which worked just that way, and such conversations did rapidly go away :-) What's evolved here instead are a couple of filtered lists, such as cp-lite, where you can get the conversations that one or another monitor considers relevant instead of the whole firehose. It seems to work reasonably well for a lot of people. #--- # 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

To Repeat: Credentials Not Considered Necessary
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 1:03 AM 11/5/95, Simon Spero wrote: >On Sat, 4 Nov 1995, Timothy C. May wrote: > >> Therefore, there are few ways that citizenship can be "checked." Period. A >> foreigner who wishes to "prove" his non-U.S. status could, of course, show >> his green card. But this is different from proving citizenship. >> > >And here we have the rub. People with permanent residency (i.e. green >cards) are fully entitled to access to strong crypto. Most foreign >students are on J-1 visas, which do not grant permanent residency. Irrelevant. J-1 persons are still accorded the basic rights of citizens, save for a few things like voting, holding certain offices, and perhaps jury duty (not sure about this, as my recent jury summons was apparently based on my Calif. Driver's License and required no form of identification whatsoever). My basic point was that "J-1," "permanent resident," "citizen," "undocumented," and "completely and totally without proper papers" are, for the purposes being discussed here, all essentially identical. Any sysadmin who expects to have papers proving "citizenship" or any other status will have a tough time. Saying "People with permanent residency (i.e. green cards) are fully entitled to access to strong crypto." and--presumably--implying that J-1 visa holders are _not_ entitled to use strong crypto within the U.S. (or, for that matter, in their own countries, but this is another issue), is misleading. The laws about "showing a foreign national" certain items do not differentiate, so far as I have seen, between various kinds of visas. In any case, sysadmins generally do not ask for any kind of ID or proof of citizenship, morality, residency, etc. (On my many computer accounts over the years, as but one example, _never_ have I have been asked for credentials of any kind. Never. Not even a driver's license, let alone a passport or birth certificate or whatever. My current Internet Service Providers, netcom.com and got.net, are blithely uncaring about the fact that I am technically a citizen of Ruritania, and am not in the U.S. legally.) --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

Re: Sun speaks out - but not to the cypherpunks
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

Todd Glassey <todd(a)lgt.com> writes: > Pardon the flame but I really have just about heard enough of this BS... No one needs to listen to anything if they don't want to, Todd, but I think that some things need saying none the less. I think the old saying is: You can lead a horse to water, but you can't make him think, or something like that ... >>This response came from Sun to Risks: >> >>> Date: Mon, 16 Oct 1995 21:22:40 -0700 >>> From: Caveh.Jalali(a)eng.sun.com (Caveh Jalali) >>> Subject: Re: Risks in Java >>> >>> If we are going to "analyze" java security, let's keep in mind that >>> there is an important distinction between the language (java) and the >>> machinery which runs the java program. Hmm, this is a very interesting prespective, coming from Sun Engineering as it were. The company that says that the Network is the machine, or somesuch. I always thought that security consisted of everything: hardware, software, and wetware. (Or it did the last time, I checked my handbook.) Admittedly this is a horrible inconvenience, especially when it comes to security. >>> Java is a general-purpose programming language along the lines of C/C++. >>> So, there is no doubt that its expressive power overwhelms our >>> theoretician's abilities to predict java-programs behavior -- this is >>> where we start getting into the halting problem, computability and other >>> black magic. Basically, i don't think we can "trust" programs >>> written in any *useful* programming language. >> >>Read: We can't trust Java programs. This may well be true. But sloppy design, design which ignores the most basic difficulties cannot be brushed away by simply saying that "it exceeds theoretician's predictive abilitiies." That simply doesn't cut it. "Ignoring the obvious" is simply that. It's a planned process of "ignoring the obvious". One example of this that should serve as a useful case study is a recent problem which was brought to the Canadian public's attention just this week, on a program called the Fifth Estate. The CBC (Canadian Broadcasting Corporation) detailed a software code problem in one of AECL's (Atomic Energy of Canada Limited's) instruments which deliver penetrating radiation. The software which controlled the radiation dose, would periodically override the oncologist's calibration and deliver a radiation dose 100 times what was prescribed. This software "bug" literally killed wherever the machine was in use. A simple hardware solution engineered into the product as part of a redundancy check program would not only have saved many lives, but could have confirmed that there were serious code deficencies. A redundancy program which AECL did NOT have. Then again AECL did not consider that it had to mathematically prove it's code either. So I guess, they "ignored the obvious" not once, but twice. A simple lesson can be learned here, one which I believe is applicable to Java. If your parameters are going to be that you cannot trust your production code, then you MUST engineer on that basis, that the production will not be trustworthy, rather than simply crying like Chicken Little, that mission critical applications must simply "live with" engineered inferiority. Or alternatively, another lesson could be pulled out: To avoid this problem, ensure that your code is mathematically provable or utilize appropriate hardware overrides. Case study, #2: Netscape. During their code design, they assumed that all servers on a network were trustworthy and would continue to be trustworthy. They designed their product on that basis. In fact, over time the very opposite will be true. As an exploitation algorithm propogates, the significant percentage of servers which are NOT trustworthy will begin to grow exponentially. The true assumption which Netscape should have started with is a simple one, and is the only assumption that ANY production house can start with: that the network has a reliable transport mechanism, one which will route around damage. That's it. Any other assumptions are poor design and engineering and are demonstrative of a misunderstanding of the environmental conditions in which the engineered product is expected to perform. >Dr. Fred, you seem to spend a lot of engery slamming Java and HotJava. Are >you unaware that the HotJava Platform is the first generation pass at an >inline extensible GUI harness. Underline the total concept "extensible GUI >harness". This includes a series of tool functions to *help* perform secure >messeging (like those supplied iun Netscape 2.0/Java.), but because of the >enormity of the task and the number of facets on the face of this gem it >will be some time before the final versions of the first generation will be >available. I can't speak for "Dr. Fred", but I always worry when people start to refer to something as a "gem", and start talking about the "enormity of the task". Especially if an engineer starts talking in such lyrical, flowery prose. Enormous tasks always lead to complexity which can never be solved by simple linear thinking. And the engineer from Sun is right, that it will be some time before first generation products are available. (This will certainly be the case if "mathematical proofs" become mandatory as part of an ACT in Action plan. ) >No one else had been working on this piece of technology before SMCC >started their effort. From the word floating about the SMCC labs they >didn't even know what they had. > >So rather than slamming them, SMCC, or their PR folks for Well, I'd rather that marketers stick to marketing AFTER a product development cycle is completed. Generally, you would think (hopefully) that people who are technologists, just *might* have a better knowledge of what they have, (or don't have) wouldn't you? Maybe?? Or maybe not ... After all you wouldn't want some kid, some little snotty brat, some kid who started playing around well over a decade ago -- when he was in his teens -- as a projadmin on one of Honeywell's Multiplexed Information and Computing Service beasts showing you up for your temerity? Or would you cry about the "kid" slamming you? >I hope that you understand my point?. The net/net is that OLTP needs to be >scaleable to be a saleable commodity and without the ability to do >"java-ish" like local applets... There is no clean way to do this, Well if we're gonna bottom line it, and talk turkey, and leave Chicken Little back at the table, skewered as it were, I'll extend a helping hand. The net/net is really, really simple, a product that doesn't perform as advertised is not a saleable commodity. No one buys cars which don't start or cans that leak. Sure you can have a body by Pininfarina or one by Alcan but if the engineering isn't there under that beautiful skin then you don't have ANYTHING TO OFFER FOR VALUE. >As an aside - What blows my mind is the number of cycles people spend >bitching and moaning about Java itself rather than working to create a >better solution. Well. It's just not my responsibility to create a solution. And I have a tendancy not to "bitch and moan". I might be one sarcastic castrating SOB, but bitchy and moany is not something I'm routinely accused of. I simply have a reputation for a degree of frankness. Nothing personal is meant by it. I'm actually a very nice person. Truly.;-I >I just want to say "Get a clue. Moan about something that is important and >pertinent to the technologies at hand". > > >These comments are my own - Appreciated. And I mean that with sincerity that your comments are appreciated. I understand that each person here DOES express their individual opinions. Sometimes some very strong opinions. Myself included. Generally, wallflowers will not find comfort on this list. We'll recommend that those people should stick to writing browser programs. Oops, scratch that last thought ... >Sincereley, >Todd Glassey >todd(a)lgt.com Alice de 'nonymous ... ...just another one of those... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.

2 1

Re: Photuris Primality verification needed
by Hilarie Orman 17 Dec '03

17 Dec '03

> Recently, someone asked for a smaller prime of only 512-bits for speed. > This is more than enough for the strength of keys needed for DES, 3DES, > MD5 and SHA. Perhaps this would be easier to have more complete and > robust verification as well. Depending on what you think of the strength of those algorithms, the 512-bit mod p system may not be strong enough. The *strength* of 512-bit mod p DH systems is only about 56 bits. You need 1024-bit primes for a *strength* of 80 bits. In contrast, the 155-bit elliptic curve in the Photuris draft has a strength of about 76 bits.

1 0

Re: [NOISE] Re: 800_ape [FUQ Win95 List]
by Rich Graves 17 Dec '03

17 Dec '03

> On Sat, 4 Nov 1995, Rich Graves wrote: > > > I'm putting together a "Windows 95 Frequently Unanswered Questions File." This little P.S. attracted a lot of attention in private email. FYI, it's now available at: gopher://quixote.stanford.edu:70/0R1400265-1416663-/win95netbugs and in the newsgroups. It's short. Several points are of interest, if not direct relevance. Point D.8., apparent bugs in handling of longints, if confirmed, could have beaucoup crypto relevance. For the record, I hadn't noticed the acronym, but I like it. A lot. -rich

1 0

That's not what I wrote!
by tcmay＠got.net 17 Dec '03

17 Dec '03

Some of you may think this is a trivial correction, but I think it important, albeit bizarre: At 2:41 AM 11/5/95, Rich Graves wrote: >On Sat, 4 Nov 1995, Timothy C. May wrote: >> Rich'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." No, that is NOT what I wrote. It has been changed, with no indication that it is not what I wrote. If you check my original you'll find that what I wrote was: --- 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." --- I can guess why Rich "corrected" my post, but he was in error for at least two reasons. First, because he didn't indicate that he'd corrected me. Second, because my item did not need correction. I originally wrote "Chris's," referring to Chris Hibbert, and then thought about the grammatical rules about forming possessives out of words ending in "s," and so I added the alternative "(or Chris')". Perhaps a minor point, and not one I'll lose sleep over, but I think it a bad thing to _ever_ correct the words of another in quoted material without indicating so. Editors who worry about typos and misspellings in quoted material usually put a "[sic]" in the text, mainly, I think, to let themselves off the hook for letting an error through. (Though I think another reason is to show graphically the igorance [sic] of the quoted author.) This point about Rich's post should not distract from his good comments that I responded to (or the points in the post that contained this correction, points I have not yet read). --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."

1 0