July 2018 - cypherpunks-legacy

Re: [p2p-hackers] OneSwarm status?
by Tomas Isdal 06 Jul '18

06 Jul '18

We are still actively developing OneSwarm, both general maintenance to keep out bugs that pop up, and implementing new features. Best place to follow development is to look at the GitHub project. https://github.com/CSEMike/OneSwarm You description is pretty accurate. Users can download files from within the network, those downloads are designed to be anonymous and be really hard for an adversary to track. If the desired file isn't on the network they can _manually_ fall back to download it as a "normal" torrent (which isn't anonymous) and chose to share it in the private network. Let me know if you have any other questions and thank for "...OneSwarm is the the most interesting p2p project I've heard of in a very long time."! // Tomas > ---------- Forwarded message ---------- > From: David Barrett <dbarrett(a)quinthar.com> > Date: Sun, Nov 20, 2011 at 10:00 PM > Subject: [p2p-hackers] OneSwarm status? > To: theory and practice of decentralized computer networks > <p2p-hackers(a)lists.zooko.com> > > > I think OneSwarm is the the most interesting p2p project I've heard of > in a very long time. If I understand it correctly, OneSwarm is a > standard BitTorrent client that uses an anonymizing layer as a "read > through cache". So it'll attempt to download the torrent anonymously > from other OneSwarm nodes, only falling back on the (non-anonymous) > torrent if needed. I think it's a very clever design, and I'm curious > if anybody has any recent, real-world experience with it? Is the > project still moving forward? > > And perhaps most importantly: how long until this is built in to one > of the major torrent clients and enabled by default? > > -david > _______________________________________________ > p2p-hackers mailing list > p2p-hackers(a)lists.zooko.com > http://lists.zooko.com/mailman/listinfo/p2p-hackers > _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- 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: [cryptography] Key escrow 2012
by Nico Williams 06 Jul '18

06 Jul '18

On Sun, Mar 25, 2012 at 10:55 PM, Marsh Ray <marsh(a)extendedsubset.com> wrote: > On 03/25/2012 11:45 AM, Benjamin Kreuter wrote: >> The US government still wants a No, probably parts of it: the ones that don't have to think of the big picture. The U.S. government is not monolythic. The NSA has shown a number of times that they are interested in strong civilian cryptography for reasons of... national security. In a battle between law enforcement and national security the latter has to win. >> system where encrypted communications can be arbitrarily decrypted, >> they just dress up the argument and avoid using dirty words like "key >> escrow." > > Aside from the deep moral and constitutional problems it poses, does anyone > think the US Govt could have that even from a practical perspective? > > * Some of the largest supercomputers in the world are botnets or are held by > strategic competitor countries. This precludes the old key shortening trick. > > * The Sony PS3 and HDMI cases show just how hard it can be to keep a master > key secure sometimes. Master keys could be quite well protected, but from a > policy perspective it's still a gamble that something won't go wrong which > compromises everyone's real security (cause a public scandal, expose > industrial secrets, etc.). Key escrow == gigantic SPOF. Even if you split the escrow across several agencies and don't use a single master key, it's still concentrating systemic failure potential into too few points. To build a single point of catastrophic failure into one's economic infrastructure is one of the biggest strategic blunders I can imagine (obviously there's worse, such as simply surrendering when one clearly has the upper hand, say). Back in the early 90s this probably wasn't as clear as it is today. > * Am I correct in thinking that computing additional trapdoor functions to > enable USG/TLA/LEA decryption is not free? Mobile devices are becoming the > primary computing devices for many. People may be willing to pay XX% in > taxes, but nobody wants to pay a decrease in performance and battery life to > enable such a misfeature. Most users already pay heavy battery/performance taxes in the form of uninstallable adware built into their devices. The vendors might be the ones to object then since they might have to stop shipping such software. But ultimately this argument depends on how heavy a burden the users end up feeling. For my money the winning argument is the strategic idiocy/insanity of unnecessary SPOFs. Who wants to ever even think of saying to the POTUS "Mr. President, we have a mole, they've stolen the codes for our civilian networks and they've shut them down from the people's shear fear of financial and other losses. It will take months to re-key everything and in the meantime we'll lose X% of GDP. The stock and bond markets have crashed." As time passes X will tend to increase in the event of such a catastrophe. The higher that percentage the more crippling the attack, with derivatives losses becoming overwhelming at small values of X. It could get worse: "Mr. President, we can't even re-key without changing all these hardware dongles that are manufactured by the enemy, who's now not selling them to us." If the point of key escrow is to make law enforcement easier then there are much simpler non-cryptographic solutions -- not ones to your taste or mine perhaps, but certainly ones that don't involve strategic SPOFs. I'm with you: key escrow is necessarily dead letter, at least for the time being and the foreseeable future. Nico -- _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- 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

[i2p] weekly status notes [feb 1]
by jrandom 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi y'all, weekly status time * Index 1) 0.5 status 2) nntp 3) tech proposals 4) ??? * 1) 0.5 status There has been lots of progress on the 0.5 front, with a big batch of commits yesterday. The bulk of the router now uses the new tunnel encryption and tunnel pooling [1], and it has been working well on the test network. There are still some key pieces left to integrate, and the code is obviously not backwards compatible, but I'm hoping we can do some wider scale deployment sometime next week. As mentioned before, the initial 0.5 release will provide the foundation on which different tunnel peer selection/ordering strategies can operate. We'll start with a basic set of configurable parameters for the exploratory and client pools, but later releases will probably include other options for different user profiles. [1]http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=H EAD * 2) nntp As mentioned on LazyGuy's site [2] and my blog [3], we've got a new NNTP server up and running on the network, reachable at nntp.fr.i2p. While LazyGuy has fired up some suck [4] scripts to read in a few lists from gmane, the content is pretty much of, for, and by I2P users. jdot, LazyGuy, and myself did some research into what newsreaders could be used safely, and there seem to be some pretty easy solutions. See my blog for instructions on running slrn [5] to do anonymous newsreading and posting. [2] http://fr.i2p/ [3] http://jrandom.dev.i2p/ [4] http://freshmeat.net/projects/suck/ [5] http://freshmeat.net/projects/slrn/ * 3) tech proposals Orion and others have put up a series of RFCs for various tech issues up on ugha's wiki [6] to help flesh out some of the harder client and app level problems out there. Please use that as the place to discuss naming issues, updates to SAM, swarming ideas, and the like - when you post up there, we can all collaborate at our own place to get a better result. [6] http://ugha.i2p/I2pRfc * 4) ??? Thats all I have for the moment (good thing too, as the meeting starts momentarily). As always, post up your thoughts whenever and wherever :) =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB/+1+GnFL2th344YRAuF5AKDF/FzxzlKs25B2FRLsmC61KRQjlgCg/YjD kF6G0CoDu08TvpEtuzuzH9o= =ewBU -----END PGP SIGNATURE----- _______________________________________________ i2p mailing list i2p(a)i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Re: [p2p-hackers] OneSwarm status?
by Tomas Isdal 06 Jul '18

06 Jul '18

We are still actively developing OneSwarm, both general maintenance to keep out bugs that pop up, and implementing new features. Best place to follow development is to look at the GitHub project. https://github.com/CSEMike/OneSwarm You description is pretty accurate. Users can download files from within the network, those downloads are designed to be anonymous and be really hard for an adversary to track. If the desired file isn't on the network they can _manually_ fall back to download it as a "normal" torrent (which isn't anonymous) and chose to share it in the private network. Let me know if you have any other questions and thank for "...OneSwarm is the the most interesting p2p project I've heard of in a very long time."! // Tomas > ---------- Forwarded message ---------- > From: David Barrett <dbarrett(a)quinthar.com> > Date: Sun, Nov 20, 2011 at 10:00 PM > Subject: [p2p-hackers] OneSwarm status? > To: theory and practice of decentralized computer networks > <p2p-hackers(a)lists.zooko.com> > > > I think OneSwarm is the the most interesting p2p project I've heard of > in a very long time. If I understand it correctly, OneSwarm is a > standard BitTorrent client that uses an anonymizing layer as a "read > through cache". So it'll attempt to download the torrent anonymously > from other OneSwarm nodes, only falling back on the (non-anonymous) > torrent if needed. I think it's a very clever design, and I'm curious > if anybody has any recent, real-world experience with it? Is the > project still moving forward? > > And perhaps most importantly: how long until this is built in to one > of the major torrent clients and enabled by default? > > -david > _______________________________________________ > p2p-hackers mailing list > p2p-hackers(a)lists.zooko.com > http://lists.zooko.com/mailman/listinfo/p2p-hackers > _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- 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: [cryptography] Key escrow 2012
by Nico Williams 06 Jul '18

06 Jul '18

On Sun, Mar 25, 2012 at 10:55 PM, Marsh Ray <marsh(a)extendedsubset.com> wrote: > On 03/25/2012 11:45 AM, Benjamin Kreuter wrote: >> The US government still wants a No, probably parts of it: the ones that don't have to think of the big picture. The U.S. government is not monolythic. The NSA has shown a number of times that they are interested in strong civilian cryptography for reasons of... national security. In a battle between law enforcement and national security the latter has to win. >> system where encrypted communications can be arbitrarily decrypted, >> they just dress up the argument and avoid using dirty words like "key >> escrow." > > Aside from the deep moral and constitutional problems it poses, does anyone > think the US Govt could have that even from a practical perspective? > > * Some of the largest supercomputers in the world are botnets or are held by > strategic competitor countries. This precludes the old key shortening trick. > > * The Sony PS3 and HDMI cases show just how hard it can be to keep a master > key secure sometimes. Master keys could be quite well protected, but from a > policy perspective it's still a gamble that something won't go wrong which > compromises everyone's real security (cause a public scandal, expose > industrial secrets, etc.). Key escrow == gigantic SPOF. Even if you split the escrow across several agencies and don't use a single master key, it's still concentrating systemic failure potential into too few points. To build a single point of catastrophic failure into one's economic infrastructure is one of the biggest strategic blunders I can imagine (obviously there's worse, such as simply surrendering when one clearly has the upper hand, say). Back in the early 90s this probably wasn't as clear as it is today. > * Am I correct in thinking that computing additional trapdoor functions to > enable USG/TLA/LEA decryption is not free? Mobile devices are becoming the > primary computing devices for many. People may be willing to pay XX% in > taxes, but nobody wants to pay a decrease in performance and battery life to > enable such a misfeature. Most users already pay heavy battery/performance taxes in the form of uninstallable adware built into their devices. The vendors might be the ones to object then since they might have to stop shipping such software. But ultimately this argument depends on how heavy a burden the users end up feeling. For my money the winning argument is the strategic idiocy/insanity of unnecessary SPOFs. Who wants to ever even think of saying to the POTUS "Mr. President, we have a mole, they've stolen the codes for our civilian networks and they've shut them down from the people's shear fear of financial and other losses. It will take months to re-key everything and in the meantime we'll lose X% of GDP. The stock and bond markets have crashed." As time passes X will tend to increase in the event of such a catastrophe. The higher that percentage the more crippling the attack, with derivatives losses becoming overwhelming at small values of X. It could get worse: "Mr. President, we can't even re-key without changing all these hardware dongles that are manufactured by the enemy, who's now not selling them to us." If the point of key escrow is to make law enforcement easier then there are much simpler non-cryptographic solutions -- not ones to your taste or mine perhaps, but certainly ones that don't involve strategic SPOFs. I'm with you: key escrow is necessarily dead letter, at least for the time being and the foreseeable future. Nico -- _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- 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

Tor 0.0.9rc6 is out
by Roger Dingledine 06 Jul '18

06 Jul '18

This release improves reliability for clients. It's not perfect yet, but I think it's better. Let me know if it breaks something. tarball: http://tor.freehaven.net/dist/tor-0.0.9rc6.tar.gz signature: http://tor.freehaven.net/dist/tor-0.0.9rc6.tar.gz.asc win32 exe: http://tor.freehaven.net/dist/tor-0.0.9rc6-win32.exe win32 sig: http://tor.freehaven.net/dist/tor-0.0.9rc6-win32.exe.asc (use -dPr tor-0_0_9rc6 if you want to check out from cvs) o Bugfixes on 0.0.9pre: - Clean up some more integer underflow opportunities (not exploitable we think). - While hibernating, hup should not regrow our listeners. - Send an end to the streams we close when we hibernate, rather than just chopping them off. - React to eof immediately on non-open edge connections. o Bugfixes on 0.0.8.1: - Calculate timeout for waiting for a connected cell from the time we sent the begin cell, not from the time the stream started. If it took a long time to establish the circuit, we would time out right after sending the begin cell. - Fix router_compare_addr_to_addr_policy: it was not treating a port of * as always matching, so we were picking reject *:* nodes as exit nodes too. Oops. o Features: - New circuit building strategy: keep a list of ports that we've used in the past 6 hours, and always try to have 2 circuits open or on the way that will handle each such port. Seed us with port 80 so web users won't complain that Tor is "slow to start up". - Make kill -USR1 dump more useful stats about circuits. - When warning about retrying or giving up, print the address, so the user knows which one it's talking about. - If you haven't used a clean circuit in an hour, throw it away, just to be on the safe side. (This means after 6 hours a totally unused Tor client will have no circuits open.) ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Re: [cryptography] bitcoin scalability to high transaction rates
by Alfonso De Gregorio 06 Jul '18

06 Jul '18

On Wed, Jul 20, 2011 at 1:08 PM, Eugen Leitl <eugen(a)leitl.org> wrote: > On Wed, Jul 20, 2011 at 11:56:06AM +0200, Alfonso De Gregorio wrote: > >> I'd better rephrase it in: expectation to have "money backed by >> bitcoins" exhibiting all the desirable properties of a perfect >> currency (ie, stable money) are greatly exaggerated. > > The question is not whether it's perfect, but whether it's good enough. The acceptable distance from a stable currency, as the concept of good enough, depends again on what you are trying to achieve. As a digital currency, and distributed system, Bitcoin is nothing less than truly ingenious. I'm enthusiast about it. However, Bitcoin it's neither local nor should be confused with a system ready to be a sound alternative to the gold standard. And in the debate was rised a question about the eventual effect of having money backed by BTCs instead of gold. My argument stems from there. Btw, there's a nice article published few weeks ago by Nathan Lewis on Forbes: A Return To Basics: What Is Stable Money? http://www.forbes.com/2011/06/30/stable-money-gold.html > -- > Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org alfonso _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- 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

Tor 0.0.9rc6 is out
by Roger Dingledine 06 Jul '18

06 Jul '18

This release improves reliability for clients. It's not perfect yet, but I think it's better. Let me know if it breaks something. tarball: http://tor.freehaven.net/dist/tor-0.0.9rc6.tar.gz signature: http://tor.freehaven.net/dist/tor-0.0.9rc6.tar.gz.asc win32 exe: http://tor.freehaven.net/dist/tor-0.0.9rc6-win32.exe win32 sig: http://tor.freehaven.net/dist/tor-0.0.9rc6-win32.exe.asc (use -dPr tor-0_0_9rc6 if you want to check out from cvs) o Bugfixes on 0.0.9pre: - Clean up some more integer underflow opportunities (not exploitable we think). - While hibernating, hup should not regrow our listeners. - Send an end to the streams we close when we hibernate, rather than just chopping them off. - React to eof immediately on non-open edge connections. o Bugfixes on 0.0.8.1: - Calculate timeout for waiting for a connected cell from the time we sent the begin cell, not from the time the stream started. If it took a long time to establish the circuit, we would time out right after sending the begin cell. - Fix router_compare_addr_to_addr_policy: it was not treating a port of * as always matching, so we were picking reject *:* nodes as exit nodes too. Oops. o Features: - New circuit building strategy: keep a list of ports that we've used in the past 6 hours, and always try to have 2 circuits open or on the way that will handle each such port. Seed us with port 80 so web users won't complain that Tor is "slow to start up". - Make kill -USR1 dump more useful stats about circuits. - When warning about retrying or giving up, print the address, so the user knows which one it's talking about. - If you haven't used a clean circuit in an hour, throw it away, just to be on the safe side. (This means after 6 hours a totally unused Tor client will have no circuits open.) ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Re: [cryptography] bitcoin scalability to high transaction rates
by Alfonso De Gregorio 06 Jul '18

06 Jul '18

On Wed, Jul 20, 2011 at 1:08 PM, Eugen Leitl <eugen(a)leitl.org> wrote: > On Wed, Jul 20, 2011 at 11:56:06AM +0200, Alfonso De Gregorio wrote: > >> I'd better rephrase it in: expectation to have "money backed by >> bitcoins" exhibiting all the desirable properties of a perfect >> currency (ie, stable money) are greatly exaggerated. > > The question is not whether it's perfect, but whether it's good enough. The acceptable distance from a stable currency, as the concept of good enough, depends again on what you are trying to achieve. As a digital currency, and distributed system, Bitcoin is nothing less than truly ingenious. I'm enthusiast about it. However, Bitcoin it's neither local nor should be confused with a system ready to be a sound alternative to the gold standard. And in the debate was rised a question about the eventual effect of having money backed by BTCs instead of gold. My argument stems from there. Btw, there's a nice article published few weeks ago by Nathan Lewis on Forbes: A Return To Basics: What Is Stable Money? http://www.forbes.com/2011/06/30/stable-money-gold.html > -- > Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org alfonso _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- 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: [p2p-hackers] what is on topic
by James A. Donald 06 Jul '18

06 Jul '18

On 2012-11-07 11:02 AM, Changaco wrote: > If you believe what I'm "proposing" is impossible in a P2P network, why > do you bother answering ? Because people like you have murdered over a hundred million people like me, and done so with a lordly glow of moral superiority and with the glowing endorsement of the New York Times and Harvard university. Hence that pious smugness disgusts me. It is not the technical details that are off topic, as the piety and moral superiority. If the global "fairness" of a scheme is on topic, then what constitutes global fairness is on topic. Therefore the "fairness" of a scheme should not be on topic. Bitcoin is intended as a more readily transportable substitute for gold, thus the economic history of the gold standard, and the various financial instruments built on top of gold is on topic. Whether gold or those financial instruments oppressed the poor or unduly advantaged the Jews is not on topic. Economic history of gold is on topic, political history of gold is off topic. Economics 101 is on topic. That economics 101 sounds suspiciously reactionary and supposedly oppressed the poor is off topic. _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- 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