July 2018 - cypherpunks-legacy

Kiwi Cops pay for Invading Privacy
by Dave S. 06 Jul '18

06 Jul '18

* Kiwi Cops Pay To Access Encrypted Phone Calls Police in New Zealand will pay Vodafone NZ$1.1 million to be allowed access to encrypted cell phone calls. According to Stuff.co.nz, the Crimes Act in New Zealand already allows the police to intercept phone calls, but they can't decipher the encrypted calls made on the Vodafone network. Paul Swain, the communications minister, said that the money had been allocated for the deal, which was expected to be completed in a few weeks. Meanwhile, the New Zealand police forces are outraged that they have to foot the bill. The president of the Police Association, Greg O'Connor, complained that in the US and Australia the responsibility lies with the service provider to give the police access to calls. "In New Zealand it doesn't happen. In New Zealand the telecommunications companies are creaming it off police," he said. http://www.theregister.co.uk/content/8/17143.html COMMENT: Why should the telecommunications companies foot the bill? They are not in the business of providing freebies to the State. Government agencies should pay for special services just like anyone else. The New Zealand law is much more fair than corresponding legislation in the US and Australia. ************************************************************************** Subscribe to Freematt's Alerts: Pro-Individual Rights Issues Send a blank message to: freematt(a)coil.com with the words subscribe FA on the subject line. List is private and moderated (7-30 messages per month) Matthew Gaylor, 2175 Bayfield Drive, Columbus, OH 43229 (614) 313-5722 ICQ: 106212065 Archived at http://groups.yahoo.com/group/fa/ **************************************************************************

1 0

[Asrg] A New Plan for No Spam / Velocity Indicator
by Hallam-Baker, Phillip 06 Jul '18

06 Jul '18

All, I finally got the revision of my paper 'A Plan for No Spam' through legal and posted to the VeriSign Web Site. It is in PDF (sorry no HTML or plaintext version). http://www.verisign.com/resources/wp/spam/no_spam.pdf I would draw folks attention to the Velocity Indicator described in the Authentication section. This provides an overview of the trusted hardware scheme I devised a few months back. While this is a proprietary technology which we have applied for patent protection on and intend to enforce those rights the scheme requires trusted hardware as a precondition and so the license costs would fall on the harware vendor, not the software developer so the patent would not be a bar to open source implementations (unless there is a GNU CPU planned). This post does not waive the rights VeriSign has to that technology, etc. I will be publishing a fuller paper on the scheme in the large at a later date. However here is a brief summary: The trusted hardware base can be anything that is manufactured in controlled conditions. It could be a palladium class PC, but it could equally be simply a trusted bios, or a PDA feature, or it need not be a PC at all, it could be a peripheral such as a smartcard or even a cable modem, nat box, anything you like. In the simplest version of the scheme a private key, a certificate and the current time are loaded into the TCB during manufacture. To create a message the client asks the TCB to provide an authenticator token bound to the message in the usual fashion. This carries the 'velocity indicator' as an authenticated attribute. Each time a signature is created the velocity indicator is updated to reflect the current rate of signing (you could also have a count of the total signatures over the lifetime of the message). This could be the signatures in the past hour and the past day (say). When a recipient receives a message the velocity indicator and signature are checked. The probability that a message is spam is low if BOTH the signature binds to the specific delivery of the message to the user (i.e. has a valid to: field) and the velocity indicated is low. There are a couple of possible tweaks to protect anonymity. For example it is not necessary that the signature be bound to a particular key. You could use the key installed during manufacture to request new keys. You can even partition the box so you have separate counts for different signers (this could be appropriate for a bulk emailer box). If someone takes a box apart and extracts a key we revoke it - not such a big issue as you might think, the gaming studies we have done show that that would be a very poor strategy for an attacker. In essence what we have done is to reinvent the 'sender-pays' concept - hence my previous arguments against handing over actual cash. It is not necessary to have the expense of a transfer system with all the excessive mechanism to prevent fraud that would entail. All that is necessary is the scarcity property of money which we simulate in an entirely scalable fashion. Unlike hashcash and the like this scheme is not vulnerable to moore's law or assumptions of computational cost. The one big drawback is that is does depend on replacing the hardware of the Internet. This is not actually as big a deal as it sounds since it need not be the PC, it could be a cable modem or a NAT box or even a dongle. We could even sell/rent a box to an ISP that would be built on trusted hardware that would sign all the emails going through their mail servers with the velocity indicator being recorded on a per IP address basis. Bulk mailers that send out mailing lists etc have to be dealt with differently but they cannot conceal the fact they are generating large numbers of emails. There is also a layer to defend against certain obvious abuses and such but I will describe those separately since they don't depend on the trusted hardware. Here I have to untangle an issue that came up with the Borderware people who have had similar ideas to some we came up with but I could not talk about at the time. Phill _______________________________________________ Asrg mailing list Asrg(a)ietf.org https://www1.ietf.org/mailman/listinfo/asrg --- end forwarded text --- 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'

1 0

[liberationtech] Cryptoparty in Los Altos, California
by Rhona Mahony 06 Jul '18

06 Jul '18

The Los Altos Library is letting us offer a Cryptoparty for the general public in a big room with sunlight and wifi on Sunday, May 19, 2013, from 1 pm to 3 pm at 13 South San Antonio Road, Los Altos, California. http://www.sccl.org/locations/hours-and-locations/los-altos/news We hope that our team of teenage volunteer teachers will come again, after their brilliant work at the Cryptoparty on the Stanford University campus on February 24, 2013. http://wildbee.org/2013/03/07/cryptoparty-stanford/ We are covering very basic topics: strong passwords, Https Everywhere, DuckDuckGo and Startpage, ad blockers, Cryptocat, Truecrypt, PGP email with Thunderbird, and Tor. http://fluffernutter.info/cryptoparty/guests.html Come if you like, to teach or learn. ~~Rhona Rhona Mahony rmahony(a)stanford.edu -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- 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

1 0

Re: [tor-relays] Electronic surveillance on major tor exits
by Name Withheld 06 Jul '18

06 Jul '18

This is in response to something from Roger's email on funding exit relays, but I didn't want to derail such an important conversation by responding directly. He mentioned: "At the same time, much of our performance improvement comes from better load balancing -- that is, concentrating traffic on the relays that can handle it better. The result though is a direct tradeoff with relay diversity: on today's network, clients choose one of the fastest 5 exit relays around 25-30% of the time, and 80% of their choices come from a pool of 40-50 relays." This has probably been discussed before, but the first thing that came to my mind was, "how does this simplify surveillance of tor traffic flows?" I know we badly need the performance improvement to continue moving Tor into the mainstream, but when it comes at the cost of a huge amount of all tor requests are exiting through a small subset of nodes, are we baking in a serious vulnerability? Most Tor users probably don't read the manual and follow best practices. I'm sure we've all seen traffic where users are using google maps to find directions from their home, or logging into their true-name mail accounts. When you combine this "State of our Method" with a choke on the number For monied countries that practice aggressive electronic surveillance (China, Russia, and the larger western states), it becomes more and more tempting to set up (or subvert) expensive, fast exits (with tshark and an SSL-stripper on it) and be guaranteed significant amounts of traffic from people that they view as having something to hide. And if the same routing calculus applies to non-exit nodes, they can do the same thing on the non-exit layers, not only improving their correlation attacks, but creating a plausible chance of controlling some tunnels end-to-end. I don't think that's a good situation for anybody other than the monitors. I know that this is one of the reasons why "more nodes" is the largest everyday push (I went from 1 to 3 in the last month), and "we're working on it," and the node-funding push should help some of this, but I think it's important to review what direction relay diversity is heading in the long-term when the metrics start leaning in a certain way. _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ----- 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

1 0

Fwd: Bitcoin P2P e-cash paper
by R.A. Hettinga 06 Jul '18

06 Jul '18

Begin forwarded message: > From: "Satoshi Nakamoto" <satoshi(a)vistomail.com> > Date: October 31, 2008 2:10:00 PM GMT-04:00 > To: cryptography(a)metzdowd.com > Subject: Bitcoin P2P e-cash paper > > I've been working on a new electronic cash system that's fully > peer-to-peer, with no trusted third party. > > The paper is available at: > http://www.bitcoin.org/bitcoin.pdf > > The main properties: > Double-spending is prevented with a peer-to-peer network. > No mint or other trusted parties. > Participants can be anonymous. > New coins are made from Hashcash style proof-of-work. > The proof-of-work for new coin generation also powers the > network to prevent double-spending. > > Bitcoin: A Peer-to-Peer Electronic Cash System > > Abstract. A purely peer-to-peer version of electronic cash would > allow online payments to be sent directly from one party to another > without the burdens of going through a financial institution. > Digital signatures provide part of the solution, but the main > benefits are lost if a trusted party is still required to prevent > double-spending. We propose a solution to the double-spending > problem using a peer-to-peer network. The network timestamps > transactions by hashing them into an ongoing chain of hash-based > proof-of-work, forming a record that cannot be changed without > redoing the proof-of-work. The longest chain not only serves as > proof of the sequence of events witnessed, but proof that it came > from the largest pool of CPU power. As long as honest nodes control > the most CPU power on the network, they can generate the longest > chain and outpace any attackers. The network itself requires > minimal structure. Messages are broadcasted on a best effort basis, > and nodes can leave and rejoin the network at will, accepting the > longest proof-of-work chain as proof of what happened while they > were gone. > > Full paper at: > http://www.bitcoin.org/bitcoin.pdf > > Satoshi Nakamoto > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

1 0

RE: [p2p-hackers] Re: [rest-discuss] Re: RESTful authorization
by Nick Lothian 06 Jul '18

06 Jul '18

> > p2p-hackers, meet rest-discuss. rest-discuss, I'd like to > introduce you to p2p-hackers. > > RESTafarians: there is a long-running conversation on > p2p-hackers about friendnets, also known as darknets, small > world networks, and F2F networks; also capabilities security, > sometimes known as smart contracts. An example thread begins > at http://zgp.org/pipermail/p2p-hackers/2005-August/002915.html > > p2p-hackers: Tyler Close' method for HTTP access control > using nothing but unguessable (and secret) URIs came up on > REST-discuss. That thread begins at > http://groups.yahoo.com/group/rest-discuss/message/5228 In > the context of friendnets, Tyler's scheme is a beautifully > simple way of controlling access using nothing but low-tech > means. Not only does it limit access to trusted parties, it > also allows for transitive relationships. (Warning: his > scheme is counterintuitive, since the dependence on secret > URLs smells like security through obscurity). > Interesting idea. It may not be security via obscurity, but it does appear to ignore a number of practical considerations. For instance, what about the secret URL being passed on in referrer headers to other pages? I think some browsers block it when you go from a secure page to a non-secure page on another site (although I'm unsure about that). The argument that users shouldn't put links to on a secured page is more surprising than the things it is trying to avoid (to me anyway). OTOH, all browsers block HTTP authenticaion credentials from being passed in the referrer header. Nick _______________________________________________ p2p-hackers mailing list p2p-hackers(a)zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 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]

1 0

Fwd: Bitcoin P2P e-cash paper
by R.A. Hettinga 06 Jul '18

06 Jul '18

Begin forwarded message: > From: "Satoshi Nakamoto" <satoshi(a)vistomail.com> > Date: October 31, 2008 2:10:00 PM GMT-04:00 > To: cryptography(a)metzdowd.com > Subject: Bitcoin P2P e-cash paper > > I've been working on a new electronic cash system that's fully > peer-to-peer, with no trusted third party. > > The paper is available at: > http://www.bitcoin.org/bitcoin.pdf > > The main properties: > Double-spending is prevented with a peer-to-peer network. > No mint or other trusted parties. > Participants can be anonymous. > New coins are made from Hashcash style proof-of-work. > The proof-of-work for new coin generation also powers the > network to prevent double-spending. > > Bitcoin: A Peer-to-Peer Electronic Cash System > > Abstract. A purely peer-to-peer version of electronic cash would > allow online payments to be sent directly from one party to another > without the burdens of going through a financial institution. > Digital signatures provide part of the solution, but the main > benefits are lost if a trusted party is still required to prevent > double-spending. We propose a solution to the double-spending > problem using a peer-to-peer network. The network timestamps > transactions by hashing them into an ongoing chain of hash-based > proof-of-work, forming a record that cannot be changed without > redoing the proof-of-work. The longest chain not only serves as > proof of the sequence of events witnessed, but proof that it came > from the largest pool of CPU power. As long as honest nodes control > the most CPU power on the network, they can generate the longest > chain and outpace any attackers. The network itself requires > minimal structure. Messages are broadcasted on a best effort basis, > and nodes can leave and rejoin the network at will, accepting the > longest proof-of-work chain as proof of what happened while they > were gone. > > Full paper at: > http://www.bitcoin.org/bitcoin.pdf > > Satoshi Nakamoto > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

1 0

RE: [p2p-hackers] Re: [rest-discuss] Re: RESTful authorization
by Nick Lothian 06 Jul '18

06 Jul '18

> > p2p-hackers, meet rest-discuss. rest-discuss, I'd like to > introduce you to p2p-hackers. > > RESTafarians: there is a long-running conversation on > p2p-hackers about friendnets, also known as darknets, small > world networks, and F2F networks; also capabilities security, > sometimes known as smart contracts. An example thread begins > at http://zgp.org/pipermail/p2p-hackers/2005-August/002915.html > > p2p-hackers: Tyler Close' method for HTTP access control > using nothing but unguessable (and secret) URIs came up on > REST-discuss. That thread begins at > http://groups.yahoo.com/group/rest-discuss/message/5228 In > the context of friendnets, Tyler's scheme is a beautifully > simple way of controlling access using nothing but low-tech > means. Not only does it limit access to trusted parties, it > also allows for transitive relationships. (Warning: his > scheme is counterintuitive, since the dependence on secret > URLs smells like security through obscurity). > Interesting idea. It may not be security via obscurity, but it does appear to ignore a number of practical considerations. For instance, what about the secret URL being passed on in referrer headers to other pages? I think some browsers block it when you go from a secure page to a non-secure page on another site (although I'm unsure about that). The argument that users shouldn't put links to on a secured page is more surprising than the things it is trying to avoid (to me anyway). OTOH, all browsers block HTTP authenticaion credentials from being passed in the referrer header. Nick _______________________________________________ p2p-hackers mailing list p2p-hackers(a)zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 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]

1 0

Re: [liberationtech] Assange's claim about Tor losing US government support due to WikiLeaks
by liberationtech＠lewman.us 06 Jul '18

06 Jul '18

: I was a bit puzzled by it. So were people at : Cryptome<http://cryptome.org/2012/01/0053.htm>, : who asked Tor about it. Here is what Andrew Lewman (who's on this list) : wrote to them: To be clear, two other news organizations were as well, but only Cryptome published something. : Now, Andrew's statement is carefully worded, i.e. it does allow for the : possibility that Tor lost the USG money but they think it was not : Jacob/WikiLeaks-related. Yes, it was carefully worded. It was cryptome after all. Generally, the journalists were looking for some drama-filled story where there is none. : So it would be good to know whether a) Tor did lose some or all of USG : support between late 2010 and early 2012? and b) there is any evidence to : link this to WL, as Assange did? Tor did not lose existing funding. We applied for some funding right around the time when Jacob's volunteer activities with wikileaks were in the news. We did not get the funding. The lack of funding the proposal was not attributed to 'wikileaks', but rather lack of sufficient funds. I'm taking it at face value that we applied for some funding near the end of a fiscal year and were denied because there wasn't enough money in the budget to fund the project. : Whatever the motivation, USG cutting support to circumvention tools is a : big news item all in itself, regardless of the link to Assange. I wonder : why it wasn't more widely reported, if true - perhaps, by Tor project : itself?- because ultimately this would all be visible on Tor's financial : statements. We just started our 2011 audit, so in a few months we'll have something for public release. -- Andrew http://tpo.is/contact pgp 0x74ED336B _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech ----- 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

1 0

Re: [drone-list] Let's see if this works!
by Chris Nicholas 06 Jul '18

06 Jul '18

I wrote my first computer program at 11 in 1971 in BASIC, and of course, it was a bombing simulator (aircraft is flying so fast, so high, drop the bomb so far away; 1/2 a t^2) My Dad was an aerospace engineer moved to California; we had a private aircraft, and I learned to fly on instruments because I couldn't see over the dashboard. I built balsa wood planes and almost lost my fingers untold times tuning up .049 engines. I did my degree in experimental physics, and worked on classified radar systems, down the hall from a bunch of people on the Tomahawk program. I supported GIS and mapping for Sun Microsystems for many years, and knew a bunch of the guys at DMA (defense mapping agency; forerunner of today's NGA..) I co-founded GlobeXplorer, now DigitalGlobe's online arm, and now work for a little company in Cupertino that starts with 'A'. A lot of us were scared shitless when selective availability, the 100m pseudo-random noise, got turned off on the GPS network, making mass, accurate positioning feasible, because we knew this day would come: DIY-drones. A *very* small payload can pack a wallop. Controlled by the wrong intentions, it can create havoc. "With great power comes great responsiblity." Chris _______________________________________________ drone-list mailing list drone-list(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/drone-list If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. ----- 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

1 0