- cypherpunks - lists.cpunks.org

[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 04 Sep '13

04 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 03 Sep '13

03 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

Re: WaPo releases details on US offensive cyber-ops
by otr＠riseup.net 03 Sep '13

03 Sep '13

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

Eccentricity: How Hard to Crack a Cryptosystem
by John Young 02 Sep '13

02 Sep '13

One of the many eccentricities of crypto is speculating on how long and how much computing power would be needed to crack a particular cryptosystem, its algorithm or "implementation." A favorite of popular writing on the topic, it is likely these claims are pure fiction fabricated to satisfy headlines and deadlines -- and, as always, to market or rididule a competitor's piece of shit. No Wikipedia entry on the phrase "crypto implementation," the all-time favorite excuse for the shit's absolute certain failure. Some examples among hundreds: No. 1 http://www.digicert.com/TimeTravel/math.htm [No date] DigiCert's base standard is to use 2048-bit keys in secure SSL certificates - that is enormously stronger than anything Lenstra et al attempted, in fact, it would require factoring a 617-digit number. RSA Labs claim (see: http://www.rsa.com/rsalabs/node.asp?id=2004) that 2048-bit keys are 2^32 (2 to the power of 32) times harder to break using NFS, than 1024-bit keys. 2^32 = 4,294,967,296 or almost 4.3 billion, therefore breaking a DigiCert 2048-bit SSL certificate would take about 4.3 billion times longer (using the same standard desktop processing) than doing it for a 1024-bit key. It is therefore estimated, that standard desktop computing power would take 4,294,967,296 x 1.5 million years to break a DigiCert 2048-bit SSL certificate. Or, in other words, a little over 6.4 quadrillion years. In putting together our video, we estimated the age of the Universe to be 13,751,783,021 years or a little over 13.75 billion years, therefore if you tried to break a DigiCert 2048-bit SSL certificate using a standard modern desktop computer, and you started at the beginning of time, you would have expended 13 billion years of processing by the time you got back to today, and you would still have to repeat that entire process 468,481 times one after the other into our far far distant future before there was a good probability of breaking the certificate. In fact the Universe itself would grow dark before you even got close. ----- No. 2 http://www.eetimes.com/document.asp?doc_id=1279619 How secure is AES against brute force attacks? Mohit Arora, Sr. Systems Engineer & Security Architect, Freescale Semiconductor 5/7/2012 05:29 PM EDT Even with a supercomputer, it would take 1 billion billion years to crack the 128-bit AES key using brute force attack. This is more than the age of the universe (13.75 billion years). If one were to assume that a computing system existed that could recover a DES key in a second, it would still take that same machine approximately 149 trillion years to crack a 128-bit AES key. ----- No. 3 http://www.computerworld.com/s/article/354997/The_Clock_Is_Ticking_for_Encr… The clock is ticking for encryption The tidy world of cryptography may be upended by the arrival of quantum computers. By Lamont Wood March 21, 2011 06:00 AM ET Today's encryption algorithms can be broken. Their security derives from the wildly impractical lengths of time it can take to do so. Let's say you're using a 128-bit AES cipher. The number of possible keys with 128 bits is 2 raised to the power of 128, or 3.4x1038, or 340 undecillion. Assuming no information on the nature of the key is available (such as the fact that the owner likes to use his or her children's birthdays), a code-breaking attempt would require testing each possible key until one was found that worked. Assuming that enough computing power was amassed to test 1 trillion keys per second, testing all possible keys would take 10.79 quintillion years. This is about 785 million times the age of the visible universe (13.75 billion years). On the other hand, you might get lucky in the first 10 minutes. But using quantum technology with the same throughput, exhausting the possibilities of a 128-bit AES key would take about six months. If a quantum system had to crack a 256-bit key, it would take about as much time as a conventional computer needs to crack a 128-bit key. A quantum computer could crack a cipher that uses the RSA or EC algorithms almost immediately. ----- No. 4 https://xkcd.com/538/ Thanks, XKCD

1 0