- cypherpunks - lists.cpunks.org

SnakeoilMailbox?
by rysiek 12 Aug '14

12 Aug '14

Hi there, so, this got sent my way: http://securemailbox.com/ It rings several of stef-defined bells for snakeoil, but maybe I don't see something? Anybody any info on this? -- Pozdr rysiek

1 0

Update your Tors - Tor security advisory: "relay early" traffic confirmation attack
by coderman 11 Aug '14

11 Aug '14

https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-… [see also release notes per below] ''' On July 4 2014 we found a group of relays that we assume were trying to deanonymize users. They appear to have been targeting people who operate or access Tor hidden services. The attack involved modifying Tor protocol headers to do traffic confirmation attacks. The attacking relays joined the network on January 30 2014, and we removed them from the network on July 4. While we don't know when they started doing the attack, users who operated or accessed hidden services from early February through July 4 should assume they were affected. . . . Relays should upgrade to a recent Tor release (0.2.4.23 or 0.2.5.6-alpha), to close the particular protocol vulnerability the attackers used — but remember that preventing traffic confirmation in general remains an open research problem. Clients that upgrade (once new Tor Browser releases are ready) will take another step towards limiting the number of entry guards that are in a position to see their traffic, thus reducing the damage from future attacks like this one. Hidden service operators should consider changing the location of their hidden service.

5 8

Re: cypherpunks Digest, Vol 14, Issue 11
by Andrew White 11 Aug '14

11 Aug '14

> > > Message: 2 > Date: Mon, 11 Aug 2014 08:42:20 +1000 > From: "James A. Donald" <jamesd(a)echeque.com> > To: cypherpunks(a)cpunks.org > Subject: Ripple's consensus algorithm. > Message-ID: <53E7F54C.80805(a)echeque.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Bitcoin's consensus algorithm is weight of computing power, which is OK > as long as weight of computing power aligns with interest in bitcoin > being a useful currency. > > Weight of stake would be better, but so far I am unaware of any > satisfactory proposals for weight of stake. > > This is called "proof of stake" not weight of stake and is different from Ripple's consensus process. > Ripples consensus algorithm is weight of club members, and the process > for getting into the club is opaque, as are the interests and incentives > of the existing club members. > This doesn't really describe how Ripple works. Ripple relies on the agreement of 80% or more of validator nodes per gateway to verify if a transaction took place or not. I write more about this in http://rippleinvestmentguide.com/ > > I would suppose one gets into the club if no existing member blackballs > you, which would be fine if there is already sufficient diversity of > interests within the club. > Only if 80% of the networks validator nodes do that which is in practice not likely to happen on a large enough scale. > > It is not obvious to me how well the ripple consensus algorithm would > work in the event of substantial conflicts between club members, or bad > behavior by club members, or bad things happening to the network. > Has it been analyzed for performance in the event of bad behavior by > some club members? > I'll ping David Schwartz one of the co-inventors about this question.

1 0

Re: [tor-relays] [tor-dev] Hidden service policies
by grarpamp 10 Aug '14

10 Aug '14

On Sun, Jul 20, 2014 at 9:57 PM, Thomas White <thomaswhite(a)riseup.net> wrote: > Mike Hearn, > Simple. If you start filtering anything at all, regardless of what it > is ... then I will > block any connection of your relays to mine > ... > Freedom isn't free unless it is > totally free and a selective reading policy through Tor is not just a > bad idea as stated below, I find it outright insulting to me and > everyone else who cares about the free and open internet. The fact > somebody has the audacity to come to a project like Tor and propose > blacklisting mechanisms is jaw-dropping. > ... > As I recall, you are also the person who raised the idea of coin > tinting or a similar concept in the bitcoin community to identify > "suspect" coins and that backfired spectacularly on you. Yes, that is the person. Though the term is known as 'taint'. One of many discussions from that suggestion is here: https://bitcointalk.org/index.php?topic=333824.0 > so while you are reading this, let me know if you run any relays so I > can avoid them. router riker 207.12.89.16 9001 0 0 fingerprint 8657 6CF6 AA84 496F 62C0 5AFE 9F26 8962 A5F0 B2BD contact Mike Hearn <mike(a)plan99.net> accept *:8333 reject *:* Normally I would thank exits for passing BTC traffic, but now I'm unsure of this one (and a few others), especially given that's the only exit policy of the above node. To identify anon (Tor) coins for marking and tracking?

3 2

Bitcoin Armory not as secure as promised?
by Crypto 10 Aug '14

10 Aug '14

Hello Everyone! It appears that Bitcoin Armory, supposedly one of the most secure Bitcoin wallets isn't so secure after all. Check out this forum post for more details. https://bitcointalk.org/index.php?topic=731315.0 -- Crypto https://www.digitalocean.com/?refcode=b90b690ca5bb

2 1

openPDS - The privacy-preserving Personal Data Store
by Robert Hettinga 10 Aug '14

10 Aug '14

http://openpds.media.mit.edu/#philosophy PUBLICATIONS AND SELECTED PRESS openPDS allows users to collect, store, and give fine-grained access to their data all while protecting their privacy. With the rise of smartphones and their built-in sensors as well as web-apps, an increasing amount of personal data is being silently collected. Personal data–digital information about users’ location, calls, web-searches, and preferences–is undoubtedly the oil of the new economy. However, the lack of access to the data makes it very hard if not impossible for an individual to understand and manage the risks associated with the collected data. Therefore, advancements in using and mining this data have to evolve in parallel with considerations about ownership and privacy. Many of the initial and critical steps towards individuals data ownership are technological. Given the huge number of data sources that a user interacts with on a daily basis, interoperability is not enough. Rather, the user needs to actually own a secured space, a Personal Data Store (PDS) acting as a centralized location where his data live. Owning a PDS would allow the user to view and reason about the data collected. The user can then truly control the flow of data and manage fine-grained authorizations for accessing his data. openPDS: Protecting the Privacy of Metadata through SafeAnswers, PLoS One, 10.1371 (2014) On the Trusted Use of Large-Scale Personal Data, IEEE Data Engineering Bulletin, 35-4 (2012) Big Data Is Opening Doors, but Maybe Too Many, The New-York Times ACLU: AT&T Customer Privacy at Risk, Wall Street Journal - CIO Journal Own your own data, MIT News Big Data : pourquoi nos métadonnées sont-elles plus personnelles que nos empreintes digitales ?, Le Monde Private data gatekeeper stands between you and the NSA, New Scientist MIT Wants You To Own Your Own Data, Not Give It Away, New Scientist MIT-designed system lets you take control of your data, Wired (UK) Getting More Value from Cell-Phone Data, Technology Review openPDS software focuses on control of personal data, Phys.org How to stop the NSA spying on your data, New Scientist Why the collision of big data and privacy will require a new realpolitik, GigaOM 3 Projects Prove Privacy Is Not Dead, Scientific American Reiventing Society in the Wake of Big Data, The Edge New system would allow individuals to pick and choose what data to share with websites, mobile apps, Phys.org A Major ISP Wants to Give Consumers a Cut of the Online Data Market, Vice.com Protecting privacy online, Science Daily Collecte de métadonnées : est-il trop tard pour s’inquiéter?, Radio Canada (FR) Deine Daten gehören dir: Wie ein System namens OpenPDS den Datenschutz revolutionieren könnte, T3N (DE) Visuals openPDS privacy settings (.zip)

2 1

whois hack back
by Digitalfolklore 10 Aug '14

10 Aug '14

1 0

Yahoo To Add PGP Encryption For Email
by grarpamp 09 Aug '14

09 Aug '14

http://tech-beta.slashdot.org/story/14/08/08/1219241/yahoo-to-add-pgp-encry… Unusual to see slashdot pointing out obvious weaknesses in server side/pushed crypto offerings... someone got a clue. Still, more crypto is nice to have out there.

1 0

Re: [tor-talk] [OT] deleting publicly posted content
by grarpamp 08 Aug '14

08 Aug '14

On Fri, Aug 8, 2014 at 10:13 AM, Geoff Down <geoffdown(a)fastmail.net> wrote: > On Fri, Aug 8, 2014, at 01:07 PM, krishna e bera wrote: >> There is no inherent "right to forget" anything that ever happens in >> public, because that would require invading people's minds and archives. >> Court decisions requiring Google to delete correct information from >> search results are misguided - if anything they should require fuller >> search results showing the context and followup events (for example, >> information that may have exonerated the persons in question). >> Archives that are not subject to jurisdictional or changing legal >> currents, are a good use case for Tor hidden services. > We have the right to ephemeral conversation, even in public. > Before mass surveillance and recording became possible, that right was > respected. > The new laws attempt to restore that right. Before, it was a subconscious unthought mode of inter conduct (if not a firmly developed expectation) as outcome of natural limiting circumstances... ie: it wasn't possible to recorde peoples lives, so the context or concept was not thought among people. Just some limited and expensive gov't tax, census, bank type systems.Then cheap computers everywhere hit and the nazis began collecting in mass again. The new laws are a restoration of expectation in the form of an enforceable right, which is now necessary form to do it against the lack of natural limit. The laws are not even close to restoring the formal mode/expectation, and the abuse of imbedding, collection, using and sharing without explicit permission and policy based release from the principal is abhorrent to the former natural way in which they would conduct. Society is slower than data and must exert its control over it and its greed until it has developed to handle such thoughts. Beyond even any reasonable 'need', phone companies maintaining *decades* of CDR's, CC purchases, and CL *not* 'deleting' posts are all equal evils. Turns out phone companies *gave* the metas to govt's and whoever else for whatever use internal and external via chains of weak or strong MOU's, secrets, etc. Now what exactly do you think content mines like CL, your mail, your facebook are doing with your content??? Hint: much worse. It's hugely unethical to the person and society to collect, keep this, let alone process and do whatever with it. It's faster than expectation. There is an inherent ethical right to respect the society and principal person, especially if you are faster. That includes forgetting and not even [ab]using them in the first place. Otherwise you are basically stealing lunch money from retards. That's bad. There's also distinct differences between the service itself doing the (unfortunately now very often) unexpected or contrary to 'delete' recording, and public recording and mining contexts, ethics, etc. Altavista was nice, but did society really need it grown into the GoogleMine? GeoCities --> FaceBookMine? Who will honor your request to delete yourself from old 'non-service-made' public geocities/usenet archives today, from facebook archive 30yr from now? We are still slow and stupid, particularly in hindsight, therefore in a digital age we need now encode that right... just as we had been natural forgotten with time, physically moving, and new associations before then. And to encode not to keep... because we are too slow to make that decision right now.

1 0

get_key_info.sh on FinFisher for public key server
by Nathan Andrew Fain 08 Aug '14

08 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have not checked all files, just a sample. as keys have not been revoked or removed from the public server it would help if someone could execute the following on every gpg'ed file. as individuals revoke their keys, if im not mistaken, we will not be able to document the names of those keys. [get_key_info.sh] #!/bin/bash FILE="$1" for ID in $(gpg -d "$FILE" |& awk '{print $7}' | grep -v 'available'); do #gpg --dry-run --keyserver pgp.mit.edu --recv-keys 0x${ID} echo "ID: 0x$ID" w3m -dump "https://pgp.mit.edu/pks/lookup?search=0x${ID}&op=index" \ | grep pub done LOG: $ ./get_key_info.sh FinIPCatcher.zip.gpg ID: 0x977E9F54 ID: 0x0FC82479 ID: 0x0FEB4CFF ID: 0x6225EAA0 ID: 0x58143658 ID: 0x8E037629 ID: 0x8269976E pub 1024D/66878388 2013-04-17 Alfons Rauscher <alfons.rauscher(a)vervis.de> ID: 0xB03A5EA9 ID: 0xD81082F4 pub 2048R/D81082F4 2012-03-08 Melvin Teoh (Gamma Group) <mt(a)gammmagroup.com> ID: 0xF5946EA8 ID: 0x695D98C9 ID: 0x280AD26F ID: 0xF158ADF2 ID: 0xF166F2CA pub 2048R/3F895273 2013-03-05 Alexander Hagenah <ah(a)primepage.de> ID: 0x7774F144 ID: 0xA7A4AC21 pub 2048R/A7A4AC21 2013-03-05 Hari Purnama (pgp) <hp(a)gammagroup.com> $ ./get_key_info.sh FinIP-Catcher-User-Manual.docx.gpg ID: 0x977E9F54 ID: 0x0FC82479 ID: 0x0FEB4CFF ID: 0x6225EAA0 ID: 0x58143658 ID: 0x8E037629 ID: 0x8269976E pub 1024D/66878388 2013-04-17 Alfons Rauscher <alfons.rauscher(a)vervis.de> ID: 0xB03A5EA9 ID: 0xD81082F4 pub 2048R/D81082F4 2012-03-08 Melvin Teoh (Gamma Group) <mt(a)gammmagroup.com> ID: 0xF5946EA8 ID: 0x695D98C9 ID: 0x280AD26F ID: 0xF158ADF2 ID: 0xF166F2CA pub 2048R/3F895273 2013-03-05 Alexander Hagenah <ah(a)primepage.de> ID: 0x7774F144 ID: 0xA7A4AC21 pub 2048R/A7A4AC21 2013-03-05 Hari Purnama (pgp) <hp(a)gammagroup.com> $ ./get_key_info.sh FinFly-Web-Syllabus.pdf.gpg ID: 0x977E9F54 ID: 0x0FC82479 ID: 0x0FEB4CFF ID: 0x6225EAA0 ID: 0x58143658 ID: 0x8E037629 ID: 0x8269976E pub 1024D/66878388 2013-04-17 Alfons Rauscher <alfons.rauscher(a)vervis.de> ID: 0xB03A5EA9 ID: 0xD81082F4 pub 2048R/D81082F4 2012-03-08 Melvin Teoh (Gamma Group) <mt(a)gammmagroup.com> ID: 0xF5946EA8 ID: 0x695D98C9 ID: 0x280AD26F ID: 0xF158ADF2 ID: 0xF166F2CA pub 2048R/3F895273 2013-03-05 Alexander Hagenah <ah(a)primepage.de> ID: 0x7774F144 ID: 0xA7A4AC21 pub 2048R/A7A4AC21 2013-03-05 Hari Purnama (pgp) <hp(a)gammagroup.com> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlPkqtYACgkQveagdEkPM4CjfACeKDvcaLarLRepieSXiK1blPj+ E/EAoOoWomhgo4dBs3MBr6oIUZkh0pAZ =PpUm -----END PGP SIGNATURE-----

2 3