December 2003 - cypherpunks-legacy

Re: Gore's "new and improved" key escrow proposal
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

Michael wrote: > >I have tried to think of a positive use for key escrow. The only thing that I >have come up with so far is kind of like having local key escrow within one >company, or something like that. Kind of like having a master key that fits >all the offices in one wing of a building, or something like that. That could >be good in some business uses, provided you could pick your own trusted master >key holder. I don't think that is what Al Gore has in mind. I think there is a use for key escow in our society. As someone else has suggested on this list, all internal communication of the government should use escowed keys. I propse us Cypherpunks as one of the escow agents. Defininity not what Gore had in mind. -- Lucky Green <shamrock(a)netcom.com> PGP public key by finger

1 0

Re:
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

Conrad wrote: >Could they write code that could fabricate notes from giberish? >What if you encrypted a love letter and they 'decrypted' a drug deal? > That would be rather easy to acomplish with a secret algorithm. Still possible, but not quite as easy with a published one. I am sure it will be done. >Also, on the national ID card issue, I was involved in bar codes >(machine readable labels) and came across really small (grain of >rice sized) transponders with ID number encoded. These could then be >machine (transducer) readable. They were glass coated and had >various industrial applications. I have since read that they have >implanted them in pets to identify them if they run away. Next step >would be implanting them in people. You would then have an absolute >way to ID people (short of surgery). > I think this is the real problem that awaits us. While I do not believe that society is quite ready for it to be broadly deployed, I think that it inevitably will happen. First to monitor conviced criminals (to make sure that rapist really stays away from schools), then children (in case they get abduced), soon afterwards everyone else. And you know what? The public will _ask_ for it. Picture of happy shopper. "Citibank transducer (TM). Now nobody can use my account without my knowledge and best of all -- I don't have to remember to bring a card. I can't understand why not everyone is doing it." Jingle. -- Lucky Green <shamrock(a)netcom.com> PGP public key by finger

1 0

Cypherpunks = soc.women.... ?
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

The Newsweek cover on sexism on the Net may have basis; there may be a need to discuss these issues; an occassional post on the subject may be useful on this list -- but 40k? Please move this to soc.women.attitudes or alt.fan.true-lies or something. Funny. Our resident editor, Perry, is usually pretty quick on the draw with scathing "what's this to do with crypto" messages. ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "Clean the air! clean the sky! wash the wind! rishab(a)dxm.ernet.in take stone from stone and wash them..." Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

Accessing the Cpunk WAIS archive
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

"Gary Jeffers" <vikram!CCGARY(a)MIZZOU1.missouri.edu> > http://pmip.maricopa.edu/crypt/cypherpunks/Cypherpunks.src > is the location of all the Cypherpunks' posts with index. I can > get to this place by placing a "www" in front of this instruction. Do an archie search for lynx or mosaic or some other decent browser. This is a WAIS indexed archive; no hyper links; you type in a keyword, and get a list of matching articles, and select one (or more) of them to look at. ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "Clean the air! clean the sky! wash the wind! rishab(a)dxm.ernet.in take stone from stone and wash them..." Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

Gore to Cantwell
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

I hope you've all seen the latest EPIC bulletin. Gore's letter to Cantwell: > "On the other hand, we agree that we need to take action this > year to ensure that over time American companies are able to include > information security features in their program in order to maintain > their international competitiveness. We can achieve this by entering > into a new phase of cooperation among government, industry > representatives and privacy advocates with a goal of trying to develop > a key escrow encryption system that will provide strong encryption, be > acceptable to computer users worldwide, and address our national ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > security needs as well. Horses have blinkers on the sides of their eyes so that they look straight. Do politicians have eyes at all? ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "Clean the air! clean the sky! wash the wind! rishab(a)dxm.ernet.in take stone from stone and wash them..." Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

2 1

Re: Voice/Fax Checks
by Hal 17 Dec '03

17 Dec '03

JWS writes: >Well here are the answers that I'm working with in my model: >First, what you set up has to work off-line. At the same time, validation, >by its very nature, is a process that can only be accomplished online. The >part of my code that I am in the middle of right now (and strugling with) >uses a distributed dynamic hashing scheme (with some attempt at periodic >space minimalization [this is what is making it tricky]) whereby information >is recorded in the public system such that if one part of a bill is used >twice, the cheat's identity is revealed. >[...] >For types of small transactions that will be executed frequently, the >best idea is to establish accounts. In my system, when ever an agent >enters somebody else's computer, it gives the local wizard (the agent >with the final say on computational cycles, storage space, and >communications) a deposit which neither the agent nor the wizard can >cash without agreement by both [do public validation and recording >but hold off on the last steps which allow the wizard to use the money]. >The money is thus recorded globally as having been spoken for. Then, for >all transactions on the local machine, the agent simply uses its local >account, just as anybody would in a much simpler bank-based protocol, >like the ones we have now. This seems like a good approach for a lot of cases. You end up having three classes of transactions: small, medium, and large, with slightly different strategies for each. For large, you do on-line checking; for medium, you detect double-spending after the fact and use crypto to find his identity; and for small you set up an account and dip into that a bit at a time. I am curious about whether you are focussing more on some size range in your plans. One problem I still see is the small transaction where you don't tend to use the same provider again and again. On the net there are a few sites (well, quite a few, I suppose) which are heavily used, but there are a lot of places I might like to just browse through. Paying a penny per site isn't going to bother me much, but if I have to set up an account for each one ahead of time I'm probably not going to bother. So I still think there are problems with the fractional-cent-per-web-site model which I have been hearing about. >I don't agree on this point. I prefer license based e-cash which is modified >on each transaction (and unfortunatelly gets slightly bigger -- the downside >of this method). If we're going to make the conversion to ecash, we might >as well make it as powerful as mathematics will allow. Is this an approach where you determine to whom you will be sending the cash, then make it into a "check" which can only be spent by that recipient? Doesn't that require the bank's (cash issuer's) help? Or is this something else? Hal

3 2

Re: Small transaction amounts
by fnerd＠smds.com 17 Dec '03

17 Dec '03

Eric speaks of the two kinds of electronic money systems-- closed ones where crypto doesn't have to be done because the system guarantees security, and open ones where crypto has to be used. > The closure, however, of these systems means that they don't scale. > That's bad, fatal, in fact. That doesn't mean that closed systems > will disappear, merely that the largest systems must be open. > > What is desirable economically is that the boundary between closed > clearance systems and open clearance systems be porous enough that the > market can find an optimal distribution between the two varieties. Right...I think. What has to scale is the "semantics of money." Within a small area ("box"), security is guaranteed by how the enclosing system works, and over a larger area it's done by crypto (*). But for the programs, the difference is transparent, except for a cost that resembles communications cost. (*) There's also an issue of, "Can that box over there guarantee me that I can run programs securely within it?" There are ways to do this with tamperproof boxes and such. Or looser ways to do it with reputations. -fnerd - - - - - - - - - - - - - - - nutritional information per serving: less than one (1) bit -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE-----

2 1

Re: Double DES calculations
by DAVESPARKS＠delphi.com 17 Dec '03

17 Dec '03

Hal Finney wrote: > I'll give you one similar example, though. I think this is the technique > used in Pollard "rho" factoring. You have an iterated series, x=f(x), and > you want to know if it has any cycles, any values which are eventually > repeated. At first glance you might think that to look for a cycle of > length N you would have to store N values of the series and check each > value for a match, taking order of N in time and space. The Pollard tech- > nique instead runs two copies of the iteration at once, one twice as fast > as the other: x=f(x) and y=f(f(y)). Each time you just compare x and y > for a match. This takes about twice as long but uses no memory. The thread was concerning the vulnerability of Double-DES with an intermediate layer of IDEA in the middle. It was proposed that if IDEA could ultimately be TRIVIALLy cracked, then DES-IDEA-DES was no stronger than Double-DES. At that point I did some "back of the envelope" calculations on the cost of breaking Double-DES using a MITM attack. I'm not sure how "cycles" fit into DES. The brute-force technique I was hypothesizing involved trying all possible keys on the encrypt and decrypt sides, storing them the resultant 64 bit blocks (all 2^60 bytes of them), then comparing them. How would Pollard rho speed that up? /--------------+------------------------------------\ | | Internet: davesparks(a)delphi.com | | Dave Sparks | Fidonet: Dave Sparks @ 1:207/212 | | | BBS: (909) 353-9821 - 14.4K | \--------------+------------------------------------/

2 1

Re: Card Playing Protocol? (fwd)
by Arsen Ray Arachelian 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Sat, 23 Jul 1994 01:19:02 -0400 (GMT+4:00) From: Arsen Ray Arachelian <rarachel(a)prism.poly.edu> To: "Roy M. Silvernail" <roy(a)sendai.cybrspc.mn.org> Subject: Re: Card Playing Protocol? On Wed, 20 Jul 1994, Roy M. Silvernail wrote: > The effect could be different. I use i there because I want to traverse > the deck from one end to the other, and exchange each card with a > randomly selected card from the unprocessed remainder. This algorithm > goes back to my 8-bit days, when speed was everything. Although some > cards might be handled twice (probably about 35%, but I haven't done the > math), each position in the deck is filled only once (except the last > one, which is forced from the other 53). > > A card in position X will, in its turn, be moved to a random position > between itself and one end of the deck. But that card is also subject > to being 'picked from behind' when an earlier card is exchanged. So any > given card may end up on either side of its beginning location. > > But I think there's something to what you're saying. I can't articulate > it, but I get a sense that the single-pass algorithm might have a > definable shape The issue is this: at the start a card has a 1/54 chance of being swapped with >ANY< card. The second card has a chance of 1/53 of being swapped with >ANY< card, the third, a chance of 1/52... the 50th card has a chance of 1/4, ... the 53rd card has a 1/2 chance of being swaped with the last card or remains in its place (swapped with itself.) So what I'm getting at is that the cards at one end of the deck have more "mobility" than the cards in the other end of the deck. The 1st cards have a more spread out distribution so they have LESS of a chance of being swapped out with the cards at the back of the deck. The cards at the back of the deck have a very tight space from which to be swapped. Therein lies the problem of sorting. As for SPEED, in the eight bit days, it would be faster to do a MOD with a CONSTANT number than with a variable. Why? Because the compiler can find ways of optimizing the MOD via right shifts and substractions rather than using repeated substraction alone. There was some challenge somewhere to come up with ways of dividing numbers via shifting and substraction some time ago. I'm sure the division for 54 is faster than a general integer divide by substraction. It's hard to figure out how to divide by 54 via shifting, however, it would do wonders for an eight bit machine. These days, some machines have integer/floating division right in the CPU that's just as fast or almost as fast. With FPU's, even faster than shifting. :-) Let's see... how do I break 54 down.... hmmm.. Okay, if we trash the jokers it becomes easier: 52/4 == 52>>2. This equals 13. Now 13 being a prime can't be divided... I guess this is one way of looking at the card value and stripping off the suite. However, having divided by 4, you saved yourself four times the work already. So you take your picked card C and substract C>>2 from it. If the result is positive, you've got a remainder to a division by 4. You then substract 13 until you would get a negative value if you did one more substraction. The left over value is the mod 54 (I think. Someone correct me if I'm wrong.) Anyhow, this is moot as you don't need to do this by hand anymore anyway.. :-) Besides, if you want to cheat a bit, you can always take lrand() &0x0000003F which would give you a range from 0 to 63, and if you should get a value larger than 53, you substract 54 from it. :-) Since all you want is a random number from 0 to 53, it doesn't much matter. I guarantee that this is faster than division on most of the common machines anyway. :-) > An interesting thought. Guessing a card's location is pretty tough, > though. I was thinking more of seasoned players noticing the absence of > patterns they had become accustomed to. I know I saw some definite > trends when I was an avid Cribbage player. Yes, but an AI could also be trained with these patterns. A neural network attached to a tracking engine that keeps track of his hand and guesses at his opponents hand and the "odds" of what cards can come up next against the odds of what he needs to win with isn't easy, but if done right, it can prove a formidable opponent for the beginer poker player. :-) It would be matched by seasoned players undoubtedly. However, what I'm getting to here is an automated digital cash paying/payed casio dealer. That is you could set up a telnet site where others can gamble against your computer. (I'll leave the legalities of this to others :-) If this machine is done the right way, even with mental poker and even if it can't cheat you, it's still a very good card shark. You could charge say, half a ghostmark or whatever per 10 games just to play, plus a minimum bet of one ghostmark per hand with doubling/raising/etc being allowed. Hell, if you really want to get sick, you can have the AI keep databases of the player's past patterns and how he ticks. Unless players use random anonymous packet bouncers, such AI's could be properly used to run a real cypherspace <g> casino. I'm sure if we look up some mobsters and give them this idea they'd be happy to implement it once digital cash appears in wide use. Of course we're talking about ten years in the future, or never if digi cash never makes it... Don't however think that this can't be done. There are chess games that "think" ahead. If programmed with the right set of fuzzy rules and given extensive databases as to the opponents past moves/prefrences/bluffs/etc, such an AI would be a great card shark. Of course our player may decide to write a better auto-player and have it play against another AI. :-) But hey, if we're going to have smart agents, their owners can be "backers" as there are for real gamblers out there already. :-) > In poker, each hand gets a fresh shuffle. Blackjack will exhaust the > deck to a certain point and then shuffle. Depending on the house, Yep.. the reason I asked was because in high school we played by almost no rules. We'd have games where the "odd" numbered cards were wild, picture cards wild, etc.... shit like that was common place... I guess it's bastardisation, but hey, it was fun and not for money. And we didn't reshuffle often. BTW: Idea to prevent dealer cheating while shuffling the deck: Alice Builds the deck from Ace of Spades to King o'Diamonds, encrypts it, shuffles it herself, passes it to Bob, who shuffles it again, and encrypts it, then passes it to Alice who picks her hand, etc. If the cards are shuffled between every hands, this would prevent an AI from keeping tack of the odds of unplayed cards.

1 0

900 Mhz. cordless phone with encryption
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

Can anyone recommend a good 900 Mhz. cordless phone with some sort of voice encryption or scrambling? My most important objective is maximum range from the base unit, but I'd also like some privacy, too. Thanks.

1 0