- cypherpunks - lists.cpunks.org

EFF presentation at SIGINT
by Gregory Foster 27 Jul '13

27 Jul '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 EFF (Jul 5) - "The Politics of Surveillance: Understanding the National Security Agency" by @RaineyReitman: http://www.youtube.com/watch?v=OESf9y-638k Kudos to EFF for fighting the good fight, and kudos to Rainey for synthesizing and presenting a lot of useful information. Mentioned in the talk, Freedom of the Press Foundation (Jul 2) - "Encryption Works: How to Protect Your Privacy in the Age of NSA Surveillance" by @micahflee: https://pressfreedomfoundation.org/encryption-works gf - -- Gregory Foster || gfoster(a)entersection.org @gregoryfoster <> http://entersection.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJR80dJAAoJEMaAACmjGtgj9PwP/2O6erOD9Zciwh1wEWe/RpAm av4b9ZDQhcIwkMbCBKL7ptlKYe5lHIlTXqsrfdOJFRCekJYBoenKbyex2qHGi/S+ 1w0C3Qc2CNtjsIOmynDGS2dNa6YeuaRvZkQZ/BkxG5VTV703+JafaCmS2+bGL3uD oWdlbEgLIn/pGM8Hc0Epa7hsrkKt8CuQWSmqu74uuOtzUfCBYQ77/ojDlcOD/CG4 FQVNyB/PyrXXJKg/gPbhRxoWyEQ3DtfFE5/NwVKnpxCJmYeFQy3XV2ZRvGg63xat m4e49c5irQy4MOsJ6eXCvCy+uWIp7/+ce1BFHVS2SxsdAjpsyT2ZnSi9XwGJ0nGd mp9It1cbZ44N+NbrBOOC6nN3tzdFS/jbnaq2GKjnssRAamEdNG/2cYQUtK8EGtMd nWy6rKuJwNxrk8IIqJFNaACPxyeEkhckkajKoUUJRqGOth7LDv0zZI8Y0mEU07OW cZIIBr5KOn1PhPGbqNbPMJjba3cdBVAOauHmlFlWB/0vqv0x3fv8tUhji5hoZOgC Vb2YyfcdkKcvu4m7iKkLOXtLdbwITmzC8iavYFcrurUh3jdvDNcr4aw2+gJFeFBR p/+yMSfb29hW2/5G3QZUNK24+eFAsiGaUG7XFgS480PvTJV0fFxFDzkW0KTFx9qF vbug+icoNC2cBwG1Ju3o =gnIq -----END PGP SIGNATURE-----

2 1

Fwd: Goldbug.sf.net - Secure Multi-Crypto-Messenger v0.1 released
by grarpamp 27 Jul '13

27 Jul '13

This was bcc'd to me for some unknown reason. Kicking it over to a somewhat more appropriate destination. ---------- Forwarded message ---------- From: Randolph D. <rdohm321(a)gmail.com> Date: 2013/7/26 Subject: Fwd: Goldbug.sf.net - Secure Multi-Crypto-Messenger v0.1 released To: "Randolph D." <rdohm321(a)gmail.com> Does anyone know, if this tool is really secure? Fwd: >>> DOWNLOAD & PRESS RELEASE 2013-07-27 - English / Deutsch weiter unten _____ _ _ ____ / ____| | | | | _ \ | | __ ___ | | __| | |_) |_ _ __ _ | | |_ |/ _ \| |/ _` | _ <| | | |/ _` | | |__| | (_) | | (_| | |_) | |_| | (_| | GoldBug.sf.net \_____|\___/|_|\__,_|____/ \__,_|\__, | __/ | |___/ TITLE: GoldBug.sf.net: Secure Instant Messenger V0.1 has been released - with p2p Email and decentral IRC public chat DOWNLOAD: https://sourceforge.net/projects/goldbug/files/?source=navbar SHORTY: While today thousands of members of the Stop-Watching-Us initiative against surveillance programs like PRISM demonstrated in several cities all around the globe, the EFF in conjunction with the Chaos Computer Club announced a new secure Instant Messenger called: GoldBug.sf.net (http://goldbug.sf.net) Next to chat as well a serverless Email-System and public IRC-Chat has been introduced with Multi-Encryption: a kind of PGP secured with AES over SSL. The new protocol driving this is called "Echo" and has many potentials to be deployed as well for further secure and anonymous communication applications. Some net communities already call it the Neuland Messenger due to the Font Name of the Logo. DESCRIPTION: StopWatching.Us [3] is the initiative half a million web users have signed due to the mass-surveillance programs like PRISM in USA; TEMPORA in Great Britain, MICS in France and XKEYSCORE Software as well deployed e.g. in Germany. While the governments are powerless in regard to prevent foreign agencies to grab internet-line data and to protect their citizens' privacy, the end-users themself are forced to encrypt their communication and stand up for their Human Rights.Thousands of facebook [4] and twitter [5] members declared to demonstrate on the streets on (last) Saturday, July 27, in many decentral cities. As well at this date, the first release of the Secure Instant Messenger GoldBug (http://goldbug.sf.net) has been announced. It uses multi-encryption (a kind of PGP secured with AES over SSL) based on the new echo protocol. While Mega´s "Spy-proof Email" [6] and Pirate Bay Founder´s "Hemlis Mobile Chat" [7] still play around at crypto-parties to find the right development, the open-source project "GoldBug" has chosen the crypto-library "Lib-Spot-On v. 0.1" (based on libGcrypt). The project brought out not only a secure, beautiful and easy to use messenger, but also a new peer protocol behind it: The Echo Protocol. The so called "Echo" creates a peer-2-peer (p2p), respective friend-2-friend (f2f) network, which sends every (strong encrypted) data packet to everyone connected in that network to your node. When you can decrypt the packet, it is yours and readable, if not, you share it with all your connected neighbors. So far so simple. Thinking other Protocols like Jabber, IRC, Torrent etc. based on the Echo opens up a new perspective, as this new kind of Distant-Chat currently shown in the GoldBug Chat Reference Model introduces a detachment with IP addresses and Private/Public Encryption Keys. The Echo Modus can be half or full: half means, to create a dedicated line to your neighbor, and the Echo stops there: Messages are not shared in the half modus. This creates a Web-of-Trust (friend-to-friend)-network within a p2p network (and not vice versa), which is not detectable - as the user defines at each node how to utilize the Echo. This creates a new view on trust and enables a plausible deniability of having ever utilized a Web of Trust (WoT). An important point in times of 100%-surveillance and data retention tracking over several, but stable line-hops. While for example RetroShare [8] as anonymous, decentral network is a good practice model for a Web of Trust, in a Web of Trust with added echo the user can disconnect from the neighbour while keeping the trust and communication - based on the encryption-key (so called "REPLEO") e.g. shown in the GoldBug Messenger Application. Next to chat as well a serverless Email-System and public IRC-Chat has been inlcuded with the GoldBug-release based on the echo protocol and deployed by the Library Libspoton. How the communities of other apps and protocols will evaluate, discuss and test and maybe adopt the security features of the echo protocol, will be shown by some next hybrid applications - and who knows, maybe the Hemlis-Mobile application or the new secure email systems like BitMail [9] or StartMail [10] announced by IXQUICK will integrate the echo as well. WHY THE NAME: GoldBug was the title of a short story of Edgar Allan Poe about cryptograms in 1843. In the short story Mr. LeGrand, who was recently bitten by a gold-colored bug, starts an adventure with two other friends after deciphering a secret message. Poe took advantage of the popularity of cryptography and the success of the story centers on one such cryptogram. "The Gold-Bug" was an instant success and was the most popular and most widely read of Poe's works during his lifetime. It also helped to popularize cryptograms and secured writing. Even 150 Years later a still vaid approach due to the current events in this time. FEATURES: # Instant Messenger Function: Direct Chat, Group Chat, Public Chat. # the integrated Email Client enables encrypted communication without the usage of a central server. You can even email to offline-friends: other friends from you chace the message for you until your friends come online again. # IPV6 Support: As IPV6 integrates the IP-Adress of the senders into each Datapacket, you can drop this with the Gemini-Feature of a detached communication. # The so called Repleo-Feature based on the Echo-Protocols enables the detachment of logged data retention, that means Data Retention has a solution: a TTL+1 function in an elastic network environment. # Optional you can use furthermore the "GoldBug"-Feature, a kind of password, a hybride-multi-encryption, which integrates a kind of pgp with AES end to end encryption, which offers new standards in regard to Instant Messaging and the Agenda Setting of crypto parties. # Hybrid, optional P2P and F2F Modi. # Proxy Modus: Can run over Tor, 127.0.0.1. : 9150 The GoldBug logo uses the Neuland font: "Neuland is a German typeface that was designed in 1923 by Rudolf Koch. It is often used today when an “exotic” or “primitive” look is desired, such as the logos for the Jurassic Park films", says Wikipedia. That has to be regarded just as a coincidence, no one in the net community would ever have the view to call it the Neuland Messenger or subscribe it to a person, e.g. like Rudolf Koch. WEBSITE: http://goldbug.sourceforge.net https://sourceforge.net/projects/goldbug/?source=navbar DOWNLOAD: https://sourceforge.net/projects/goldbug/files/?source=navbar SOURCE: http://spot-on.svn.sourceforge.net/viewvc/spot-on/?view=tar (as well included in the GB windows installer for your convenience) DEVELOPER-SVN: svn checkout svn://svn.code.sf.net/p/spot-on/code/ spot-on-code PROTOCOL-SIMULATION: http://goldbug.sourceforge.net/img/bitmail.gif Add this gadget to your bog or website - it describes, how the echo protocol works. References: [01] http://goldbug.sourceforge.net [02] https://sourceforge.net/projects/goldbug/?source=navbar [03] https://optin.stopwatching.us/ [04] https://www.facebook.com/events/566858663364951/ [05] https://twitter.com/stopwatchingus [06] http://torrentfreak.com/dotcoms-mega-debuts-spy-proof-messaging-this-summer… [07] http://torrentfreak.com/pirate-bay-founder-announces-encrypted-nsa-proof-co… [08] http://retroshare.sourceforge.net/ [09] http://bitmail.sourceforge.net/ [10] https://beta.startmail.com/ >>>>>>>>>>>>>>> GERMAN LANGUAGE / DEUTSCHE SPRACHE: TITEL: GoldBug.sf.net: Sicherer Messenger mit Multi-Crypto V0.1 veröffentlicht - Auch p2p Email und dezentraler IRC Chat DOWNLOAD: https://sourceforge.net/projects/goldbug/files/?source=navbar KURZ: Während heute tausende von Mitgliedrn der Stop-Watching-Us Initiative gegen Massen-Überwachungsprogramme wie PRISM in vielen Städten rund um den Globus demonstrieren, hat die EFF in Verbindung mit dem CCC mitgeteilt, dass es ein neues Sofortnachrichtenprogramm gibt mit dem Namen GoldBug.sf.net (http://goldbug.sf.net) - zu Deutsch: Goldkäfer. Neben dem Chat wird damit auch ein Email-System ohne zentralen Server und ein öffentlicher IRC Chat vorgestellt mit Multi-Verschlüsselung durch eine Art von PGP abgesichert mit den Verschlüsselungsstandards AES über SSL. Das neue Protokoll, das dieses umsetzt, wird "Echo" genannt und hat zahlreiche Potentiale auch für weitere sichere und anonym eKommunikationsanwendungen genutzt zu werden. Einige Netz-Gemeinschaften nennen das Programm inzwischen auch den Neuland-Messenger. BESCHREIBUNG: StopWatching.Us [3] ist die Initiative, bei der mehr als eine halbe Million Internetnutzer unterzeichnet haben und sich gehen Massenüberwachungsprogramme wie PRISM in den USA, TEMPORA in Großbritannien, MICS in Frankeich sowie der XKEYSCORE SOftware, die ebenso auch in Deutschland angewandt wird. Während die Regierungen kraftlos sind in bezug die jeweils außländischen Agenturen davon abzuhalten, die Daten der Internet-Leitungen abzugreifen und ihre Bürger entsprechend zu schützen, sind die End-Nutzer auf sich selbst gestellt, ihre Kommunikation zu verschlüsseln und für ihre Menschen- und Grundrechte auf Privatheit aufzustehen.Tausende von Facebook [4] und Twitter [5] Mitglieder erklärten, am (letzten) Samstag, 27. Juli, in den Straßen von vielen dezentralen Städten demonstrieren zu wollen.Ebenso an diesem Datum wurde die erste Veröffentlichung des Sicheren Sofortnachrichten Programms / INstant Messengers Golbug (http://goldbug.sf.net) bekannt gegeben. Es nutzt eine Multi-Verschlüsselung (eine Art PGP mit zusätzlichem AES und SSL Standard) basierend auf dem neuen Echo-Protokol. Während für das "abhörsichere Email" von Mega [6] oder dem mobilen "Hemlis Chat" [7] des TPB Gründers immer noch auf Verschlüsselungsparties nach dem richtigen Entwicklungsansatz gesucht wird, hat das quelloffene Project "GoldBug" die Verschlüpsselungs-Bibliothek "Lib-Spot-On v. 0.1" (basierend auf libGcrypt) ausgewählt. Das Projet brachte nicht nur einen sicheren, schönen und einfach zu nutzenden Chat Messenger heraus, sondern auch ein neues Peer-Protokol dahinter: Das Echo-Protokol. Das sogenannte "Echo" erstellt ein peer-zu-peer (p2p), respektive ein freund-zu-freund (f2f) netzwerk, welches jedes (stark verschlüsselte) Datenpaket an jeden der vorhandenen Kontaktknoten senden. Wenn das Datenpacket entschlüsselt werden kann, ist es Deins, und es ist lesbar, wenn nicht, wird es weiterhin mit allen verbundenen Netzwerkknoten geteilt. Soweit so einfach. Andere Protokolle insbesondere der Kommuikation wie Jabber, IRC, Torrent etc neu zu denken basierend auf dem Echo eröffnet ganz neue Perspektiven, als dass diese neue Art einer Distanz-Kommunikation derzeit gezeigt in dem Forschungs- und Entwicklungsmodell Gold Bug Chat eine neues Beziehungsgefüge von IP Adressen und privaten-öffentlichen Schlüsseln vorstellt. Der Echo-Modus kann halb oder voll sein: Halb bedeutet, eine direkte Verbindung mit dem Nachbarn herzustelen und das Echo stoppt dann auch dort: Nachrichten werden nicht weiter geteilt in dem Halb-Modus. Somit wird ein Vertrauensgeflecht, ein Web of Trust (WoT) inmitten eines Peer-zu-Peer-Netzwerkes erstellt (und gerade nicht umgekehrt), das nicht erkennbar ist, weil der Nutzer selbst definiert an jedem Knotenpunkt, we er das Echo einsetzen möchte. Das ermöglicht eine neue Sichtweise auf Vertrauen im Interner und eröffnet auch eine Plausible Abstreitbarkeit ein Vertrauensnetzwerk (WoT) jemals eingesetzt zu haben. Das kann ein bedeutender Punkt in Zeiten von 100-Prozent-Überwachung der Netzwerkkommunikation und der Vorratsdatenspeicherung selbst über mehrer, aber stablile Netzwerküberleitungen. Während beispielsweise RetroShare [8] als anonymes und dezentrales Netzwerk ein gutes Anwenderbeispiel für ein Vertrauensnetzwerk (Web of Trust) ist, kann der Nutzer jedoch in einem Web of Trust mit hinzugefügtem Echo sich vom Nachbarn abmelden, während die Vertrauens-Signatur und die Kommunikatiosnfähigkeit erhalten bleibt - basieren auf dem Verschlüsselungs-Code (so genanntes "Repleo") wie es beispielsweise in der Anwendung GoldBug Messenger genutz wird. Neben dem Chat is tauch ein dezentrales, severloses Email System und ein öffentlicher IRC CHat in dem GoldBug Release integriert - ebenso basierend auf dem Echo Protokol, das von der Bibliothel Lib-Spot-On umgesetzt wird. Wie nun die Netzgemeinden von anderen Applikationen und Protokollen die Sicherheitsmerkmale und das Echo protokoll evaluieren, diskutieren, testen und möglicherweise auch übernehmen, wir durch ggf. entstehende Hybrid Applikationen gezeigt werden können. Und wer weiss, möglicherweise werden die Hemlis-Mobilanwendung oder die neuen sicheren Emailsysteme wie BitMail [9] oder StartMail [10], angekündigt durch IXQUICK, das Echo ebenso integrieren. WARUM DER NAME: GoldBug wer der Title einer Kurzgeschichte von Edgar Allan Poe über Cryptogramme im Jahr 1843. In der Geshichte startet Herr LeGrand, der neulich von einem gold-farbenen Käfer gebissen wurde, ein Abenteuer mit zwei weiteren Freunden - nachdem sie eine geheime Botschaft entschlüsseln konnten. Der Dichter Poe hat die Popularität von Verschlüsselung damals schon verhergesehen und der Erfolg der Kurzgeschichte basiert auf der Entschlüsselung eines solchen Kryptogramms. "Der GoldKäfer" war ein sofortiger Erfolg and das am meisten populäre und von vielen Bevölkerngsschichten gelesene Werk von Edgar Allan Poe während seiner gesamten Lebenszeit. Es halt ebenso geholfen, die Verwendung von Kryptogrammen und das Schreiben mit Verschlüsselungstechniken populär zu machen. Auch 150 Jahre später ein gültoger Anspruch in Anbetracht der derzeitigen Ereignisse in dieser Zeit. FEATURES: # Instant Messenger Function: Direct Chat, Group Chat, Public Chat. # the integrated Email Client enables encrypted communication without the usage of a central server. You can even email to offline-friends: other friends from you chace the message for you until your friends come online again. # IPV6 Support: As IPV6 integrates the IP-Adress of the senders into each Datapacket, you can drop this with the Gemini-Feature of a detached communication. # The so called Repleo-Feature based on the Echo-Protocols enables the detachment of logged data retention, that means Data Retention has a solution: a TTL+1 function in an elastic network environment. # Optional you can use furthermore the "GoldBug"-Feature, a kind of password, a hybride-multi-encryption, which integrates a kind of pgp with AES end to end encryption, which offers new standards in regard to Instant Messaging and the Agenda Setting of crypto parties. # Hybrid, optional P2P and F2F Modi. # Proxy Modus: Can run over Tor, 127.0.0.1. : 9150 The GoldBug logo uses the Neuland font: "Neuland is a German typeface that was designed in 1923 by Rudolf Koch. It is often used today when an “exotic” or “primitive” look is desired, such as the logos for the Jurassic Park films", says Wikipedia. That has to be regarded just as a coincidence, no one in the net community would ever have the view to call it the Neuland Messenger or subscribe it to a person, e.g. like Rudolf Koch. WEBSITE: http://goldbug.sourceforge.net https://sourceforge.net/projects/goldbug/?source=navbar DOWNLOAD: https://sourceforge.net/projects/goldbug/files/?source=navbar SOURCE: http://spot-on.svn.sourceforge.net/viewvc/spot-on/?view=tar (as well included in the GB windows installer for your convenience) DEVELOPER-SVN: svn checkout svn://svn.code.sf.net/p/spot-on/code/ spot-on-code PROTOCOL-SIMULATION: http://goldbug.sourceforge.net/img/bitmail.gif Add this gadget to your bog or website - it describes, how the echo protocol works. References: [01] http://goldbug.sourceforge.net [02] https://sourceforge.net/projects/goldbug/?source=navbar [03] https://optin.stopwatching.us/ [04] https://www.facebook.com/events/566858663364951/ [05] https://twitter.com/stopwatchingus [06] http://torrentfreak.com/dotcoms-mega-debuts-spy-proof-messaging-this-summer… [07] http://torrentfreak.com/pirate-bay-founder-announces-encrypted-nsa-proof-co… [08] http://retroshare.sourceforge.net/ [09] http://bitmail.sourceforge.net/ [10] https://beta.startmail.com/

1 0

OHAI. Also: the shortest Internet censorship debate... EVAH
by rysiek 27 Jul '13

27 Jul '13

OHAI Cypherpunks, I am new here, I am not however new to the topics discussed here. I was involved in many a thing related to privacy, anonymity, freedom of speech (and *after* speech), copyright reform, yadda, yadda, etc. Aaanyway, I bring bad tidings from Poland: yesterday morning the Minister of Justice praised David Censormoron's plan to filter porn in the UK and suggested that maybe it should be implemented in Poland as well. I also bring good tidings from Poland: yesterday evening Polish Prime Minister and the Minister of Administration and Digitization (you should get one of those in your country, they're great) strongly denounced any such ideas. Hence, I have been involved in the shortest Internet porn censorship... ever: http://rys.io/en/109 -- Pozdr rysiek

1 0

Re: SSLegance
by grarpamp 26 Jul '13

26 Jul '13

> This does nothing for the case of "server gives their keys to the feds" Can SSH operate in ephemeral mode? > is active MITM a big enough threat that we need to be worrying > about it other than in airports and hotels? Recent news apparently confirms that 'cooperating' with large adversaries centrally is apparently easier and less costly than those same entities screwing around in the wiring closets of such random local places against specific targets.

1 0

Forward Secrecy
by grarpamp 26 Jul '13

26 Jul '13

Check your preferences are set. Somehow I bet there will be a move to this rather soon. Yet note, Dec, a provider simply logging the session keys is still possible. Though much costlier for evil pursue that cheap route if there are lots of small mail providers out there for people to use... who says you have to use the big three, or cannot run a mail service? Or a distributed social / call / sharing platform, etc? Next topic, DHT p2p tech... we are 'always on' right? http://news.cnet.com/8301-13578_3-57595202-38/feds-put-heat-on-web-firms-fo… http://news.cnet.com/8301-13578_3-57591179-38/data-meet-spies-the-unfinishe… http://googleonlinesecurity.blogspot.com/2011/11/protecting-data-for-long-t… http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html

3 2

Feds put heat on Web firms for master encryption keys
by Eugen Leitl 26 Jul '13

26 Jul '13

(See also https://en.wikipedia.org/wiki/Convergence_(SSL) ) http://news.cnet.com/8301-13578_3-57595202-38/feds-put-heat-on-web-firms-fo… Feds put heat on Web firms for master encryption keys Whether the FBI and NSA have the legal authority to obtain the master keys that companies use for Web encryption remains an open question, but it hasn't stopped the U.S. government from trying. Declan McCullagh by Declan McCullagh July 24, 2013 4:00 AM PDT Large Internet companies have resisted the government's demands for encryption keys requests on the grounds that they go beyond what the law permits, according to one person who has dealt with these attempts. (Credit: Declan McCullagh) The U.S. government has attempted to obtain the master encryption keys that Internet companies use to shield millions of users' private Web communications from eavesdropping. These demands for master encryption keys, which have not been disclosed previously, represent a technological escalation in the clandestine methods that the FBI and the National Security Agency employ when conducting electronic surveillance against Internet users. If the government obtains a company's master encryption key, agents could decrypt the contents of communications intercepted through a wiretap or by invoking the potent surveillance authorities of the Foreign Intelligence Surveillance Act. Web encryption -- which often appears in a browser with a HTTPS lock icon when enabled -- uses a technique called SSL, or Secure Sockets Layer. "The government is definitely demanding SSL keys from providers," said one person who has responded to government attempts to obtain encryption keys. The source spoke with CNET on condition of anonymity. The person said that large Internet companies have resisted the requests on the grounds that they go beyond what the law permits, but voiced concern that smaller companies without well-staffed legal departments might be less willing to put up a fight. "I believe the government is beating up on the little guys," the person said. "The government's view is that anything we can think of, we can compel you to do." A Microsoft spokesperson would not say whether the company has received such requests from the government. But when asked whether Microsoft would turn over a master key used for Web encryption or server-to-server e-mail encryption, the spokesperson replied: "No, we don't, and we can't see a circumstance in which we would provide it." Google also declined to disclose whether it had received requests for encryption keys. But a spokesperson said the company has "never handed over keys" to the government, and that it carefully reviews each and every request. "We're sticklers for details -- frequently pushing back when the requests appear to be fishing expeditions or don't follow the correct process," the spokesperson said. Sarah Feinberg, a spokeswoman for Facebook, said that her employer has not received requests for encryption keys from the U.S. government or other governments. In response to a question about divulging encryption keys, Feinberg said: "We have not, and we would fight aggressively against any request for such information." Apple, Yahoo, AOL, Verizon, AT&T, Opera Software's Fastmail.fm, Time Warner Cable, and Comcast declined to respond to queries about whether they would divulge encryption keys to government agencies. Encryption used to armor Web communications was largely adopted not because of fears of NSA surveillance -- but because of the popularity of open, insecure Wi-Fi networks. The "Wall of Sheep," which highlights passwords transmitted over networks through unencrypted links, has become a fixture of computer security conventions, and Internet companies began adopting SSL in earnest about three years ago. "The requests are coming because the Internet is very rapidly changing to an encrypted model," a former Justice Department official said. "SSL has really impacted the capability of U.S. law enforcement. They're now going to the ultimate application layer provider." An FBI spokesman declined to comment, saying the bureau does not "discuss specific strategies, techniques and tools that we may use." NSA director Keith Alexander, shown here at a Washington, D.C. event this month, has said that encrypted data are "virtually unreadable." (Credit: Getty Images) Top secret NSA documents leaked by former government contractor Edward Snowden suggest an additional reason to ask for master encryption keys: they can aid bulk surveillance conducted through the spy agency's fiber taps. One of the leaked PRISM slides recommends that NSA analysts collect communications "upstream" of data centers operated by Apple, Microsoft, Google, Yahoo, and other Internet companies. That procedure relies on a FISA order requiring backbone providers to aid in "collection of communications on fiber cables and infrastructure as data flows past." Mark Klein, who worked as an AT&T technician for over 22 years, disclosed in 2006 (PDF) that he met with NSA officials and witnessed domestic Internet traffic being "diverted" through a "splitter cabinet" to secure room 641A in one of the company's San Francisco facilities. Only NSA-cleared technicians were allowed to work on equipment in the SG3 secure room, Klein said, adding that he was told similar fiber taps existed in other major cities. But an increasing amount of Internet traffic flowing through those fiber cables is now armored against surveillance using SSL encryption. Google enabled HTTPS by default for Gmail in 2010, followed soon after by Microsoft's Hotmail. Facebook enabled encryption by default in 2012. Yahoo now offers it as an option. "Strongly encrypted data are virtually unreadable," NSA director Keith Alexander told (PDF) the Senate earlier this year. Unless, of course, the NSA can obtain an Internet company's private SSL key. With a copy of that key, a government agency that intercepts the contents of encrypted communications has the technical ability to decrypt and peruse everything it acquires in transit, although actual policies may be more restrictive. One exception to that rule relies on a clever bit of mathematics called perfect forward secrecy. PFS uses temporary individual keys, a different one for each encrypted Web session, instead of relying on a single master key. That means even a government agency with the master SSL key and the ability to passively eavesdrop on the network can't decode private communications. Google is the only major Internet company to offer PFS, though Facebook is preparing to enable it by default. Even PFS isn't complete proof against surveillance. It's possible to mount a more advanced attack, sometimes called a man-in-the-middle or active attack, and decode the contents of the communications. A Wired article in 2010 disclosed that a company called Packet Forensics was marketing to government agencies a box that would do precisely that. (There is no evidence that the NSA performs active attacks as part of routine surveillance, and even those could be detected in some circumstances.) The Packet Forensics brochure said that government agencies would "have the ability to import a copy of any legitimate key they obtain (potentially by court order)." It predicted that agents or analysts will collect their "best evidence while users are lulled into a false sense of security afforded by Web, e-mail or VOIP encryption." With a few exceptions, even if communications in transit are encrypted, Internet companies typically do not encrypt e-mail or files stored in their data centers. Those remain accessible to law enforcement or the NSA through legal processes. Leaked NSA surveillance procedures, authorized by Attorney General Eric Holder, suggest that intercepted domestic communications are typically destroyed -- unless they're encrypted. If that's the case, the procedures say, "retention of all communications that are enciphered" is permissible. Valerie Caproni, who was the FBI's general counsel at the time this file photo was taken, told Congress that the government needs "individualized solutions" when "individuals who put encryption on their traffic." (Credit: Getty Images) It's not entirely clear whether federal surveillance law gives the U.S. government the authority to demand master encryption keys from Internet companies. "That's an unanswered question," said Jennifer Granick, director of civil liberties at Stanford University's Center for Internet and Society. "We don't know whether you can be compelled to do that or not." The government has attempted to use subpoenas to request copies of encryption keys in some cases, according to one person familiar with the requests. Justice Department guidelines say subpoenas may be used to obtain information "relevant" to an investigation, unless the request is "unreasonably burdensome." "I don't know anyone who would turn it over for a subpoena," said an attorney who represents Internet companies but has not fielded requests for encryption keys. Even a wiretap order in a criminal case would be insufficient, but a FISA order might be a different story, the attorney said. "I'm sure there's some logic in collecting the haystack." Kurt Opsahl, a senior staff attorney at the Electronic Frontier Foundation, challenged the notion that current law hands the government the power to demand master encryption keys. Even with a FISA order for the private key, Opsahl said, the amount of technical assistance that a company must provide to the NSA or other federal agencies "has a limit." Federal and state law enforcement officials have previously said encrypted communications were beginning to pose an obstacle to lawful surveillance. Valerie Caproni, the FBI's general counsel at the time, told a congressional hearing in 2011, according to a transcript: Encryption is a problem, and it is a problem that we see for certain providers... For individuals who put encryption on their traffic, we understand that there would need to be some individualized solutions if we get a wiretap order for such persons... We are suggesting that if the provider has the communications in the clear and we have a wiretap order, that the provider should give us those communications in the clear. "One of the biggest problems with compelling the [private key] is it gives you access to not just the target's communications, but all communications flowing through the system, which is exceedingly dangerous," said Stanford's Granick. Update, 11:40 a.m. PT: Adds additional comments from a Facebook representative saying the company has not received such requests. Disclosure: McCullagh is married to a Google employee not involved with this issue.

7 7

Forward Secrecy
by grarpamp 26 Jul '13

26 Jul '13

>> Somehow I bet there will be a move to this rather soon. > I have my doubts. Newer SSL libraries have PFS support but whether or > not admins or hosting providers will upgrade to them (or enable PFS > ciphersuites) in a reasonable period of time remains to be seen. For > example, Dreamhost has no immediate plans to upgrade their server > infrastructure to include releases of OpenSSL that support PFS. It could be viewed as an interesting differentiator given the leaks in the news. Who will, who won't? What's their motivation? And does it matter? >> Yet note, Dec, a provider simply logging the session keys is still >> possible. > On the server side, or in their production networks? >From the servers obviously, it's just another log item, master/session key... openssl s_client -connect google.com:https -cipher ECDHE-RSA-AES256-GCM-SHA384 (leaving in the -no_ticket and not using -reconnect as some might not.) >> Though much costlier for evil pursue that cheap route if there are >> lots of small mail providers out there for people to use... who >> says you have to use the big three, or cannot run a mail service? > running a personal mail service is problematic today for several > reasons. > Firstly, the CPU power required to perform decent spam filtering is significant. No, CPU is cheap and largely sits idle, particularly for limited nodes. > it makes more sense to buy the services of a provider who factors that in. You are your own provider, often protected by current provider law. So run things, a mesh, a node, whatever might be of interest. Noting whatever contract law you wish to recognize... > Second, if your server is on a net in CONUS, it can be blackbagged. As is no different than any other country. > Third, antispam blacklists are notorious for deciding that an IP is hostile and blacklisting it Then further develop heuristic science, markov windows, various local classifiers and distributed consensus subscriptions, non soley IP based things. > this is why I stopped running my own, incidentally - > fewer and fewer people were receiving mail from me Stop chickening out and relying on sole services, complain according to your inalienable rights, stay strong and force the market to incorporate and honor distributed ones. There's been talk of coordinating a next gen mix mail deployment, tor/i2p nodes, etc... well those are already sunk costs, same as your own internet connection is, so give them a domain and call it free/bitcoin email up to 25k accounts per node. Today that's a few thousand nodes or 75mil people. Much costlier to produce/demand session keys from 3k nodes around the world than from say google's 10. > A few of us have been testing Retroshare (http://retroshare.sf.net/) Yes, people should openly publish invitations to their technology tests, joining up in them to qualify the technologies and models would be a good thing. We need to break free of this simple 'get it all in one place' mentality. Start signing your current apparrent node into a global DHT. Start looking at things like diaspora. Start distributing services. Start using anonymization and encryption by default.

1 0

Subquantum Crypto Attack
by John Young 26 Jul '13

26 Jul '13

Has subquantum crypto attack been substantiated? arXiv:quant-ph/0203049v2 12 Apr 2002 Subquantum Information and Computation Antony Valentini It is argued that immense physical resources for nonlocal communication, espionage, and exponentially-fast computation are hidden from us by quantum noise, and that this noise is not fundamental but merely a property of an equilibrium state in which the universe happens to be at the present time. It is suggested that non-quantum or nonequilibrium matter might exist today in the form of relic particles from the early universe. We describe how such matter could be detected and put to practical use. Nonequilibrium matter could be used to send instantaneous signals, to violate the uncertainty principle, to distinguish non-orthogonal quantum states without disturbing them, to eavesdrop on quantum key distribution, and to outpace quantum computation (solving NP-complete problems in polynomial time). ... 6 Eavesdropping on Quantum Key Distribution Alice and Bob want to share a secret sequence of bits that will be used as a key for cryptography. During distribution of the key between them, they must be able to detect any eavesdropping by Eve. Three protocols for quantum key distribution BB84 [20], B92 [21], and E91 (or EPR) [22] are known to be secure against classical or quantum attacks (that is, against eavesdropping based on classical or quantum physics) [23]. But these protocols are not secure against a subquantum attack [7]. ... E91 is particularly interesting for it relies on the completeness of quantum theory that is, on the assumption that there are no hidden elements of reality. Pairs of spin-1/2 particles in the singlet state are shared by Alice and Bob, who perform spin measurements along random axes. For coincident axes the same bit sequence is generated at each wing, by apparently random quantum outcomes. The eavesdropper cannot elicit any information from the particles while in transit ..... because there is no information encoded there [22]. But our Eve has access to information outside the domain of quantum theory. She can measure the particle positions while in transit, without disturbing the wavefunction, and so predict the outcomes of spin measurements at the two wings (for the publicly announced axes).12 Thus Eve is able to predict the key shared by Alice and Bob.

1 0

Re: [liberationtech] CJDNS hype
by Eugen Leitl 25 Jul '13

25 Jul '13

----- Forwarded message from Caleb James DeLisle <calebdelisle(a)lavabit.com> ----- Date: Thu, 25 Jul 2013 23:58:34 +0300 From: Caleb James DeLisle <calebdelisle(a)lavabit.com> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] CJDNS hype User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, Sorry for the wait on my part as well, I was very busy last week. On 07/24/2013 05:27 AM, Michael Rogers wrote: > Hi Caleb, > > Thanks for the detailed answers - I'm sorry it's taken me so long to reply. > > - From your answers and the whitepaper I think I'm starting to understand how the switching and routing layers fit together. Would I be right in thinking that each node populates its DHT routing table with nodes that are one or more hops away at the switching layer, and that each hop at the switching layer is a link between two people who know each other? So two nodes that are neighbours at the DHT layer are't necessarily neighbours at the switching/social layer? Exactly. There is no real concept of "neighbors" at the DHT layer but there is address space distance so some nodes are "close". > > And if there's more than one candidate for a slot in the DHT routing table, am I right in thinking that some weighted combination of DHT ping time and label length is used to pick the best candidate, where label length is a combination of path length (at the switching layer) and the degree of the nodes along the path (with short paths and low-degree nodes resulting in shorter labels)? Yup. > >>> More generally, could you explain how CJDNS detects and routes around faults? > >> The simple version is that it pings at random nodes in it's table. When a node is unresponsive, it and anyone who is behind it is dropped from the table. > > A few questions about pings: > > Is it possible for a node that's being pinged to distinguish a ping from a data packet? (What would happen if a node responded correctly to pings but dropped data packets?) Yes, the destination of the ping does know that it's a ping since it needs to respond to it. If it dropped non-pings it would be unreachable and if it dropped layer3 "forward me" messages then it would break the network. > > Can a node on the switching path between the pinger and the pingee distinguish a ping from a data packet? Only by guessing based on size and timing. > > Can a node on the switching path between the pinger and the pingee respond to a ping on the pingee's behalf? Never ever. That's critical to the model that when you are told about a node that you don't trust that it's real until you're sure that you've talked to it. > >>> Could you explain what a route prefix is and how you can be sure that a set of Sybil identities will share a route prefix? How is the route prefix used in detecting and routing around faults? > >> This requires understanding the base method by which cjdns works. When I start up my router, I connect to my specified peers which I have manually configured, these are people whom I know well enough to be assured that they are honest peers. > >> Then my node's switch core assigns each one an interface index. My node then compresses the interface indexes of it's neighbors into a label and inserts the entries with key and label into it's routing table. > >> My node randomly asks nodes in it's routing table for pieces of their table, the question could be simplified as "who do you know, how do you reach them", the response from them is entries taken directly from their routing table. > >> When Alice tells me that she knows Bob and his label is 12345, I take Alice's label which might be abcd and splice them together to have a label which routes from me to Alice to Bob, then after Bob has been pinged along this path, I begin to trust it. > >> This is all an oversimplification, for the actual way it works please consult the whitepaper. > > Thanks, that's a really helpful explanation. So it seems to me that you're using the same observation as SybilGuard and similar systems: although the number of Sybils is unlimited, the number of social edges between Sybils and non-Sybils is limited, so those edges can be used to limit the impact of Sybils. > > It's a cool observation, but the devil's in the details - how do you actually apply that observation in practice? Is there some algorithm in cjdns that detects anomalous routing table entries by examining the prefixes of their switching labels? Other than short paths (labels) being preferred, there are only a few tricks aimed specifically at accidental problems. If I discover route a->b->c->d->w->x->y->z->d then I discover a->b->c->d I will replace the first with the second since I can prove that the first is an indirect representation of the second. There are no specific defenses against sybil attacks but I don't think any are needed given the fact that it's inherently different from a traditional overlay network. > >>> Could you explain why a set of Sybil identities will produce an absurdly long path, and how you can be sure that the routing table has already been populated with fast non-Sybil nodes? > >> Re the absurd length of paths, since more nodes mean more interface indexes, it stands to reason that the more interface indexes will make a longer label. Long labels are avoided by cjdns. > > Bear in mind that Sybils don't have to exist simultaneously. For example, Alice could tell me that she has one neighbour other than me, Bob. I add Bob to my routing table, but later I detect that he's not routing packets correctly, so I drop him. Then Alice tells me that Bob's no longer her neighbour but she has a new neighbour, Carol. I add Carol to my routing table, but later I detect that she's not routing packets correctly, so I drop her. Then Alice tells me that Carol's no longer her > neighbour but she has a new neighbour, Dave... > > At any given time, Alice only has two interfaces, so my labels for Bob, Carol, Dave, etc will be short. > > Obviously this is just a toy example, but it shows that in the general case a Sybil attack doesn't necessarily produce long labels. That's a valid point. We tried to avoid trapping bad behavior and dropping a node because in my opinion it is too brittle and is more likely to introduce a vulnerability. Rather than trust early and detect known bad behavior, cjdns is slow to trust. If you tell me about a new node I will generally not use it until the node I'm currently using fails. This hurts performance but helps stability once the network is functional. > >>> It sounds like you're saying that a Sybil attack won't work because the victims have already populated their routing tables prior to the attack - but what about a new node joining the network after the attack has started? > >> Unless your direct peers (with whom you have a relationship) are sybil nodes, they will keep their tables clean and when you ask them for nodes, they will give you honest nodes whom also have clean tables. You will see a few sybil nodes in your table but they will also come with many valid nodes which will cause the router to slow down it's search for nodes, curtailing their effort to pollute the routing table > > I think I need more detail to understand how this works. I receive routing information from my peers, who receive it from their own peers, etc. Each node is supposed to keep its table clean in order to share clean information with its peers - how does it do that? What operations are performed to clean the information before sharing it with peers? When I receive information from my peers, how do I know whether it's clean? I'm on very unstable ground here, possibly bullshitting... None of this has been simulated so I have to tread carefully. Basically each route has a "value", when a node is inserted, the route to that node has a value of 0, valid ping responses increment the number and timeouts halve it. High numbers and short paths are favored but even a long path is favored over a "0 value route". When you ask a node for routes, it will give you routes which are either: 1. A perfect match to the ip address you queries (even if 0 reach) 2. The highest reach node which is closet to the query target than them. (them == the node to whom you sent the query) Since cjdns populates it's table by periodically querying randomly generated ip addresses, nodes share their best paths causing a sort of "wisdom of the crowd" effect and making it difficult for a sybil attack to gain traction. > >>> Nevertheless, a node could selectively drop traffic bound for certain recursive routing hops, while forwarding other traffic, right? > >> Yes but each node is a recursive router and you're allowed to forward to any router whose address is numerically closer to the destination than your own so if someone is blocking a router, there are many others to choose from. > >> Granted we don't have any tools for detecting that a recursive router is misbehaving and blacklist it but this is an implementation cat-and-mouse game which the protocol will support. > > What mechanism in the protocol would make it possible for future implementations to detect misbehaving nodes? We would have to make some small protocol changes to make this work but what immediately comes to mind is A sending a forward request to B to forward to C then sending a switch level packet to C asking if he got the message. Only A and C need to have the protocol patch and there is already a protocol versioning system in place so this would be trivial to integrate. You have to trust C not to lie to you though. This kind of complexity is why I have tried to avoid explicit detection and why I say "cat and mouse game". > >>> The point I was trying to make in my previous email is that whatever information the packets carry to distinguish one packet from another, the adversary can use that information to target certain packets while maintaining the appearance of high overall reliability. > >> All of the distinguishing information (IPv6 header) is encrypted so the only thing is the routing label (unless you're at the recursive routing layer) > > Sorry, I'm confused about layers again. An IPv6 packet's journey across the network consists of one or more DHT hops, each of which consists of one or more switching hops, is that right? And the IPv6 header is encrypted at each DHT hop, so nodes along the switching path of each DHT hop can only read the switching label (and maybe the DHT address of the next DHT node), but not the IPv6 header? Basically correct, the switch can read the label and likely use it's routing table to determine the address of the next hop but cannot determine the destination. For performance and scalability this feature may be removed. > > How does a node learn the keys of its DHT neighbours in order to encrypt packets that only they can decrypt? (Obviously when its DHT neighbours are also its social neighbours this is easy, but what happens when they're not?) When you do a DHT query, you get the keys (and protocol version numbers) along with the paths. > >>>> Can't spoof a packet because the IPv6 address is the public key hash. > >>> Is every packet signed with the corresponding private key? Seems like that would be expensive. > >> Not signed, encrypted with an authenticator, this is very fast. If you don't know the symmetrical key, you can't modify any packet without me knowing and you obviously can't read my packets. The symmetrical key only needs to be derived once. > > I can see how that would prove to the IPv6 destination that the claimed IPv6 source was the real source of the packet - but I can't see how it would prove to any other node that the claimed source was the real source (presumably the symmetric key is only known to the source and destination). So it seems to me that it's still possible to make /some/ nodes believe that a packet originated from a different source than its true source, which might be a building block for other attacks (eg > manipulating the fault detection mechanism). Your technical analysis is spot on. There is no code which relies on the packets originating from someone else so your attack building block this is not much of an issue for me. Anyway signing packets for all the world to see not only performs poorly but is problematic in other ways. I'm not sure people would want their packets to be linked to their identity forever, they can be decrypted after all, by the destination if no one else. Thanks, Caleb > > Cheers, Michael > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJR8ZF6AAoJECYAmptlsgnW+Y0P/3ts2lZ7LCAJBujU0SZKFHBn EnFdhNfXSqIGKi2wo+8zO8RIvnCC60IcMqljVbkQiqE8jTZBVwsSuIuob9P4pukm E2vwLd7PJ1s4JR/t/vxoKep84s+S5xbfJT/bNDNwBMWZSTVYUeC1a7wmou1d/uIj oBn9ELWk9iRuc5OTkNdXuCNr/tT57QjYuhIuE9KIySZ+a+Jn4TPC6cMaQ90lwbKS UFlcuDU9EvDWp4ATGSqTLhkoPp5cVqj+Kz9iGIBml3xKW50h+6Ol0C10iYo7e/qP 1AcUHa/kU6r2uCSHyQndzoL6PzWmJ4gRz1PCZe+xPPFcBojeBNdApPylmsqfvB5r YBIESmsr4mexEqrwFJqJRlvk0s1iJya47uAH3JH/23xFvYGTV4X05Eh/nrwGxo5z 5swfE2GKHIDA5SoszkGLMLu6SgpFBCQjy6lSlI6VNjh0ElL76lu2uLxxrS6XQQLw YetGH2PTgzZoaSwydG6OnZkTX9Ae5FdMNlIn68RijP26xMAY84W0M6uEEBNZvC+W Vau16LFTk6MmHi7PHtQLkjlEVLuoFX0EsPWHti8l+9my7sRCCVO4n6vD11+FSMg6 uAelkHGJ0TZEC36DiU67wnZpSo7KBBw0re2GOaewATm0NNnwm44a0ie58z7IunCM 0wu9uJ6jNuVmLM9I8C4E =2PzJ -----END PGP SIGNATURE----- -- 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://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[tor-talk] Tor Weekly News — July, 24th 2013
by Eugen Leitl 25 Jul '13

25 Jul '13

----- Forwarded message from dope457 <dope457(a)riseup.net> ----- Date: Wed, 24 Jul 2013 14:06:09 +0200 From: dope457 <dope457(a)riseup.net> To: tor-news(a)lists.torproject.org, tor-talk(a)lists.torproject.org Subject: [tor-talk] Tor Weekly News — July, 24th 2013 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 Reply-To: tor-talk(a)lists.torproject.org ======================================================================== Tor Weekly News July 24th, 2013 ======================================================================== Welcome to the 4th issue of Tor Weekly News, the weekly newsletter that covers what is happening in the great Tor community. The next newsletter is going to be posted to the resurrected tor-news mailing-list. Just subscribe! [1] [1] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-news Summer Development Meeting 2013 ------------------------------- About 40 core Tor contributors gathered over July 22-23 at the Technische Universität München [2] in Germany for this year's Summer Development Meeting [3]. That's quite a number, and as could be expected, there are a huge number of topics up for discussion — the brainstorming session generated around 150. Gunner from Aspiration Tech [4] is once again facilitating the meeting, helping everyone focus on the most pressing issues. Rough notes from some of the break-out sessions are now up on the wiki. A list of the topics and a brief summary of the discussions are given below: * Love for volunteers: strategies for outreach and long-term support; identifying where they're most needed [5] * Censorship and pluggable transports: documenting the now-large number of pluggable transports; discussing countries' differing censorship strategies [6] * Fundraising: funding outlook seems to be positive, although diversity in funding sources is needed to reduce dependency on single institutions like the US Government [7] * Website Translation: notes from a discussion which led to the definition of a new translation review process and a list of actionables [8] * Service infrastructure: multiple fundamental services could use some more love: GetTor (TBB by email), website, Trac, check.tp.org, BridgeDB; shutting down unmaintained services [9] * Operational security: random notes on OpSec for Tor people [10] On the sidelines of the dev meeting, Roger and Jake are doing a public talk on the topic of 'Tor and the Censorship Arms Race'. [11] If you want to meet people who spend their day making Tor a reality, you can join them for a public hack day [12] on Friday, July 26, 2013. Bring your ideas, questions, projects, and technical expertise with you! [2] http://www.tum.de/ [3] https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMee… [4] http://aspirationtech.org/ [5] https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMee… [6] https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMee… [7] https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMee… [8] https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMee… [9] https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMee… [10] https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMee… [11] https://gnunet.org/tor2013tum [12] https://blog.torproject.org/blog/join-us-tor-hack-day-munich-germany Remote descriptor fetching in Stem ---------------------------------- Damian Johnson announced [13] having implemented remote descriptor fetching in Stem [14], a feature to migrate more metrics measurement tools to Python [15]. “Its usage is pleasantly simple” wrote Damian. See for yourself in the excellent documentation! [16] [13] https://lists.torproject.org/pipermail/tor-dev/2013-July/005156.html [14] https://stem.torproject.org/ [15] https://lists.torproject.org/pipermail/tor-dev/2013-May/004924.html [16] https://stem.torproject.org/api/descriptor/remote.html Orbot 12.0.1 call for beta testing ---------------------------------- After a long interval, Nathan Freitas announced the release of a new version of Orbot - a client for the Tor network on Android mobile devices [17]. For Orbot 12.0.1, the developers have “switched versioning styles to a simpler major.minor.bugfix model”, wrote Nathan. He continues with a call for testing: “Since we haven't done a release in a while, and we have some new build tools, I mostly want to make sure I have not done something terribly wrong in the build process. Please confirm back if you are able to successfully use this release.” Updates in 12.0.1: * Updated to Tor 0.2.4.15-RC * flashy screen bug fixed now shows traffic * Stats in notification area * better handling of preference settings * Changes added superuser permission for Cyanogen You can download and start testing this release here [18] or here [19]. [17] https://lists.torproject.org/pipermail/tor-talk/2013-July/029063.html [18] https://rink.hockeyapp.net/apps/92ace552aa5344d1a802decb71525897/ [19] https://guardianproject.info/releases/Orbot-release-12.0.1-beta-1.apk Miscellaneous development news ------------------------------ Lunar reported on the trip to Brussels for LSM 2013. [20] To sum it up, “people are really supportive of what we do these days”. anonym outlined [21] the release schedule for Tails 0.20. intrigeri announced [22] that Tails has switched to a more conventional task manager. It might now be easier for you to see what needs to be done. Have a look at the current list of 496 open issues [23], there might be something waiting just for you. Tor developers would love to find an easier way to debug tor when the daemon crashes. Nick Mathewson came up with an initial piece of code that could (when complete) dump stack traces on assertion, crash, or general trouble to the logs. There's more work to be done before it can be merged in Tor. Feel free to help — especially if you know how to do this on Windows or BSD. [24] Nick Mathewson along with Andrea created a wiki page for initial 0.2.5 series ticket triage [25]. If you have your own agenda for 0.2.5, you should be talking to them now! Kostas Jakeliunas reported on their GSoC project about producing a searchable metrics archive. [26] Arturo reported on his activities on Ooni probe in June. [27] Pierre Lalet announced [28] that he started working on an implementation of the Tor protocol in Python. The intent is to have an independent implementation to test Tor. As the author puts it, "the purpose is NOT to implement a secure or robust implementation that could be an alternative to Tor." Have a look at the code [29]: "Comments, fixes and questions welcome !" [20] https://lists.torproject.org/pipermail/tor-reports/2013-July/000292.html [21] https://mailman.boum.org/pipermail/tails-dev/2013-July/003292.html [22] https://mailman.boum.org/pipermail/tails-dev/2013-July/003297.html [23] https://labs.riseup.net/code/projects/tails/issues [24] https://trac.torproject.org/projects/tor/ticket/9299 [25] https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/025/TicketTr… [26] https://lists.torproject.org/pipermail/tor-dev/2013-July/005158.html [27] https://lists.torproject.org/pipermail/tor-reports/2013-July/000291.html [28] https://lists.torproject.org/pipermail/tor-dev/2013-July/005161.html [29] https://github.com/cea-sec/TorPylle Upcoming events --------------- Jul 26 | Tor Hack Day | München, Germany | https://blog.torproject.org/blog/join-us-tor-hack-day-munich-germany | Jul 31-05 | Tor at OHM | Geestmerambacht, Netherlands | https://ohm2013.org/ | Aug 1-4 | Runa Sandvik @ DEF-CON 21 | Rio Hotel, Las Vegas, USA | https://www.defcon.org/html/defcon-21/dc-21-index.html | Aug 13 | Roger at the 3rd USENIX Workshop on Free and Open Communications on the Internet | Washington, DC, USA | https://www.usenix.org/conference/foci13/ This issue of Tor Weekly News has been assembled by Lunar, dope457, harmony, moskvax, malaparte, whabib, and David Fifield. Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page [30], write down your name and subscribe to the team mailing-list [31] if you want to get involved! [30] https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews [31] https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0