- cypherpunks - lists.cpunks.org

Re: design and implementation of "replay prevention windows"
by coderman 31 Oct '13

31 Oct '13

On Thu, Sep 26, 2013 at 4:05 PM, coderman <coderman(a)gmail.com> wrote: > i'm looking for information on the design and implementation of replay > windows in various protocols. oddly enough, this is a surprisingly obtuse subject. it is constrained by: - the encryption and authentication primitives in use - identity and session management concerns. (e.g. key agreement) - and of course, run time resource constraints (memory, CPU, bandwidth, etc.) Syverson's Replay Attack Taxonomy[0] (abridged): - Run external attacks (one run of protocol to attack subsequent runs) - Run internal attacks (using one part of protocol to attack itself in same run) - Classic replay (no contemporaneous or repeated runs needed) - Interleaving attacks (using concurrent runs of a protocol against other runs of the same protocol) provides a foundation for discussing replay attack prevention. so far i've only come across one good reference design and implementation of a replay window: "RFC 4302 - IP Authentication Header - Appendix B: Extended (64-bit) Sequence Numbers" http://tools.ietf.org/html/rfc4302#page-28 and encountered a number of other options for replay prevention in the context of key agreement or transport privacy: - time stamping messages - sequence numbering messages - type tagging messages - identity tagging messages (reflection prevention) - ensuring full information priciple when using hash functions - generating session keys without mutual trust - triple passwords (kerberos) additional resources invited; the journey continues... 0. "A taxonomy of replay attacks [cryptographic protocols]" http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA463948

1 0

apologies to Jacob
by coderman 30 Oct '13

30 Oct '13

he sent a thoughtful and classy response to my character assassination. this and other actions show a desire to improve which i applaud. also suggested: post entire content for future clarity to avoid much ado about nothing... a good practice i will consistently employ henceforth. (i for one enjoy continual web rot as a feature, not a bug. transient information more useful as information source itself :) last but not least, it's a small world. those without reputations may be premium people you're just not familiar with... best regards,

1 0

First cryptoparty in Russia, need celebrety
by Mikhail Shirkov 30 Oct '13

30 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, cpunks! https://www.cryptoparty.in/moscow - we're prepare first cryptoparty in Moscow, Russia. We want video foreword or live from some well known media person. Julian Assange, or Edward Snowden will be perfect )) Can someone help in finding the way to communicate with them, or suggest other interesting personality in cypherpunks world. All best, Mikhail -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJScRlgAAoJEE7a0kqv6Bk3X8EH/1N+4F0Zj6AzrSgqsnULD1p0 ztKQL5aCuLrGLd4ZIiiQmXmQ34bNhUfuG87DwiR6sfjsu3DFFy3yDJlA2IlxRi1+ BgSUM3yKKY52bLv/F/R8JZooiPsjBzm4zP0o41NkcmTZvAd7nN6Zhk5G6/NsrIav v4O0F0ziDKYhnKZabUP/hH6XBpFIczHF+vZcmCNlq63+EXBxMd+sJucPGD8kINNt dOGpxcmYhSiAF/nvLjVfNP7oOvU8IqaQkLHur4xYd5LEa/YgSy+nF7vBPGEvTL0k Tyl4pYDIahH2fNNt5lX0HQ7Im4OcThoSs5aHf5U1u/vrv+tgUiH+pmNd7U5hVL8= =9E4U -----END PGP SIGNATURE-----

3 2

[cryptome] After Der Spiegel " revealed that the roof of the embassy in Berlin
by Haim Barak 30 Oct '13

30 Oct '13

After Der Spiegel " revealed that the roof of the embassy in Berlin placed blocks suspicious , it turns out that these additions are also installed in other cities . Evaluation of equipment is listening to the American National Security Agency Amir Rappaport | 29/10/2013 8:38 What's behind the " boxes " uniformity mirror placed on the roofs of the U.S. embassies in major cities around the world and building additions seem " natural ." It seems to be hiding the most sophisticated listening facilities . Researcher Ronen Solomon discovered the testing facilities identical pictures of the roofs of the U.S. embassies in Beijing , Dubai, Berlin , Moscow , Madrid and Tel Aviv. , After comprehensive research published in the German weekly " Der Spiegel " , following revelations about the eavesdropping carried out by the Americans to the top German leadership . according to " citrus Spiegel " , on the roof of the embassy in Berlin built blocks that appear as part of the structure , but in fact it is made of the facilities 'soft' gray or white. material that does not block the absorption from the listening facilities are behind him. U.S. listening devices '' on the roofs of embassies in the world After the discovery Der Spiegel " revealed for the first time , based on the findings of Solomon , that identical facilities on the roofs of embassies are many other cities , including Tel Aviv. In all cases it seemed as if it were part of the building , but we notice that H"kobiot " are , in fact, building additions . If the findings of the " Citrus Spiegel " right , the savers of listening to the American intelligence agency scattered throughout the world. Tel Aviv is no exception : in addition L"kobiot " is also found on the roof of the U.S. embassy in Tel Aviv , like other major cities , Tel Aviv there are other antennas that are hidden , probably because it's not an intelligence listening equipment . Israeli security officials say they are not surprised by exposing eavesdropping in Germany and that they are aware of the American listening mechanism being not only from the roofs of embassies , but also through satellite listening equipment and other means . The assumption in Israel is the U.S. listening to all the conversations that take place in the Middle East as well as Europe , especially if they are not encrypted . U.S. wiretapping saga continues world countries , and today the U.S. ambassador was invited to Spain to talk with accusations that the U.S. had listened to more than 60 million phone calls to Spain during the month. Ambassador called to talk to the Spanish Minister for European Affairs , Inigo Mendez de Vigo , and the meeting between the two lasted 40 minutes . Madrid at the end of the conversation released a message saying : " Spain to the United States emphasized the importance of maintaining a climate of confidence in bilateral relations , and the importance of awareness extent of the actions , if it turns out that they actually took place , are unacceptable between countries that partnership and friendship ." As in the case of Germany and France , published information originally one of the local newspapers , " El Mundo " , and its origin is a document provided to the leak , a U.S. National Security Agency , former Edward Snowden . http://rotter.net/forum/scoops1/57437.shtml Source: http://www.nrg.co.il/online/1/ART2/517/655.html?hp=1&cat=666&loc=1 -- Haim Barak To Serve and Protect Our Community In God We Trust Israel#: 5353... Email: haim357(a)gmail.com http://haim357.wordpress.com/ <http://haim357.files.wordpress.com/2009/11/banner.jpg> This e-mail is intended only for the named recipient(s) and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No waiver of privilege, confidence or otherwise is intended by virtue of communication via the Internet. Any unauthorized use, dissemination or copying is strictly prohibited. Thank you.

2 1

PRISM too much trouble? Get MUSCULAR
by Gregory Foster 30 Oct '13

30 Oct '13

WaPo (Oct 30) - "#NSA infiltrates [private] links [between] Yahoo, Google data centers worldwide, #Snowden documents say": http://www.washingtonpost.com/world/national-security/nsa-infiltrates-links… > According to a top secret accounting dated Jan. 9, 2013, NSA’s acquisitions directorate sends millions of records every day from Yahoo and Google internal networks to data warehouses at the agency’s Fort Meade headquarters. In the preceding 30 days, the report said, field collectors had processed and sent back 181,280,466 new records — ranging from “metadata,” which would indicate who sent or received e-mails and when, to content such as text, audio and video. > > The NSA’s principal tool to exploit the data links is a project called MUSCULAR, operated jointly with the agency’s British counterpart, GCHQ. From undisclosed interception points, the NSA and GCHQ are copying entire data flows across fiber-optic cables that carry information between the data centers of the Silicon Valley giants. gf -- Gregory Foster || gfoster(a)entersection.org @gregoryfoster <> http://entersection.com/

2 1

Re: Gentlemen do not read each other's mail...
by Bill Stewart 30 Oct '13

30 Oct '13

At 07:57 PM 10/24/2013, Jim Bell wrote: >According to White House spokesman Jay Carney, the United States "is >not monitoring and will not monitor the communications of the chancellor." Which is NSA-speak for "has monitored the chancellor and will again but for now is only monitoring other officials of the German government, not her." And of course gentlemen don't read each others' mail, but she's a lady, so she's fair game.

2 1

crypto & security (urls)
by brian carroll 30 Oct '13

30 Oct '13

// this could also apply to crypto and shoddy security products... Why Apple Wants to Bust Your iPhone http://www.nytimes.com/2013/11/03/magazine/why-apple-wants-to-bust-your-iph… "Economists have theories about market conditions that encourage planned obsolescence. A company has strong incentives to degrade product durability when it has a lot of market power and when consumers don’t have good substitute products to choose from." The Prison Guard With a Gift for Cracking Gang Codes http://nautil.us/blog/the-prison-guard-with-a-gift-for-cracking-gang-codes ABCDEFGHIJKLM ZYXWVUTSRQPON // what are the security implications of discarded or lost electronics // including the deep context of 'archaeology of electronics' equipment // where stored data could be recovered decades, perhaps centuries later. // such that landfills or other sites may also have a data security dimension Nokia phone lost underwater for 3 months, still works http://timesofindia.indiatimes.com/tech/tech-news/hardware/Nokia-phone-lost… (preceding urls via Digg.com) // circuit anomalies, potential RNG or entropy relevance Researchers find a way to predict 'dragon kings' in small circuits http://phys.org/news/2013-10-dragon-kings-small-circuits.html // book cover, note typography... Cryptography: The Science of Secret Writing http://www.reanimationlibrary.org/catalog/items/101675 book search https://www.google.com/search?q= Cryptography%3A The Science of Secret Writing ▧ ▣ ▥

1 0

[tor-dev] Tech report: Evaluation of a libutp-based Tor Datagram Implementation
by Karsten Loesing 30 Oct '13

30 Oct '13

Hi tor devs, Steven, Rob, and I wrote a tech report on evaluating Steven's libutp Tor implementation in the public Tor network and using Chutney and Shadow: https://research.torproject.org/techreports/libutp-2013-10-30.pdf >From the introduction: """ Datagram designs are a promising approach to overcome Tor's performance-related problems. Advantages of datagram designs over stream designs are that they allow better end-to-end congestion management, reduce queue lengths on nodes, and prevent cell loss on one circuit delaying cells on other circuits. In earlier reports we compared possible Tor datagram designs and outlined a testing plan. In this report we evaluate our implementation of a libutp-based Tor datagram design. However, this evaluation does not focus on performance improvements over the current stream-based Tor implementation, because we found that our datagram-based Tor implementation is not mature enough for such a comparison. The focus is rather on our approach to integrate a datagram design into the Tor source code and on setting up test environments to evaluate the new design. We hope that our findings will be useful when further tweaking our libutp-based design or implementing other datagram designs. In the next section we describe our libutp-based Tor implementation in sufficient detail for others to understand our source code and to act as blueprint for implementing other datagram designs. Sections 3 to 5 outline the experimental setup that we used to evaluate our implementation and point out roadblocks that kept us busy longer than necessary. Section 6 concludes the report by sketching out possible next steps. """ As the introduction says, this report doesn't contain shiny performance comparisons, because we kept hitting bugs and then ran out of time. But the report contains detailed instructions for experimenting with libutp and Tor, and it has plenty of footnotes containing starting points and a conclusion with suggested next steps. In short, we had to stop when things started to be fun. Unfortunately, neither of us can work on this topic in the next two months at the very least. If anybody here wants to pick up this work and comes up with bug fixes or even a performance comparison to current Tor, please post your findings here! All the best, Karsten _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

1 0

[tor-talk] Tor Weekly News — October 30th, 2013
by Lunar 30 Oct '13

30 Oct '13

======================================================================== Tor Weekly News October 30th, 2013 ======================================================================== Welcome to the eighteenth issue of Tor Weekly News, the weekly newsletter that covers what is happening in the Tor community. A few highlights from this year’s Google Summer of Code ------------------------------------------------------- The Google Summer of Code 2013 program is over since the end of September. While Nick, Moritz and Damian attended the GSoC Mentor Summit [1] at Google’s main campus last week, here are a few highlights from three of the five projects that were carried through the summer. [1] https://lists.torproject.org/pipermail/tor-reports/2013-October/000367.html Robert worked on enhancing Tor’s Path Selection algorithm. The enhancement [2] uses active measurements of the Round-Trip-Time of Tor circuits. Rejecting the slowest circuits will improve the average latency of Tor circuits. The results of this work will hopefully be integrated into Tor 0.2.5.x and should then be usable by users. Robert wrote: “Working with the Tor community is very encouraging since there are highly skilled and enthusiastic people around. I am really happy to have made that decision and can definitely recommend doing so to others.” [2] https://bitbucket.org/ra_/tor-rtt Johannes Fürmann created a censorship simulation tool that facilitates testing of applications in a simulated network which can be configured and extended to behave like censorship infrastructure in various countries. EvilGenius [3] can be used to do automated “smoke testing”, i.e. find out if code still works properly if a node in the network manipulates traffic in different ways. Other than that, it can be used to automatically test decentralized network applications. “Overall, working with Tor was a great experience and I hope to be able to work with the Tor community again” said Johannes. [3] https://github.com/TheTorProject/EvilGenius Kostas Jakeliūnas worked on creating a searchable and scalable Tor Metrics data archive [4]. This required implementing a Tor relay consensus and descriptor search backend that can encompass most of the archival data available (as of now, the currently running backend covers relays from 2008 up until now). Those curious to browse Tor relay archives — searching for a needle in the very large haystack or just looking around — might enjoy playing with the current test platform [5]. It can run powerful queries on the large dataset without query parameter/span restrictions. Many use cases are supported [6] — for example, since the newest consensus data is always available, the backend can be used in an ExoneraTor-like fashion. Together with Karsten Loesing, Kostas hopes to integrate this system with the current Onionoo [7], hopefully further empowering (and eventually simplifying) the overall Tor Metrics ecosystem. Kostas described the project as “an interesting and challenging one — a lot of work […] to make it robust and truly scalable.” He also added: “Working with Tor was a great experience: I found the developer community to be welcoming indeed, comprised of many people who are professionals in their field. It should be noted that where there are interesting problems and a clear cause, great people assemble.” [4] http://github.com/wfn/torsearch [5] http://ts.mkj.lt:5555/ [6] https://github.com/wfn/torsearch/blob/master/docs/use_cases_examples.md [7] https://www.torproject.org/projects/onionoo.html Collecting data against network level adversaries ------------------------------------------------- “The anonymity of a connection over Tor is vulnerable to an adversary who can observe it in enough places along its route. For example, traffic that crosses the same country as it enters and leaves the Tor network can potentially be deanonymized by an authority in that country who can monitor all network communication.” Karsten Loesing, Anupam Das, and Nikita Borisov began their call for help to Tor relay operators [8] by stating a problem that has recently attracted some interest by the research community. The question “which part of the Internet does a Tor relay lie in” is easy enough to answer, but “determining routes with high confidence has been difficult“ so far. The best source of information could come from the relay operators, as Karsten et al. wrote: “To figure out where traffic travels from your relay, we’d like you to run a bunch of ‘traceroutes’ — network measurements that show the paths traffic takes.” This one-time experiment — for now — is meant to be used by “several researchers, but the leads are Anupam Das, a Ph.D. student at the University of Illinois at Urbana-Champaign, and his advisor Nikita Borisov.” In order to participate, shell scripts are available which automate most of the process. They have been reviewed with care from several members of the Tor community and are available from a Git repository [9]. Since their initial email, Anupam Das has assembled a FAQ regarding scope, resource consumption, and other topics [10]. Be sure to run the scripts if you can. As Karsten, Anupam, and Nikita concluded, “with your help, we will keep improving to face the new challenges to privacy and freedom online.” [8] https://lists.torproject.org/pipermail/tor-relays/2013-October/003113.html [9] https://bitbucket.org/anupam_das/traceroute-from-tor-relays [10] http://web.engr.illinois.edu/~das17/tor-traceroute_v1.html#faq Tor Help Desk Roundup --------------------- Using the Tor Browser Bundle is still proving to be tricky for many Ubuntu users who upgraded from Ubuntu 13.04 to 13.10. The commonly reported error is that users cannot enter text in any of the browser’s text fields, including the URL and search bars. So far this problem appears to be resolved by removing ibus with apt-get before running the Tor Browser. Users who need ibus can try running `export GTK_IM_MODULE=xim`, as documented in Trac ticket #9353 [11]. [11] https://bugs.torproject.org/9353 Miscellaneous news ------------------ David Goulet is asking for a final round of reviews of his rewrite of torsocks [12] so it can replace the old implementation. Lunar has updated the package in Debian experimental to encourage testing [13]. A few portability bugs and a deadlock [14] has already been ironed out in the process. [12] https://trac.torproject.org/projects/tor/ticket/10007 [13] https://lists.torproject.org/pipermail/tor-talk/2013-October/030730.html [14] https://github.com/dgoulet/torsocks/commit/e55eae3d3 The next Tails contributor meeting will be held on November 6th [15]. The present agenda has “firewall exceptions for user-run local services”, “decide what kind of questions go into the FAQ”, among other topics. [15] https://mailman.boum.org/pipermail/tails-dev/2013-October/003956.html Matthew Finkel has sent a draft proposal [16] with possible solutions for Hidden Services backed by multiple servers. Several comments have been made already, with Nick Mathewson giving a heads-up on the work he has started on merging thoughts and discussions in a new specification [17]. [16] https://lists.torproject.org/pipermail/tor-dev/2013-October/005674.html [17] https://gitweb.torproject.org/user/nickm/torspec.git/blob/refs/heads/rendsp… James B. reported [18] a tutorial on bsdnow.tv [19] describing how to setup Tor relays, bridges, exit nodes and hidden services on FreeBSD. Their last week’s podcast called “A Brief Intorduction” [20] features a live demonstration (beginning at 43:52). [18] https://lists.torproject.org/pipermail/tor-talk/2013-October/030800.html [19] http://www.bsdnow.tv/tutorials/tor [20] http://www.bsdnow.tv/episodes/2013_10_23-a_brief_intorduction The Guardian Project has made a new release of its chat application for Android systems. ChatSecure v12 (previously known has Gibberbot) contains several new features [21] and is fully integrated with Orbot. [21] https://guardianproject.info/2013/10/24/chatsecure-v12-provides-comprehensi… Upcoming events --------------- Nov 04 | Workshop on Privacy in the Electronic Society | Berlin, Germany | http://wpes2013.di.unimi.it/ | Nov 05-07 | 20th ACM Conference on Computer and Communications Security | Berlin, Germany | http://www.sigsac.org/ccs/CCS2013/ This issue of Tor Weekly News has been assembled by Lunar, dope457, Matt Pagan, Kostas Jakeliūnas, ra, Johannes Fürmann, Karsten Loesing, and Roger Dingledine. 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 [22], write down your name and subscribe to the team mailing list [23] if you want to get involved! [22] https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews [23] https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

1 0

Re: [tor-dev] bananaphone obfsproxy module
by David Stainton 30 Oct '13

30 Oct '13

Howdy, Thanks. Your obfsproxy is a nice piece of work. Bananaphone + Obfs2 sounds cool! Modular transport chains make a lot of sense... I like modular transports... recently for fun I wrote a VPN in Python Twisted [https://github.com/david415/hushVPN] using twisted consumers and producers. My idea was to have a modular system where transports could easily be swapped. Over UDP it's very fast and I was thinking that maybe I could reuse some of that code to write packet transports for obfsproxy. For instance Tor over ICMP, DNS etc... Obfs2 over Bananaphone over UDP? Right now the david-bananaphone branch is functional code. I've tested it with ssh. SSH over Markov chains! It's laggy but it works. Leif's design plans are interesting... He will be better at explaining it. Perhaps it does something similar to your idea of RHE + Obfs2. Briefly: RHE(CRYPTO(HAMMERTIME(TOR))) - RHE is Banaphone's markov or random weighted Reverse Hash Encoding - CRYPTO is NaCl crypto_stream - Hammertime: "adds chaff to a bytestream to impede passive timing analysis" The goal is to not have any distinguishable patterns in the byte stream. Is that what Obfs2 accomplishes? We will do the crypto_stream secret key exchange using NaCl crypto_box and Elligator; spewing noise after keys are sent Elligator etc... We were thinking to first implement the key exchange without Elligator... and do that part later. I'm working on the basic key exchange to work in branch david-bananaphone-keyexchange https://github.com/david415/obfsproxy/tree/david-bananaphone-keyexchange I'm currently troubleshooting a problem with the message passing... Maybe I do not understand your api well enough... I'm getting strange behavior. It would help if another pair of eyes would look at this. Perhaps later I will formulate a question regarding the obfsproxy api... And I was hoping Leif would help me fix this branch: david-bananaphone-nacl-hammertime https://github.com/david415/obfsproxy/tree/david-bananaphone-nacl-hammertime I wrote a naclStreamEncoder coroutine and made hammertime_rh_server return coroutine chains with the NaCl stream encoders. It doesn't work at all... really a rough draft scribbling of code that makes the BananaPhoneBuffer unit tests through an exception... OK. I will add ALL commandline options to obfsproxy-bananaphone! OK... bandwidth overhead calculations... I'll take a look and run some tests. Onward! David On Tue, Oct 29, 2013 at 7:19 PM, George Kadianakis <desnacked(a)riseup.net> wrote: > Greetings, > > I'm the guy who develops obfsproxy. I recently noticed that you are > writing a bananaphone module for it. The code looks good and you even > understood the pretty-much undocumented obfsproxy API! Nice! > > BTW, I thought I should let you know that we are currently writing > software that combines transports together in chains. This means that > you don't have to worry about data redundancy in bananaphone, since > you can combine it with an obfuscating transport like obfs2 to create > the following chain: > tor data -> |obfs2 encoding| ->|bananaphone encoding| -> tor bridge -> |bananaphone decoding| ->|obfs2 decoding| -> tor data > This would create a bananaphone-encoded channel which transfers > obfs2'ed Tor data (so the bananaphone traffic will look uniform, since > obfs2 data is uniform (whether uniform bananaphone traffic is useful for > censorship circumvention is a different story))). > > FWIW, we are still in the process of writing this transport > combiner. You can read more about it in: > https://trac.torproject.org/projects/tor/ticket/7167 > https://trac.torproject.org/projects/tor/ticket/9744 > https://gitweb.torproject.org/pluggable-transports/obfs-flash.git > We should also create a Wiki page about it soon, I guess. > > Anyway, this transport combiner business means that you only have to > worry about making the bananaphone transport work. It would also be > nice if the transport was configurable, so that we can tweak its > parameters easily. I would also be interested in some bandwidth > overhead calculations :) > > BTW, feel free to send me any questions you have about obfsproxy or > pluggable transports. > > Cheers! > > PS: Feel free to CC the public tor-dev mailing list in your reply if > you want. _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

1 0