- cypherpunks - lists.cpunks.org

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

Reduced NSA TA History
by John Young 24 Jul '13

24 Jul '13

Th NSA Traffic Analysis history reduced from 11.5MB to 3.2MB: http://cryptome.org/2013/07/nsa-traffic-analysis.pdf

1 0

NSA History of Traffic Analysis
by John Young 24 Jul '13

24 Jul '13

NSA released on 23 July 2013 "The History of Traffic Analysis: World War I-Vietnam." http://www.nsa.gov/about/_files/cryptologic_heritage/publications/misc/traf… It notes the formation of T/A (Traffic Analysis) and C/A (Cryptanalysis) as the two elements of code-breaking, using the mail analogy of T/A for the envelope, C/A for the contents. As noted elsewhere T/A is now publicized as "metadata."

1 0

Join us for a public hack day on Friday, July 26, 2013 in Munich, Germany.
by Eugen Leitl 24 Jul '13

24 Jul '13

https://blog.torproject.org/blog/join-us-tor-hack-day-munich-germany JOIN US - Tor Hack Day, Munich, Germany Posted July 8th, 2013 by kelley in dev meeting hack day Join us for a public hack day on Friday, July 26, 2013 in Munich, Germany. Thank you to our hosts at the Technische Universität München (http://www.tum.de) The agenda and conversations will be determined by you and Tor's team of developers and researchers - so bring your ideas, questions, projects and technical expertise with you! This event is open to the public and free of charge - no RSVP necessary. Friday, July 26, 2013 Start Time: 10:00 am Location: LRZ building, Sminarraum (H.E. 008), Bolzmannstrabe 1, 85748 Garching, Germany. NOTE: the room is to the right of the main entrance. For questions please contact execdir(a)torproject.org

1 0

Re: Python Random Number Generator for OTP
by Bill Stewart 24 Jul '13

24 Jul '13

> > >Â Why not use /dev/random, instead of "ensuring you have entropy"Â > > /dev/random limits the output size to the > estimated entropy. So it has abysmal > performance unless there are high performance entropy sources available. This is for a one-time pad. Limiting the output size to the estimated entropy is a *requirement*. Abysmal performance is fine, because you're going to transfer the pad using a briefcase handcuffed to a courier's arm or some similarly high-cost high-latency physical distribution method, though if you've got a higher-performance entropy source, great. > After the initial seeding this gains very little security in practice. If "gains very little security in practice" is good enough for you, you don't need a one-time pad. Yes, the pseudo-random bits you get out of /dev/urandom will probably be much better than the bits the Russians got by mashing down the keys on typewriters, and you're probably not going to be attacked with the persistence of the Venona decrypters, but don't waste your time using one-time pads unless you're going to use them perfectly. You're much better off using a long-enough RSA key and some Diffie-Hellman session key generation. (Of course, you still want good random numbers for those, but /dev/random is plenty fast enough for that, at least on any non-virtual machine.)

3 3