July 2018 - cypherpunks-legacy

[ShmooCon-News] First selected BoF run by Jon Callas, CTO, PGP Corporation
by shmoocon-news＠lists.shmoo.com 06 Jul '18

06 Jul '18

We're pleased to announce our first selected though-provoking and potentially controversial BoF for ShmooCon 2005 will be run by Jon Callas, CTO, PGP Corporation. For more information check out: http://www.shmoocon.org/program.html#callas We look forward to folks discussing how "Information wants to be free, but programmers want to eat." Check it out! Sincerely, Beetle _______________________________________________ Shmoocon-News mailing list Shmoocon-News(a)lists.shmoo.com https://lists.… [View More]

1 0

Re: Status of opportunistic encryption
by Victor Duchovni 06 Jul '18

06 Jul '18

On Mon, May 29, 2006 at 07:21:29AM +0200, Florian Weimer wrote: > * Sandy Harris: > > > Recent news stories seem to me to make it obvious that anyone with privacy > > concerns (i.e. more-or-less everyone) should be encrypting as much of their > > communication as possible. Implementing opportunistic encryption is the > > best way I know of to do that for the Internet. > > > > I'm somewhat out of touch, though, so I do not know to what extent people … [View More]> > are using it now. That is my question here. > > It seems to me opportunistic encryption has moved to the application > layer, at least as far as Internet mail is concerned. Many MTAs use > TLS automatically with whatever certificates they can get. Of course, > this only guards against active attacks, but it seems to me that this > is a reasonable threat model. It only guards against *passive* eavesdropping. Active attacks can forge DNS MX records, inject BGP routes, ... Actual MITM resistant peer authentication with SMTP+TLS is extremely rare. I know it happens sometimes because I have it running for a small number of destinations, otherwise I would suspect that nobody is doing it. http://www.postfix.org/TLS_README.html#client_tls_harden Once the new 2.3 TLS code is folded into the production Postfix 2.3 snapshots (at which point the new documentation will be published), see http://www.postfix.org/TLS_README.html#client_tls_levels http://www.postfix.org/TLS_README.html#client_tls_policy Preview: It is regrettably the case, that TLS secure-channels (fully authenticated and immune to man-in-the-middle attacks) impose constraints on the sending and receiving sites that preclude ubiquitous deployment. One needs to manually configure this type of security for each destination domain, and in many cases implement non-default TLS policy table entries for additional domains hosted at a common secured destination. With Postfix 2.3, we make secure-channel configurations substantially easier to configure, but they will never be the norm. For the generic domain with which you have made no specific security arrangements, this security level is not a good fit. Historical note: while the documentation of these issues and many of the related features are new with Postfix 2.3, the issue was well understood before Postfix 1.0, when Lutz Jaenicke was designing the first unofficial Postfix TLS patch. See, his original post http://thread.gmane.org/gmane.ietf.apps-tls/304/focus=304 and the first response http://thread.gmane.org/gmane.ietf.apps-tls/304/focus=305. The problem is not even unique to SMTP or even TLS, similar issues exist for secure connections via aliases for HTTPS and Kerberos. SMTP merely uses indirect naming (via MX records) more frequently. I should also note that once one abandons the (still) unrealistic assumption of a secure DNS, it is not just SMTP + TLS that runs into trouble. For example, many Kerberos client libraries do a forward lookup (to alias- expand CNAMEs) and some perversely a reverse lookup (often the owner of the IP address is the worst source of the machine's name), and then give you a mutually authenticated channel to whatever principal they construct from now rather questionable data. This carries over to SASL GSSAPI, where GSSAPI abstraction makes working around this (in practice nobody tries even with native Kerberos) even harder. Consequently, also SSH with GSS KEX, is not MITM resistant when the attacker can tamper with DNS responses. Ultimately, to close similar security issues in many other protocols, we need a secure DNS, but I am somewhat pessimistic about the likelihood of this happening soon. -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAIL Morgan Stanley confidentiality or privilege, and use is prohibited. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] [View Less]

1 0

[ShmooCon-News] First selected BoF run by Jon Callas, CTO, PGP Corporation
by shmoocon-news＠lists.shmoo.com 06 Jul '18

06 Jul '18

We're pleased to announce our first selected though-provoking and potentially controversial BoF for ShmooCon 2005 will be run by Jon Callas, CTO, PGP Corporation. For more information check out: http://www.shmoocon.org/program.html#callas We look forward to folks discussing how "Information wants to be free, but programmers want to eat." Check it out! Sincerely, Beetle _______________________________________________ Shmoocon-News mailing list Shmoocon-News(a)lists.shmoo.com https://lists.… [View More]

1 0

Re: Status of opportunistic encryption
by Victor Duchovni 06 Jul '18

06 Jul '18

On Mon, May 29, 2006 at 07:21:29AM +0200, Florian Weimer wrote: > * Sandy Harris: > > > Recent news stories seem to me to make it obvious that anyone with privacy > > concerns (i.e. more-or-less everyone) should be encrypting as much of their > > communication as possible. Implementing opportunistic encryption is the > > best way I know of to do that for the Internet. > > > > I'm somewhat out of touch, though, so I do not know to what extent people … [View More]> > are using it now. That is my question here. > > It seems to me opportunistic encryption has moved to the application > layer, at least as far as Internet mail is concerned. Many MTAs use > TLS automatically with whatever certificates they can get. Of course, > this only guards against active attacks, but it seems to me that this > is a reasonable threat model. It only guards against *passive* eavesdropping. Active attacks can forge DNS MX records, inject BGP routes, ... Actual MITM resistant peer authentication with SMTP+TLS is extremely rare. I know it happens sometimes because I have it running for a small number of destinations, otherwise I would suspect that nobody is doing it. http://www.postfix.org/TLS_README.html#client_tls_harden Once the new 2.3 TLS code is folded into the production Postfix 2.3 snapshots (at which point the new documentation will be published), see http://www.postfix.org/TLS_README.html#client_tls_levels http://www.postfix.org/TLS_README.html#client_tls_policy Preview: It is regrettably the case, that TLS secure-channels (fully authenticated and immune to man-in-the-middle attacks) impose constraints on the sending and receiving sites that preclude ubiquitous deployment. One needs to manually configure this type of security for each destination domain, and in many cases implement non-default TLS policy table entries for additional domains hosted at a common secured destination. With Postfix 2.3, we make secure-channel configurations substantially easier to configure, but they will never be the norm. For the generic domain with which you have made no specific security arrangements, this security level is not a good fit. Historical note: while the documentation of these issues and many of the related features are new with Postfix 2.3, the issue was well understood before Postfix 1.0, when Lutz Jaenicke was designing the first unofficial Postfix TLS patch. See, his original post http://thread.gmane.org/gmane.ietf.apps-tls/304/focus=304 and the first response http://thread.gmane.org/gmane.ietf.apps-tls/304/focus=305. The problem is not even unique to SMTP or even TLS, similar issues exist for secure connections via aliases for HTTPS and Kerberos. SMTP merely uses indirect naming (via MX records) more frequently. I should also note that once one abandons the (still) unrealistic assumption of a secure DNS, it is not just SMTP + TLS that runs into trouble. For example, many Kerberos client libraries do a forward lookup (to alias- expand CNAMEs) and some perversely a reverse lookup (often the owner of the IP address is the worst source of the machine's name), and then give you a mutually authenticated channel to whatever principal they construct from now rather questionable data. This carries over to SASL GSSAPI, where GSSAPI abstraction makes working around this (in practice nobody tries even with native Kerberos) even harder. Consequently, also SSH with GSS KEX, is not MITM resistant when the attacker can tamper with DNS responses. Ultimately, to close similar security issues in many other protocols, we need a secure DNS, but I am somewhat pessimistic about the likelihood of this happening soon. -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAIL Morgan Stanley confidentiality or privilege, and use is prohibited. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] [View Less]

1 0

Re: [Freedombox-discuss] FreedomBox/Unhosted/PageKite for Access Innovation Prize 2012
by John Gilmore 06 Jul '18

06 Jul '18

> > That's it. Did I miss anything? :-) Sure. Here are three more scenarios. What all of them share is that YOU choose which friends with static IP addresses to trust, and that those friends' FreedomBoxes handle much of the setup and maintenance overhead. These three scenarios don't require ANY centralized infrastructure other than a DNS provider that everyone needs anyway. Since FreedomBox is built out of standardized software, even friends who don't have FreedomBoxes can act as … [View More]your friends, if they are already running, or willing to run, that software on their existing Linux servers. == Scenario DNS Redirect == Offer an option to host your website on your freedombox, with a dynamic IP address, that is reached via one, two, or more friends' freedomboxes' static IP addresses who serve up your domain records. Domain records (also known as your "DNS zone") describe what IP addresses your web server (and other servers) are located on, the domain names of the servers that serve up your DNS zone, and possibly public keys and signatures that secure this and other information. In the standard DNS protocol, these records can be changed dynamically and are globally cached for high performance and reliability. (This is how the Internet already works.) Our software would provide both server and client implementations of a domain name server / redirector. If you have a static IP address, your FreedomBox can host a domain server, which serves up your own domain name(s), and also serves up the name(s) of friends. This DNS server would accept dynamic updates from your friends' FreedomBoxes, which would revise the IP address in the zone. The client software that runs in your FreedomBox would merely publish these dynamic updates (to your friends' FreedomBoxes) whenever your FreedomBox's public IP address changed. These updates would be cryptographically signed to avoid unwanted changes. By choosing more than one friend to host your domain zone, you would avoid single points of failure. Web accesses would come directly from the world to your dynamically-addressed FreedomBox. Even friends who don't have a static IP address can improve your reachability/reliability, if they have a dynamic and publicly reachable IP address. You should start with one friend with a static IP address as an "anchor" site. Once browsers support DNS-signed SSL certificates using the IETF DANE TLS protocol, the same software can securely publish your public key without making you interact with an SSL certificate provider (reducing the setup costs and making more of it automatable). Pros: Relatively low setup overhead. Works with SSL or without. Requires minimal permanent storage in all participating FreedomBoxes. Trivial ongoing overhead for your friend sites. Web accesses from the world go straight to your box. Can convert transparently to the Webproxy Redirect mode below, or to the Friends Web Cache mode below. Cons: Requires that you have at least ONE public IP address, dynamically assigned. Must find one or two friends. Must register those friends' domain names with your domain provider as your NS servers. == Scenario Webproxy Redirect == Same setup as above, except you don't even have a publicly reachable dynamic IP address. All you have is a NAT address and your NAT redirector is completely oblivious to all attempts to punch a hole through it. So you find two or more friends and they serve up your DNS records as before, but each of them advertise the entire set of friends' IP addresses as the address of your web site. And each of them runs a web proxy that relays any incoming web accesses from their box, out over their ISP, to your box, using the PageKite protocol. FreedomBox software would again provide both the server software and the client software for this. Your FreedomBox would at all times keep a TCP connection up to each friend's FreedomBox so that web accesses can be relayed to you down that TCP connection. Incoming web accesses from the world would go at random to any of your friends' FreedomBoxes. Those boxes would relay the traffic to yours. If you or the world can't reach some of your friends, those friends' proxies would not answer, and clients would try another address, making it possible to reach you anyway. As in DNS Redirect mode, can also publish IETF DANE TLS keys to eventually avoid SSL certificate setup overhead. Pros: Relatively low setup overhead. Works with SSL or without. Requires minimal permanent storage in all participating FreedomBoxes. Can convert transparently to the DNS Redirect mode above, or to the Friends Web Cache mode below. Cons: Must find one or two friends. Must register those friends' domain names with your domain provider as your NS servers. Your friends must be willing to have ALL your web traffic go via their ISP connection. We could ship a FreedomBox with just one of these modes working, and then upgrade the software to transparently switch to the lower overhead mode whenever your FreedomBox is on a publicly reachable IP address. Indeed, both modes could be combined: Your DNS zone could publish both your dynamic IP address (if you have one), and the static (or dynamic) IP addresses of your friends. Accesses made from the world that randomly pick your own IP address would go directly; access that pick your friends' addresses would go via proxies at your friends. == Scenario Friends Web Cache == Setup for this scenario is the same as in Web Redirect: Your box is on the Internet, and can call out to public IP addresses, and maybe it even has a dynamic or static IP address of its own. In this scenario, again you pick one, two, or more friends who publish your DNS records, let you update the addresses in your DNS zone with your publicly reachable IP address if you have one, and also publish the whole collection of your friends' IP addresses as your web address. Your friends run a PageKite proxy that relays any incoming web access to your FreedomBox. But this time that proxy also caches web page contents, using the standard HTTP web cacheing protocol, so that a second access to a page that Friend 1 has already served up, will not need to go to your box, but can be served up directly from Friend 1's box to many web requesters until it times out. If you have a small web site, your friends end up cacheing the whole thing, such that accesses no longer have to go to your FreedomBox, saving 50% of the Internet traffic that is used in Scenario Webproxy Redirect. Your friends' FreedomBoxes would remember the pages that they have proxied, temporarily, either in RAM or in nonvolatile storage. They are free to throw away these cached pages at any time; when they do, the next access to that page goes back to being proxied to your FreedomBox. There are complications for SSL web accesses. The simplest thing to do is to always proxy them (only cache non-SSL accesses). To enable cacheing for SSL accesses, two obvious approaches appear: either your friends' FreedomBoxes would need to store a temporary or permanent copy of your private key (so they could negotiate an SSL session on your website's behalf), with obvious security issues; or your friends could proxy the SSL/TLS session setup, and then be handed the secret key for just that SSL/TLS session, such that they could impersonate your web server (sending answers from their cache) only to that client (also with obvious security problems, but lesser ones). Pros: Relatively low setup overhead. Requires minimal permanent storage in all participating FreedomBoxes. Can convert transparently to the DNS Redirect mode above, or to the Webproxy Redirect mode above. Uses only half the bandwidth of the Webproxy Redirect mode, and improves the latency of accesses to your website. Cons: Must find one or two friends. Must register those friends' domain names with your domain provider as your NS servers. Your friends must be willing to have ALL your web traffic go via their ISP connection. Requires some temporary storage (RAM or Flash) in your friends' FreedomBoxes. Has complications and reduces security for SSL web accesses. John _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss(a)lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [View Less]

1 0

[camram-spam] long commentary from a knowledgeable outsider
by Eric S. Johansson 06 Jul '18

06 Jul '18

<x-flowed>I wanted to try and get a rough approximation of hardware costs and performance for a hardware based attack against hashcash postage. So I wrote to Nicko van Someren. I chose Niko because I heard him speak that the digital commerce society of Boston on some of the scaling issues regarding a micromint[1] based currency system. A nutshell, he pretty well demolished the feasibility of micromint. In general, Nicko is not a fan of proof of work systems for a variety of reasons … [View More]but he has some really good information that he gave me permission to share with the hashcash group. In my opinion, the content convinced me that hashcash will provide a degree of defense against Spam. On the downside, there are some serious issues regarding theft of service and bulk generation of stamps but I don't consider them a mortal wound, it's just a wound that bleeds real heavily... Please read the entire message before commenting because I may have addressed some of the points further on. [1]http://theory.lcs.mit.edu/~rivest/RivestShamir-mpay.pdf --- eric ----------------------- my question to Nicko was: """My primary concern is that there is a risk that someone could define a hashcash coin generator using relatively cheap hardware (e.g. FPGA) and enable the at home spammer to generate lots of coins. I'm wondering if you would be willing to do a first-order approximation analysis on the cost versus speed curve for hardware generating hashcash coins? """ to which he replied: At 12:00 PM 6/8/2001 +0100, Nicko van Someren wrote: > Hashcash is different to MicroMint in that, as long as the >stamp is correctly constructed it will be hard to do any precomputation >to make bulk mailing more efficient and the economies of scale that >are both the key to and the downfall of MicroMint do not apply. That >said, the cost of repetitive bulk computation is nearly always >sub-linear in the amount of work to be done. > > The problems with proof of work schemes are many and varied. >The most obvious is the inequality of the amount of processing power >available to different people, or indeed to the same person in different >contexts. I send mail from both a 733 MHz G4 PowerPC (in an Apple Mac) >and a 16 MHz 68000 (in a Palm Pilot). Since the mail recipient can not >reliably tell from which machine I sent then mail either it is going >to take a couple of minutes to send a mail from the Palm or it will >only take a second but I can forge spam as having come from the Palm >and send hundreds a second from the Mac. To make matters worse, those >who would spam have already shown themselves to not be beyond using >the computing resources of others so I think that we can be confident >that spam would be sent using "stolen stamps". > > To address your specific question about hardware, as a rough >guess, special hardware can do the same work as a general purpose CPU >in about 0.1 to 0.2 as many clock ticks. For hash functions and some >block ciphers (e.g. DES) the speed up can be even greater. What's more, >since these days the fast FPGAs have more gates than you can shake a >stick at you will be able to put multiple engines on one chip and I >would expect that an off the shelf Xylinx development card with a big, >fast gate array directly on the PCI bus would in practice be able to >compute a SHA1 of something as small as an email address, date and >integer at a rate a good 500 times faster than my PowerPC. This >of course would depend on the hash algorithm and the amount of data >used. You could strengthen against the use of hardware by using a >system that needed more memory and used functions such as multiply >operations which are expensive in hardware but which CPU designers >spend a lot of effort upon. > > Given that a $2000 PCI bus card will let me send spam to >10,000 people in the same time that a legitimate user can send a >party invitation to 20 friends I expect that a SHA-1 based "proof >of work" stamp is not going to be useful to spammers. All that it >will do is make the sale of email addresses more profitable since >there will be a market for "stamped, addresses envelopes" for >which you can charge $100 for 100,000 instead of the current rate >of $50 per million filtered addresses. > > In short, I don't think proof of work based stamps will do >much for reducing spam. I think that to do that we need a more >innovative solution. If there were a ubiquitous micropayment scheme >in circulation then I would go for a system that required cold hard >cash to be sent with each email from someone you have not listed in >your "free list". For most spam you'll get some cash, making large >scale spam less cost effective as an advertising method, and if it >is from someone that you really want to talk to you'll just send the >cash back with your first mail back to the sender. > > So that's my 2 pennies worth (or 2,000,000,000 CPU cycles!) > > Nicko my reply was: >At 12:00 PM 6/8/2001 +0100, Nicko van Someren wrote: >> The problems with proof of work schemes are many and varied. >>The most obvious is the inequality of the amount of processing power >>available to different people, or indeed to the same person in different >>contexts. I send mail from both a 733 MHz G4 PowerPC (in an Apple Mac) >>and a 16 MHz 68000 (in a Palm Pilot). Since the mail recipient can not >>reliably tell from which machine I sent then mail either it is going >>to take a couple of minutes to send a mail from the Palm or it will >>only take a second but I can forge spam as having come from the Palm >>and send hundreds a second from the Mac. To make matters worse, those >>who would spam have already shown themselves to not be beyond using >>the computing resources of others so I think that we can be confident >>that spam would be sent using "stolen stamps". > >on the range of processing power issue, I believe a more realistic >bottom-line would be around a Pentium I/200 MHz. Wouldn't any e-mail >coming from a PalmPilot go through some form of a conduit on the higher >performance machine? That conduit could generate stamps. > >On the point about forging what class of machine as a way of getting out >of generating "expensive" stamps, we were not going to adjust the stamp >based on the senders resources. > >On the point about stolen stamps, I was planning on defeating that by >making hashcash be a client to client protocol and the only thing >intervening machines might do is validate that the stamp is present. > >>[hardware description snipped] >> Given that a $2000 PCI bus card will let me send spam to >>10,000 people in the same time that a legitimate user can send a >>party invitation to 20 friends I expect that a SHA-1 based "proof >>of work" stamp is not going to be useful to spammers. All that it >>will do is make the sale of email addresses more profitable since >>there will be a market for "stamped, addresses envelopes" for >>which you can charge $100 for 100,000 instead of the current rate >>of $50 per million filtered addresses. > >your thoughts are confirming one suspicion which is that even if hashcash >hardware was implemented, it would raise the cost of spamming and cut out >some of the more cost sensitive portions of the market. Remember that >each stamp can only be used once and that it's only good for a finite >period of time (for example, eight days). It would make it more difficult >for a spammer to deliver continual postage because in their >precalculation, they would need to create stamps that would be valid in >the future for a limited period of time. > >This still opens the market for spammer hardware to the at home spammer >where they would sell boards in addition to the list of e-mail addresses. > >> In short, I don't think proof of work based stamps will do >>much for reducing spam. I think that to do that we need a more >>innovative solution. If there were a ubiquitous micropayment scheme >>in circulation then I would go for a system that required cold hard >>cash to be sent with each email from someone you have not listed in >>your "free list". For most spam you'll get some cash, making large >>scale spam less cost effective as an advertising method, and if it >>is from someone that you really want to talk to you'll just send the >>cash back with your first mail back to the sender. > >it would be a short-term solution that would work until the hardware folks >catch up. I think it's worth moving ahead with the technique anyway >because it would create the infrastructure necessary for incorporating >micropayments. > >I need to run out now but I may send more thoughts later. > >I very much appreciate you taking the time to answer my questions. > >---eric to which he replied to my reply... At 05:02 PM 6/8/2001 +0100, Nicko van Someren wrote: >"Eric S. Johansson" wrote: > > > > I would like permission to forward bits of your message to the hashcash > > mailing list. > >Sure, as long as you quote me in context. > > > > The problems with proof of work schemes are many and varied. > > >The most obvious is the inequality of the amount of processing power > > >available to different people, or indeed to the same person in different > > >contexts. I send mail from both a 733 MHz G4 PowerPC (in an Apple Mac) > > >and a 16 MHz 68000 (in a Palm Pilot). Since the mail recipient can not > > >reliably tell from which machine I sent then mail either it is going > > >to take a couple of minutes to send a mail from the Palm or it will > > >only take a second but I can forge spam as having come from the Palm > > >and send hundreds a second from the Mac. To make matters worse, those > > >who would spam have already shown themselves to not be beyond using > > >the computing resources of others so I think that we can be confident > > >that spam would be sent using "stolen stamps". > > > > on the range of processing power issue, I believe a more realistic > > bottom-line would be around a Pentium I/200 MHz. Wouldn't any e-mail > > coming from a PalmPilot go through some form of a conduit on the higher > > performance machine? That conduit could generate stamps. > >I post directly from handhelds all the time but if you were to introduce >HashCash you could indeed mandate a gateway (with suitable sign-on) for >posting from light weight devices. > > > On the point about forging what class of machine as a way of getting out of > > generating "expensive" stamps, we were not going to adjust the stamp based > > on the senders resources. > >I think that having one size fit all will either render prefectly >legitimate posting way to slow in some circumstances or make it >too easy for the commited spammer to produce. > > > On the point about stolen stamps, I was planning on defeating that by > > making hashcash be a client to client protocol and the only thing > > intervening machines might do is validate that the stamp is present. > >Unless you plan to rebuild the structure of the internet's email >system this is going to be sent in the RFC822 header. You can't >have challenge-response stamps for store-and-forward email. Even >if you could deal with this there is no way to stop the turely nasty >spammer from just cracking someone else's machine and using it to >compute stamps for him. > > > >[hardware description snipped] > > > Given that a $2000 PCI bus card will let me send spam to > > >10,000 people in the same time that a legitimate user can send a > > >party invitation to 20 friends I expect that a SHA-1 based "proof > > >of work" stamp is not going to be useful to spammers. All that it > > >will do is make the sale of email addresses more profitable since > > >there will be a market for "stamped, addresses envelopes" for > > >which you can charge $100 for 100,000 instead of the current rate > > >of $50 per million filtered addresses. > > > > your thoughts are confirming one suspicion which is that even if hashcash > > hardware was implemented, it would raise the cost of spamming and cut out > > some of the more cost sensitive portions of the market. Remember that each > > stamp can only be used once and that it's only good for a finite period of > > time (for example, eight days). It would make it more difficult for a > > spammer to deliver continual postage because in their precalculation, they > > would need to create stamps that would be valid in the future for a limited > > period of time. > >I don't see this as a problem. Most people who spam buy in the mailing >list from somewhere. Unless they plan to sit on the list for a long >time (i.e. more than a week) then they could buy in the bulk stamps too. >I bet the address dealers will cut you a deal if you come back for a >second round of stamps too. > > > This still opens the market for spammer hardware to the at home spammer > > where they would sell boards in addition to the list of e-mail addresses. > >Or allow you to log into their secure server and submit a list of >1,000,0000 addresses which would be stamped in a matter of minutes >for a small charge. > > > > In short, I don't think proof of work based stamps will do > > >much for reducing spam. I think that to do that we need a more > > >innovative solution. If there were a ubiquitous micropayment scheme > > >in circulation then I would go for a system that required cold hard > > >cash to be sent with each email from someone you have not listed in > > >your "free list". For most spam you'll get some cash, making large > > >scale spam less cost effective as an advertising method, and if it > > >is from someone that you really want to talk to you'll just send the > > >cash back with your first mail back to the sender. > > > > it would be a short-term solution that would work until the hardware folks > > catch up. I think it's worth moving ahead with the technique anyway > > because it would create the infrastructure necessary for incorporating > > micropayments. > >I'm not sure I agree. The design of an infrastructure for >incorpoating micropayments is easy. Define the XML for the >payment object, base 64 encode the payment, stick it in the >X-payment: header line of the mail. Done. What is needed is >the mail software on the desktops of tens of millions of users >to be changed to be changed to support the system. Furthermore >until you have it on the desktop of everyone with whom you talk >you'll run into endless trouble. > >The crux of the problem is that free email services with no >recourse for misuse are all to easy to get hold of. Unless >you stop accepting mail from mail servers that don't limit the >source and volume of their mail then you will always have spam. >If HotMail were to require some sort of ID before you could get >an account, and refuse to give a second one on the basis of the >same ID if the first account was canceled, then you would >quickly stop getting spam from HotMail. If you simply require >HotMail to compute stamps on every mail that they send then I >can't complain; they've already spent $5,000,000 with nCipher >for crypto hardware to speed up their SSL login and I expect >that they would do the same for the HashCash stamps. > >One way to ensure some sort of recourse is to require that there >is a valid, routable reply address. The vast majority of spam >mails do not have valid reply addresses. If you requried some >sort of challenge-response on the first communication between >two parties that would stop untracable spam. Furthermore such >a system can be automated by those who care but still be made >workable for those who don't want to upgrade their mail software. >If you send me a mail and you don't have an automated responder >you will simply see an authentication message with a request that >you reply with the given subect line. > >Anyway, as I've said before I really don't think proof-of-work >schemes are the solution. Even if you think that people would >accept a ten second per recipient delay before sending their >mail then the spammer can still send 50,000 mails a week on a >standard machine, and they can compute over the week and splurge >them out on some free ISP all in one go. It's not a useful >deterant. > > Nicko to which I replied (yes folks, this is the last bit) >> > On the point about forging what class of machine as a way of getting >> out of >> > generating "expensive" stamps, we were not going to adjust the stamp based >> > on the senders resources. >> >>I think that having one size fit all will either render prefectly >>legitimate posting way to slow in some circumstances or make it >>too easy for the commited spammer to produce. > >understood and I agree. It's just like you've pointed out that it's it's >easy for a spammer to claim to be a low-power machine and thereby enabling >them to get by with less postage. I'm not sure this is a mortal wound but >it certainly bleeds heavily. > >> > On the point about stolen stamps, I was planning on defeating that by >> > making hashcash be a client to client protocol and the only thing >> > intervening machines might do is validate that the stamp is present. >> >>Unless you plan to rebuild the structure of the internet's email >>system this is going to be sent in the RFC822 header. You can't >>have challenge-response stamps for store-and-forward email. > >actually, you can. Think back to the days of UUCP. One model we are >trying on for size would have both MUAs talk to each other and communicate >certain parameters. Yes, it's potentially very slow especially for people >that don't live on the net all the time but only check e-mail once a week. > >> Even >>if you could deal with this there is no way to stop the turely nasty >>spammer from just cracking someone else's machine and using it to >>compute stamps for him. > >yup, that's a hazard and one that can be defended against. The closer one >couples the hashcash environment to the MTA, the more difficult it becomes >for someone to steal services to generate stamps. > > >> > your thoughts are confirming one suspicion which is that even if hashcash >> > hardware was implemented, it would raise the cost of spamming and cut out >> > some of the more cost sensitive portions of the market. Remember that >> each >> > stamp can only be used once and that it's only good for a finite period of >> > time (for example, eight days). It would make it more difficult for a >> > spammer to deliver continual postage because in their precalculation, they >> > would need to create stamps that would be valid in the future for a >> limited >> > period of time. >> >>I don't see this as a problem. Most people who spam buy in the mailing >>list from somewhere. Unless they plan to sit on the list for a long >>time (i.e. more than a week) then they could buy in the bulk stamps too. >>I bet the address dealers will cut you a deal if you come back for a >>second round of stamps too. > >let's see, let's work the numbers. Assuming a X-hashcash:string is >somewhere in the area of 40 bytes, stamps for one million addresses is >roughly 40 MB, 10 million stamps would be 400 MB. One could easily fit >this on a CD or download via a DSL or cable modem. So transport would not >be a big deal for a single Spam client but it would get rather interesting >with thousands of spammer clients. > >Using your numbers, (500 times speed up), a spammer could generate one >stamp every 0.02 seconds (assuming the average stamp computation time was >10 seconds). This means that one million stamps would take 20,000 (5.5 >hours) seconds to generate. If we mixed in to the stamp definition a hash >of the message body as well, then it would be more difficult (but not >impossible) for the spammer to precompute stamps because they would have >to have the message body before they generated stamps. > >one board would allow them to service roughly 130 one million address >customers per month. servicing 1000 customers would take seven >boards. If people wanted to ship more than one piece of spam per month, >then the spam stamp creators would need to increase their capital >investment and ongoing monthly costs which would in turn increase the cost >of spam which would keep some people out of the market. > >This conversation is helping me understand how proof of work calculations >fail and the rate at which they would fail. The big question is can we >exploit the arms race in our favor? I think the answer is yes but only >for a relatively short period of time. But that would allow us to lay the >groundwork for peer-to-peer postage. > >> > This still opens the market for spammer hardware to the at home spammer >> > where they would sell boards in addition to the list of e-mail addresses. >> >>Or allow you to log into their secure server and submit a list of >>1,000,0000 addresses which would be stamped in a matter of minutes >>for a small charge. > >either my math is wrong or I didn't understand just how fast the speedup >would go. You still have the bandwidth issue when transferring stamps >which will most certainly take more than a few minutes. At least with the >bandwidth available to most people. ;-) > >> > it would be a short-term solution that would work until the hardware folks >> > catch up. I think it's worth moving ahead with the technique anyway >> > because it would create the infrastructure necessary for incorporating >> > micropayments. >> >>I'm not sure I agree. The design of an infrastructure for >>incorpoating micropayments is easy. Define the XML for the >>payment object, base 64 encode the payment, stick it in the >>X-payment: header line of the mail. Done. What is needed is >>the mail software on the desktops of tens of millions of users >>to be changed to be changed to support the system. Furthermore >>until you have it on the desktop of everyone with whom you talk >>you'll run into endless trouble. > >well, yes. We do need to change all desktops but we're discussing how to >do this without necessarily replacing the clients. The current model >favors the development of a proxy which does the hashcash >calculation. Obviously, we do want to get this into every e-mail client >on the face of the planet. It's not going to happen but with network >effects, I think we can encourage enough people to make the transition >that it will be worthwhile. > >One of the "encouragements" will be the delivery of messages from hashcash >users to non hashcash users. This message (created by autoresponder) will >instruct the user to click on a URL which will generate a hashcash coin >and a "get out of hashcash jail free" card. The "get out of hashcash jail >free" card will tell the recipient's MUA to release the trapped message. > >The reason why I keep harping on it being an important (but not essential) >precursor to using payments is that it will create the infrastructure for >handling payments, bounces, double spending and more importantly put in >place a code base that will only require minor changes (in theory) to >handle real currency instead of proof of work. > >as Bob will tell you, I have my own reality distortion field that has been >in operation for far longer than I've known Bob. > >>Anyway, as I've said before I really don't think proof-of-work >>schemes are the solution. Even if you think that people would >>accept a ten second per recipient delay before sending their >>mail then the spammer can still send 50,000 mails a week on a >>standard machine, and they can compute over the week and splurge >>them out on some free ISP all in one go. It's not a useful >>deterant. > > 60480 stamps in a week @ ten seconds per stamp assuming the machine runs > 24 by 7. It won't be a Windows box... ;-) > >The analysis we've gone over certainly indicates that this is a high >probability. My experience with spammers from the ISP perspective tells >me that hashcash (or something like it) will make a dent. It won't be >perfect by any stretch of the imagination but I can live with that. > >again, I truly appreciate your advice and information. I will keep you >informed so that what decisions we make in building the hashcash >infrastructure will also be expandable to handle electronic currency when >someone is ready to deploy it. > >---eric --------------------------------------------------------------------- To unsubscribe, e-mail: camram-spam-unsubscribe(a)camram.org For additional commands, e-mail: camram-spam-help(a)camram.org </x-flowed> --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' -- ____________________________________________________________________ "...where annual election ends, tyranny begins;" Thomas Jefferson & Samuel Adams The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage(a)ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- -------------------------------------------------------------------- [View Less]

1 0

Firefox through Tor
by Eric H. Jung 06 Jul '18

06 Jul '18

Hi, I'm happy to announce a new Firefox extension which is built with Tor in mind from the ground up. FoxyProxy - http://foxyproxy.mozdev.org I took the things I liked about SwitchProxy, TorButton, ProxyButton, QuickButton, xyzproxy, etc. and added a number of crucial features: * Tor Wizard - now zero configuration to use Firefox with Tor * Define proxy use based on URL patterns using wildcards and/or regular expressions: now you can route *.onion domains and web mail accounts (gmail, … [View More]

1 0

Status of opportunistic encryption
by Sandy Harris 06 Jul '18

06 Jul '18

Some years back I worked on the FreeS/WAN project (freeswan.org) IPsec for Linux. One of our goals was to implement "opportunistic encryption", to allow any two appropriately set up machines to communicate securely, without pre-arrangement between the two system administrators. Put authentication keys in DNS; they look those up and can then use IKE to do authenticated Diffie-Hellman to create the keys for secure links. Recent news stories seem to me to make it obvious that anyone with privacy … [View More]

1 0

Re: [tahoe-dev] several questions about tahoe backup
by Brian Warner 06 Jul '18

06 Jul '18

On 3/1/12 11:50 AM, Dmitriy Kazimirov wrote: > 98% of this are results of tahoe backup runs and deep-check --repair > --add-lease takes more than 2 days to complete and it never completed > successfully for one reason or another. Usually it crashes on > network(I think related to gateway's network connection) errors and > starts from beginning. Yeah, I'm really satrting to think that we need that RepairAgent that we keep talking about: something inside the tahoe client node (or … [View More]inside the "Agent" that we discusses briefly at the last Summit) which can manage a rate-limited asynchronous interruptable/restartable check/repair/renew process. Doing it entirely from the command line is too fragile: it basically implies that the whole process needs to complete before 1: your CLI command gets killed, 2: the node gets bounced, 3: the client's connections to the storage servers remain intact. The hard part about the RepairAgent has always been how to configure it. But I'm starting to think that tahoe.cfg should just be able to list a couple of aliases and a frequency (once/day, etc). > I tried to make specific aliases for each tahoe backup destination and > parallize deep-check but new questions arise: > - if other gateway performs deep-check on directory, and at same time > - tahoe backup writes new backup - is it safe?Will worse possible > result be 'Uncoordinate Write Error' but no data loss except > possible current backup session? Backups use almost entirely immutable files and directories, and immutable files are not vulnerable to collision problems. The only mutable directory is the top-level one (which contains the timestamped subdirectories and the "Latest" link). So the only potential danger is that the "tahoe backup" is modifying that directory while the "deep-check --repair" is repairing it. It's hard to say what the chances are of bad things happening here. A couple of thoughts: - "tahoe backup" modifies the top-level directory at the very end of the process, while "deep-check --repair" visits the top directory at the very beginning of the process. If you start both at the same time, they probably won't collide. - if the directory needed repairing, then the "tahoe backup" modify-directory operation will effectively repair it at the same time, perhaps reducing the chances that deepcheck--repair will try to repair it later - The chances of UCWE resulting in lost data depends upon the encoding parameters and how many simultaneous writers there are. With 3-of-10, assuming all shares are available, there'd have to be 5 simultaneous versions of the file before none of them are recoverable (two shares of version A, two of version B, two*C, two*D, two*E). Which theoretically means that one tahoe-backup writer, one repairer, and one previously-existing version should always result in at least one version being recoverable. But, this is highly dependent upon what sort of damage the repairer was trying to fix in the first place. > - if several deep-checks are being performed on directory, from > different gateways(due for example script error) - is it safe?(I > knew it does not make sense to do so but what will be worse possible > result?) (incidentally deep-check without --repair is always safe: it doesn't modify the shares at all) Multiple deep-check --repair operations on the same directory runs the same UCWE risk as multiple writers trying to modify a directory at the same time: the danger is that each will successfully replace shares on different servers at the same time, resulting in some old "A" shares, some new "B" shares, and some new (different) "C" shares. Having a variety of share versions reduces your recoverability margins. We haven't ever tried to seriously model or test this. It would be interesting to create a directory, set up multiple clients, have them all repeatedly hammer away at it (making modifications) and measure how many UCWEs they get, and when/if the file becomes unrecoverable. It'd probably be a good idea to instrument the storage servers to send details of how the shares are changing to a common logfile, so we could reconstruct the process later. cheers, -Brian _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [View Less]

1 0

[camram-spam] long commentary from a knowledgeable outsider
by Eric S. Johansson 06 Jul '18

06 Jul '18

<x-flowed>I wanted to try and get a rough approximation of hardware costs and performance for a hardware based attack against hashcash postage. So I wrote to Nicko van Someren. I chose Niko because I heard him speak that the digital commerce society of Boston on some of the scaling issues regarding a micromint[1] based currency system. A nutshell, he pretty well demolished the feasibility of micromint. In general, Nicko is not a fan of proof of work systems for a variety of reasons … [View More]but he has some really good information that he gave me permission to share with the hashcash group. In my opinion, the content convinced me that hashcash will provide a degree of defense against Spam. On the downside, there are some serious issues regarding theft of service and bulk generation of stamps but I don't consider them a mortal wound, it's just a wound that bleeds real heavily... Please read the entire message before commenting because I may have addressed some of the points further on. [1]http://theory.lcs.mit.edu/~rivest/RivestShamir-mpay.pdf --- eric ----------------------- my question to Nicko was: """My primary concern is that there is a risk that someone could define a hashcash coin generator using relatively cheap hardware (e.g. FPGA) and enable the at home spammer to generate lots of coins. I'm wondering if you would be willing to do a first-order approximation analysis on the cost versus speed curve for hardware generating hashcash coins? """ to which he replied: At 12:00 PM 6/8/2001 +0100, Nicko van Someren wrote: > Hashcash is different to MicroMint in that, as long as the >stamp is correctly constructed it will be hard to do any precomputation >to make bulk mailing more efficient and the economies of scale that >are both the key to and the downfall of MicroMint do not apply. That >said, the cost of repetitive bulk computation is nearly always >sub-linear in the amount of work to be done. > > The problems with proof of work schemes are many and varied. >The most obvious is the inequality of the amount of processing power >available to different people, or indeed to the same person in different >contexts. I send mail from both a 733 MHz G4 PowerPC (in an Apple Mac) >and a 16 MHz 68000 (in a Palm Pilot). Since the mail recipient can not >reliably tell from which machine I sent then mail either it is going >to take a couple of minutes to send a mail from the Palm or it will >only take a second but I can forge spam as having come from the Palm >and send hundreds a second from the Mac. To make matters worse, those >who would spam have already shown themselves to not be beyond using >the computing resources of others so I think that we can be confident >that spam would be sent using "stolen stamps". > > To address your specific question about hardware, as a rough >guess, special hardware can do the same work as a general purpose CPU >in about 0.1 to 0.2 as many clock ticks. For hash functions and some >block ciphers (e.g. DES) the speed up can be even greater. What's more, >since these days the fast FPGAs have more gates than you can shake a >stick at you will be able to put multiple engines on one chip and I >would expect that an off the shelf Xylinx development card with a big, >fast gate array directly on the PCI bus would in practice be able to >compute a SHA1 of something as small as an email address, date and >integer at a rate a good 500 times faster than my PowerPC. This >of course would depend on the hash algorithm and the amount of data >used. You could strengthen against the use of hardware by using a >system that needed more memory and used functions such as multiply >operations which are expensive in hardware but which CPU designers >spend a lot of effort upon. > > Given that a $2000 PCI bus card will let me send spam to >10,000 people in the same time that a legitimate user can send a >party invitation to 20 friends I expect that a SHA-1 based "proof >of work" stamp is not going to be useful to spammers. All that it >will do is make the sale of email addresses more profitable since >there will be a market for "stamped, addresses envelopes" for >which you can charge $100 for 100,000 instead of the current rate >of $50 per million filtered addresses. > > In short, I don't think proof of work based stamps will do >much for reducing spam. I think that to do that we need a more >innovative solution. If there were a ubiquitous micropayment scheme >in circulation then I would go for a system that required cold hard >cash to be sent with each email from someone you have not listed in >your "free list". For most spam you'll get some cash, making large >scale spam less cost effective as an advertising method, and if it >is from someone that you really want to talk to you'll just send the >cash back with your first mail back to the sender. > > So that's my 2 pennies worth (or 2,000,000,000 CPU cycles!) > > Nicko my reply was: >At 12:00 PM 6/8/2001 +0100, Nicko van Someren wrote: >> The problems with proof of work schemes are many and varied. >>The most obvious is the inequality of the amount of processing power >>available to different people, or indeed to the same person in different >>contexts. I send mail from both a 733 MHz G4 PowerPC (in an Apple Mac) >>and a 16 MHz 68000 (in a Palm Pilot). Since the mail recipient can not >>reliably tell from which machine I sent then mail either it is going >>to take a couple of minutes to send a mail from the Palm or it will >>only take a second but I can forge spam as having come from the Palm >>and send hundreds a second from the Mac. To make matters worse, those >>who would spam have already shown themselves to not be beyond using >>the computing resources of others so I think that we can be confident >>that spam would be sent using "stolen stamps". > >on the range of processing power issue, I believe a more realistic >bottom-line would be around a Pentium I/200 MHz. Wouldn't any e-mail >coming from a PalmPilot go through some form of a conduit on the higher >performance machine? That conduit could generate stamps. > >On the point about forging what class of machine as a way of getting out >of generating "expensive" stamps, we were not going to adjust the stamp >based on the senders resources. > >On the point about stolen stamps, I was planning on defeating that by >making hashcash be a client to client protocol and the only thing >intervening machines might do is validate that the stamp is present. > >>[hardware description snipped] >> Given that a $2000 PCI bus card will let me send spam to >>10,000 people in the same time that a legitimate user can send a >>party invitation to 20 friends I expect that a SHA-1 based "proof >>of work" stamp is not going to be useful to spammers. All that it >>will do is make the sale of email addresses more profitable since >>there will be a market for "stamped, addresses envelopes" for >>which you can charge $100 for 100,000 instead of the current rate >>of $50 per million filtered addresses. > >your thoughts are confirming one suspicion which is that even if hashcash >hardware was implemented, it would raise the cost of spamming and cut out >some of the more cost sensitive portions of the market. Remember that >each stamp can only be used once and that it's only good for a finite >period of time (for example, eight days). It would make it more difficult >for a spammer to deliver continual postage because in their >precalculation, they would need to create stamps that would be valid in >the future for a limited period of time. > >This still opens the market for spammer hardware to the at home spammer >where they would sell boards in addition to the list of e-mail addresses. > >> In short, I don't think proof of work based stamps will do >>much for reducing spam. I think that to do that we need a more >>innovative solution. If there were a ubiquitous micropayment scheme >>in circulation then I would go for a system that required cold hard >>cash to be sent with each email from someone you have not listed in >>your "free list". For most spam you'll get some cash, making large >>scale spam less cost effective as an advertising method, and if it >>is from someone that you really want to talk to you'll just send the >>cash back with your first mail back to the sender. > >it would be a short-term solution that would work until the hardware folks >catch up. I think it's worth moving ahead with the technique anyway >because it would create the infrastructure necessary for incorporating >micropayments. > >I need to run out now but I may send more thoughts later. > >I very much appreciate you taking the time to answer my questions. > >---eric to which he replied to my reply... At 05:02 PM 6/8/2001 +0100, Nicko van Someren wrote: >"Eric S. Johansson" wrote: > > > > I would like permission to forward bits of your message to the hashcash > > mailing list. > >Sure, as long as you quote me in context. > > > > The problems with proof of work schemes are many and varied. > > >The most obvious is the inequality of the amount of processing power > > >available to different people, or indeed to the same person in different > > >contexts. I send mail from both a 733 MHz G4 PowerPC (in an Apple Mac) > > >and a 16 MHz 68000 (in a Palm Pilot). Since the mail recipient can not > > >reliably tell from which machine I sent then mail either it is going > > >to take a couple of minutes to send a mail from the Palm or it will > > >only take a second but I can forge spam as having come from the Palm > > >and send hundreds a second from the Mac. To make matters worse, those > > >who would spam have already shown themselves to not be beyond using > > >the computing resources of others so I think that we can be confident > > >that spam would be sent using "stolen stamps". > > > > on the range of processing power issue, I believe a more realistic > > bottom-line would be around a Pentium I/200 MHz. Wouldn't any e-mail > > coming from a PalmPilot go through some form of a conduit on the higher > > performance machine? That conduit could generate stamps. > >I post directly from handhelds all the time but if you were to introduce >HashCash you could indeed mandate a gateway (with suitable sign-on) for >posting from light weight devices. > > > On the point about forging what class of machine as a way of getting out of > > generating "expensive" stamps, we were not going to adjust the stamp based > > on the senders resources. > >I think that having one size fit all will either render prefectly >legitimate posting way to slow in some circumstances or make it >too easy for the commited spammer to produce. > > > On the point about stolen stamps, I was planning on defeating that by > > making hashcash be a client to client protocol and the only thing > > intervening machines might do is validate that the stamp is present. > >Unless you plan to rebuild the structure of the internet's email >system this is going to be sent in the RFC822 header. You can't >have challenge-response stamps for store-and-forward email. Even >if you could deal with this there is no way to stop the turely nasty >spammer from just cracking someone else's machine and using it to >compute stamps for him. > > > >[hardware description snipped] > > > Given that a $2000 PCI bus card will let me send spam to > > >10,000 people in the same time that a legitimate user can send a > > >party invitation to 20 friends I expect that a SHA-1 based "proof > > >of work" stamp is not going to be useful to spammers. All that it > > >will do is make the sale of email addresses more profitable since > > >there will be a market for "stamped, addresses envelopes" for > > >which you can charge $100 for 100,000 instead of the current rate > > >of $50 per million filtered addresses. > > > > your thoughts are confirming one suspicion which is that even if hashcash > > hardware was implemented, it would raise the cost of spamming and cut out > > some of the more cost sensitive portions of the market. Remember that each > > stamp can only be used once and that it's only good for a finite period of > > time (for example, eight days). It would make it more difficult for a > > spammer to deliver continual postage because in their precalculation, they > > would need to create stamps that would be valid in the future for a limited > > period of time. > >I don't see this as a problem. Most people who spam buy in the mailing >list from somewhere. Unless they plan to sit on the list for a long >time (i.e. more than a week) then they could buy in the bulk stamps too. >I bet the address dealers will cut you a deal if you come back for a >second round of stamps too. > > > This still opens the market for spammer hardware to the at home spammer > > where they would sell boards in addition to the list of e-mail addresses. > >Or allow you to log into their secure server and submit a list of >1,000,0000 addresses which would be stamped in a matter of minutes >for a small charge. > > > > In short, I don't think proof of work based stamps will do > > >much for reducing spam. I think that to do that we need a more > > >innovative solution. If there were a ubiquitous micropayment scheme > > >in circulation then I would go for a system that required cold hard > > >cash to be sent with each email from someone you have not listed in > > >your "free list". For most spam you'll get some cash, making large > > >scale spam less cost effective as an advertising method, and if it > > >is from someone that you really want to talk to you'll just send the > > >cash back with your first mail back to the sender. > > > > it would be a short-term solution that would work until the hardware folks > > catch up. I think it's worth moving ahead with the technique anyway > > because it would create the infrastructure necessary for incorporating > > micropayments. > >I'm not sure I agree. The design of an infrastructure for >incorpoating micropayments is easy. Define the XML for the >payment object, base 64 encode the payment, stick it in the >X-payment: header line of the mail. Done. What is needed is >the mail software on the desktops of tens of millions of users >to be changed to be changed to support the system. Furthermore >until you have it on the desktop of everyone with whom you talk >you'll run into endless trouble. > >The crux of the problem is that free email services with no >recourse for misuse are all to easy to get hold of. Unless >you stop accepting mail from mail servers that don't limit the >source and volume of their mail then you will always have spam. >If HotMail were to require some sort of ID before you could get >an account, and refuse to give a second one on the basis of the >same ID if the first account was canceled, then you would >quickly stop getting spam from HotMail. If you simply require >HotMail to compute stamps on every mail that they send then I >can't complain; they've already spent $5,000,000 with nCipher >for crypto hardware to speed up their SSL login and I expect >that they would do the same for the HashCash stamps. > >One way to ensure some sort of recourse is to require that there >is a valid, routable reply address. The vast majority of spam >mails do not have valid reply addresses. If you requried some >sort of challenge-response on the first communication between >two parties that would stop untracable spam. Furthermore such >a system can be automated by those who care but still be made >workable for those who don't want to upgrade their mail software. >If you send me a mail and you don't have an automated responder >you will simply see an authentication message with a request that >you reply with the given subect line. > >Anyway, as I've said before I really don't think proof-of-work >schemes are the solution. Even if you think that people would >accept a ten second per recipient delay before sending their >mail then the spammer can still send 50,000 mails a week on a >standard machine, and they can compute over the week and splurge >them out on some free ISP all in one go. It's not a useful >deterant. > > Nicko to which I replied (yes folks, this is the last bit) >> > On the point about forging what class of machine as a way of getting >> out of >> > generating "expensive" stamps, we were not going to adjust the stamp based >> > on the senders resources. >> >>I think that having one size fit all will either render prefectly >>legitimate posting way to slow in some circumstances or make it >>too easy for the commited spammer to produce. > >understood and I agree. It's just like you've pointed out that it's it's >easy for a spammer to claim to be a low-power machine and thereby enabling >them to get by with less postage. I'm not sure this is a mortal wound but >it certainly bleeds heavily. > >> > On the point about stolen stamps, I was planning on defeating that by >> > making hashcash be a client to client protocol and the only thing >> > intervening machines might do is validate that the stamp is present. >> >>Unless you plan to rebuild the structure of the internet's email >>system this is going to be sent in the RFC822 header. You can't >>have challenge-response stamps for store-and-forward email. > >actually, you can. Think back to the days of UUCP. One model we are >trying on for size would have both MUAs talk to each other and communicate >certain parameters. Yes, it's potentially very slow especially for people >that don't live on the net all the time but only check e-mail once a week. > >> Even >>if you could deal with this there is no way to stop the turely nasty >>spammer from just cracking someone else's machine and using it to >>compute stamps for him. > >yup, that's a hazard and one that can be defended against. The closer one >couples the hashcash environment to the MTA, the more difficult it becomes >for someone to steal services to generate stamps. > > >> > your thoughts are confirming one suspicion which is that even if hashcash >> > hardware was implemented, it would raise the cost of spamming and cut out >> > some of the more cost sensitive portions of the market. Remember that >> each >> > stamp can only be used once and that it's only good for a finite period of >> > time (for example, eight days). It would make it more difficult for a >> > spammer to deliver continual postage because in their precalculation, they >> > would need to create stamps that would be valid in the future for a >> limited >> > period of time. >> >>I don't see this as a problem. Most people who spam buy in the mailing >>list from somewhere. Unless they plan to sit on the list for a long >>time (i.e. more than a week) then they could buy in the bulk stamps too. >>I bet the address dealers will cut you a deal if you come back for a >>second round of stamps too. > >let's see, let's work the numbers. Assuming a X-hashcash:string is >somewhere in the area of 40 bytes, stamps for one million addresses is >roughly 40 MB, 10 million stamps would be 400 MB. One could easily fit >this on a CD or download via a DSL or cable modem. So transport would not >be a big deal for a single Spam client but it would get rather interesting >with thousands of spammer clients. > >Using your numbers, (500 times speed up), a spammer could generate one >stamp every 0.02 seconds (assuming the average stamp computation time was >10 seconds). This means that one million stamps would take 20,000 (5.5 >hours) seconds to generate. If we mixed in to the stamp definition a hash >of the message body as well, then it would be more difficult (but not >impossible) for the spammer to precompute stamps because they would have >to have the message body before they generated stamps. > >one board would allow them to service roughly 130 one million address >customers per month. servicing 1000 customers would take seven >boards. If people wanted to ship more than one piece of spam per month, >then the spam stamp creators would need to increase their capital >investment and ongoing monthly costs which would in turn increase the cost >of spam which would keep some people out of the market. > >This conversation is helping me understand how proof of work calculations >fail and the rate at which they would fail. The big question is can we >exploit the arms race in our favor? I think the answer is yes but only >for a relatively short period of time. But that would allow us to lay the >groundwork for peer-to-peer postage. > >> > This still opens the market for spammer hardware to the at home spammer >> > where they would sell boards in addition to the list of e-mail addresses. >> >>Or allow you to log into their secure server and submit a list of >>1,000,0000 addresses which would be stamped in a matter of minutes >>for a small charge. > >either my math is wrong or I didn't understand just how fast the speedup >would go. You still have the bandwidth issue when transferring stamps >which will most certainly take more than a few minutes. At least with the >bandwidth available to most people. ;-) > >> > it would be a short-term solution that would work until the hardware folks >> > catch up. I think it's worth moving ahead with the technique anyway >> > because it would create the infrastructure necessary for incorporating >> > micropayments. >> >>I'm not sure I agree. The design of an infrastructure for >>incorpoating micropayments is easy. Define the XML for the >>payment object, base 64 encode the payment, stick it in the >>X-payment: header line of the mail. Done. What is needed is >>the mail software on the desktops of tens of millions of users >>to be changed to be changed to support the system. Furthermore >>until you have it on the desktop of everyone with whom you talk >>you'll run into endless trouble. > >well, yes. We do need to change all desktops but we're discussing how to >do this without necessarily replacing the clients. The current model >favors the development of a proxy which does the hashcash >calculation. Obviously, we do want to get this into every e-mail client >on the face of the planet. It's not going to happen but with network >effects, I think we can encourage enough people to make the transition >that it will be worthwhile. > >One of the "encouragements" will be the delivery of messages from hashcash >users to non hashcash users. This message (created by autoresponder) will >instruct the user to click on a URL which will generate a hashcash coin >and a "get out of hashcash jail free" card. The "get out of hashcash jail >free" card will tell the recipient's MUA to release the trapped message. > >The reason why I keep harping on it being an important (but not essential) >precursor to using payments is that it will create the infrastructure for >handling payments, bounces, double spending and more importantly put in >place a code base that will only require minor changes (in theory) to >handle real currency instead of proof of work. > >as Bob will tell you, I have my own reality distortion field that has been >in operation for far longer than I've known Bob. > >>Anyway, as I've said before I really don't think proof-of-work >>schemes are the solution. Even if you think that people would >>accept a ten second per recipient delay before sending their >>mail then the spammer can still send 50,000 mails a week on a >>standard machine, and they can compute over the week and splurge >>them out on some free ISP all in one go. It's not a useful >>deterant. > > 60480 stamps in a week @ ten seconds per stamp assuming the machine runs > 24 by 7. It won't be a Windows box... ;-) > >The analysis we've gone over certainly indicates that this is a high >probability. My experience with spammers from the ISP perspective tells >me that hashcash (or something like it) will make a dent. It won't be >perfect by any stretch of the imagination but I can live with that. > >again, I truly appreciate your advice and information. I will keep you >informed so that what decisions we make in building the hashcash >infrastructure will also be expandable to handle electronic currency when >someone is ready to deploy it. > >---eric --------------------------------------------------------------------- To unsubscribe, e-mail: camram-spam-unsubscribe(a)camram.org For additional commands, e-mail: camram-spam-help(a)camram.org </x-flowed> --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' -- ____________________________________________________________________ "...where annual election ends, tyranny begins;" Thomas Jefferson & Samuel Adams The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage(a)ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- -------------------------------------------------------------------- [View Less]

1 0