- cypherpunks - lists.cpunks.org

interesting commercial cjdns project: Enigmabox
by Eugen Leitl 07 Oct '13

07 Oct '13

Just came across http://enigmabox.net/ which is a commercial project using cjdns/Hyperboria for transport and offers end to end encrypted VoIP and operates http (and more?) exits. The hardware seems to be PCEngines ALIX. It doesn't ship with Tor, but Tor can be used with it. Don't see any open source, but users are getting root access on the system.

1 0

Re: [tor-talk] Freenet and hidden services
by Eugen Leitl 07 Oct '13

07 Oct '13

----- Forwarded message from str4d <str4d(a)i2pmail.org> ----- Date: Mon, 7 Oct 2013 10:58:41 +0000 (UTC) From: str4d <str4d(a)i2pmail.org> To: tor-talk(a)lists.torproject.org Subject: Re: [tor-talk] Freenet and hidden services X-Mailer: smtp.postman.i2p - Official I2P Mailer Message-Id: <20131007105841.28054AE2B3(a)smtp.postman.i2p> Reply-To: tor-talk(a)lists.torproject.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I consider Tahoe-LAFS to be the (current) best solution for this. It provides a distributed data store, which can be used for hosting (with a Javascript "web server"). I know Tahoe works with Tor via SOCKS but I don't personally know of any active networks. Tahoe has been used in I2P as a distributed data store for a long time, and there are several "deepsites" hosted in it. We are actively working to make Tahoe integrate better with Tor/I2P. Zooko recently posted a *much* better summary of this: https://cpunks.org//pipermail/cypherpunks/2013-October/001242.html str4d On 10/07/2013 08:11 PM, Jerzy Łogiewa wrote: > Do you mean if Tor wold have distributed data store like freenet? > > Nice idea, please implement this. :~ > > -- Jerzy Łogiewa -- jerzyma(a)interia.eu > > On Oct 6, 2013, at 3:26 AM, It's Good to be Alive wrote: > >> Hi, I'm fairly new at Tor, and this is my first time on a mailing >> list, so if there's a better place to ask, let me know. Are >> there any plans, long-term or short, for augmenting Tor with >> Freenet-style resilient, distributed, encrypted hosting in place >> of the current hidden-service model? I understand that they are >> different projects with different goals, but in the wake of the >> Freedom Hosting fiasco it seems that the idea has merit. >> Certainly both sides would benefit? Freenet is not always >> anonymous, and hidden services are not always resilient, but >> together... What are the pros and cons of this idea, and what >> stands in the way of implementing it? Just curious. Cheers! >> Thanks for your time. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCgAGBQJSUpPHAAoJENXeOJaUpGWyy/4H/36aYQmjKCPYxT8SdYEL2vOV IJ/vhIhWFeSkS/VKXtMHyP272HR+J+oTQ+IqeFYVD+MZFXWB3+lpoqkvsG8YhCDY yq2k7M8y37vnxwt+KhrEL4Ql6tcwHuA4LcePw9mT1EiPhDFrUKCa2HBIz6SZ7IDz NNN9ISBkt4eslF9k3vUnqWUA4S/Wd4geTtKMJBxgIfXzt0p/ppSm5LR8tSwo/Yxc QMB4SL0toj1srv/fjFKR/Gy4TU3rww9sCr0rDlTtlOx8JVjc9imEynq00WIlQwi1 x1jDLvKvqg2hricJjVMHXRwhERadQjgg2FHxyaE2fpfhOZ6uHjZ7U9XLZTpEFnM= =gliq -----END PGP SIGNATURE----- -- 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

Analysis of Silk Road’s Historical Impact on Bitcoin
by Eugen Leitl 07 Oct '13

07 Oct '13

http://thegenesisblock.com/analysis-silk-roads-historical-impact-bitcoin/ Analysis of Silk Road’s Historical Impact on Bitcoin Oct 3, 2013 Posted By Jonathan Stacke In Featured, News Tagged Bitcoin, Price, Silk Road, Volume Comments 11 Silk Road, the online drug bazaar that has eluded authorities and been ingrained in the bitcoin narrative for years, was shut down yesterday. Ross Ulbricht was named in the court documents outlining Silk Road’s activities, as were a number of key data points that offer insights into the impact the world’s most infamous retail website has had on bitcoin. Ulbricht was caught as a result of human error and excessive risks related to physical delivery of false identification being delivered to his home address in San Francisco from Canada. After tracking the package, authorities found their way to Ulbricht and were able to compile a significant case against him (more details in the official complaint embedded below). Notably, it does not appear he was tracked as the result of any underlying flaws with tor, used for anonymous web browsing, or bitcoin, the only currency accepted on Silk Road. For years the cloaked narcotics website has found its way into bitcoin-oriented conversations, but only now are the qualitative and quantitative data points available to asses Silk Road’s true impact on the fledgling digital currency. A History of Influence Facts offered by federal prosecutors overlayed onto bitcoin trading data tells a convincing story about the intertwined histories of bitcoin and Silk Road. It appears that a significant portion of bitcoin’s early traction and price gains can be traced directly to Silk Road, with that impact waning over time, most dramatically in the past six months. On December 30, 2010, bitcoin was traded at $0.30/BTC. The court documents filed yesterday point to Silk Road’s first known publicity occurring via posts from Ulbricht on internet forums and an explanatory WordPress page beginning on January 27, 2011. Bitcoin tripled in value, reaching parity with USD, just two weeks later on February 8. early 2011 Bitcoin then traded between between $0.65 and $0.80 for the next two months until interest was reignited by coverage in major publications, including TIME Magazine and The New York Times. In the weeks following the NYC piece, bitcoin prices and volume exploded, drawing significant attention from the media. Notably, Gawker broke a story about the Silk Road itself, pushing up the last gain of one of bitcoin’s early bubbles. As bitcoin reached a remarkable 100x year-to-date growth at $30/BTC on June 7, the relationship between Silk Road and bitcoin would see its first true test. On June 8, 2011, Senators Charles Shumer and Joe Manchin wrote a letter to Attorney General Eric Holder, urging him to investigate bitcoin for its relationship to online narcotics purchases, as well as “urge [Holder] to take immediate action and shut down the Silk Road network.” Bitcoin plunged 66% to $10 over the next three days, trending downward to $2 by November 2011. It would seem that in 2011, direct use of bitcoin on Silk Road or speculators on its adoption comprised between 66% and 93% of the currency’s value. 2011 bubble Over the next few months as the calendar rolled over into 2012, once again coverage from a number of important press outlets like TIME and Wired rallied enthusiasm for bitcoin, pushing prices up to a stabilized $5 by February. According to the complaint released yesterday, that is also around the time Ulbricht began to add features to Silk Road, including the establishment of a forum and “stealth mode” for top vendors. In June of 2012, bitcoin began another rally. By this time, infrastructure in the bitcoin world had begun to increase dramatically, including the first bitcoin ASIC companies to begin advertising products and new exchanges being formed. Gawker ran another story about Silk Road in July 2012, which appears to have had positive impact on bitcoin prices, though not nearly to the extent it did previously. The months following proved to be highly transitional, with Bitcoin Foundation putting a public face on the new industry and early 2013 seeing the European financial troubles that led to the climb to $260 in April of this year and unprecedented global attention. Just a few weeks later the markets would see another test of the relationship between Bitcoin and Silk Road. Between April 24 and May 1, Silk Road suffered a series of DDoS attacks that sent bitcoin prices sliding downwards. The negative price action was timed perfectly with the attacks, indicating a strong relationship. While the drop was significant at 35% initially before leveling off around a 25% loss – it was notably lighter than the impact of negative Silk Road news previously. april 2013 ddos Looking at the impact from the most recent news, we see a similar pattern emerging. Despite being the definitive end of Silk Road, with its founder detained and the logos of federal agencies plastered across the site, the impact on bitcoin prices was relatively muted. On the initial news break USD/BTC rates fell 20-35%, depending on the exchange, before settling around 10-15% lower than before the news shortly thereafter. October 2013 Quantifiable Impact Also contained within the filings were a number of aggregate statistics about Silk Road’s transactional volume that shed significant light on how much of the bitcoin market was built around the company’s narcotics trade. Specifically, the complaint states that site’s total revenue between February 2011 and July 2013 was 9.5 million bitcoin. Over that same period approximately 225 million bitcoin were transacted over the block chain, of which the 9.5 million in Silk Road sales accounted for just 4%. Similarly, total exchange volume over the same period was roughly 75 million bitcoin, making Silk Road approximately 12% of total volume. This, of course, assumes all bitcoins used for purchases on the site were purchased on exchanges rather than obtained from in person transactions, mining, earnings, gifts or reused by sellers to purchase from others on the site. Important to remember is that these figures are aggregate stats over two years of revenue. Unless fiat-equivalent sales on Silk Road were growing exponentially alongside bitcoin exchange rates over the past two years, this also means the bitcoin volume listed in the filing is front loaded into the periods when more bitcoins were required for the same fiat equivalent purchasing power. This coincides with the market reactions that also indicates a significantly reduced importance of Silk Road on the bitcoin economy. Looking Forward The bitcoin markets as a whole seem well poised to move forward. An unknown has been removed from the ecosystem, but a number of concerns remain. While bitoin will likely recover, there are probably more than a few concerned bitcoin users right now. The contents of the filing pertained almost exclusively to the charges against Ulbricht, but give little insight into what other information was obtained. Whether or not home addresses or bitcoin addresses of Silk Road users were retained in some way is still unclear and the extent to which such matters are prosecutable has yet to be determined. There is also a strong likelihood of copycat sites arising. While the recent action may deter US citizens, Silk Road was known for its global reach, meaning an aspiring entrepreneur could run a similar company from anywhere in the world. The business model is proven and the technology still apparently sound and repeatable. The downfall was related to human error, which was clearly outlined in the filing, creating an advanced watchlist for the next person to avoid. The barriers to entry are remarkably low and now paired with a known surplus of both demand and supply in the marketplace. While Silk Road’s early impact on digital currency appears to have been quite significant, any new participant at this stage will likely encounter the same decreasing importance to the broader bitcoin ecosystem.

2 1

Russia to monitor 'all communications' at Winter Olympics in Sochi
by Eugen Leitl 07 Oct '13

07 Oct '13

http://www.theguardian.com/world/2013/oct/06/russia-monitor-communications-… Russia to monitor 'all communications' at Winter Olympics in Sochi Exclusive: Investigation uncovers FSB surveillance system – branded 'Prism on steroids' – to listen to all athletes and visitors Shaun Walker in Moscow The Guardian, Sunday 6 October 2013 15.31 BST Sochi, venue for 2014 Winter Olympics The Black Sea resort of Sochi has apparently been wired so that the FSB can log all visitor communications. Photograph: Ignat Kozlov/AP Athletes and spectators attending the Winter Olympics in Sochi in February will face some of the most invasive and systematic spying and surveillance in the history of the Games, documents shared with the Guardian show. Russia's powerful FSB security service plans to ensure that no communication by competitors or spectators goes unmonitored during the event, according to a dossier compiled by a team of Russian investigative journalists looking into preparations for the 2014 Games. In a ceremony on Red Square on Sunday afternoon, the president, Vladimir Putin, held the Olympic flame aloft and sent it on its epic journey around the country, saying Russia and its people had always been imbued with the qualities of "openness and friendship", making Sochi the perfect destination for the Olympics. But government procurement documents and tenders from Russian communication companies indicate that newly installed telephone and internet spying capabilities will give the FSB free rein to intercept any telephony or data traffic and even track the use of sensitive words or phrases mentioned in emails, webchats and on social media. The journalists, Andrei Soldatov and Irina Borogan, who are experts on the Russian security services, collated dozens of open source technical documents published on the Zakupki government procurement agency website, as well as public records of government oversight agencies. They found that major amendments have been made to telephone and Wi-Fi networks in the Black Sea resort to ensure extensive and all-permeating monitoring and filtering of all traffic, using Sorm, Russia's system for intercepting phone and internet communications. Putin at a Sochi Olympic flame ceremony in Moscow on Sunday. Photograph: Ivan Sekretarev/AP The Sorm system is being modernised across Russia, but particular attention has been paid to Sochi given the large number of foreign visitors expected next year. Technical specifications set out by the Russian state telecoms agency also show that a controversial technology known as deep packet inspection, which allows intelligence agencies to filter users by particular keywords, is being installed across Russia's networks, and is required to be compatible with the Sorm system. "For example you can use the keyword Navalny, and work out which people in a particular region are using the word Navalny," says Soldatov, referring to Alexei Navalny, Russia's best-known opposition politician. "Then, those people can be tracked further." Ron Deibert, a professor at the University of Toronto and director of Citizen Lab, which co-operated with the Sochi research, describes the Sorm amendments as "Prism on steroids", referring to the programme used by the NSA in the US and revealed to the Guardian by the whistleblower Edward Snowden. "The scope and scale of Russian surveillance are similar to the disclosures about the US programme but there are subtle differences to the regulations," says Deibert. "We know from Snowden's disclosures that many of the checks were weak or sidestepped in the US, but in the Russian system permanent access for Sorm is a requirement of building the infrastructure." "Even as recently as the Beijing Olympics, the sophistication of surveillance and tracking capabilities were nowhere near where they are today." Gus Hosein, executive director of Privacy International, which also co-operated with the research, said: "Since 2008, more people are travelling with smartphones with far more data than back then, so there is more to spy on." Wary of Sorm's capabilities, earlier this year a leaflet from the US state department's bureau of diplomatic security warned anyone travelling to the Games to be extremely cautious with communications. "Business travellers should be particularly aware that trade secrets, negotiating positions, and other sensitive information may be taken and shared with competitors, counterparts, and/or Russian regulatory and legal entities," the document reads. The advice contains an extraordinary list of precautions for visitors who wish to ensure safe communications, such as removing batteries from phones when not in use and only travelling with "clean" devices. Soldatov and Borogan have discovered that the FSB has been working since 2010 to upgrade the Sorm system to ensure it can cope with the extra traffic during the Games. All telephone and ISP providers have to install Sorm boxes in their technology by law, and once installed, the FSB can access data without the provider ever knowing, meaning every phone call or internet communication can be logged. Although the FSB technically requires a warrant to intercept a communication, it is not obliged to show it to anyone. Tellingly, the FSB has appointed one of its top counterintelligence chiefs, Oleg Syromolotov, to be in charge at Sochi: security will thus be overseen by someone who has spent his career chasing foreign spies rather than terrorists. Another target may well be gay rights, likely to be one of the biggest issues of the Games. Putin has said that competitors who wear rainbow pins, for example, will not be arrested under the country's controversial new law that bans "homosexual propaganda". However, it is likely that any attempts to stage any kind of rally or gathering to support gay rights will be ruthlessly broken up by police, as has been the case on numerous occasions in Russian cities in the past. Using DPI, Russian authorities will be able to identify, tag and follow all visitors to the Olympics, both Russian and foreign, who are discussing gay issues, and possibly planning to organise protests. "Athletes may have particular political views, or they may be openly gay," says Deibert. "I think given recent developments in Russia, we have to be worried about these issues." At a rare FSB press conference this week, an official, Alexei Lavrishchev, denied security and surveillance at the Games would be excessive, and said that the London Olympics featured far more intrusive measures. "There, they even put CCTV cameras in, excuse me for saying it, the toilets," said Lavrishchev. "We are not taking this kind of measure." The FSB did not respond to a request for comment from the Guardian, while a spokesperson for the Sochi Olympics referred all requests to the security services. But Russian authorities often express a belief that NGOs working on human rights and other issues have subversive agendas dictated from abroad, and the FSB apparently feels that with so many potentially dangerous foreigners descending on the Black Sea resort for the Olympics, it has a duty to keep an eye on them. In the end, the goal is overarching, but simple, says Soldatov: "Russian authorities want to make sure that every connection and every move made online in Sochi during the Olympics will be absolutely transparent to the secret services of the country."

1 0

Re: [liberationtech] The missing component: Mobile to Web interoperability (in Internet Freedom Technologies)
by coderman 07 Oct '13

07 Oct '13

On Wed, Sep 25, 2013 at 9:32 PM, coderman <coderman(a)gmail.com> wrote: > [... re: NSA has found a way to break Tor... ] > i suspect it is the latter that is more concerning. of course NSA has > the ability; but do they share it? the recent releases[0] have shown this to be more complicated than expected. in terms of sharing: other domestic agencies and some of the FVEY partners appear to be partially looped in? likely to find out more over the years,... in terms of breaking Tor: the core Tor protocol and network is described repeatedly as difficult to compromise. attacking the client, opportunistic de-anonymization, selective denial of service, and mallory-in-the-middle attacks, all appear extremely effective when they are pointed at Tor users of interest. Tor's dependencies are failing in practice, rather than the network or protocol itself. Roger says the limited number of users targeted is reassuring, “If those documents actually represent what they can do, they are not as big an adversary as I thought,”[1] the lack of widespread de-anonymization of Tor users is an interesting situation. i do not agree that they don't have the ability. other sources clearly show their privileged positioning in the IP core for active attacks as well as the global passive DPI tapping infrastructure technically capable of linking large numbers of Tor users.[2] instead this implies that the other routes to identifying users, particularly taking advantage of the endpoint and operational risks above, are cheaper and more effective. for less effort and resources locate them via side channel tricks, infect them with spyware, and observe what they do pre-encryption-and-pre-proxy directly. it's clear to see why they've been using this approach. [here is where i plug Qubes Tor VM, Tails, Whonix] so after addressing the client side weaknesses, perhaps the elligator datagram based effort[3] will be making progress in time to thwart this new adversary model as the low hanging fruit of Tor client cracking dries up... ;) best regards, 0. NSA Tor dox: http://www.washingtonpost.com/world/national-security/secret-nsa-documents-… http://cryptome.org/2013/10/nsa-iat-tor.pdf http://cryptome.org/2013/10/nsa-tor.pdf http://cryptome.org/2013/10/gchq-mullenize.pdf http://cryptome.org/2013/10/nsa-egotisticalgiraffe.pdf http://cryptome.org/2013/10/nsa-tor-stinks.pdf http://cryptome.org/2013/10/packet-stain/packet-staining.htm 1. "Secret NSA documents show campaign against Tor encrypted network" http://www.washingtonpost.com/world/national-security/secret-nsa-documents-… 2. passing the buck on the math; the details you need: https://metrics.torproject.org/index.html / https://trac.torproject.org/projects/tor/ticket/6443 , answer for the question: what is the probability of picking a guard and exit relay using any of five-eyes-and-their-friendlies AS'es, or that travels transoceanic cables at these points, or uses guard and exit relays hosted at an IX under legally compelled (FVEY) or unaware collaboration (e.g. Belgacom)? 3. sorry, no; there is no Tor datagram protocol in the works yet, however initial considerations are in progress: "Implement and experiment with one or more datagram-based designs" https://trac.torproject.org/projects/tor/ticket/4684 http://www.cl.cam.ac.uk/~sjm217/papers/tor11datagramcomparison.pdf this is summarized as picking from multiple hard to very hard options. i'm fond of even more difficulty, and combining these techniques and others (multi-path SCTP in userspace, client-side traffic shaping/prioritization, stochastic fair queuing and packet reordering, etc) for better protection against traffic analysis and active attacks.... might take a while to code up *grin*

1 0

[21] crypto and surveillance
by brian carroll 07 Oct '13

07 Oct '13

// disclaimer: all my posts and diagrams copyright free... a few ideas related to the context for crypto today. there is certain irony in crypto that can be subverted and used to attack or surveil via stealth. reminds of the basic situation with most home electronics, blackboxed. such as IPcams that remain on 24/7/365 and have microphones accessible over the network, compromises built-in. thus to seek security is to extend the hidden security state and its illegal home invasion. solution: five dollar on/off switch, activate security device only when away, and upon return turn it off again, limiting the designed for boundlessness of political technology. 2-Port RJ45 Manual Network Switch https://www.dropbox.com/s/lk7gg8zgf7wxjjj/RJ45switch.JPG the diagrams here reference the following NSA document... The Borders of Cryptology - NSA & Electronic Warfare* http://cryptome.org/2013/09/nsa-cryptology-borders.pdf diagrams created with the excellent software tool yEd... yEd - Graph Editor - yWorks (freeware) http://www.yworks.com/en/products_yed_about.html the question of crypto in a complex environment where it has both offensive and defensive functioning, relating to weak and strong crypto and security ratings crypto (protection & exploitation) https://www.dropbox.com/s/d7jrpilz35dvk4k/graph1v1.gif the paradoxical utility and purpose of compromised crypto that has both strong and weak, secure and insecure characteristics in a complex environment dual-use multilevel crypto https://www.dropbox.com/s/ndwlu9lqf4yvhy9/graph2v1.gif the role of installation and usage errors as related to security and exploits, inherent in complicated or high-literacy approaches crypto implementation flaw https://www.dropbox.com/s/bjofccwrun7lok1/graph3v1.gif this is the direct reference and extension of the NSA diagram above. cryptanalysis was included, Technical Surveillance Countermeasures (TSCM), though likely other domains are missing or perhaps in relational error. improvements or corrections appreciated... Electromagnetic Borders of Cryptology https://www.dropbox.com/s/tp7dbqjbmpscv0h/diagram4v1.gif this is my estimation of the situation today, based on the above technosocial structure. it does not include many aspects and is limited by my lack of awareness and understanding, though makes an attempt at an integrated view of the larger dynamics involved... Context for computer Crypto today https://www.dropbox.com/s/jn73d4d9b5ksz8u/context5v1.gif additional diagrams will follow, surveying aspects of this same territory... --- Grant Hart - You're the Reflection of the Moon On the Water http://www.youtube.com/watch?v=NTH4Zu8gleA ☾

1 0

[zfs] [Review] 4185 New hash algorithm support
by Eugen Leitl 07 Oct '13

07 Oct '13

----- Forwarded message from Saso Kiselkov <skiselkov.ml(a)gmail.com> ----- Date: Mon, 07 Oct 2013 00:47:52 +0100 From: Saso Kiselkov <skiselkov.ml(a)gmail.com> To: illumos-zfs <zfs(a)lists.illumos.org> Subject: [zfs] [Review] 4185 New hash algorithm support Message-ID: <5251F6A8.2040305(a)gmail.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Reply-To: zfs(a)lists.illumos.org Please review what frankly has become a bit of a large-ish feature: http://cr.illumos.org/~webrev/skiselkov/new_hashes/ This webrev implements new hash algorithms for ZFS with much improved performance. There are three algorithms included: * SHA-512/256: truncated version of SHA-512 per FIPS 180-4. Uses all existing code from the sha2 module (with new H(0) consts), but the native 64-bit arithmetic used in SHA-512 provides a ~50% performance boost relative to SHA-256 on 64-bit hardware. * Skein-512: 80% faster than SHA-256 in optimized C implementation, and a very high security margin (Skein was a finalist in SHA-3). Also includes a KCF SW provider. * Edon-R-512: 350% faster than SHA-256 in optimized C implementation. Security margin lower than Skein. To address any security concerns associated with using new algorithms this patch also implements salted checksum support. We store a random 256-bit secret key (the salt) in the MOS and use it to pre-seed the hash algorithms (Skein and Edon-R use this, SHA-512/256 is just a straight hash). Any attacker thus cannot simply mount a collision attack on the algorithm, since they can't completely control the input. ATM I didn't implement support for booting off of pools with salted checksums, thus root pools are limited to sha256 and the new sha512 (new GRUB stage2 needed for sha512 support, obviously). It's possible, but I see fairly little reason in doing so (is anybody running dedup on their rpool and running into hash performance limitations?). For performance and correctness testing I've included a set of tiny test suites in usr/src/common/crypto/{edonr/skein/sha2}/test. Simply cd into the test subdirectory in a shell with your build environment set up and type 'make'. See attached file for an example of the output. To those who will inevitably ask about Keccak/SHA-3, here are my reasons why I didn't integrate it (in decreasing order of significance): * Keccak's software performance is worse than SHA-2. * There's no hardware support for Keccak and there likely never will be, as SHA-3 != Keccak. * SHA-3 has yet to be standardized, and there are even some questions around that, be they tinfoil hat material or otherwise: http://tiny.cc/schneier_sha-3 * To be sure, at some point in the future there will be HW support for SHA-3 (which may or may not be faster than Edon-R in SW), but seeing as how HW vendors are easily backdoored, I'm not convinced we should put a lot of trust in their work: http://tiny.cc/hw_trojans_becker13 Cheers, -- Saso root@illumos-build:...gate.git/usr/src/common/crypto# for TEST in edonr skein sha2; do ( cd $TEST/test ; make ); done Building 32-bit test... Running 32-bit test... Running algorithm correctness tests: Edon-R-224 Message: test_msg0 Result: OK Edon-R-224 Message: test_msg1 Result: OK Edon-R-256 Message: test_msg0 Result: OK Edon-R-256 Message: test_msg1 Result: OK Edon-R-384 Message: test_msg0 Result: OK Edon-R-384 Message: test_msg2 Result: OK Edon-R-512 Message: test_msg0 Result: OK Edon-R-512 Message: test_msg2 Result: OK Running performance tests (hashing 1024 MiB of data): Edon-R-256 2604591 us (6.05 CPB) Edon-R-512 4227055 us (9.81 CPB) Building 64-bit test... Running 64-bit test... Running algorithm correctness tests: Edon-R-224 Message: test_msg0 Result: OK Edon-R-224 Message: test_msg1 Result: OK Edon-R-256 Message: test_msg0 Result: OK Edon-R-256 Message: test_msg1 Result: OK Edon-R-384 Message: test_msg0 Result: OK Edon-R-384 Message: test_msg2 Result: OK Edon-R-512 Message: test_msg0 Result: OK Edon-R-512 Message: test_msg2 Result: OK Running performance tests (hashing 1024 MiB of data): Edon-R-256 2002762 us (4.65 CPB) Edon-R-512 1006284 us (2.34 CPB) Building 32-bit test... Running 32-bit test... Running algorithm correctness tests: Skein_256/256 Message: test_msg0 Result: OK Skein_256/256 Message: test_msg1 Result: OK Skein_256/256 Message: test_msg2 Result: OK Skein_512/512 Message: test_msg0 Result: OK Skein_512/512 Message: test_msg2 Result: OK Skein_512/512 Message: test_msg3 Result: OK Skein1024/1024 Message: test_msg0 Result: OK Skein1024/1024 Message: test_msg3 Result: OK Skein1024/1024 Message: test_msg4 Result: OK Running performance tests (hashing 1024 MiB of data): Skein_256/256 14110264 us (32.76 CPB) Skein_512/512 12465191 us (28.94 CPB) Skein1024/1024 16864123 us (39.15 CPB) Building 64-bit test... Running 64-bit test... Running algorithm correctness tests: Skein_256/256 Message: test_msg0 Result: OK Skein_256/256 Message: test_msg1 Result: OK Skein_256/256 Message: test_msg2 Result: OK Skein_512/512 Message: test_msg0 Result: OK Skein_512/512 Message: test_msg2 Result: OK Skein_512/512 Message: test_msg3 Result: OK Skein1024/1024 Message: test_msg0 Result: OK Skein1024/1024 Message: test_msg3 Result: OK Skein1024/1024 Message: test_msg4 Result: OK Running performance tests (hashing 1024 MiB of data): Skein_256/256 3328342 us (7.73 CPB) Skein_512/512 2549537 us (5.92 CPB) Skein1024/1024 3547695 us (8.24 CPB) Building 32-bit test... Running 32-bit test... Running algorithm correctness tests: SHA256 Message: test_msg0 Result: OK SHA256 Message: test_msg1 Result: OK SHA384 Message: test_msg0 Result: OK SHA384 Message: test_msg2 Result: OK SHA512 Message: test_msg0 Result: OK SHA512 Message: test_msg2 Result: OK SHA512_224 Message: test_msg0 Result: OK SHA512_224 Message: test_msg2 Result: OK SHA512_256 Message: test_msg0 Result: OK SHA512_256 Message: test_msg2 Result: OK Running performance tests (hashing 1024 MiB of data): SHA256 6745601 us (15.66 CPB) SHA512 19033518 us (44.19 CPB) Building 64-bit test... Running 64-bit test... Running algorithm correctness tests: SHA256 Message: test_msg0 Result: OK SHA256 Message: test_msg1 Result: OK SHA384 Message: test_msg0 Result: OK SHA384 Message: test_msg2 Result: OK SHA512 Message: test_msg0 Result: OK SHA512 Message: test_msg2 Result: OK SHA512_224 Message: test_msg0 Result: OK SHA512_224 Message: test_msg2 Result: OK SHA512_256 Message: test_msg0 Result: OK SHA512_256 Message: test_msg2 Result: OK Running performance tests (hashing 1024 MiB of data): SHA256 4551774 us (10.57 CPB) SHA512 3029591 us (7.03 CPB) ------------------------------------------- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876&id_secret=22842876-a25d3… Powered by Listbox: http://www.listbox.com ----- 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

trusted computing?
by Juan Garofalo 06 Oct '13

06 Oct '13

What about implementing aes or similar in something like a stm32 arm? The micro is interfaced to a keyboard and a lcd text display. Then you can type your emails or chat messages, have them encrypted in the arm micro, and sent through usb to a non-trusted host pc(or whatever) for delivery.

2 1

SilkRoad coins
by coderman 06 Oct '13

06 Oct '13

On Wed, Oct 2, 2013 at 11:56 AM, coderman <coderman(a)gmail.com> wrote: > ... > i would be interested to know what coin addresses were seized, and how > they are used going forward (if it all?). they moved the coins to new wallet(s) and who knows what happens to them next... http://blockchain.info/address/1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX?sort=1 http://blockchain.info/unspent?active=1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX&fo…

2 1

Re: [cryptography] the spell is broken
by Eugen Leitl 06 Oct '13

06 Oct '13

----- Forwarded message from Jeffrey Goldberg <jeffrey(a)goldmark.org> ----- Date: Thu, 3 Oct 2013 20:26:00 -0500 From: Jeffrey Goldberg <jeffrey(a)goldmark.org> To: Jon Callas <jon(a)callas.org> Cc: "cryptography(a)randombit.net" <cryptography(a)randombit.net> Subject: Re: [cryptography] the spell is broken Message-Id: <601145B1-5C4B-4E27-AD30-6445B8436DE0(a)goldmark.org> X-Mailer: Apple Mail (2.1811) Jon, first of all thank you for your extremely thoughtful note. I suspect that we will find that we don’t actually disagree about much, and also my previous rant was driven by the general anger and frustration that all of us are experiencing. That is, I amy have been misdirecting my anger at the whole situation at you, a fellow victim. On 2013-10-03, at 4:31 PM, Jon Callas <jon(a)callas.org> wrote: > You might call it "security theatre," but I call it (among other things) "protest.” I would put it more strongly than that. I think that NIST needs to be punished. Even if Dual_EC_DRBG were their only lapse, any entity that has allowed themselves to be used that way should be forced to exit the business of being involved in making recommendations on cryptography. I don’t have to think that they are bad people or even that they could have prevented what happened. But I think there needs to be an unambiguous signal to every other (potential) standards body about what happens if you even think of allowing for the sabotage of crypto. I imagine that everyone is looking at public protocols for picking curves now. Everyone is looking at how every step in the establishment of a recommendation can be made provably transparent. That is all a good thing, and it does require that NIST pay dearly. But it isn’t a trust issue. I don’t “trust” the NIST less than I trust any other standard’s body. The need to be put out of the crypto business as a signal and deterrent to others, but not because they are inherently less trustworthy. But not using AES is a protest that hurts only ourselves. It doesn’t punish where punishment is needed. > I have also called it "trust," "conscience," and other things including "emotional." I'm willing to call it "marketing" in the sense that marketing often means non-technical. Agreed. > I disagree with "security theatre" because in my opinion security theatre is *empty* or *mere* trust-building, I still think the term is appropriate, and indeed I think that your sentence about conscience and emotions actually reinforces my claim that it is theater. But I think that it is largely a definitional question which isn’t worth pursuing. I’m using the term in a slightly different way than you are. > but I don't fault you for being upset. I don't blame you for venting in my direction, either. I will, however, repeat that I believe this is something gentlepersons can disagree on. A decision that's right for me might not be right for you and vice-versa. Absolutely! Although I still stand by my “security theater” statement, I think I also mean it less pejoratively than it came across. Anyone (including me and the company that I work for) who has moved to 256 bit symmetric keys is engaging in “security theater” in my sense of the word. It’s nothing to be particularly proud of, but it doesn’t make us the TSA either. > > Since the AES competition, NIST has been taking a world-wide role in crypto standards leadership. Yep. And (sadly) that has go. As I said, they need to pay a heavy price so that it is absolutely clear that some behaviors are beyond the pale. > A good standard, however, is not necessarily the *best*, it's merely agreed upon. That’s true. > I think Twofish is a better algorithm than Rijndael. OK. I was flat out wrong. I was ignorant of your longstanding view of ciphers. I’m not competent to really have an opinion about whether your judgement is correct there, but that isn’t relevant. I thought Twofish was pulled out of a hat. I was wrong. And I also apologize for accusing you of pulling Twofish out of hat. > ZRTP also has in it an option for using Skein's one-pass MAC instead of HMAC-SHA1. Why? Because we think it's more secure in addition to being a lot faster, which is important in an isochronous protocol. I agree that if you are changing ciphersuites, it’s as good a time as any to move to a SHA-3 candidate. And as there some questions that need to be answered about official SHA-3, I’m happy with Skein. Again, I’m not competent to judge the relative merits of SHA-3 candidates. > Silent Phone already has Twofish in it, and is already using Skein-MAC. Ah. So yes, we are in very different starting places. Your choice seems very reasonable. > In Silent Text, we went far more to the "one true ciphersuite" philosophy. I think that Iang's writings on that are brilliant. > > As a cryptographer, I agree, but as an engineer, I want options. I think I am in a different position. I’m neither an engineer nor a cryptographer. I’m the guy who can kinda sorta read bits of the cryptography literature and advise the engineers on what to do with respect to using these tools. And what we decide affects the security of a very large number of users. So for me, the “one true ciphersuite” notion was ideal. I could pay attention and follow the consensus advice. You may be competent to, say, pick Skein over Blake for some particular purpose, but I’m not. And I don’t want to have to make those choices. Not only is it that I don’t want to make such choices, but you shouldn’t want me to either. You don’t want me and zillions of application developers to be making such choices. So the loss of “one true ciphersuite”. Think about it, it’s taken a decade to get typical application developers to understand that for many purposes you can’t just use SHA1, but you need to contain it in HMAC. Now they are going to have to unlearn that for the new class of hash algorithms. If we are forced from the Eden of one true ciphersuite, we may end up with people who really aren’t competent to judge picking algorithms out of a hat. So, I guess that some of my frustration that I’m taking out in various directions is rooted in that. Expelled from the paradise of one true ciphersuit, I have the responsibility to choose between the good and the bad didn’t get enough to eat from the tree of knowledge. > One True Suite works until that suite is no longer true, and then you're left hanging. Yep. I was certainly aware of the risks, but I guess I took a bit of a CYA approach. If people spent enormous amounts of money building certain things into chips, they surely would have investigated very carefully before making such a commitment. (I should say that it really isn't CYA; I want to make the best choices for our customers. I also am intensely curious about this stuff, even if I’m not a cryptographer by any means.) > Now let me go back to my comment about standards. Standards are not about what's *best*, they're about what's *agreed*, and part of what's agreed on is that they're good enough. When one is part of a standards regime, one sublimates one's personal opinions to the collective good of the standard. Yes. I fully agree. And I agree that there were things that went into the selection of Rijndael that may not be what I would chose. I fully get that. But having been selected more than a decade ago, AES has been subject to far far more scrutiny than anything else. As a consequence, I think that the gap between our understanding of AES and the NSA’s is smaller than the gap for lesser studied ciphers. So I’m not talking about following the standard as soon as the winner is declared, but the benefits of it having been the standard for so long decrease my uncertainty about it. > That collective good of the standard is also "security theatre" in the sense that one uses it because it's the thing uses to be part of the community. I can see how that might be the case under an even looser definition than I was using, but I’m not really buying it in this case. > I think Twofish is better than AES. I believe that Skein is better than SHA-2. I also believe in the value of standards. Acknowledged. I had misjudged your motivations, and in a fairly insulting way. I appreciate the grace in your response. > The problem one faces with the BULLRUN documents gives a decision tree. The first question is whether you think they're credible. If you don't think BULLRUN is credible, then there's an easy conclusion -- stay the course. If you think it is credible, then the next decision is whether you think that the NIST standards are flawed, either intentionally or unintentionally; in short, was BULLRUN *successful*. If you think they're flawed, it's easy; you move away from them. My take is that BULLRUN was successful in parts. I’m not sure whether the count Dual_EC_DRBG as a success or not, as problems with it were discovered early. It stank from the outset and BULLRUN just confirmed that the stink had a nasty source. Leaving RSA Inc aside, no one really needed to change ciphersuites. Yet it was that revelation that sent me reeling. So the question which other standards *could* they have gotten away with subverting. Quite simply not everything has the kind of math that Dual_EC_DRBG has and not everything has the same “gaps” in the history of where certain things come from. You seem to be suggesting that if BULLRUN was successful anywhere, then it was successful everywhere (and they tried it with everything). Furthermore, at least with AES, you seem to be assuming that if BULLRUN was successful in a case in 2006, then it was also done successfully before 2001. And so when looking at which things I need to move away from, I have to judge the risks that they’ve been compromised in light of all of the information that we have. The new information was confirmation that at least after 2001, the NSA was willing and able to subvert at least one NIST cryptographic standard. I have to integrate that piece of exceedingly distressing news in light of everything else we know about the things I rely on. And so this is what we rely on: AES, SHA-2, and the (alleged) CSPRNGs in commercial operating systems. Looking at those realistically, my energies haven’t been focused on looking for replacements for AES and SHA2, but how to deal with potentially malicious CSPRNGs from Apple and Microsoft. So my focus on improving key generation against undetectably malicious CSPRNGs. > The hard decision is the one that comes next -- I can state it dramatically as "Do you stand with the NSA or not?" which is an obnoxious way to put it, as there are few of us who would say, "Yes, I stand with the NSA." You can phrase less dramatically it as standing with NIST, or even less dramatically as standing with "the standard." You can even state it as whether you believe BULLRUN was successful, or lots of other ways. I’m sorry, but that I have to reject. That is an all or nothing absolutism that I not only think is wrong, but is pernicious. “If you don’t take my position on all things that have come out of NIST you are a stooge for the NSA”. I really don’t think that is something you want to be saying. > Moreover, it's not all-or-nothing. Bernstein and Lange have been arguing that the NIST curves are flawed since before Snowden. Lots of people have been advocating moving to curve 25519. I want a 384-or-better curve because my One True Curve has been P-384. Ah. Good. You are not taking an all-or-nothing position. I seem to have misread something then. I concur about P-384. Were we using elliptic curves, I would be advocating the same move. > If I'm going to move away from the NIST/NSA curve (which seems wise), what about everything else? This isn’t a philosophical or judgement difference between us. It’s just a technical starting place, but > Conveniently, I happen to have alternates for AES and SHA-2 in my back pocket, where they've been *alternates* in my crypto going back years. They're even in part of the software, sublimated to the goodness of the standard. The work is merely pulling them to the forefront and tying a bow around it. OK. You have persuaded me that you are making the right choice for your situation. > And absolutely, this is an emotional response. It's protest. Intellectually, I believe that AES and SHA2 are not compromised. Emotionally, I am angry and I want to distance myself from even the suggestion that I am standing with the NSA. As Coderman and Iang put it, I want to *signal* my fury. I am so pissed off about this stuff that I don't *care* about baby and bathwater, wheat and chaff, or whatever else. I also want to signal reassurance to the people who use my system that yes, I actually give a damn about this issue. So do I. So do I. I am furious. And I want to let the world know. And most importantly, I want to do what I can to make sure that nothing like this happens again. I wrote at top what kind of signal I think is needed for that. > I admire your cool head, Don’t mistake it for lack of anger. > but I have to stand over there. I apologize for angering you, but I'm not sorry. No apology needed. And I once again apologize for thinking and saying that you made your ciphersuite choices naively. And again, thank you for this discussion. Cheers, -j _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/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

1 0