September 2013 - cypherpunks - lists.cpunks.org

Re: [Cryptography] NSA and cryptanalysis
by John Young 04 Sep '13

04 Sep '13

> > you have to wish that the news reporters publish the actual doc instead > > of uselessly paraphrasing it in an effort to claim interpretive credit. This is the achilles heel of the Snowden drop. PowerPoint, Photoshop and redactions coutured in editorial elaboration of documents not revealed is exactly what officials do to spin material and manipulate the public. The Snowden material needs an untethered, unchoked, and unmarionetted leaker not more commercial journalism dribbling what, unforntunately has become common in the "era of WikiLeaks journalism," is disinfo. And implies the prospect of complicity with authorities under rigging of privileged journalism and coddled D-Noticers. The Guardian has belatedly confessed to that. And WaPo and the NYT have they have and will vet Snowden material with the USG before release. Which suggests cotinuation of a lot more editorial elaboration, TV garavitasing, bowdlerized reports and articles, Dough-Boy books, Op X films, primly steriolized documentaries. In effect, a propaganda push right out of the 1950s through the 2010s configured for cyberwar coldwar. Manchurian Assange, Manning, Snowden featured a la Zizek in the Guardian yesterday. Little crypto will be revealed, except misleading urge to use it as Snowden has done, instead much fancified metadata -- not to overlook the metaphysics of hyping entertaining leakage, now a booming culture of deceit continuing the cult of spy fiction began in days of Art of War. >If there's breaks with any "B" or other respected public algos, >you can bet they keep that well compartmented. Losing some >node somewhere is no big deal. Going dark on all your nodes >as a result of wholesale crypto replacement response would >be a big deal. > >Knowledge of "A" would indeed be interesting to instructive.

2 1

[Bitcoin-development] 0.8.4 released, fixes critical denial-of-service issue
by Eugen Leitl 04 Sep '13

04 Sep '13

----- Forwarded message from Gavin Andresen <gavin(a)bitcoinfoundation.org> ----- Date: Wed, 4 Sep 2013 11:16:35 +1000 From: Gavin Andresen <gavin(a)bitcoinfoundation.org> To: Bitcoin Dev <bitcoin-development(a)lists.sourceforge.net> Subject: [Bitcoin-development] 0.8.4 released, fixes critical denial-of-service issue Bitcoin-Qt version 0.8.4 is now available from: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.4/ This is a maintenance release to fix a critical bug and three security issues; we urge all users to upgrade. There were no changes from 0.8.4 release candidate 2, so if you are running 0.8.4rc2 you do not need to upgrade. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues How to Upgrade -------------- If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). If you are upgrading from version 0.7.2 or earlier, the first time you run 0.8.4 your blockchain files will be re-indexed, which will take anywhere from 30 minutes to several hours, depending on the speed of your machine. 0.8.4 Release notes =================== Security issues --------------- An attacker could send a series of messages that resulted in an integer division-by-zero error in the Bloom Filter handling code, causing the Bitcoin-Qt or bitcoind process to crash. Bloom filters were introduced with version 0.8, so versions 0.8.0 through 0.8.3 are vulnerable to this critical denial-of-service attack. A constant-time algorithm is now used to check RPC password guess attempts; fixes https://github.com/bitcoin/bitcoin/issues/2838 (CVE-2013-4165) Implement a better fix for the fill-memory-with-orphan-transactions attack that was fixed in 0.8.3. See https://bitslog.wordpress.com/2013/07/18/buggy-cve-2013-4627-patch-open-new… for a description of the weaknesses of the previous fix. (CVE-2013-4627) Bugs fixed ---------- Fix multi-block reorg transaction resurrection. Fix non-standard disconnected transactions causing mempool orphans. This bug could cause nodes running with the -debug flag to crash. OSX: use 'FD_FULLSYNC' with LevelDB, which will (hopefully!) prevent the database corruption issues many people have experienced on OSX. Linux: clicking on bitcoin: links was broken if you were using a Gnome-based desktop. Fix a hang-at-shutdown bug that only affects users that compile their own version of Bitcoin against Boost versions 1.50-1.52. Other changes ------------- Checkpoint at block 250,000 to speed up initial block downloads and make the progress indicator when downloading more accurate. Thanks to everybody who contributed to the 0.8.4 releases! ---------------------------------------------------------- Pieter Wuille Warren Togami Patrick Strateman pakt Gregory Maxwell Sergio Demian Lerner grayleonard Cory Fields Matt Corallo Gavin Andresen ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development ----- 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 — September 4th, 2013
by Eugen Leitl 04 Sep '13

04 Sep '13

----- Forwarded message from Lunar <lunar(a)torproject.org> ----- Date: Wed, 4 Sep 2013 12:51:54 +0200 From: Lunar <lunar(a)torproject.org> To: tor-news(a)lists.torproject.org, tor-talk(a)lists.torproject.org Subject: [tor-talk] Tor Weekly News — September 4th, 2013 User-Agent: Mutt/1.5.21 (2010-09-15) Reply-To: tor-talk(a)lists.torproject.org ======================================================================== Tor Weekly News September 4th, 2013 ======================================================================== Welcome to the tenth issue of Tor Weekly News, the weekly newsletter that covers what is happening in the skyrocketing Tor community. Serious network overload ------------------------ <borealis> if it really is a coordinated attack from a bot twice the size of the regular tor network i'm much surprised tor is still usable at all — #tor, 2013-09-02 18:38 UTC The tremendous influx of new clients that started mid-August [1] is stretching the current Tor network and software to its limits. Several relay operators reported their relays to be saturated [2] by the amount of connections and circuits that relays currently have to handle [3]. Mike Perry wishing to “compare load characteristics since 8/19 for nodes with different types of flags” issued a call to relay operators [4]: “especially useful [are] links/graph images for connection counts, bandwidth, and CPU load since 8/19.” It was reported on IRC that on some relays, only one circuit was successfully created out of four attempts. This unfortunately implies that clients retry to build more circuits, resulting in even more load on Tor relays. The tor 0.2.4 series introduced a new circuit extension handshake dubbed “ntor” [5]. This new handshake is faster (especially on the relay side) than the original circuit extension handshake, “TAP”. Roger Dingledine came up with a patch to prioritize circuit creations using ntor over TAP [6]. Various observers reported that these overwhelming unidentified new clients were likely to be using Tor 0.2.3. Prioritizing ntor is then likely to make them less a burden for the network, and should help the network to function despite being overloaded by circuit creations. Sathya and Isis both reported the patch to work. Nick Mathewson pointed out a few issues in the current implementation [7] but overall it looks like a band-aid good enough for the time being. [1] https://metrics.torproject.org/users.html?graph=direct-users&start=2013-08-… [2] https://lists.torproject.org/pipermail/tor-relays/2013-August/002594.html [3] https://lists.torproject.org/pipermail/tor-relays/2013-August/002589.html [4] https://lists.torproject.org/pipermail/tor-relays/2013-August/002612.html [5] https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/216-nt… [6] https://bugs.torproject.org/9574#comment:10 [7] https://bugs.torproject.org/9574#comment:12 Latest findings regarding traffic correlation attacks ----------------------------------------------------- Erik de Castro Lopo pointed tor-talk readers [8] to a new well written paper named “Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries.” [9] To be presented at the upcoming CCS 2013 conference [10] this November in Berlin, Aaron Johnson, Chris Wacek, Rob Jansen, Micah Sherr, and Paul Syverson describe their experiments on traffic correlation attacks. This research paper follows on a long series of earlier research papers to better understand how Tor is vulnerable to adversaries controlling portions of the Tor network or monitoring users and relays at the network level. Roger Dingledine wrote to tor-talk readers [11]: “Yes, a big enough adversary can screw Tor users. But we knew that. I think it’s great that the paper presents the dual risks of relay adversaries and link adversaries, since most of the time when people are freaking out about one of them they’re forgetting the other one. And we really should raise the guard rotation period. If you do their compromise graphs again with guards rotated every nine months, they look way different.” One tricky question with raising guard rotation period [12] is: “How do we keep clients properly balanced to match the guard capacities?” [13] It is also probably another signal for any Tails supporter that wishes to help implementing guard persistence [14]. “I have plans for writing a blog post about the paper, to explain what it means, what it doesn’t mean, what we should do about it, and what research questions remain open” wrote Roger. Let’s stay tuned! [8] https://lists.torproject.org/pipermail/tor-talk/2013-September/029755.html [9] http://www.ohmygodel.com/publications/usersrouted-ccs13.pdf [10] http://www.sigsac.org/ccs/CCS2013/ [11] https://lists.torproject.org/pipermail/tor-talk/2013-September/029756.html [12] https://bugs.torproject.org/8240 [13] https://bugs.torproject.org/9321 [14] https://labs.riseup.net/code/issues/5462 A peek inside the Pirate Browser -------------------------------- Torrent-sharing website The Pirate Bay started shipping a custom browser — the Pirate Browser — on August 10th. They advertised using Tor to circumvent censorship but unfortunately did not provide any source code for their project. Matt Pagan examined the contents of the package [15] in order to get a better idea of what it was. He compared the contents of the Pirate Browser 0.6b archive using cryptographic checksums to the contents of the Tor Browser Bundle 2.3.25-12 (en-US version). According to Matt’s findings the Pirate Browser includes unmodified versions of tor 0.2.3.25 and Vidalia 0.2.20. The tor configuration contains slight deviation from the one shipped with the Tor Browser Bundle. One section labeled “Configured for speed” unfortunately shows wrong understanding of the Tor network. Roger Dingledine commented in a subsequent email [16]: “Just for the record, the three lines here don’t help speed much (or maybe at all).” The remaining configuration change that “probably has the biggest impact on performance“, according to Roger, excludes exit nodes from Denmark, Ireland, United Kindgom, the Netherlands, Belgium, Italy, China, Iran, Finland, and Norway. “Whether it improves or reduces performance [Roger] cannot say, though. Depends on a lot of complex variables around Internet topologies.” The browser itself is based of Firefox 23.0, with FoxyProxy configured to use Tor only for a few specific addresses [17], and a few extra bookmarks. Later, Matt also highlighted [18] that some important extensions of the Tor Browser, namely HTTPS Everywhere, NoScript, and Torbutton were also missing from the Pirate Browser. In any cases, the Pirate Browser is unlikely to explain the sudden influx of new Tor clients. grarpamp forwarded an email exchanged with the Pirate Browser admin contact [19] which shows that numbers (550 000 known direct downloads) and dates (“most downloads during the first week”) do not match. [15] https://lists.torproject.org/pipermail/tor-talk/2013-August/029703.html [16] https://lists.torproject.org/pipermail/tor-talk/2013-August/029729.html [17] http://piratebrowser.com/piratebrowser_patterns.json [18] https://lists.torproject.org/pipermail/tor-talk/2013-August/029707.html [19] https://lists.torproject.org/pipermail/tor-talk/2013-August/029736.html Monthly status reports for August 2013 -------------------------------------- The wave of regular monthly reports from Tor project members for the month of August has begun. Sherief Alaa released his report first [20], followed by reports from George Kadianakis [21], Lunar [22], Arturo Filastò [23], Colin C. [24], Arlo Breault [25], Philipp Winter [26], Roger Dingledine [27], Karsten Loesing [28], and Isis Lovecruft [29]. The latter also caught up with June [30], and July [31]. [20] https://lists.torproject.org/pipermail/tor-reports/2013-September/000314.ht… [21] https://lists.torproject.org/pipermail/tor-reports/2013-September/000315.ht… [22] https://lists.torproject.org/pipermail/tor-reports/2013-September/000316.ht… [23] https://lists.torproject.org/pipermail/tor-reports/2013-September/000317.ht… [24] https://lists.torproject.org/pipermail/tor-reports/2013-September/000318.ht… [25] https://lists.torproject.org/pipermail/tor-reports/2013-September/000319.ht… [26] https://lists.torproject.org/pipermail/tor-reports/2013-September/000320.ht… [27] https://lists.torproject.org/pipermail/tor-reports/2013-September/000321.ht… [28] https://lists.torproject.org/pipermail/tor-reports/2013-September/000322.ht… [29] https://lists.torproject.org/pipermail/tor-reports/2013-September/000323.ht… [30] https://lists.torproject.org/pipermail/tor-reports/2013-September/000324.ht… [31] https://lists.torproject.org/pipermail/tor-reports/2013-September/000325.ht… Help Desk Roundup ----------------- This week Tor help desk saw an increase in the number of users wanting to download or install Orbot. Orbot can be downloaded from the Google Play store, the Amazon App store, f-droid.org, and guardianproject.info. Guides on using Orbot can be found on the Guardian Project’s Orbot page [32], or on the Tor Project’s Android page [33]. It looks like Orbot is currently inaccessible from the Google Play store in Iran. Please join the discussion on tor-talk [34] if you have input about the latter. [32] https://guardianproject.info/apps/orbot/ [33] https://www.torproject.org/docs/android.html [34] https://lists.torproject.org/pipermail/tor-talk/2013-August/029684.html All versions of the Tor Browser Bundle which include tor 0.2.4.x have been reported to work in Iran. This includes the latest Pluggable Transport Bundle, the 3.0 alpha series, and the 2.4 beta series. Follow our Farsi blog [35] for more Iran related news. [35] https://fa-blog.torproject.org/ Miscellaneous news ------------------ The next Tails contributors meeting [36] will happen on IRC on September 4th at 8pm UTC (10pm CEST). “Every one interested in contributing to Tails is welcome” to join #tails-dev on the OFTC network. [36] https://mailman.boum.org/pipermail/tails-dev/2013-August/003523.html Yawning Angel has been “designing a UDP based protocol to serve as the bulk data transport for something along the lines of ‘obfs3, but over UDP’.” They are soliciting feedback on their initial draft of the Lightweight Obfuscated Datagram Protocol (LODP) [37]. [37] https://lists.torproject.org/pipermail/tor-dev/2013-August/005334.html Kévin Dunglas announced [38] their work on a PHP library for the Tor Control Port [39], released under the MIT license. [38] https://lists.torproject.org/pipermail/tor-dev/2013-August/005340.html [39] https://github.com/dunglas/php-torcontrol/ Kathy Brade and Mark Smith have released a first patch [40] for Mozilla’s update mechanism which “successfully updated TBB on Linux, Windows, and Mac OS ‘in the lab’ using both incremental and ‘full replace’ updates.” This is meant for the 3.x series of the Tor Browser Bundle and is still a work a progress, but this is a significant milestone toward streamlined updates for TBB users. [40] https://bugs.torproject.org/4234#comment:19 Erinn Clark announced [41] that the software powering trac.torproject.org has been upgraded to version 0.12.3. Among several other improvements, this new version allowed Erinn to experiment with the often requested Git integration [42]. [41] https://lists.torproject.org/pipermail/tor-dev/2013-August/005328.html [42] https://lists.torproject.org/pipermail/tor-dev/2013-September/005346.html David Goulet has released the second release candidate for the 2.0 rewrite of Torsocks [43]: “Please continue to test, review and contribute it!” [43] https://lists.torproject.org/pipermail/tor-dev/2013-September/005359.html Much to her surprise, Erinn Clark found a “fraudulent PGP key with [her] email address” on the keyservers [44]. “Do not under any circumstances trust anything that may have ever been signed or encrypted with this key” of short id 0xCEE1590D. She reminded that the Tor Project official signatures are listed on the project’s website [45]. [44] https://lists.torproject.org/pipermail/tor-dev/2013-September/005348.html [45] https://www.torproject.org/docs/signing-keys.html Philipp Winter published the final paper version [46] of the ScrambleSuit pluggable transport [47], dubbed “A Polymorphic Network Protocol to Circumvent Censorship”. [46] http://www.cs.kau.se/philwint/pdf/wpes2013.pdf [47] http://www.cs.kau.se/philwint/scramblesuit/ Upcoming events --------------- Sep 4 8pm | Tor Q&A with Roger Dingledine | University of the Sciences, Philadelphia, PA, USA | http://www.phillylinux.org/meetings.html | Sep 29-01 | Tor at OpenITP Circumvention Tech Summit IV | Berlin, Germany | https://www.openitp.org/openitp/circumvention-tech-summit.html | Oct 09-10 | Andrew speaking at Secure Poland 2013 | Warszawa, Poland | http://www.secure.edu.pl/ This issue of Tor Weekly News has been assembled by Lunar, dope457, mttp, malaparte, Nima, bastik, 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 [48], write down your name and subscribe to the team mailing list [49] if you want to get involved! [48] https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews [49] 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

Re: [Cryptography] NSA and cryptanalysis
by Eugen Leitl 04 Sep '13

04 Sep '13

----- Forwarded message from Jerry Leichter <leichter(a)lrw.com> ----- Date: Mon, 2 Sep 2013 00:06:21 -0400 From: Jerry Leichter <leichter(a)lrw.com> To: "Perry E. Metzger" <perry(a)piermont.com> Cc: "cryptography(a)metzdowd.com List" <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] NSA and cryptanalysis X-Mailer: Apple Mail (2.1283) On Sep 1, 2013, at 6:06 PM, Perry E. Metzger wrote: > We know what they spec for use by the rest of the US government in > Suite B. > > http://www.nsa.gov/ia/programs/suiteb_cryptography/ > > AES with 128-bit keys provides adequate protection for classified > information up to the SECRET level. Similarly, ECDH and ECDSA using > the 256-bit prime modulus elliptic curve as specified in FIPS PUB > 186-3 and SHA-256 provide adequate protection for classified > information up to the SECRET level. Until the conclusion of the > transition period defined in CNSSP-15, DH, DSA and RSA can be used > with a 2048-bit modulus to protect classified information up to the > SECRET level. > > AES with 256-bit keys, Elliptic Curve Public Key Cryptography using > the 384-bit prime modulus elliptic curve as specified in FIPS PUB > 186-3 and SHA-384 are required to protect classified information at > the TOP SECRET level. Since some products approved to protect > classified information up to the TOP SECRET level will only contain > algorithms with these parameters, algorithm interoperability between > various products can only be guaranteed by having these parameters as > options. > > We clearly cannot be absolutely sure of what they actually use, but > we know what they procure commercially. If you feel this is all a big > disinformation campaign, please feel free to give evidence for that. I > certainly won't exclude the possibility, but I find it unlikely. I'll make just a couple of comments: - Given the huge amount of material classified these days, SECRET doesn't seem to be a very high level any more, whatever its official definition. TOP SECRET still means a great deal though. But the really important stuff is compartmented (SCI), and Suite B is not approved for it - it has to be protected by unpublished Suite A algorithms. - To let's look at what they want for TOP SECRET. First off, RSA - accepted for a transition period for SECRET, and then only with 2048 bit moduli, which until the last year or so were almost unknown in commercial settings - is completely out for TOP SECRET. So clearly they're faith in RSA is gone. (Same for DH and DSA.) It looks as if they are betting that factoring and discrete logs over the integers aren't as hard as people had thought. The whole business of AES-128 vs. AES-256 has been interesting from day one. Too many recommendations for using it are just based on some silly idea that bigger numbers are better - 128 bits is already way beyond brute force attacks. The two use the same transforms and the same key schedule. The only clear advantage AES-256 has is 4 extra rounds - any attack against the basic algorithm would almost certainly apply to both. On the other hand, many possible cracks might require significantly heavier computation for AES-256, even if the same fundamental attack works. One wonders.... NSA also wants SHA-384 - which is interesting given recent concerns about attacks on SHA-1 (which so far don't seem to extend to SHA-384). I don't want to get into deep conspiracy and disinformation campaign theories. My read of the situation is that at the time NSA gave its approval to this particular combination of ciphers, it believed they were secure. They seem to be having some doubts about RSA, DSA, and DH, though that could be, or could be justified as, ECC being as strong with much smaller, more practical, key lengths. Now, imagine that NSA really did find a way in to AES. If they were to suddenly withdraw approval for its use by the government, they would be revealing their abilities. A classic conundrum: How do you make use of the fruits of your cryptanalytic efforts without revealing that you've made progress? England accepted bombing raids on major cities to keep their crack of Enigma secret. So the continuation of such support tells us little. What will be interesting to see is how long the support continues. With work under way to replace SHA, a new version of the NSA recommendations will eventually have to be produced. Will it, for example, begin a phase-out of AES-128 for SECRET communications in favor of requiring AES-256 there as well? (Since there's no call so far to develop a cipher to replace AES, it would be difficult for NSA to recommend something else.) It's indeed "a wilderness of mirrors", and we can only guess. But I'm very wary of using NSA's approval of a cipher as strong evidence, as the overall situation is complex and has so many tradeoffs. -- Jerry _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- 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

3 2

Re: Email traffic analysis (Was: Who bought off Zimmermann?)
by Bill Stewart 03 Sep '13

03 Sep '13

At 08:43 PM 8/30/2013, grarpamp wrote: > > On 8/30/13, Jon Callas <jon(a)callas.org> wrote: > > What we're learning from Snowden is that they're doing traffic analysis -- > > analyzing movements, social graphs, and so on and so forth. The irony here > > is that this tells us that the crypto works. > >Are we sure? This seems to tell us they are doing traffic analysis >and so forth. >It doesn't seem to say much about cryptanalytic capabilities. For all we know >they could have all the crypto in the bag but need analysis to identify >talkers due to people being exceedingly careful about the message content. > >"Blue hen rides over the book on the left side when the sun is low. >Do you copy?" If they know that Alice and Bob have been sending mail to each other, that's often more valuable than the traffic itself. Certainly for the model that says they're tracking two or three degrees of separation from Alice the Foreigner, with a court letting them demand that ISPs hand over any plaintext they have, though you can avoid some of that by using remailers. >>> Received:, Message-ID:, etc. Those are tricky. They're not really part of SMTP, they're part of the email message. A "pen register" style of wiretapping the envelope gets you the SMTP headers TO and FROM and the IP addresses and email options, but at least if you're using SMTP encryption you won't get the message headers. On the other hand, if you're just using PGP or SMIME on the message body, you do get them, so that's not going to help alice(a)gmail.com much.

1 0

Re: WaPo releases details on US offensive cyber-ops
by John Young 03 Sep '13

03 Sep '13

Bart, An et al asks: How cyber ops physically take place, the architecture and engineering of the cyber architecture Snowden alludes to. Computers and networks are small pieces compared to where they housed, bunkered, trenched, drowned, aired, emitted, lofted, arrayed, hidden. Those structures of the infrastructure are as costly as the human power and much greater in scope and necessity -- and immensely targetable thanks to ostentatious appurtenances of antennas, fences, barriers, sensors, stand-offs, chopper pads, cafes, health and environmental inspections, power lines and sub-stations, and not least loose lips of contractors and disaffected employees. We know the location of some of the principal offices and HQs, but those are misleading icons, as much ruses as as leaked budget tables, congrats for those teasing leads BTW. Specifics may be withheld to "protect operations and lives" but that also leaves out how these systems function beyond stupidly idiotic slides and dissimulative photoshops, which may thrill and placate with top classification markings governmental overseers reading public but are ridiculously simple-minded to techies who are obliged to seance dot connections of mouse to LAN to WAN to Internet to hubs to hotels to White House to SE-WE-ME. Care to share those kind docs we architects can de-blueprint for you? At 08:23 PM 9/2/2013, you wrote: >Greg, et al -- I'm going to keep digging on US cyber operations, and >particularly on "computer network exploitation" and "computer >network attack." I'd be interested in theories, questions or >suggestions from the smart folks here as I think about my reporting >strategy. --Bart > >----------------- >Date: Mon, 02 Sep 2013 12:44:04 -0500 >From: Gregory Foster <gfoster(a)entersection.org> >Subject: WaPo releases details on US offensive cyber-ops > >Washington Post (Aug 30) - "U.S. spy agencies mounted 231 offensive >cyber-operations in 2011, documents show" by @BartonGellman & @nakashimae: >http://www.washingtonpost.com/world/national-security/us-spy-agencies-mount… > > > under an extensive effort code-named GENIE, U.S. computer > > specialists break into foreign networks so that they can be put > > under surreptitious U.S. control. Budget documents say the $652 > > million project has placed ?covert implants,? sophisticated > > malware transmitted from far away, in computers, routers and > > firewalls on tens of thousands of machines every year, with plans > > to expand those numbers into the millions.

1 0

building a community on RetroShare
by Eugen Leitl 03 Sep '13

03 Sep '13

One of my RS identities is -----BEGIN PGP PUBLIC KEY BLOCK----- Version: OpenPGP:SDK v0.9 xsBNBFG68IABCADXB1o49wDjL8ZF91kivo4pSMdq0xfzKMXi6ZyNt/oxhlNCBK6o PaVpo6GNu7E2Gdvh5ZQn+p6NQYE4y+2riQIsStO/ikmKaIfZ43wOOFdy52R71HHF nb3JzvS7pBhskpaBmyYiAoe9lHaOMPzpizJzbG26yFY+jizm1IcCa/vggzTSpzFc 5AfQBNwL+TXovaUi4FU4FLYlD0jikwQAVony4l3SB4cTjULVBxJyJATGwnTayAUn LQQIzdEYOIhNSVO4JEa8lmWhnWZHNUV9FwG48TiTkyMhZsS4urrwqd7KaX3T5ihC hksJPCFgFUtaIZBzQOpw2kNTYtMrEhTRRA0rABEBAAHNN0V1Z2VuIExlaXRsIChH ZW5lcmF0ZWQgYnkgUmV0cm9TaGFyZSkgPGV1Z2VuQGxlaXRsLm9yZz7CwF8EEwEC ABMFAlG68IAJEBwZ2iRKZrKNAhkBAAD9Wgf8CzCNaUoRqPqrbv5peqzrsl4Jv/wT 0dp9tvrJm7ooV5iAX81NRdwXOQ098iLoRKPaSHIcQz949nV93mUn70/7dexvrFYn P1Ugnp08f1WSH0wtwjB1C6NeN6h+RTwFtgy/92oJpbHumN+eEeFjMCLLxrJUIWFK 0np0oE7+Y1izFfuMWsfh7HzhO4E9eTMzzHHAgsDC2zI5An5W1yJ1HGmudB/EfFP3 fur+s711VE3jlfvzfx1fB7Hve8+0lWQAvwAnaJNANorZFnsieQkClmqpp4jLqAQU Ss9BlEu2REP7LZ2aWyDBqmGV1370pHNm37dfjMiEDsCsmyE146rHpH984w== =38D/ -----END PGP PUBLIC KEY BLOCK----- see you there.

3 2

what to install on a secure communication device
by Eugen Leitl 03 Sep '13

03 Sep '13

I'm looking to build a list for reasonably secure (no snake oil) ways to communicate (search, store, etc.). My ad hoc list so far is: Pidgin/OTR cables Jitsi Tor YaCy RetroShare TorChat Tahoe LAFS GnuNet No doubt I'm missing a lot. Any further suggestions?

7 7

Stego, ease of use and maximal availability
by Romana Machado 03 Sep '13

03 Sep '13

Mo, I wish your student great success. I will definitely take a look! I expect the UI for a plugin to be quite different to that of a web app. I've chosen not to build a plugin or a single platform app for obvious reasons, though it is nice to know that there are efforts in these directions that may assist my own in part. Here's the plan to create ease of use: taking note of the UIs of existing tools, collaborating with experienced UI designers, and making use of an extensive background and contacts in UI test. Romana Machado

1 0

Help with JPEG Stego app?
by Romana Machado 02 Sep '13

02 Sep '13

I've decided to upgrade my project, Stego, conceived as an easy-to-use, near-universally available, maximally browser compliant, message PGP encrypted, steganography web app, to encode JPEGs, the most universal image format today (in cell phone cameras, and all over the web). Which means I have to decipher information-dense papers, pick a suitable algorithm, and code it up in client-side Javascript. Which greatly increases the workload, but I expect I'll be a better engineer for it. It also means that I'll be reusing none of the original code. Fortunately there are a few open source Javascript JPEG libraries. I'm writing to ask for help with picking the stego algorithm, hoping that someone here has a knowledgable opinion. Romana Machado 310-940-7888

4 5