Re: DNA of relative indicts man, cuckolding ignored
Major Variola (ret.) wrote: > Slashdot pointed to this story of a man indicted via > his *relative's* DNA sample: > > http://news.bbc.co.uk/2/hi/uk_news/wales/3044282.stm > > But an interesting, unmentioned issue is this: in population > DNA surveys you find that a lot of purported fathers *aren't*. > So the possibility of indicting a cuckolded man on the basis > of nominal (only) relatives is quite real. Only he was convicted because he confessed. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Criminalizing crypto criticism
Alan wrote: > > On Friday 27 July 2001 11:13, Steven M. Bellovin wrote: > > In message <[EMAIL PROTECTED]>, Declan McCullagh writes: > > >One of those -- and you can thank groups like ACM for this, if my > > >legislative memory is correct -- explicitly permits encryption > > >research. You can argue fairly persuasively that it's not broad > > >enough, and certainly 2600 found in the DeCSS case that the judge > > >wasn't convinced by their arguments, but at least it's a shield of > > >sorts. See below. > > > > It's certainly not broad enough -- it protects "encryption" research, > > and the definition of "encryption" in the law is meant to cover just > > that, not "cryptography". And the good-faith effort to get permission > > is really an invitation to harrassment, since you don't have to > > actually get permission, merely seek it. > > Even worse is if the "encryption" is in bad faith to begin with. (i.e. They > know it is broken and/or worthless, but don't want the general public to find > out.) > > Imagine some of the usual snake-oil cryto-schemes applied to copyrighted > material. Then imagine that they use the same bunch of lawyers as the > Scientologists. > > This could work out to be a great money-making scam! Invent a bogus copy > protection scheme. Con a bunch of suckers to buy it for their products. Sue > anyone who breaks it or tries to expose you as a fraud for damages. > > I mean if they can go after people for breaking things that use ROT-13 > (eBooks) and 22 bit encryption (or whatever CSS actually uses), then you can > go after just about anyone who threatens your business model. > > I guess we *do* have the best government money can buy. We just were not the > ones writing the checks... The fundamental problem is that crypto for rights protection doesn't work in general, and certainly can't work where the decryption technology has to be in the hands of the person you are trying to protect it from. Criticising the DMCA because it protects weak crypto seems to me to be the wrong angle - it doesn't matter whether the crypto is weak or strong, it can be broken. The important thing is that we should continue to be able to demonstrate that fact. Rights management can only be done by legal and social means, not technological ones. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Non-Repudiation in the Digital Environment (was Re: First Monday August 2000)
Bram Cohen wrote: > > On Sat, 7 Oct 2000, Ben Laurie wrote: > > > > Since we're in hair-splitting mode, I should point out that "prevents > > the denial of an act" is not equivalent to a "negation that something is > > false". Of course, logically, it comes to the same thing, but then, so > > does "assertion that something is true". > > Of course, the idea that you could 'prevent the denial of an act' is > completely wrong. The explanation "All this fancy-schmancy crypto stuff is > bullshit" is pretty much universally applicable. I have to agree that actually doing stuff with crypto is substantially more useful (and interesting) than trying to prove things with it. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: [camram-spam] Re: Microsoft publicly announces Penny Black PoW postage project
Richard Clayton wrote: and in these schemes, where does our esteemed moderator get _his_ stamps from ? remember that not all bulk email is spam by any means... or do we end up with whitelists all over the place and the focus of attacks moves to the ingress to the mailing lists :( He uses the stamp that you generated. Each subscruber adds [EMAIL PROTECTED] as an address they receive mail at. Done. Trivial. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: "If you didn't pay for it, you've stolen it!"
Sunder wrote: > To add to this: > > There is no law stating that I cannot take my books and read them > backwards, skip every other word, read the odd chapters in reverse and the > even chapters forward, or try to "decode" the book by translating it to > another language, ask someone with better eyes than mine to read it to me, > or chose to wear green tinted lenses while reading it, read it to kids or > the elderly, lend it - or rent it to friends, use it as a paperweight, ^^^ this, I believe, there are laws about. At least here. > drop it on the floor, et cetera. I can take it with me to other countries > and read it there, as well etc. Once I bought it, it's mine. Again, only within the permitted uses. For example, copying it and selling copies is clearly not permitted. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Brands' private credentials
Adam Back wrote: On Mon, May 10, 2004 at 02:42:04AM +, Jason Holt wrote: Another approach to hiding membership is one of the techniques proposed for non-transferable signatures, where you use construct: RSA-sig_A(x),RSA-sig_B(y) and verification is x xor y = hash(message). Where the sender is proving he is one of A and B without revealing which one. (One of the values is an existential forgery, where you choose a z value first, raise it to the power e, and claim z is a signature on x= z^e mod n; then you use private key for B (or A) to compute the real signature on the xor of that and the hash of the message). You can extend it to moer than two potential signers if desired. There is code for this in openssl (not sure if its the same technique, its described as a ring signature). One of the more amusing aspects is it was posted anonymously and signed by a group of likely-looking candidates. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
sub
subscribe cypherpunks-moderated -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Celsius 451 -the melting point of Cat-5 Re: networktopology
Steve Furlong wrote: > A list of "address servers", using any IP address and port, would be > written up in a text or binary file. This text file would be XORd with a > couple of random 128kB pads, and then sent to a newsgroup. A client who > wished to retrieve the list would read the result pad, then fetch the > random pads from any of a bunch of "pad servers". XOR them together and > read off the list. None of the sites hosting the random pads would be > holding any "restricted" information, so there'd be no justification for > closing them down. Why bother with the pads? Just post to a newsgroup in plain, surely? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: all about transferable off-line ecash (Re: Brands off-linetech)
Anonymous wrote: > > [Copied to Adam so he doesn't have to wait for some moderator to get > off his fat ass and approve it. And BTW permission is NOT granted to > forward this or any part of it to the DBS list because Hettinga is an > asshole who kicks people off his list for spite. He can piss in his > own sandbox if he wants but we don't have to play in it.] > > Adam Back wrote: > > On Mon, Apr 08, 2002 at 04:15:09AM +0200, Anonymous wrote: > > > First, off-line coins suck, as described above. [...] > > > > Off-line coins just offer an extra optional feature for the user, any > > user who chooses can instead use them as online coins. So I would > > argue off-line coins are better than online coins. > > It's not just an extra feature; an off-line system inherently requires > users to identify themselves to the bank at withdrawal time. It cannot > allow users to anonymously exchange coins at the bank. So it has an > inherent lack of anonymity which is not present in an online system. If they withdraw blinded coins, then although they were identified they are not linked with the coins. Did I miss something? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Two ideas for random number generation: Q for Eugene
gfgs pedo wrote: > > hi, > > --- [EMAIL PROTECTED] wrote: > > On 22 Apr 2002 at 0:08, Ben Laurie wrote: > > > > Oh surely you can do better than that - making it > > hard to guess the seed > > > is also clearly a desirable property (and one that > > the square root "rng" > > > does not have). > U can choose any arbitrary seed(greater than 100 bits > as he (i forgot who) mentioned earlier.Then subject it > to the Rabin-Miller test. > Since the seed value is a very large number,it would > be impossible to determine the actual value.The > chances the intruder find the correct seed or the > prime number hence generated is practically verly low. Uhuh - and how do you choose this large seed? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: [PracticalSecurity] Anonymity - great technology but hardly used
Travis H. wrote: > Part of the problem is using a packet-switched network; if we had > circuit-based, then thwarting traffic analysis is easy; you just fill > the link with random garbage when not transmitting packets. I > considered doing this with SLIP back before broadband (back when my > friend was my ISP). There are two problems with this; one, getting > enough random data, and two, distinguishing the padding from the real > data in a computationally efficient manner on the remote side without > giving away anything to someone analyzing your traffic. I guess both > problems could be solved > by using synchronized PRNGs on both ends to generate the chaff. The > two sides getting desynchronzied would be problematic. Please CC me > with any ideas you might have on doing something like this, perhaps it > will become useful again one day. But this is trivial. Since the traffic is encrypted, you just have a bit that says "this is garbage" or "this is traffic". OTOH, this can leave you open to traffic marking attacks. George Danezis and I wrote a paper on a protocol (Minx) designed to avoid marking attacks by making all packets meaningful. You can find it here: http://www.cl.cam.ac.uk/users/gd216/minx.pdf. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Earthlink to Test Caller ID for E-Mail
Peter Gutmann wrote: Eugen Leitl <[EMAIL PROTECTED]> writes: "A way that works" would involve passphrase-locked keyrings, and forgetful MUAs (this mutt only caches the passphrase for a preset time). "A way that works *in theory* would involve ...". The chances of any vendor of mass-market software shipping an MUA where the user has to enter a password just to send mail are approximately... zero. And it doesn't even work in theory - once your PC is hacked, the passphrase would be known the first time you used it. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Remailers an unsolveable paradox?
Tyler Durden wrote: The hascash idea is OK, and obviously will work (as of now...the dividing line between human and machine is clearly not static, and smarter spam operations will start doing some segmentation analysis and then find it worthwhile to pay up). But the kind of person that may have legitimate need of a remailer may not understand and/or trust what would probably be necessary to use hashcash. And OK "that's their tough luck", but then I always feel there's safety in numbers. Since you already have to use a special client to inject email to the remailer network, they would have no need to understand hashcash. It would just happen. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Spam Spotlight on Reputation
Bill Stewart wrote: At 03:15 PM 9/6/2004, Hadmut Danisch wrote: On Mon, Sep 06, 2004 at 11:52:03AM -0600, R. A. Hettinga wrote: > > E-mail security company MX Logic Inc. will report this week that 10 percent > of all spam includes such SPF records, I have mentioned this problem more than a year ago in context of my RMX draft (SPF, CallerID and SenderID are based on RMX). Interestingly, nobody really cared about this major security problem. All RMX-derivatives block forged messages (more or less). But what happens if the attacker doesn't forge? That's a hard problem. And a problem known from the very beginning of the sender verification discussion. It's not a hard problem, just a different problem. Whitelisting your friends and aggressively filtering strangers is an obvious technique for reducing false positives without increasing false negatives, but it fails if spammers can forge identities of your friends. RMX-derivatives help this problem, and they help the joe-job problem. If a spammer wants to claim that they're the genuine spammers-are-us.biz, well, let them. I find it more annoying that there are spammers putting PGP headers in their messages, knowing that most people who use PGP assume PGP-signed mail is from somebody genuine and whitelist it. Surely you should check that: a) The signature works b) Is someone in your list of good keys before whitelisting? -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Your source code, for sale
Tyler Durden wrote: Hum. So my newbie-style question is, is there an eGold that can be verified, but not accessed, until a 'release' code is sent? proof-of-delivery protocols might help (but they're patented, as I discovered when I reinvented them a few years back). In other words, say I'm buying some hacker-ed code and pay in egold. I don't want them to be able to 'cash' the gold until I have the code. Meanwhile, they will want to see that the gold is at least "there", even if they can't cash it yet. Is there a way to send a 'release' to an eGold (or other) payment? Better yet, a double simultaneous release feature makes thing even more interesting. Simultaneous release is (provably?) impossible without a trusted third party. I think this is one of the interesting applications of capabilities. Using them, you can have a TTP who is ignorant of what is running - you and your vendor agree some code that the TTP will run, using capability based code. In your case, this code would verify the eGold payment and the code (difficult to do this part with certainty, of course) and release them when both were correct. Because of the capabilities, the TTP could run the code without fear, and you would both know that it performed the desired function, but neither of you could subvert it. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Your source code, for sale
Tyler Durden wrote: What if I block the outbound "release the money" message after I unbundle the images. Sure, I've already committed my money, but you can't get to it. In effect I've just ripped you off, because I have usable product and you don't have usable money. Well, yes, but this would be a very significant step forward from the current situation. As t-->infinity the vast majority of non-payments are going to be for the purpose of greed. If the payment is already 'gone', then you need a whole different set of motives for wanting to screw somebody even if you get nothing out of it. So in other words, you have at least solved the payment problem "to the first order", with no 3rd party. With fancier mechanisms I would think you can solve it to 2nd order too. How do you make the payment already "gone" without using a third party?
Re: Your source code, for sale
Hal Finney wrote: Ben Laurie writes: How do you make the payment already "gone" without using a third party? Of course there has to be a third party in the form of the currency issuer. If it is someone like e-gold, they could do as I suggested and add a feature where the buyer could transfer funds irrevocably into an escrow account which would be jointly controlled by the buyer and the seller. This way the payment is already "gone" from the POV of the buyer and if the seller completes the transaction, the buyer has less incentive to cheat him. In the case of an ecash mint, a simple method would be for the seller to give the buyer a proto-coin, that is, the value to be signed at the mint, but in blinded form. The buyer could take this to the mint and pay to get it signed. The resulting value is no good to the buyer because he doesn't know the blinding factors, so from his POV the money (he paid to get it signed) is already "gone". He can prove to the seller that he did it by using the Guillou-Quisquater protocol to prove in ZK that he knows the mint's signature on the value the seller gave him. The seller thereby knows that the buyer's costs are sunk, and so the seller is motivated to complete the transaction. The buyer has nothing to lose and might as well pay the seller by giving him the signed value from the mint, which the seller can unblind and (provably, verifiably) be able to deposit. Cute. You could adapt Lucre to do this. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Deniable Thumbdrive?
Tyler Durden wrote: I got a hold of a little gadget recently that is very nearly perfect for certain forms of data storage. It's called a "Thumbdrive" and I bought it online somewhere (64Meg for about $179 or so). The cool thing about this drive (small enough that it has holes for use as a keychain) is that it's got a "Public" area and a private area, and the private area is accessible (if one desires) only via the little fingerprint reader on the top of the drive. (It's also USB based, and on Windows2000 and beyond you don't need any software drivers--just plug it in to a USB port and it appears as a drive). ANyway, I was wondering. I'd really like a nice software mod of this thing so that, depending on which finger I use for verification, a different private area on the drive will open (right now several users can be assigned access by the master user to use their fingerprint for access to the single private area). Of course, there should be no indication that there even IS more than one private area. So...anyone heard of such a hack/mod, or is there a straightforward way to go about doing it oneself? Nice! Get them to cut _all_ your fingers off instead of just one. Just say no to amputationware. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Two ideas for random number generation
Tim May wrote: > > On Monday, April 22, 2002, at 11:23 PM, Joseph Ashwood wrote: > > > > From: <[EMAIL PROTECTED]> > >> If a RNG runs off Johnson noise, then the ability to predict its > >> output would imply the ability to violate the second law of > >> thermodynamics. If it runs off shot noise, then the ability to > >> predict its output would disprove quantum mechanics. > > > > Actually there are models that fit the universe that are entirely > > deterministic. > > Could you mention what they are? > > Boehm's "hidden variables" model is generally discredited (some would > say "disproved"). As I understand it, Bell's inequality definitively cannot be explained by hidden variables, hence the whole action-at-a-distance thing. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Lucky's 1024-bit post [was: RE: objectivity and factoringanalysis]
Lucky Green wrote: > > [Written originally in response to a post on Cryptography. --Lucky] > > Enzo wrote: > > Further to Lucky's comments: in the last few days I have > > discussed keysize issues with a few people on a couple of > > mailing lists, and I have encountered a hostility to large > > keysizes of which, frankly, I don't understand the reasons. > > On the client side at least, performance is not an > > issue: PGP 7.0.3 with my new 4096-bit PGP key appears to be > > as snappy as it was with 1024-bit keys, and the table at > > http://www.mccune.cc/PGPpage2.htm#Speed looks > quite > > reassuring. > > > > In particular, none of the naysayers explained me clearly why > > it should be reasonable to use 256-bit ciphers like AES with > > 1024-bit PK keypairs. > > Allow me to shed at least some light on the strange phenomenon that you > experienced for I have experienced the same phenomenon and was able to > glean at least a few of the reasons why application authors and > maintainers have proven so reluctant to increase RSA key sizes or > mandate minimum key sizes in their applications. > > 1) Very, very few applications, and no cryptographic libraries that I am > aware of, that currently employ RSA perform any kind of sanity check on > the size of the keys. The current release version of various programs > that I looked at will happily accept a 4-bit RSA client key that anyone > could factor in their head. VeriSign not too long ago signed a 384-bit > SSL server key that may readers of this list could break with the old > computers in their home. Such certificate signing practices, or their > lack thereof, are nothing short of irresponsible. OpenSSL allows you to specificy acceptable ciphersuites, and this does, in fact, consitute a check on size both on the PK and the symmetric cipher (and if it isn't working, I'd like to know!). > I have not tested the following hypothesis and am not willing to spend > the required $125 on the experiment, but I would not be in the least > surprised if many public CA's would readily sign a certificate for a > 4-bit RSA key. C.f. the "being caught with one's pants down" observation > in my previous post. If somebody want to perform this experiment, better > do it quick, since the CA vendors read this mailing list. :-) Actually, ISTR its impossible to generate a certificate request below some size in the hundreds of bits (I forget exactly what, but there's some bit of stuff that has to be asymmetrically crypted that is that long). > 2) One frequently voiced argument against increasing key sizes is the > resultant decrease in performance. Yes, it is absolutely true that > increasing the size of an RSA key leads to a decrease in performance. > However, larger keys decrease performance less than naive experiments > may seem to indicate. For many applications, generating a 2048-bit key > and comparing the performance with that of a 1024-bit key will lead to > numbers that differ widely, much more so than can be attributed to the > larger key size. > > The reason for this phenomenon is that RSA algorithm performance is > highly dependent on optimizations that are both key size and processor > specific. The same optimization strategy that will give you blazingly > fast performance with a 1024-bit key will absolute kill performance with > a 4096-bit key, for which a different optimization strategy is needed. > Similarly, optimizations are highly processor specific. An optimization > designed specifically for a Pentium III processor will run slower on a > Pentium IV than your basic Pentium optimized code would. Coo. Do you have more details on what optimisations these might be, because clearly the test: if(keysize > 1024) optimise_this_way(); else optimise_that_way(); is exceedingly cheap. And one I'd be happy to add to OpenSSL. > Some applications offer the correct optimizations for each key size. > Others just optimize for 1024-bit keys, thus leading to abysmal > performance with some larger keys. > > Example: PGP appears to offer excellent performance optimizations across > all key sizes. The performance difference between a 1024-bit RSA key and > a 4096-bit key can't be much more than a second. (I didn't directly time > this, but I can hear when the outgoing mail from my laptop hits the mail > spool on my SMTP server; the increase in lag is insignificant from a > user perspective). > > OpenSSH with 4096-bit keys on both ends on a 450 and 333 MHz machine > respectively is noticeably slower than with 1024-bit keys, perhaps by a > couple of seconds, but still well within user tolerance. I suspect > additional optimizations are possible which would decrease the lag > further. Numbers like "a couple of seconds" would kill HTTPS stone dead, of course. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woo
Re: Two ideas for random number generation
"Major Variola (ret)" wrote: > There is a fascinating demo-photograph that shows reflections off > 4 stacked steel balls is a classical fractal. "Topology in chaotic scattering" - DAVID SWEET, EDWARD OTT & JAMES A. YORKE http://www.nature.com/cgi-taf/DynaPage.taf?file=/nature/journal/v399/n6734/abs/399315a0_fs.html Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Odp: Cypherpunks Europe
Eugen Leitl wrote: > > On Mon, 29 Apr 2002, Steve Furlong wrote: > > > Blow me. > > Troll, and ye shalt be heard. > > Seriously, while the relationship between furriners and merkins has been > notoriously strained, might there not be need for a cpunx-europe@? For > regional announcements, and such. English to be preferrable mode of > communication, but occasional multilingual excursions could be perhaps > tolerated (yes, even frogspeak). > > The rationale is to mutually decouple regionally and politically local > babble. Who feels compelled to keep track of everything, can always > subscribe to a yet another list. > > What say ye, Eurotrash? Wouldn't get me anywhere, since I'd be on both lists... Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: p2p and asymmetric bandwidth (Re: Fear and Futility atCodeCon)
[EMAIL PROTECTED] wrote: > > -- > On 29 Apr 2002 at 14:58, Sampo Syreeni wrote: > > [IPv6] nicely solves the problem with NATs, true. However, most > > firewalls I know are there for security reasons. Those will > > likely be adapted to work for 6to4 as well. The transition > > period will likely see some cracks where p2p can work, but I > > suspect those will be closed in due course. > > Customers want P2P. Businesses will supply it. The reason they > are not supplying it now is that there is an IP shortage. Absolutely not so - the reason they are not supplying it now is that letting arbitrary machines inside your firewall advertise services is a fantastically huge security hole. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: convenience and advantages of cash (Re: Eyes on the Prize...notthe Millicent Ghetto)
Adam Back wrote: > The bank charges 20 GBP or more to do the same day transfer > electronically (CHAPs), where as the "no fee" option is BACs and takes > 3 working days and they keep the interest on your money while it's > moving. BTW, pedantry: they're CHAPS (Clearing House Automated Payment System) and BACS (Bank Automated Clearing System). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: trillions a day?
[EMAIL PROTECTED] wrote: > > On 14 May 2002 at 13:47, R. A. Hettinga wrote: > > > At 8:10 AM -0700 on 5/14/02, [EMAIL PROTECTED] wrote: > > > > > > > How could this possibly be true? :ast I checked, GDP for the US > > > was about 10 trillion bucks a year, the combined GDP of > > > every nation on earth per year can't be more than 100 trillion, > > > most of which doesn't involve anything crosiing a border, > > > so how can there possibly be trillions of dollars worth of > > > foreign exchange a day? > > > > > > You're confusing assets with transactions. > > > > Cheers, > > RAH > > > > > > I'm really not, I'm just wondering what the hell all these transactions > are. I understand that in principle I could convert 100 dollars > into Euros and back again 100 times to generate 10,000 dollars > worth of transactions, but why would I? If I'm under the delusion > that the dollar is overvalued, presumably somebody else must > be of the opposite opinion for a trade to take place, right? > So if I change my mind half an hour later, presumably it's > because the dollar went down, right? So the people who thought > the dollar was undervalued should be even more confident in their > opinion, I would think. > Yeah, I know, if the world worked that way stock price > graphs would look like smooth slowly varying curves instead > of spikey hairy monsters. > But still, trillions a day? it just seems incredible to me that > there should be that many transactions. Think arbitrage. Allegedly only 2% of foreign exchange transactions are actually related to anything real. The other 98% are just banks playing gambling games on the money markets. Scary, if you ask me. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: convenience and advantages of cash (Re: Eyes on the Prize...notthe Millicent Ghetto)
Adam Back wrote: > Largest thing I bought cash was 2,000 GBP for a 2nd hand car some > years ago. I did toy with trying to buy a house with paper cash to > see if it could be done, but I didn't bother in the end -- but I think > that all that would have happened is the seller's lawyer would go to > the bank and pay it in to make sure it's good. Actually, the way house buying works (generally) in the UK is that you deposit your money with _your_ solicitor, who promises the seller's solicitor that they have it, contracts are exchanged (typically by fax!) and then they settle at their convenience. Scarily insecure, technically. In fact, many years ago I had a solicitor who trusted me to such an extent that he financed a house purchase from his firm's client slush fund (i.e. he promised that he had the money even though he hadn't, and was prepared to back it from that fund). That's the kind of personal touch bits on the wire will never replace :-) Oh, incidentally, this whole process is going to become bits on the wire very shortly, I believe - one of the first high-value transactions to become so in the UK. The UK Land Registry has been all electronic for a long time, too, I'm told. But because it works we don't hear about it much. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: BBC hijacks TiVo recorders
Steve Schear wrote: > BBC hijacks TiVo recorders > But viewers in the UK were surprised this week to find that the > second episode of the little-known BBC sitcom "Dossa and Joe" had > been recorded without their knowledge and added to the system's main > menu screen. Hmmm. My Tivo didn't record it. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Palm security
Adam Shostack wrote: > I find myself storing a pile of vaugely sensitive information on my > palm. Where do I find the competent analysis of this? Ideally, I'd > like to be able to protect things that I move into a "sensitive" area > (passwords), and maybe select items in other places that I want to > encrypt. I don't really want to have to enter a password each time I > look at my schedule and todo lists. > > Someone suggested YAPS > (http://www.palmblvd.com/software/pc/Yaps-2000-11-7-palm-pc.html) are > there others I should look at? I use Keyring (http://sourceforge.net/projects/gnukeyring/), though it seems to have moved on some since I last looked... Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: CP meet at H2K2?
dmolnar wrote: > On Thu, 20 Jun 2002, Greg Newby wrote: > > >>the next couple of days. I'm thinking of a CP >>meet Saturday night July 12. Anyone else gonna be there? > > > I should be there, since I'm free and in the area. > > In a similar vein, who's going to be at DEF CON? Me :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Ross's TCPA paper
Barney Wolff wrote: > A pseudonym that I can give up at will and that can never afterwards > be traced to me is equivalent to an anonym. No, a pseudonym can be linked to stuff (such as reputation, publications, money). An anonym cannot. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Ross's TCPA paper
R. A. Hettinga wrote: > At 12:06 AM +0100 on 7/1/02, Ben Laurie wrote: >>No, a pseudonym can be linked to stuff (such as reputation, >>publications, money). An anonym cannot. > > More to the point, there is no such "thing" as an "anonym", by definition. Hmm. So present the appropriate definition? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Ross's TCPA paper
Barney Wolff wrote: > My use of "anonym" was a joke. Sorry if it was too deadpan. But > my serious point was that if a pseudonym costs nothing to get or > give up, it makes one effectively anonymous, if one so chooses. Well, yeah, I'd say that single-use pseudonyms are, in fact, the definition of anonyms. Zero cost is not required, of course, except to make anonymity, err, zero cost. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Which universe are we in?
Eric Cordian wrote: > Still, Nature abhors overcomplexification, and plain old quantum mechanics > works just fine for predicting the results of experiments. Oh yeah? So predict when this radioactive isotope will decay, if you please. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Tax consequences of becoming a US citizen
Nomen Nescio wrote: > On Tue, Jul 09, at 02:02PM, Tim May wrote: > >>>Also, a person having extensive offshore (outside the U.S.) >>>assets may well find his assets are now taxable in the U.S. >>>And for those with capital assets not taxed in their home >>>countries (e.g., Germany, Japan), this may be quite a shock. >> > > On 9 Jul 2002 at 18:40, Gabriel Rocha wrote: > >>This applies wether he is a US citizen or not, green card holder >>or not, Sealand citizen or not. Once the IRS sinkstheir claws >>into you, you're screwed. > > > Are you saying that if someone is legally resident in the US for a > while, the US IRS will attempt to get his assets all over the > world forever? I find this hard to believe. > Fascinating. Take it to taxpunks. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Virtuallizing Palladium
Nomen Nescio wrote: > Ben Laurie wrote: > >>Albion Zeglin wrote: >> >>>Similar to DeCSS, only one Palladium chip needs to be reverse engineered and >>>it's key(s) broken to virtualize the machine. >> >>If you break one machine's key: >> >>a) You won't need to virtualise it >> >>b) It won't be getting any new software licensed to it > > > This is true, if you do like DeCSS and try to publish software with the > key in it. The content consortium will put the cert for that key onto > a CRL, and the key will stop working. > > The other possibility is to simply keep the key secret and use it to strip > DRM protection from content, then release the now-free data publicly. > This will work especially well if the companies offer free downloads of > content with some kind of restrictions that you can strip off. If you > have to pay for each download before you can release it for free, then > you better be a pretty generous guy. > > Or maybe you can get paid for your efforts. This could be the true > killer app for anonymous e-cash. Heh. Cool! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Tunneling through hostile proxy
Adam Back wrote: > On Tue, Jul 23, 2002 at 06:11:04PM +, Jason Holt wrote: > >> The default behavior for an SSL proxy is to pass the encrypted bytes >>back and forth, allowing you to connect all the way to the other server. > > > This isn't just the default behavior; it's the only defined behavior > right? > > >>However, it is possible for the proxy to have its own CA which has >>been added to your browser. Then it acts as a man in the middle and >>pretends to be the remote host to you, and vice versa. In that >>case, it works as you describe, watching the data during its interim >>decryption. > > > While it's _possible_ to do this, I've never heard of a server hosted > application that advertises that it's doing this. I would think it > would be quite hard to get a CA to issue you a certificate if this is > what you intended to do with it (act as a general MITM on SSL > connections you proxy). Errr - its tricky anyway, coz the cert has to match the final destination, and, by definition almost, that can't be the proxy. I believe its pretty common for server farms to use SSL-enabled reverse proxies where the SSL terminates at the proxy. Different scenario, though. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Challenge to David Wagner on TCPA
Lucky Green wrote: > Ray wrote: > >>>From: "James A. Donald" <[EMAIL PROTECTED]> >>>Date: Tue, 30 Jul 2002 20:51:24 -0700 >> >>>On 29 Jul 2002 at 15:35, AARG! Anonymous wrote: >>> both Palladium and TCPA deny that they are designed to restrict what applications you run. The TPM FAQ at http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf reads >>> >>>They deny that intent, but physically they have that capability. >> >>To make their denial credible, they could give the owner >>access to the private key of the TPM/SCP. But somehow I >>don't think that jibes with their agenda. > > > Probably not surprisingly to anybody on this list, with the exception of > potentially Anonymous, according to the TCPA's own TPM Common Criteria > Protection Profile, the TPM prevents the owner of a TPM from exporting > the TPM's internal key. The ability of the TPM to keep the owner of a PC > from reading the private key stored in the TPM has been evaluated to E3 > (augmented). For the evaluation certificate issued by NIST, see: > > http://niap.nist.gov/cc-scheme/PPentries/CCEVS-020016-VR-TPM.pdf Obviously revealing the key would defeat any useful properties of the TPM/SCP. However, unless the machine refuses to run stuff unless signed by some other key, its a matter of choice whether you run an OS that has the aforementioned properties. Of course, its highly likely that if you want to watch products of Da Mouse on your PC, you will be obliged to choose a certain OS. In order to avoid more sinister uses, it makes sense to me to ensure that at least one free OS gets appropriate signoff (and no, that does not include a Linux port by HP). At least, it makes sense to me if I assume that the certain other OS will otherwise become dominant. Which seems likely. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Palladium: technical limits and implications
AARG!Anonymous wrote: > Adam Back writes: > >>I have one gap in the picture: >> >>In a previous message in this Peter Biddle said: >> >> >>>In Palladium, SW can actually know that it is running on a given >>>platform and not being lied to by software. [...] (Pd can always be >>>lied to by HW - we move the problem to HW, but we can't make it go >>>away completely). >> > > Obviously no application can reliably know anything if the OS is hostile. > Any application can be meddled with arbitrarily by the OS. In fact > every bit of the app can be changed so that it does something entirely > different. So in this sense it is meaningless to speak of an app that > can't be lied to by the OS. > > What Palladium can do, though, is arrange that the app can't get at > previously sealed data if the OS has meddled with it. The sealing > is done by hardware based on the app's hash. So if the OS has changed > the app per the above, it won't be able to get at old sealed data. I don't buy this: how does Palladium know what an app is without the OS' help? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: dangers of TCPA/palladium
David Wagner wrote: > Ben Laurie wrote: > >>Mike Rosing wrote: >> >>>The purpose of TCPA as spec'ed is to remove my control and >>>make the platform "trusted" to one entity. That entity has the master >>>key to the TPM. >>> >>>Now, if the spec says I can install my own key into the TPM, then yes, >>>it is a very useful tool. >> >>Although the outcome _may_ be like this, your understanding of the TPM >>is seriously flawed - it doesn't prevent your from running whatever you >>want, but what it does do is allow a remote machine to confirm what you >>have chosen to run. >> >>It helps to argue from a correct starting point. > > > I don't understand your objection. It doesn't look to me like Rosing > said anything incorrect. Did I miss something? > > It doesn't look like he ever claimed that TCPA directly prevents one from > running what you want to; rather, he claimed that its purpose (or effect) > is to reduce his control, to the benefit of others. His claims appear > to be accurate, according to the best information I've seen. The part I'm objecting to is that it makes the platform trusted to one entity. In fact, it can be trusted by any number of entities, and you (the owner of the machine) get to choose which ones. Now, it may well be that if this is allowed to proceed unchecked that in practice there's only a small number of entities there's any point in choosing, but that is a different matter. Chers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Overcoming the potential downside of TCPA
Joseph Ashwood wrote: > Lately on both of these lists there has been quite some discussion about > TCPA and Palladium, the good, the bad, the ugly, and the anonymous. :) > However there is something that is very much worth noting, at least about > TCPA. > > There is nothing stopping a virtualized version being created. > > There is nothing that stops say VMWare from synthesizing a system view that > includes a virtual TCPA component. This makes it possible to (if desired) > remove all cryptographic protection. > > Of course such a software would need to be sold as a "development tool" but > we all know what would happen. Tools like VMWare have been developed by > others, and as I recall didn't take all that long to do. As such they can be > anonymously distributed, and can almost certainly be stored entirely on a > boot CD, using the floppy drive to store the keys (although floppy drives > are no longer a "cool" thing to have in a system), boot from the CD, it runs > a small kernel that virtualizes and allows debugging of the TPM/TSS which > allows the viewing, copying and replacement of private keys on demand. > > Of course this is likely to quickly become illegal, or may already, but that > doesn't stop the possibility of creating such a system. For details on how > to create this virtualized TCPA please refer to the TCPA spec. What prevents this from being useful is the lack of an appropriate certificate for the private key in the TPM. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: TCPA/Palladium user interst vs third party interest (Re: responding to claims about TCPA)
Adam Back wrote: > The remote attesation is the feature which is in the interests of > third parties. > > I think if this feature were removed the worst of the issues the > complaints are around would go away because the remaining features > would be under the control of the user, and there would be no way for > third parties to discriminate against users who did not use them, or > configured them in given ways. > > The remaining features of note being sealing, and integrity metric > based security boot-strapping. > > However the remote attestation is clearly the feature that TCPA, and > Microsoft place most value on (it being the main feature allowing DRM, > and allowing remote influence and control to be exerted on users > configuration and software choices). > > So the remote attesation feature is useful for _servers_ that want to > convince clients of their trust-worthiness (that they won't look at > content, tamper with the algorithm, or anonymity or privacy properties > etc). So you could imagine that feature being a part of server > machines, but not part of client machines -- there already exists some > distinctions between client and server platforms -- for example high > end Intel chips with larger cache etc intended for server market by > their pricing. You could imagine the TCPA/Palladium support being > available at extra cost for this market. > > But the remaining problem is that the remote attesation is kind of > dual-use (of utility to both user desktop machines and servers). This > is because with peer-to-peer applications, user desktop machines are > also servers. > > So the issue has become entangled. > > It would be useful for individual liberties for remote-attestation > features to be widely deployed on desktop class machines to build > peer-to-peer systems and anonymity and privacy enhancing systems. > > However the remote-attestation feature is also against the users > interests because it's wide-spread deployment is the main DRM enabling > feature and general tool for remote control descrimination against > user software and configuration choices. > > I don't see any way to have the benefits without the negatives, unless > anyone has any bright ideas. The remaining questions are: > > - do the negatives out-weigh the positives (lose ability to > reverse-engineer and virtualize applications, and trade > software-hacking based BORA for hardware-hacking based ROCA); > > - are there ways to make remote-attestation not useful for DRM, > eg. limited deployment, other; > > - would the user-positive aspects of remote-attestation still be > largely available with only limited-deployment -- eg could interesting > peer-to-peer and privacy systems be built with a mixture of > remote-attestation able and non-remote-attestation able nodes. A wild thought that occurs to me is that some mileage could be had by using remotely attested servers to verify _signatures_ of untrusted peer-to-peer stuff. So, you get most of the benefits of peer-to-peer and the servers only have to do cheap, low-bandwidth stuff. I admit I haven't worked out any details of this at all! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Overcoming the potential downside of TCPA
Joseph Ashwood wrote: > - Original Message - > From: "Ben Laurie" <[EMAIL PROTECTED]> > >>Joseph Ashwood wrote: >> >>>There is nothing stopping a virtualized version being created. >> > >>What prevents this from being useful is the lack of an appropriate >>certificate for the private key in the TPM. > > > Actually that does nothing to stop it. Because of the construction of TCPA, > the private keys are registered _after_ the owner receives the computer, > this is the window of opportunity against that as well. The worst case for > cost of this is to purchase an additional motherboard (IIRC Fry's has them > as low as $50), giving the ability to present a purchase. The > virtual-private key is then created, and registered using the credentials > borrowed from the second motherboard. Since TCPA doesn't allow for direct > remote queries against the hardware, the virtual system will actually have > first shot at the incoming data. That's the worst case. The expected case; > you pay a small registration fee claiming that you "accidentally" wiped your > TCPA. The best case, you claim you "accidentally" wiped your TCPA, they > charge you nothing to remove the record of your old TCPA, and replace it > with your new (virtualized) TCPA. So at worst this will cost $50. Once > you've got a virtual setup, that virtual setup (with all its associated > purchased rights) can be replicated across an unlimited number of computers. > > The important part for this, is that TCPA has no key until it has an owner, > and the owner can wipe the TCPA at any time. From what I can tell this was > designed for resale of components, but is perfectly suitable as a point of > attack. If this is true, I'm really happy about it, and I agree it would allow virtualisation. I'm pretty sure it won't be for Palladium, but I don't know about TCPA - certainly it fits the bill for what TCPA is supposed to do. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Signing as one member of a set of keys
Anonymous wrote: > Steps to verify the "ring signature" file (note: you must have the openssl > library installed): > > > 1. Save http://www.inet-one.com/cypherpunks/dir.2002.08.05-2002.08.11/msg00221.html, > as text, to the file ringsig.c. Delete the paragraph of explanation, and/or any > HTML junk, so the file starts with: > > /* Implementation of ring signatures from > * http://theory.lcs.mit.edu/~rivest/RivestShamirTauman-HowToLeakASecret.pdf > * by Rivest, Shamir and Tauman > > and it ends with: > > lPglqmmy3p4D+psNU1rlNv6yH/L0PgcuW7taVpbopjl4HLuJdWcKHJlXish3D/jb > eoQ856fYFZ/omGiO9x1D0BsnGFLZVWob4OIZRzO/Pc49VIhFy5NsV2zuozStId89 > [...] > */ > > > 2. The "[...]" above is where a remailer caused some of the signature > to be stripped out. Replace the last few lines of ringsig.c with the > text from > http://www.inet-one.com/cypherpunks/dir.2002.08.05-2002.08.11/msg00306.html. > This has the lines from the END PGP PUBLIC KEY BLOCK line onward. > The last lines of the ringsig.c file should be: > > BjHTDH0VZeu3IxUFh37w2fIEehL8WrXvCoCMFnd1/bnn/qI/STXgg6as579/yBIJ > nJra7Ceru4q4wUssK79T6SdOM6wcvVg96ub4UOTaPO4wYhhadCbLFpl3tPfTLceb > */ > > > 3. Compile ringsig.c using the openssl library, to form an executable file > "ringsig". Try running ringsig and you will get a usage message. > > > 4. Get the two perl scripts from > http://www.inet-one.com/cypherpunks/dir.2002.08.05-2002.08.11/msg00313.html > and save them as "ringver" and "ringsign". > > > 5. Run the ringsig.c file through the "pgp" program to create a PGP key > ring file from the PGP PUBLIC KEY BLOCK data. With the command line > version of PGP 2.6.2 the command is: > > pgp -ka ringsig.c sigring.pgp > > This will also show you the set of keys, one of which made the signature. > > *** COULD SOMEONE PLEASE FOLLOW THE STEPS ABOVE AND PUT THE ringsig.c, > ringsign, ringver, AND sigring.pgp FILES ON A WEB PAGE SO THAT PEOPLE > CAN DOWNLOAD THEM WITHOUT HAVING TO GO THROUGH ALL THESE STEPS? *** Once it works, I'll happily do that, but... > 6. Finally, the verification step: run the ringver perl script, giving the > PGP key file created in step 5 as an argument, and giving it the ringsig.c > file as standard input: > > ./ringver sigring.pgp < ringsig.c > > This should print the message "Good signature". ben@scuzzy:~/tmp/multisign$ ./ringver pubring.pkr < testwhole ERROR: Bad signature (Incidentally, this was the procedure I followed in the first place, except I manually broke the file into parts, rather than using ringver). I still suggest sending the relevant file as an attachment, so it doesn't get mangled in transit. I wonder how many people are now convinced I didn't write this code? ;-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Signing as one member of a set of keys
Anonymous wrote: >>>*** COULD SOMEONE PLEASE FOLLOW THE STEPS ABOVE AND PUT THE ringsig.c, >>>ringsign, ringver, AND sigring.pgp FILES ON A WEB PAGE SO THAT PEOPLE >>>CAN DOWNLOAD THEM WITHOUT HAVING TO GO THROUGH ALL THESE STEPS? *** >> >>Once it works, I'll happily do that, but... >> >> >>>6. Finally, the verification step: run the ringver perl script, giving the >>>PGP key file created in step 5 as an argument, and giving it the ringsig.c >>>file as standard input: >>> >>>./ringver sigring.pgp < ringsig.c >>> >>>This should print the message "Good signature". >> >>ben@scuzzy:~/tmp/multisign$ ./ringver pubring.pkr < testwhole >>ERROR: Bad signature > > > Could you post the files anyway on a web page, then the author can check > them against his copies and see which are corrupted? OK. Coming soon. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Chaum's unpatented ecash scheme
Nomen Nescio wrote: > David Chaum gave a talk at the Crypto 2002 conference recently in which > he briefly presented a number of interesting ideas, including an approach > to digital cash which he himself said would "avoid the ecash patents". > > The diagram he showed was as follows: > > > Optimistic Authenticator > > z = x^s > > Payer f(m)^a z^b Bank > -> > > [f(m)^a z^b]^s > <- > >m, f(m)^s > -> > > > It's hard to figure out what this means, but it bears resemblance to a > scheme discussed on the Coderpunks list in 1999, a variant on a blinding > method developed by David Wagner. See > http://www.mail-archive.com/coderpunks@toad.com/msg02323.html for a > description, with a sketch of a proof of blindness at > http://www.mail-archive.com/coderpunks@toad.com/msg02387.html and > http://www.mail-archive.com/coderpunks@toad.com/msg02388.html. > > In Chaum's diagram it is not clear which parts of the key are private and > which public, although z is presumably public. Since the bank's action > is apparently to raise to the s power, s must be secret. That suggests > that x is public. However Chaum's system seems to require dividing by > (z^b)^s in order to unblind the value, and if s is secret, that doesn't > seem possible. > > In Wagner's scheme everything was like this except that the bank's key > would be expressed as x = z^s, again with x and z public and s secret. > f(m) would be a one-way function, which gets doubly-blinded by being > raised to the a power and multiplied by z^b, where a and b are randomly > chosen blinding factors. The bank raises this to its secret power s, > and the user unblinds to form f(m)^s. To later deposit the coin he does > as in the third step, sending m and f(m)^s to the bank. > > For the unblinding, the user can divide by (z^b)^s, which equals z^(b*s), > which equals (z^s)^b, which equals x^b. Since x is public and the user > chose b, he can unblind the value. Maybe the transcription above of the > Chaum scheme had a typo and it was actually similar to the Wagner method. Sounds like it. > > Chaum commented that the payer does not receive a signature in this > system, and that he doesn't need one because he is protected against > misbehavior by the bank. This is apparently where the scheme gets > its name. Note that the scheme as described (and corrected) is vulnerable to marking by the bank, and so is not anonymous. This is discussed and fixed in my paper on Lucre (http://anoncvs.aldigital.co.uk/lucre/theory2.pdf). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Signing as one member of a set of keys
Len Sassaman wrote: > On Sat, 17 Aug 2002, Anonymous wrote: > > >>*** COULD SOMEONE PLEASE FOLLOW THE STEPS ABOVE AND PUT THE ringsig.c, >>ringsign, ringver, AND sigring.pgp FILES ON A WEB PAGE SO THAT PEOPLE >>CAN DOWNLOAD THEM WITHOUT HAVING TO GO THROUGH ALL THESE STEPS? *** > > > The files are available at: > > http://www.abditum.com/~rabbi/ringsig/ > > Also, if you'd like to send me a more detailed blurb for the webpage, I'd > be happy to put it up. Otherwise, this will have to do. > > >>9. Please report whether you were able to succeed, and if not, which step >>failed for you. > > > I just ran into a bunch of errors when trying to compile with OpenSSL > 0.9.7beta3. I'm debugging now... There's a fixed verion on the page I just posted (admittedly against a current 0.9.7 snapshot, not beta3). http://www.alcrypto.co.uk/ringsign/ Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Signing as one member of a set of keys
Anonymous wrote: >>>*** COULD SOMEONE PLEASE FOLLOW THE STEPS ABOVE AND PUT THE ringsig.c, >>>ringsign, ringver, AND sigring.pgp FILES ON A WEB PAGE SO THAT PEOPLE >>>CAN DOWNLOAD THEM WITHOUT HAVING TO GO THROUGH ALL THESE STEPS? *** >> >>Once it works, I'll happily do that, but... >> >> >>>6. Finally, the verification step: run the ringver perl script, giving the >>>PGP key file created in step 5 as an argument, and giving it the ringsig.c >>>file as standard input: >>> >>>./ringver sigring.pgp < ringsig.c >>> >>>This should print the message "Good signature". >> >>ben@scuzzy:~/tmp/multisign$ ./ringver pubring.pkr < testwhole >>ERROR: Bad signature > > > Could you post the files anyway on a web page, then the author can check > them against his copies and see which are corrupted? http://www.alcrypto.co.uk/ringsign/ Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Signing as one member of a set of keys
Anonymous wrote: > Len Sassaman has put the ringsig program up at > >>http://www.abditum.com/~rabbi/ringsig/ > > > First, the ring signature portion has successfully been repaired from > the truncation imposed by the anon remailer in the original post. > > Second, unfortunately all of the tabs have been converted to spaces. > This will prevent the sig from verifying. > > Third, a number of the lines have been wrapped. This will also prevent > the verification from going through. The version I posted does not appear to suffer from either of these problems (but also does not verify). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: The Liberty Dollar
Steve Schear wrote: > At 03:52 PM 8/29/2002 -0500, Gary Jeffers wrote: > >>The money is backed by silver and gold and can be redeemed widely >> in America. > > > True but only fractionally (i.e., the precious metal content is only a > fraction of the face value). And this is different from the US dollar how? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Wolfram on randomness and RNGs
Eric Cordian wrote: > Steve Schear writes: > > >>Stephen Wolfram's book, "A New Kind of Science," is nothing if not >>interesting. This encyclopedia-sized volume traces how his fascination >>with cellular automata, beginning in the 1970s, led him to spend decades >>exploring the significance of complexity created from simple rules. > > > I bought a copy the day it came out. It's an interesting read, but as far > as I can tell, contains nothing of startling import. It contains not a > single proof. It merely suggests that Cellular Automata are sufficiently > rich to model any physical process, and maybe someone, someday, will use > them for that purpose. > > Then again, so are Turing Machines. Conway proved long ago that cellular automata can model Turing machines (see "Winning Ways", Berlekamp, Guy and Conway (in some order I forget) for the proof - and many other amusing distractions). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Real-world steganography
Peter Gutmann wrote: > I recently came across a real-world use of steganography which hides extra > data in the LSB of CD audio tracks to allow (according to the vendor) the > equivalent of 20-bit samples instead of 16-bit and assorted other features. > According to the vendors, "HDCD has been used in the recording of more than > 5,000 CD titles, which include more than 250 Billboard Top 200 recordings and > more than 175 GRAMMY nominations", so it's already fairly widely deployed. Yeah, right - and green felt-tip around the edges of your CD improves the sound, too. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: What email encryption is actually in use?
Lucky Green wrote: > I also agree that current MTAs' implementations of STARTTLS are only a > first step. At least in postfix, the only MTA with which I am > sufficiently familiar to form an opinion, it appears impossible to > require that certs presented by trusted parties match a particular hash > while certs presented by untrusted MTAs can present any certificate they > desire to achieve EDH-level security. This is probably a stupid question, but... why would you want to do this? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: What email encryption is actually in use?
Adam Shostack wrote: > On Wed, Oct 02, 2002 at 04:54:54PM +0100, Ben Laurie wrote: > | Lucky Green wrote: > | >I also agree that current MTAs' implementations of STARTTLS are only a > | >first step. At least in postfix, the only MTA with which I am > | >sufficiently familiar to form an opinion, it appears impossible to > | >require that certs presented by trusted parties match a particular hash > | >while certs presented by untrusted MTAs can present any certificate they > | >desire to achieve EDH-level security. > | > | This is probably a stupid question, but... why would you want to do this? > > So that your regular correspondants are authenticated, while anyone > else is opportunisticly encrypted. ??? How does checking their MTA's cert authenticate them? What's wrong with PGP sigs? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: What email encryption is actually in use?
Adam Shostack wrote: > Whats wrong with PGP sigs is that going on 9 full years after I > generated my first pgp key, my mom still can't use the stuff. Mozilla+enigmail+gpg. It just works. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: What email encryption is actually in use?
James A. Donald wrote: > -- > Adam Shostack wrote: > >>>Whats wrong with PGP sigs is that going on 9 full years >>>after I generated my first pgp key, my mom still can't use >>>the stuff. >> > > On 3 Oct 2002 at 17:33, Ben Laurie wrote: > >>Mozilla+enigmail+gpg. It just works. > > > If we had client side encryption that "just works" we would be > seeing a few more signed messages on this list, and those that > appear, would actually be checked. Send an unnecessarily > encrypted message to Tim and he wil probably threaten to shoot > you. Why would I want to sign a message to this list? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: why bother signing? (was Re: What email encryption is actually in use?)
On Fri, Oct 04, 2002 at 01:07:50PM -0700, Major Variola (ret) wrote: > At 04:45 PM 10/3/02 -0700, James A. Donald wrote: > >-- > >James A. Donald wrote: > >> > If we had client side encryption that "just works" we would > >> > be seeing a few more signed messages on this list, > > >Ben Laurie wrote: > >> Why would I want to sign a message to this list? > > > >Then all the people who read this list, were they to receive a > >communication from you, they would know it was the same Ben > >Laurie who posts to this list. > > But Ben is not spoofed here! He is now. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: Trojan-modified Sendmail floating around - 8.12.6 - Since Sept. 28th or earlier.
Bill Stewart wrote: > Somebody backdoored the source code for Sendmail on the official server. > So if you recompile from scratch, your sendmail is 0wned. > Another reason not to run mail systems as root In this case, as I understand it, it bites when you compile. So, its another reason not to build them as root. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Re: The End of the Golden Age of Crypto
Jim Choate wrote: What I'd like to know is does Godel's apply to all forms of para-consistent logic as well It applies to "any sufficiently complex axiomatic system". Allegedly. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
