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
[EMAIL PROTECTED] wrote: On 21 Apr 2002 at 10:00, Major Variola (ret) wrote: At 11:22 AM 4/21/02 +0200, Eugen Leitl wrote: I disagree here somewhat. Cryptography ttbomk doesn't have means of construction of provably strong PRNGs, especially scalable ones, and with lots of internal state (asymptotically approaching one-time pad properties), and those which can be mapped to silicon real estate efficiently both in time (few gate delays, GBps data rates) and in space (the silicon real estate consumed for each bit of PRNG state). What is a provably strong PRNG? Strong against what? If I'm supposed to know this, and have forgotten it, a pointer will suffice. I know what the attacks are for a crypto-strong plain-ole-analog-based-RNG. Its quite easy to generate apparently-random (ie, PRNGs) from block ciphers being fed, say, integers, or their own output, etc. These can be made small and fast in hardware. Large families of these can be constructed e.g. by varying bits e.g., in Blowfish's S-tables, etc. Yes. If you know what PRNG somebody is using and you know the seed you know the output. Seems to me the best a PRNG could hope to get is a situation where, looking at a long stream of output, there's no way of predicting the future output that's more efficient than guessing the initial seed. I don't think achieving that is all that hard in practice. 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). 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: 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: 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: Ben's blinding, plus pre-publishing
Jason Holt wrote: Are the journals going to be snippy about copyright issues? Most journals don't like papers to have been published elsewhere first. Screw 'em, I say. 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?
Greg Newby wrote: H2K2, 2600's conference, is at Hotel Penn in New York July 12-14. http://www.h2k2.net CP contributors who are scheduled include John Young and yours truly. Maybe others I didn't recognize or see yet. I heard of a few other tentatives. The full conference schedule should be online within the next couple of days. I'm thinking of a CP meet Saturday night July 12. Anyone else gonna be there? Woah! Me! By a miracle! Not at H2K2 (well, until now, I hadn't heard about it), but I will be in NY, en route back to the UK (on Sunday). 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
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
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 Simulate a Pentium VI in Java and all extant code could be accessed. If you live long enough for it to run, yeah. Similarly, is Microsoft's signing keys were cracked then any code could be signed. Duh. If the software needs a real-time connection to the internet though, then protection could be built into it. Oh yeah? How? Laptop applications would be vulnerable until we have pervasive wireless connection. How many bits do you think MS will use for the keys? Enough. 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: 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: dangers of TCPA/palladium
Mike Rosing wrote: Why exactly is this so much more of a threat than, say, flash BIOS upgrades? The BIOS has a lot more power over your machine than the TPM does. The difference is fundamental: I can change every bit of flash in my BIOS. I can not change *anything* in the TPM. *I* control my BIOS. IF, and only IF, I can control the TPM will I trust it to extend my trust to others. 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. It would be fantastic in all the portables that have been stolen from the FBI for example. Assuming they use a password at turn on, and the TPM is used to send data over the net, then they'd know where all their units are and know they weren't compromised (or how badly compromised anyway). But as spec'ed, it is very seriously flawed. 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. 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
AARG!Anonymous wrote: Adam Back writes: - Palladium is a proposed OS feature-set based on the TCPA hardware (Microsoft) Actually there seem to be some hardware differences between TCPA and Palladium. TCPA relies on a TPM, while Palladium uses some kind of new CPU mode. Palladium also includes some secure memory, a concept which does not exist in TCPA. This is correct. Palladium has ring -1, and memory that is only accessible to ring -1 (or I/O initiated by ring -1). 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 User wrote: This program can be used by anonymous contributors to release partial information about their identity - they can show that they are someone from a list of PGP key holders, without revealing which member of the list they are. Maybe it can help in the recent controvery over the identity of anonymous posters. It's a fairly low-level program that should be wrapped in a nicer UI. I'll send a couple of perl scripts later that make it easier to use. Hmm. So has anyone managed to get the signature to verify? Doesn't work for me! But perhaps things got mangled in the mail? Or I chose the wrong subset of the email to verify (I tried all the obvious ones)? Sending this stuff as attachments instead of inline would work better, of course. 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: 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: What good are smartcard readers for PCs
Lisa wrote: They are also actively used to modify DirecTV Dish Network access cards to steal service. Damn. We'd better ban them then. I've heard this Interweb thingy is used to steal content - should we ban that, too? -- 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: 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?
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?)
Ben Laurie wrote: 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. I will confirm this as a (detectable) spoof :-) 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
Re: [fc] list of papers accepted to FC'03
Tim May wrote: On Friday, November 15, 2002, at 07:55 AM, IanG wrote: -- I see pretty much a standard list of crypto papers here, albeit crypto with a waving of finance salt. What ever happened to Financial Cryptography? The organisers did say they were going to look at wider accessibility for the coming year, but I see only these papers that are, from the titles at least, anything that speaks to non-cryptographers: ...list of a few slightly interesting-sounding papers elided... Even they're a stretch. All are specialised, and none are of interest to the non-deep-techies. On a related front, how much interest is there in running EFCE this coming June? Is the conference still being held on an expensive Caribbean island? I've never been to an FC Conference, for various reasons. Certainly one of them is that I have things I'd rather buy with the $3000 I'd have to spend if I attended. My speculation, not having attended but having talked to people who have, is that the conference is a junket, a reason to go to Caribbean during the winter. Fine, if IBM or Citicorp is paying. A nice, untaxable fringe benefit. Not so fine for hackers and people like us. For that, there's the Codecon in SF which Bram and Len and others are involved in. EFCE is pretty much CodeCon for FC (though it might be fairer to but it the other way round, since EFCE came first). Cheers, Ben. -- http://www.apache-ssl.org/ben.html Available for contract work.
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: Logging of Web Usage
John Young wrote: Ben, Would you care to comment for publication on web logging described in these two files: http://cryptome.org/no-logs.htm http://cryptome.org/usage-logs.htm Cryptome invites comments from others who know the capabilities of servers to log or not, and other means for protecting user privacy by users themselves rather than by reliance upon privacy policies of site operators and government regulation. This relates to the data retention debate and current initiatives of law enforcement to subpoena, surveil, steal and manipulate log data. I don't have time right now to comment in detail (I will try to later), but it seems to me that, as someone else commented, relying on operators to not keep logs is really not the way to go. If you want privacy or anonymity, then you have to create it for yourself, not expect others to provide it for you. Of course, it is possible to reduce your exposure to others whilst still taking advantage of privacy-enhancing services they offer. Two obvious examples of this are the mixmaster anonymous remailer network, and onion routing. It seems to me if you want to make serious inroads into privacy w.r.t. logging of traffic, then what you want to put your energy into is onion routing. There is _still_ no deployable free software to do it, and that is ridiculous[1]. It seems to me that this is the single biggest win we can have against all sorts of privacy invasions. Make log retention useless for any purpose other than statistics and maintenance. Don't try to make it only used for those purposes. Cheers, Ben. [1] FWIW, I'd be willing to work on that, but not on my own (unless someone wants to keep me in the style to which I am accustomed, that is). -- 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: Logging of Web Usage
Bill Frantz wrote: At 6:16 PM -0800 4/2/03, Seth David Schoen wrote: Bill Frantz writes: The http://cryptome.org/usage-logs.htm URL says: Low resolution data in most cases is intended to be sufficient for marketing analyses. It may take the form of IP addresses that have been subjected to a one way hash, to refer URLs that exclude information other than the high level domain, or temporary cookies. Note that since IPv4 addresses are 32 bits, anyone willing to dedicate a computer for a few hours can reverse a one way hash by exhaustive search. Truncating IPs seems a much more privacy friendly approach. This problem would be less acute with IPv6 addresses. I'm skeptical that it will even take a few hours; on a 1.5 GHz desktop machine, using openssl speed, I see about a million hash operations per second. (It depends slightly on which hash you choose.) This is without compiling OpenSSL with processor-specific optimizations. Ah yes, I haven't updated my timings for the new machines that are faster than my 550Mhz. :-) The only other item is importance is that the exhaustive search time isn't the time to reverse one IP, but the time to reverse all the IPs that have been recorded. You only need to build the dictionary once. 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: [cta@hcsin.net: Re: CNN: 'Explores Possibility that Power Outage is Related to Internet Worm']
Eric Murray wrote: Food for thought and grounds for further research: - Forwarded message from Bernie, CTA [EMAIL PROTECTED] - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk List-Id: bugtraq.list-id.securityfocus.com List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Delivered-To: moderator for [EMAIL PROTECTED] From: Bernie, CTA [EMAIL PROTECTED] Organization: HCSIN To: [EMAIL PROTECTED] Date: Fri, 15 Aug 2003 14:09:12 -0400 Subject: Re: CNN: 'Explores Possibility that Power Outage is Related to Internet Worm' Priority: normal In-reply-to: [EMAIL PROTECTED] X-mailer: Pegasus Mail for Windows (v4.11) It is ridiculous to accept that a lightning strike could knock out the grid, or the transmission system is over stressed. There are many redundant fault, limit and Voltage-Surge Protection safeguards and related instrumentation and switchgear installed at the distribution centers and sub stations along the Power Grid that would have tripped to prevent or otherwise divert such a major outage. Yeah, ridiculous. So who remembers what caused the last major power outage in NY? (Hint: it wasn't _one_ lightning strike). -- 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: 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: 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
Re: 3. Proof-of-work analysis
Adam Back wrote: Here's a forward of parts of an email I sent to Richard with comments on his and Ben's paper (sent me a pre-print off-list a couple of weeks ago): One obvious comment is that the calculations do not take account of the CAMRAM approach of charging for introductions only. You mention this in the final para of conclusions as another possible. We wanted to assess whether pure proof-of-work helps. CAMRAM and other approaches may well change the calculations, but they also introduce lots of complications. It seems we now have hard figures to support the notion that proof-of-work cannot be a complete solution in itself. We will be making that clearer in a revision of the paper (and fixing some errors). 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: 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: [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
