December 2003 - cypherpunks-legacy

Re: ecash remailer
by Bill Stewart 17 Dec '03

17 Dec '03

At 01:20 PM 11/1/95 -0500, Michael Froomkin <froomkin(a)law.miami.edu> wrote: >I thought a property of Chaumian DigiCash was that a coin *had* to go back >to the bank before it could be spent again. No. The basic Chaum Digicash method looks like this: 1) Alice creates a number of a recognizable form (Chaum's 1985 CACM paper uses n1n2n3...n64n1n2n3....n64, i.e. a 64-bit number concatenated with itself). 2) Alice blinds the number and sends it to the bank (along with some request for withdrawing money from her account or payment in other coin or whatever.) 3) The bank signs the number and sends it back. 4) Alice unblinds the coin; now it's good, recognizably signed, and untraceable. 5a) Alice gives the coin to Bob, who deposits it; the bank records the coin number, and in case of double-spending, the first person to the bank wins. This is useful for on-line transactions, or off-line where everyone trusts each other. OR 5b) Alice gives the coin to Bob using a complicated cut&choose protocol that doesn't give away her identity if it's only used once, but if she also gives the same coin to Carol with the same protocol, Bob and Carol can identify Alice with probability 1 - 1/2**n, for some adequately large n. This is more work, but you can use it for off-line transactions where you don't trust Alice not to double-spend. The protocol doesn't say what to do to Alice if you catch her cheating; depending on the environment you can debit her account or sue her etc. 6) Bob now has a number, signed by the Bank of Foo, which he can either give to them to deposit or get cash or use for highway toll (if Foo is really the highway company) or give to somebody else to spend (which is a little messy in the cut&choose method.) >Logically, I can see at least four possibilities: >1) payee data is encoded onto the coin at time of payment, making it >impossible for Carol to bank the coin. I see no evidence of this in the >docs at the Digicash site, but I just rechecked quickly and may have >missed it. The basic protocol doesn't say anything about what a valid coin looks like; you could use the example in Chaum's paper or a long string followed by a checksum or whatever. You _could_ put the payee's name account number in the string as the 64-bit "random" number, or even put both payer and payee. The bank could insist on that sort of thing if they wanted. If I remember right, the version in the Digicash trial left you the choice of filling in a specific payee or using "@" for bearer-payable coins. >2) No payee data as such is encoded on the coin but it is marked "spent" >to prevent multiple uses by payee to the detriment of payor. The bank marks the coin spent upon deposit. >3) the Digicash software only allows you to send a "spent" coin to the >bank. You have to hack the software to send the coin to Carol (do you >have to break your own key?). I don't know if their merchant-client software lets you do this or not, but it's just a matter of implementation, not protocol. >4) nothing in the DigiCash software or protocol prevents you from sending >a coin to Carol so long as you trust Carol not to get you in trouble by >misusing the coin in some way. That's why Chaum is interested in >hardware based agents that would keep you from respending coins you receive. Your problem isn't trusting Carol not to get you in trouble, it's trusting Alice not to spend the coin again. Hardware-based agents are interesting because they make it easier to enforce double-spending prevention in off-line systems, and to offer better anonymity because you've got more trust that the person didn't double-spend. Stefan Brands has done a lot of work on this. In on-line systems you can check whether a coin's been spent already by depositing it - the problem is that on-line systems aren't always convenient for many applications (e.g. newspaper machines), and the costs of communication for an on-line system may be higher than the cost of a sufficiently smart smart-card. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

5 5

PROTECT YOUR COMPUTER
by otasco＠ix7.ix.netcom.com 17 Dec '03

17 Dec '03

NU-DAWN The original use for this product was with the United States Military for the cleaning and protecting of the Windows, cockpits,& Jet Fighter Helmets, as well as many other uses in the Avionics industry. The cost of the product was to expensive for the average consumer so it was never retailed, Until 1996 when one of our employees came up with an alternative for one of the Main ingredients. NU-DAWN is now available to the consumer,so you may have the same cleaning and protecting Qualities The United States MILITARY has Used to Clean & protect 50- 100 Million dollar Aircraft. NU-DAWN actually seals the pores of the plastic. It makes small scratches less visible, leaving a surface that is fresh, Lustrous and protected. Nu-Dawn dries perfectly, no smears, no scratches, no smudges and no oily, tacky or sticky residue. Best of all you can apply it in seconds in one simple step. For a limited time we are offering Nu-dawn to you, so we may obtain testimonials before bringing it to national RETAILERS. The price of Nu-dawn has not yet been determined, but for this test market we would like to offer it to you for a Price of only $ 4.95 For 1 Pint. This is a fraction of what we will be selling this in the retail market but, WE NEED YOUR TESTIMONIALS FOR OUR NATIONAL ADVERTISING CAMPAIGN. Due to the price, LIMIT OF TWO PER CUSTOMER 100% MONEY BACK GUARANTEE IF YOU ARE NOT COMPLETLY SATISFIED. ORDER 2 PINTS FREE SHIPPING & HANDLING To order please send a check or Money order along with $ 1.50 S&H your name and address: to: OTASCO P.O. BOX 10447 GLENDALE, CA 91209 All orders are shipped within 2 days from placement of order. We would like to hear your comments and suggestions, Best of all any NEW uses that you come up with for NU-DAWN. CUSTOMER SERVICE 1-800-645-4871 SUGGESTED USES FOR NU-DAWN PLASTIC POLISH * Plastic Storm Windows & Skylights * Acrylic Aquariums * Boat Windows & Fiberglass * Office Furniture * Auto Interiors, Gauges, Chrome, & Acrylic * Telephones, Pagers * Collapsible Windows on Convertibles & Sport Utility Vehicles * Arcrylic Trophies & Awards *Motorcycle Windscreens, Visors, Fairings & Helmets * Plastic Display Cases * Snowmobile Windsheilds, Helmets, & Hoods * Gauges & Insrument * Golf Clubs * Turntable Dust Covers, Stereo Faceplates * Compact Discs, Video Laser Discs, & CD ROM'S * Acrylic Hot Tubs & Spas * Safty Shields *Arcrylic, Fiberglass or Cultured Marble Tubs, * Shower Curtains * Microwave Oven Doors, Decorator Acrylic Refrigerator Panels * Inline Skates, Skateboards, & Sporting Goods

1 0

Hit-and-Run Anonymous Posts (Re: "Dr." Fred)
by tcmay＠got.net 17 Dec '03

17 Dec '03

Before someone corrects me: I wrote: "Exceptions are the cases when an anonymous source has something "sensitive" to contribute, such as the release of the putative MD4 code, and the like." MD or RC4, I forget which it was. My point is that anonymity has been used to post stuff like this (putatively), and that this is a "good" use of anonymity. Good in the sense of being non-flamish, non-infantile. (Not everyone thinks using anonymous posts to "liberate" intellectual property is a "good" thing, but then I'm sure a lot of people don't think it's good that the secrets of how to fix plumbing are written up in books for all to 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

RE: The great GAK crack (making GAK economically impossible) (fwd)
by Fisher Mark 17 Dec '03

17 Dec '03

> I believe that any denial-of-service attack will simply drive up the costs >of licensing encryption programs and keys to the point that only >corporations will be able to afford to release encryption products and >purchase keys (in bulk). Remember, we have to pay them for the privelidge >(not right) of communicating "securely". If domestic GAK is mandated, my recommendation to my employer will be to not transmit anything via the Internet that we wouldn't want on the cover of The New York Times (or EE Times). As a U.S. subsidiary of a foreign corporation, I would not be surprised if our communications were decrypted and the contents passed along to our U.S. competitors if domestic GAK is mandated. (Can you say, "industrial espionage"? I knew you could.) ========================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm(a)indy.tce.com Indianapolis, IN "Their walls are built of cannon balls, their motto is 'Don't Tread on Me'"

2 1

Re: IBM's Microkernal
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Responding to msg by perry(a)piermont.com ("Perry E. Metzger") on Wed, 01 Nov 11:51 AM >Why is this being sent to cypherpunks? Its totally >irrelevant. It's related to IBM's work on machine/code interface security, encryption and authentication capabilities. Cryptographers may want to examine how these work in Microkernal. If IBM will allow access to the features. And it's related to parallel alarms sounded on cypherpunks about the impossibility of any durable security which does not anticipate ever-changing attacks devised by authors of competing products and services. Finally, not your hat size, to be sure, it's related to the vanity of computer security consultants who dismiss unknown competition at the peril of their credibility. "The free market is a terror for tortured souls." Anonymous.

2 1

!!! DEATH THREAT !!!
by HugeCajones Remailer 17 Dec '03

17 Dec '03

You should be careful before you do foolish things like making a death threat because it can have really bad results. It can make people really nervous and think maybe they should get you first. Sometimes they hire other people to get you before you get themreally bad people sometimes. Sometimes even bad people who act like they are good people and fool everyone until they kill you. Which brings me to the point I am trying to make: You should not try to kill the Constitution any more because there is not enough left to make people safe and they might get really nervous and think maybe they should get you firstor even after. For revenge. People like the Constitution a lot and if you are making a death threat against it then it is like saying your going to kill someone elses friend or family and everyone knows that they will kill you because they are domestic and not a stranger. Or is it that they are stranger and not domesticated? Never mind. You know what I mean. Especially if you try to make it so that they cannot put aluminum foil hats on their thoughts and their words and their writing. Then they get really, really, nervous and maybe start thinking that they have to kill everybody because they are not safe from anybody. You should be careful if you find yourself walking next to someone whistling that Crosby Stills & Nash song "If you cant kill the one you lovethen kill the one youre with." (ç Thats a joke but it would be really funny if you took it serious and whacked someone out for whistling it anyway.) (Its not like they have a Constitutional right to whistle it or anything....hee, hee.) You should be careful before you vote to kill the Constitution and look under all your chairs and stuff, just in case. You should maybe look in your conscience too and see if you are not a bad person maybe. You should also maybe look in a mirror and make sure you are not cross eyed and that there is nobody beside you whistling that song "If looks could killthen you would only be hurting yourself."(<== that's a joke.) Even if you do think you can kill the Constitution and still have all of the people believe you are not a bad person then you should at least try not to let really stupid people who you work with say things like "I am too stupid to learn about this stuff so I am going to let the guys who want to make aluminum foil hats illegal and put everyone in jail decide how I vote to kill the Constitution." The one those guys who always say "Nuke DC" call Swinestein said that and it made everyone think you are all that stupid and going to let people with guns who kill women and children make your votes for you. Then even more of them say "Nuke DC" especially when they remember how bad the guys with the guns that you are letting vote for you fucked their friend (sorry but thats what they did) for making a stink with the IRS. That is really all I am trying to say. Is that you should be careful that you dont kill so much of the Constitution and let the guys with the guns screw so many people that nobody feels safe from them anymore because they wont just get nervous about them they will get nervous about you too because you promised to protect them and didnt. Just try to remember that it never ends. If you take away some of the guns from people then you have to take away all the guns or you are in big trouble. If you take away some of the Constitution from people then you have to take away all of the Constitution or you are in big trouble. Even if you think you took away all of the things that people can use to be safe and free then they will make morelike Doritos. If you try to kill them with bullshit then they will try to kill you with their own brand of fertilizer. If you take away their aluminum foil hats then they will make hats out of paper and call them Forever Young. Killing the Constitution is a lot like killing DCif your going to do it then you might as well do it right and do it all at once. Guys with guns who want to kill Freeh-dumb know that and so do guys with nukes who are Freeh-dumb fighters. (My uncle made up a new word about himhe said he "testiLies to Congress.") Dont be a stranger, APlayerToBeNamedLater p.s - If you see Declan McCullagh getting in his car and driving like hell away from the city then you should get in your car and do the same thing. You dont need to pack a suitcase because I think if he does that then there is already one packed. (Thats what the guys with guns told you in your secret meetings so you will kill the Constitution for them isnt it?) p.p.s.- If you hear someone say "President Freeh" then do not wait for Declan just get the hell out of there real fast anyway. You can come to my place if you want and help me send out secret aluminum foil hats. (Bring a whoopee cushion and we will make little funny booms instead of big scary ones. We are a little more laid back out here in the country than you guys in the big city.)

1 0

Re: Keyed-MD5, and HTTP-NG
by baldwin 17 Dec '03

17 Dec '03

Perry, I wish that the field of cryptography was as well advanced as the field of Bridge Building. A modern Bridge Builder can design a bridge that is easy to construct and will in fact last for 100 years. Unfortunately, modern Cryptography is like Bridge Building in the late 1800s. Back then, it was possible to build bridges that did last for 100 years but lots of cities refused to pay the extra costs in materials, labor and time to make a solid bridge, and as a result the bridges did not last. To make it worse, there was no systematic teaching of the best practices, so often no one would realize that they had build and/or bought a weak bridge until the day that it fell apart. The sad result of the state of the art in Cryptography is that we end up with situations like the one you described where it takes months to get agreement among Cryptographers and then it turns out that one of the other choices would have been better. Not surprisingly, the other choices often run slower than the initial choice. However, there is little guarantee that the second choice will resist all new attacks. One of the reasons that the IPsec authenticator was analyzed was that it had been chosen as the IPsec authenticator. As soon as a large organization picks a new authenticator, the researchers will try their hand on breaking that one. In the field of Cryptographic Engineering, we just don't have a well tested construct for authenticators. If the IPsec group was run by scientists instead of engineers, then they would consider cryptographic constructs that have "provable" security properties (e.g., faking this authenticator is as hard as factoring a Blum integer (a composite number with two strong primes)). The downside of having this kind of provable security is that the packet processing time would be enormous. You would loose all the benefits of a T1 connection to the Internet in order to get provable security on your authenticator or encryptor. Speaking for myself, I am glad that the IETF is run by engineers. The vitriol you spewed is quite justified. People at RSA and IBM both agreed that the IPsec authenticator would resist all known attacks. In fact, a fully conforment IPsec implementation will still resist the new attack because IPsec requires that the all keys be changed every 2**32 packets. However, this new attack makes Cryptographers nervous. Perhaps it could be extended to work with only 2**40 chosen packets in which case there is a noticeable chance of it succeeding with only 2**32 packets. Only further research will tell. Currently, the only way to get the MD5 key is to feed in 2**60 chosen messages of various lengths. Of course, this is another good reason to use different keys for the MD5 authenticator and packet encryption. Wisely, IPsec requires different keys for the authenticator and the encryptor. I also understand your being upset about not hearing about this attack the moment it was published. Actually, as soon as RSA Labs confirmed the weakness we did call some of the editors of the IPsec specifications to let them know about it. The consensus was that this was not a show stopper. The IPsec protocols could be rolled out as is. Later, once a better authenticator had been developed and tested, it could be substituted for the existing one. One of the excellent features of the IPsec specification is that new algorithms can be substituted easily (modulo a "small matter of programming"). Perhaps your main complaint is that it took time for the attack to be confirmed by other researchers before the issue was brought to the IPsec authors. That is another effect of the current state of the art in Cryptography, and an effect of the normal academic process. It takes time to understand and confirm a weakness, and it is necessary to confirm weaknesses (researchers make mistakes in designing attacks just like they make mistakes in designing ciphers). That's the way things are in "cryptography today". I guess my conclusion is to say "Sorry". Several professional cryptographers gave it their best shot, and the authenticator turned out to be somewhat weaker than expected. --Bob ______________________________ Reply Separator _________________________________ Subject: Re: Keyed-MD5, and HTTP-NG Author: perry(a)piermont.com at INTERNET Date: 10/31/95 5:25 PM "baldwin" writes: > Simon, > There are a few different ways to add key material to MD5 to > make it suitable as a shared-secret authenticator function. Some of these > are less resistant to attacks than others. For example, the keyed MD5 > mechanism that is part of the current IPsec specifications can be > attacked using 2**60 chosen messages. Fortunately, the IPsec specs > also require that the shared MD5 key be changed every 2**32 messages, > so this attack is unlikely to succeed. Specifically, IPsec uses > MD5 as follows: X = MD5(key | keypad | Message), where "|" means > concatenation and the "keypad" pads out the key to 512 bits. > Basically, this function is the same as standard MD5 with a > different initialization vector for the compression operation > on the first block of the message. > RSA Labs recommends that a people use an authenticator like > X = MD5(key1, MD5(key2, Message)). This resists the chosen plaintext > attacks that were published at the crypto conference in Spring 1995. Pardon me. The amount of vitriol I am going to spew is probably difficult for people to understand because most folks around here weren't following the keyed MD5 discussions during the IPSEC work and have no idea of the sort of crap the professional cryptographic community put us through. We spent months, and months, and months, and months, getting advice from every cryptographer on the planet. Every conceivable combination of pads, multiple keys, keys before the text, after, before and after, etc., was discussed over and over and over again. Finally, the folks at RSA and IBM both agreed that Hugo's scheme, the one we were putting in to place, was the best possible one. (Thats the one with the padded key.) What the flying hell are you doing telling us now, and indeed not even telling the IPSEC community but instead mumbling on cypherpunks, that you guys were in possession of information BEFORE the entire discussion in midsummer that indicated that your own advice was wrong? Perry

2 1

Video as a source of randomness
by Andrew D. Isaacson 17 Dec '03

17 Dec '03

A thought just occurred to me... 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. Even if the entropy in a video signal is low, the high bandwidth would seem to make up for it. Struggling to keep my head above the crypto tide, andy -- Andrew Isaacson <adisaacs(a)mtu.edu> finger adisaacs(a)colossus.csl.mtu.edu Freshman/Comp Sci @ Michigan Technological University for PGP public key ========================================================================== "Hi, I'm, I'm, I'm... you'll have to forgive me, I'm terrible with names."

1 0

Re: Emphasizing a point by Donald Eastlake re key recovery
by Carl Ellison 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 09:34 AM 9/23/97 +0100, Ross Anderson wrote: >There is also the point that the vast majority of encryption keys are >actually used for authentication rather than confidentiality. The keys >that encrypt your bank card PIN en route from the ATM to the bank, the >keys in your satellite TV decoder, the keys in your gas meter and your >postal meter - in fact the majority of all DES keys in use - are about >authentication. In theory most of them could be replaced by digital >signature mechanisms but given the size of the installed base, it >won't happen anytime soon. For what it's worth, I once got an opinion from NSA's export control office that I could use any kind of crypto I wanted (e.g., even triple-DES) if all I'm doing is protecting a channel carrying a password (like the PIN), because that's an authentication function and therefore to be encouraged. I didn't get this in writing, however, so I'd have to go for it again. - Carl -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQCVAwUBNCkgkFQXJENzYr45AQF9EAP+Lx54AGJVvr9nOgGEaFYgMyTYFsalnPV9 3ZhqCIc6DDbjGBPf7r20SYUwz+3mhLeGLjlHleltXoT/coAChL/vSnqL0Q9/gpRI w11Sg32vFi/6Fr8fNWgEcMtmuIIZS/QSRt3hj8p0cc6UN2bjWevD97/brWhVjWYl hNdlUrgPpHw= =l1tu -----END PGP SIGNATURE----- +------------------------------------------------------------------+ |Carl M. Ellison cme(a)cybercash.com http://www.clark.net/pub/cme | |CyberCash, Inc. http://www.cybercash.com/ | |207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 | |Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 | +------------------------------------------------------------------+

1 0

Re: Win95 password caching
by llurch＠networking.stanford.edu 17 Dec '03

17 Dec '03

(A copy of this message has also been posted to the following newsgroups: csu.windows95, comp.os.ms-windows.win95.misc,comp.os.ms-windows.win95.setup,comp.security.misc,alt.security,comp.os.ms-windows.networking.misc,comp.os.ms-windows.networking.windows,comp.os.ms-windows.nt.admin.networking) [A little more context and Message-ID added from the original post; cross-posted to nt.admin because it will affect some of you, followups out] In article <4791l0$4n14(a)holly.ACNS.ColoState.EDU>, unicorn(a)holly.ACNS.ColoState.EDU (Scott McCormack) wrote: > In article <478rbq$o31(a)yuma.ACNS.ColoState.EDU>, > Jim Carlson (jimc(a)cnr.colostate.edu) wrote: > : Does anyone know how to stop Win95 from caching the windows password? > : We are thinking of using Win95 as the client for a student lab and > : need to find a way to stop it from caching passwords. As it is, when > : you log into a machine for the first time it creates a .pwl file in > : your windows directory for each person who logs into windows. This > : is not acceptible for a lab situation. > : > : I can turn this off in WfWG by placing the line "passwordcachine=no" > : in the system.ini under [NETWORK], but this does not work in Win95. > : > : I am running MS networking in Win95, so when you first log into, > : windows it asks you to log into the MS Network. It then comes up with > : a second box asking you to enter your Win95 password. You can enter > : a blank password (""), but it still creates a .pwl file and places a > : line in win.ini. > > Change the password for the login (or when you first login) to a blank > line (ie don't enter a password) and you'll never see that login prompt > again. :) This was not the question. He wants to prevent local Windows passwords from being created for network-only users. This is a serious security issue, because if a user enters her real network password for the Windows password, and someone else later picks up the .PWL files, which are not encrypted in a particularly secure way, then someone can get unauthorized access to the network as the previous user(s). We believe we have found answers in the Registry and in POLEDIT. We've also turned up another related security bug. When it's confirmed, we'll post. In the mean time, you can read the last couple messages archived at gopher://quixote.stanford.edu/1m/win95netbugs. -rich llurch(a)networking.stanford.edu moderator of the win95netbugs list http://www-leland.stanford.edu/~llurch/win95netbugs/faq.html

2 1