- cypherpunks@lists.ogf.org

Obscurity via Cross-Coin Exchanges
by Cathal Garvey 07 Mar '14

07 Mar '14

Hey all, As it came up in the Mt Gox asides in one of the variously titled threads on Nakomoto etc.: Bitcoin's pretty pseudonymous, rather than anonymous. Coin transactions are public, and some can be pinned to real identities, vendors or products, while others can be well inferred, leaving a smaller, hard to quantify set of "really anonymous" addresses, coins and transactions. Added to that, you have coin "taint" and badly patched wallets that mix coins from other addresses when sending payments, correlating various receiving addresses in one single transaction. There are laundries, but my understanding is that they're not highly regarded; their methods may be questionable, potentially they can be untangled. Without a large enough set of users, you have little guarantee of laundering; if only Alice and Bob pay in, and Alice and Bob receive out, then the recipient set is clearly too bad to protect them! OK, big problem. Zerocoin was designed to help fix that problem, by minting a zero-knowledge-proof based 'coin, but it hasn't yet been implemented. What about simply exchanging different blockchain based coins, though? Would that not help to "launder" with reasonable efficacy, provided both participants use crypto to hide the transaction? From the outside, transactions occur on both blockchains, but there's no "data trail" correlating the transactions with one another as there is within each blockchain. So, Alice buys .4 btc from a friend, but knows the friend's opsec might be poor, or that the transaction may have occurred over a bad channel, or that the coins were purchased from an exchange that demands valid phone numbers, etc.: she wants to launder. She contacts Bob, a Dogecoin seller, to set up a private exchange. She asks him to sell her 0.4btc worth of Dogecoin in two transactions of unequal value (to prevent analysis by exchange rate to ID their transaction). They conduct the exchange over an encrypted channel. From the outside, someone knows she's laundering, and just bought Dogecoin, but because they don't know her Dogecoin receiving addresses, they've lost the scent; she now has 0.4btc worth of Dogecoin, and can convert that back to btc again in the same way. In a round trip, she's broken the chain; she keeps her value, minus fees, of 0.4btc, but now it's in different btc, with no blockchain-recorded transaction logs to link the original, tainted btc to the new, clean btc. As a way for an individual to "launder", does this look plausible? Is it any better or worse than laundries as they currently exist? -- Please help support my crowdfunding campaign, IndieBB: Currently at 44.8% of funding goal, with 6 days left: http://igg.me/at/yourfirstgmo/x/4252296 T: @onetruecathal, @IndieBBDNA P: +3538763663185 W: http://indiebiotech.com

4 3

See???
by Robert Hettinga 07 Mar '14

07 Mar '14

I *told* you I wasn’t Satoshi. ;-) Poor bastard... Cheers, RAH

14 20

a speech
by dan＠geer.org 06 Mar '14

06 Mar '14

Perhaps of some relevance here. We Are All Intelligence Officers Now invited address to the RSA Conference, San Francisco, 28 February 2014 http://geer.tinho.net/geer.rsa.28ii14.txt --dan

2 1

STRINT
by stef 03 Mar '14

03 Mar '14

are you as concerned as me regarding the relevance and the utility of some of these papers? it strengthens my opinion that w3 does not seem like a competent place for handling this kind of stuff. some good intentions sprinkled with lots of "libtech plausible deniable Naïveté" and some rare gems hidden in between. source: https://www.w3.org/2014/strint/report.html i started to comment on some of the topics, would be interested in more insights into the others. > 1: Privacy Protected Email > Phillip Hallam-Baker > https://www.w3.org/2014/strint/papers/01.pdf > Abstract: > This proposal is two things: First it shows that with some small adjustments to S/MIME and PGP we can merge two competing end-to-end security proposals that are too hard for people to use into one scheme that provides a useful degree of security with no thought from the user. In cases where the user has security concerns they can easily determine that they are met. The second part of the proposal is that it the Trust set deployed to secure email encryption can be leveraged to solve pretty much every other end-to-end security requirement. If people generate keys for their email we can secure chat, video, 2-facto authentication as well. yaatse (yet another attempt to save email)? this should've been the last paper, if the goal of the conf was to seem competent in this topic... > ============================== > 2: Opportunistic Encryption for MPLS > Stephen Farrell, Adrian Farrrelll > https://www.w3.org/2014/strint/papers/02.pdf > Abstract: > This is an early proposal for a way to do open-channel D-H key agreement and encryption in MPLS. Two things are maybe interesting: a) its an example of trying to add confidentiality to an existing protocol with making PM harder as a specific goal and b) maybe it shows that there could be a benefit in a generic protocol for after-the-fact MITM detection for such cases. It'd probaby be most interesting to discuss (a) as one example of something we want to do more generally and not the specifics of MPLS at the workshop; and I'd be interested in whether or not (b) is tractable (I'm not sure). hmmm, mpls is a very simple thing. and totally irrelevant if people deploy already end-to-end crypto. what is this good for? tagging anonymous streams? i guess i have to read the paper... > ============================== > 3: Overcoming the Friend-or-Foe Paradigm in Secure Communication > Sebastian Gajek, Jan Seedorf, Marc Fischlin, Oezguer Dagdalen > https://www.w3.org/2014/strint/papers/03.pdf > Abstract: > --> Essentially, our point is that with the existing end-to-end client-server security paradigm, e.g. as instantiated in TLS, the "good guys" often actually have to mount attacks in order for middleboxes (which are on the path between client ans server being able) to perform their job. The good guys are thus technically indistinguishable from the bad guys. > --> Concretely, we are proposing to extend TLS in a way that would allow authorized modification of certain, dedicated parts of the TLS payload by middleboxes, while still allowing for integrity verification by clients. The crypto for such "Interferable Secure Communication" exists and we think it is feasible to extend TLS in this way in a reasonable timeframe. i believe they are trying to sell us MITM as something that is also done by the "good guys"? wtf? > ============================== > 4: Flows and Pervasive Monitoring > Ted Hardie > https://www.w3.org/2014/strint/papers/04.pdf > Abstract: This document describes methods that may hinder a pervasive monitor's efforts to derive metadata from flows. There are three main methods discussed in the paper: aggregation, contraflow, and multipath. These are largely side-effects of other efforts at this time, but the paper discusses how they might fit into the design space of efforts intended to combat pervasive monitoring and the related consequences for network operations. > ============================== > 5: BetterCrypto.org Applied Crypto Hardening > Aaron Zauner, L. Aaron Kaplan > https://www.w3.org/2014/strint/papers/05.pdf > Abstract: > BetterCrypto is a community-driven project where admins, engineers, cryptographers, security researchers alike participate in finding well researched best-practices for commonly deployed networked applications and infrastructure. We try to outline a proper interim solution until better protocols and standards are widely deployed. Our hope is that we can contribute to a safer internet for all and better understanding of cryptographic primitives for the operations community that needs to deploy sound security on the public internet. Our focus group: sysadmins / ops. > ============================== > 6: A Complimentary Analysis (The Danger Of The New Internet Choke Points) > Andrei Robachevsky, Christine Runnegar, Karen O'Donoghue, Mat Ford > https://www.w3.org/2014/strint/papers/06.pdf > Abstract: > The ongoing disclosures of pervasive surveillance of Internet users’ communications and data by national signals intelligence agencies have prompted protocol designers, software and hardware vendors, as well as Internet service and content providers, to re-evaluate prevailing security and privacy threat models and to refocus on providing more effective security and confidentiality. At IETF88, there was consensus to address pervasive monitoring as an attack and to consider the pervasive attack threat model when designing a protocol. > In this paper, we offer a complimentary analysis. We identify some of the components of the Internet architecture that provide attractive opportunities for wholesale monitoring and/or interception, and, therefore, represent architectural vulnerabilities, or choke points. We also suggest possible mitigation strategies and pose some of the questions that need to be considered if the Internet is to evolve to reduce such vulnerabilities. Finally, we identify some significant areas of tension or trade-offs, and we consider possible areas for additional efforts. > Also: http://www.internetsociety.org/blog/tech-matters/2014/02/danger-new-interne… and > http://www.circleid.com/posts/20140218_mind_the_step_function_are_we_really… > ============================== > 7: Trust Issues with Opportunistic Encryption > Scott Rose, Stephen Nightingale, Doug Montgomery > https://www.w3.org/2014/strint/papers/07.pdf > Abstract: > The lack of authentication in opportunistic encryption could have the perverse affect of putting more end users at risk: thinking that they are "secure", an end user may divulge private information to an imposter instead of the service they believe they have contacted. When adding protection mechanisms to protocols, designers and implementers should not downplay the importance of authentication in order to make opportunistic encryption easier to deploy. We advocate that while opportunistic encryption can solve one set of problems, authentication is often desired by end users. > ============================== > 8: Challenges with End-to-End Email Encryption > Jiangshan Yu, Vincent Cheval, Mark Ryan > https://www.w3.org/2014/strint/papers/08.pdf > Abstract: > In this paper we show how the use of an extended certificate transparency can build a secure end-to-end email or messaging system using PKI without requiring trusted parties nor complex p2p key-signing arrangements such as PGP. This makes end-to-end encrypted mail possible, and users do not need to understand or concern themselves with keys or certificates. In addition, we briefly present some related concerns i.e. metadata protection, key loss mitigation, spam detection, and the security of webmail. > ============================== > 9: Strengthening the path and strengthening the end-points > Xavier Marjou, Emile Stephan, Jean-Michel Combes, Iuniana Oprescu > https://www.w3.org/2014/strint/papers/09.pdf > Abstract: > Internet data is more and more subject to pervasive monitoring. This paper investigates ways of enhancing this situation depending on where such pervasive monitoring may occur. There are two different locations to secure: the endpoints and the path between these endpoints. In the present document, we also emphasize the fact that encryption, although bringing additional data confidentiality, might in some cases contradict security’s two other pillars, which are availability and integrity. > ============================== > 10: SIP is Difficult > Jon Peterson > https://www.w3.org/2014/strint/papers/10.pdf > Abstract: > While SIP is widely used as a protocol for real-time communications, it is very difficult to secure from pervasive monitoring. In fact, one could argue that SIP’s susceptibility to mass surveillance was essential to its success in the marketplace. This paper shows why SIP’s design left the door open for eavesdropping, and what lessons RTCWeb could learn from this. > ============================== > 11: Thoughts of Strengthening Network Devices in the Face of Pervasive Surveillance > Dacheng Zhang, Fuyou Miao > https://www.w3.org/2014/strint/papers/11.pdf > Abstract: > The material released by Edward Snowden has raised serious concerns about pervasive surveillance. People worry that their privacy is not properly protected when they are using the Internet. Network product vendors also encounter the doubts on the security of their products (e.g., routers, switches, firewalls). Such doubts are seriously damaging the Internet ecosystem. In this paper we try to analyze the affects brought by the Snowden scandal on our ability to trust products at the core of the Internet and discuss what the standard organization can do to help vendors address these security concerns. > ============================== > 12: Opportunistic Encryption for HTTP URIs > Mark Nottingham > https://www.w3.org/2014/strint/papers/12.pdf > Abstract: > This is a proposed method for using TLS with http:// URIs under discussion in the HTTPbis WG, in particular for HTTP/2 but also applicable to HTTP/1. One of the biggest decisions to make is whether or not to require the certs to validate in this scenario. > ============================== > 13: CyberdefenseOriented Multilayer Threat Analysis > Yuji Sekiya, Daisuke Miyamoto, Hajime Tazaki > https://www.w3.org/2014/strint/papers/13.pdf > ============================== > 14: A Threat Model for Pervasive Passive Surveillance > Brian Trammell, Daniel Borkmann, Christian Huitema > https://www.w3.org/2014/strint/papers/14.pdf > Abstract: > This document elaborates a threat model for pervasive surveillance, assuming an adversary with an interest in indiscriminate eavesdropping that can passively observe network traffic at every layer at every point in the network between the endpoints. We provide guidelines on evaluating the observability and inferability of information and metainformation radiated from Internet protocols. The central message to protocol designers: pervasive encryption for confidentiality, protocol and implementation design for simplicity and auditability, flexibility to allow fingerprinting resistance, and moving away from static identifiers can increase protocol-level resistance to pervasive surveillance. > ============================== > 15: Why Provable Transparency is Useful Against Surveillance > Ben Laurie > https://www.w3.org/2014/strint/papers/15.pdf > ============================== > 16: Withheld > ============================== > 17: Monitoring message size to break privacy - Current issues and proposed solutions > Alfredo Pironti > https://www.w3.org/2014/strint/papers/17.pdf > Abstract: > One of the Internet traffic features that can be easily > collected by passive pervasive monitoring is the size of the exchanged > messages, or the total bandwidth used by a conversation. Several works have > showed that careful analysis of this data can break users' expected privacy, > even for encrypted traffic. Despite this, little has been done in practice to > hide message sizes, perhaps because deemed too inefficient or not a realistic > threat. > In this short paper, we contextualize message size analysis in the wider > pervasive monitoring scenario, which encompasses other powerful analysis > techniques, and we re-state the severity of the privacy breach that message > size analysis constitutes. We finally discuss proposals to fix this issue, > considering practical aspects such as required developer awareness, ease of > deployment, efficiency, and interaction with other countermeasures. > ============================== > 18: Withheld > ============================== > 19: Making The Internet Secure By Default > Michael H. Behringer, Max Pritkin, Steinthor Bjarnason > https://www.w3.org/2014/strint/papers/19.pdf > Abstract: > Pervasive monitoring on the Internet is enabled by the lack of general, fundamental security. In his presentation at the 88th IETF Bruce Schneier called for ubiquitous use of security technologies to make pervasive monitoring too expensive and thus impractical. However, today security is too operationally expensive, and thus only used where strictly required. In this position paper we argue that all network transactions can be secure by default, with minimal or no operator involvement. This requires an autonomic approach where all devices in a domain enrol automatically in a trust domain. Once they share a common trust anchor they can secure communications between themselves, following a domain policy which is by default secure. The focus of this proposal is the network itself, with all protocols between network elements, including control plane protocols (e.g., routing protocols) and management plane protocols (e.g., SSH, netconf, etc). The proposal is evolutionary and allows a smooth migration from today’s Internet technology, device by device. > ============================== > 20: Increasing HTTP Transport Confidentiality with TLS Based Alternate Services > Patrick McManus > https://www.w3.org/2014/strint/papers/20.pdf > ============================== > 21: Balance - Societal security versus individual liberty > Scott Cadzow > https://www.w3.org/2014/strint/papers/21.pdf > ============================== > 22: Strengthening the Extensible Messaging and Presence Protocol (XMPP) > Peter Saint-Andre > https://www.w3.org/2014/strint/papers/22.pdf > Abstract: > This document describes existing and potential future efforts at strengthening the Extensible Messaging and Presence Protocol (XMPP), for discussion at the W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT). > ============================== > 23: The Internet We Want or the Internet We Deserve? > David Rogers > https://www.w3.org/2014/strint/papers/23.pdf > ============================== > 24: Beyond Encrypt Everything: Passive Monitoring > Mark Donnelly, Sam Hartman > https://www.w3.org/2014/strint/papers/24.pdf > ============================== > 25: Examining Proxies to Mitigate Pervasive Surveillance > Eliot Lear, Barbara Fraser > https://www.w3.org/2014/strint/papers/25.pdf > Abstract: > The notion of pervasive surveillance assumes that it is possible for an attacker to have access to all links and devices between end points, as well as end points themselves. We examine this threat is some detail with an eye toward whether trusted intermediaries can provide relief from the attack. We go on to examine the costs associated with the various remediation methods. In at least one case, we challenge the notion that one should encrypt absolutely everything in all cases, as was implied in at least one threat analysis. Finally we summarize in a set of four principles that should be considered in future work. > ============================== > 26: Spontaneous Wireless Networking to Counter Pervasive Monitoring > Emmanuel Baccelli, Oliver Hahm, Matthias Wählisch > https://www.w3.org/2014/strint/papers/26.pdf > Abstract: > Several approaches can be employed to counter pervasive monitoring at large scale on the Internet. One category of approaches aims to harden the current Internet architecture and to increase the security of high profile targets (data centers, exchange points etc.). Another category of approaches aims instead for target dispersal, i.e. disabling systematic mass surveillance via the elimination of existing vantage points, thus forcing surveillance efforts to be more specific and personalized. This paper argues how networking approaches that do not rely on central entities -- but rather on spontaneous interaction, as locally as possible, between autonomous peer entities -- can help realize target dispersal and thus counter pervasive monitoring. > ============================== > 27: Is Opportunistic Encryption the Answer? Practical Benefits and Disadvantages > John Mattsson > https://www.w3.org/2014/strint/papers/27.pdf > Abstract: > In this paper, we give an overview of various opportunistic and unauthenticated encryption techniques, and discuss their benefits, limits, and disadvantages. We recommend the Internet community to clearly define the term “opportunistic encryption” or to use other terms. > We conclude that while opportunistic and unauthenticated encryption certainly has its uses and may with the right choices provide good enough security for a low cost, general deployment of unauthenticated encryption is not an effective way to thwart pervasive monitoring. > ============================== > 28: Clearing off the Cloud over the Internet of Things > Carsten Bormann, Stefanie Gerdes, Olaf Bergmann > https://www.w3.org/2014/strint/papers/28.pdf > Abstract: > As was foreshadowed by product introductions in 2013, the Consumer > Electronics Show 2014 has seen the introduction of a large number of > "Internet of Things" (IoT) innovations. > Almost all of these have in common that they are meant to operate via > Cloud-based services. > In the light of the recent attention to threats by state-level > tenacious attackers with significant infrastructure (STASI), in > particular to their practice of pervasive monitoring, we discuss the > implications of a cloud-centric IoT landscape, and attempt to outline > a set of principles as a program to improve the long-term outlook. > ============================== > 29: The ARPA2.net project; Integrating and bundling hardened services for normal users > Michiel Leenars, Rick van Rein > https://www.w3.org/2014/strint/papers/29.pdf > ============================== > 30: The Trust-to-Trust Model of Cloud Services > Alissa Cooper, Cullen Jennings > https://www.w3.org/2014/strint/papers/30.pdf > ============================== > 31: Linkability Considered Harmful > Leif Johansson > https://www.w3.org/2014/strint/papers/31.pdf > Abstract: > Current debate on pervasive monitoring often focus on passive attacks on the protocol and transport layers but even if these issues were eliminated through the judicious use of encryption, roughly the same information would still be available to an attacker who is able to (legally or otherwize) obtain access to linked data sets which are being maintained by large content and service providers. > ============================== > 32: Simple Opportunistic Encryption > Andrea Bittau, Michael Hamburg, Mark Handley, David Mazières, Dan Boneh > https://www.w3.org/2014/strint/papers/32.pdf > Abstract: > Network traffic encryption is becoming a requirement, not an option. Enabling > encryption will be a communal effort so a solution that gives partial benefits > until fully deployed is needed. A solution that requires little changes to > existing infrastructure will also help as it can be quickly deployed to give > immediate short-term benefits. We argue that tcpcrypt, a TCP option for > opportunistic encryption is the path of least-resistance for a solution against > large-scale traffic encryption. Tcpcrypt requires no changes to applications, > is compatible with existing networks (works with NATs), and just works by > default. It is high performance, so it can be deployed on servers without much > concern. tcpcrypt attempts to maximize security for any given setting. By > default, it will protect against passive eavesdropping, and also allows > detecting large scale interception. With authentication, tcpcrypt can provide > full security against active attackers and so it is a complete solution both for > the short-term and long-term. > ============================== > 33: An Architecture for a Secure Cloud Collaboration System > Cullen Jennings, Suhas Nandakumar > https://www.w3.org/2014/strint/papers/33.pdf > Abstract: > The Internet technical community is looking at ways to address > pervasive attacks as described in several other internet drafts. > [I-D.barnes-pervasive-problem] describes threat model to characterize > various pervasive attacks on the Internet communications. There are > many systems that need to be secured against such attacks but this > paper considers one possible way to secure cloud based collaborations > systems. At a high level, this paper sugests that users or > enterprises could run a key server that manages the keys to access > their content. The cloud service provider would not have access to > decrypt the data stored in the cloud but various users of the cloud > service could get the keys to encrypt and decrypt the contents of > collaboration sessions facilitated by the cloud service. This does > not protect the meta data of who is talking to who but can help > protect the content of the conversations. > ============================== > 34: Security and Simplicity > Steven Bellovin > https://www.w3.org/2014/strint/papers/34.pdf > ============================== > 35: Privacy at the Link Layer > Piers O’Hanlon, Joss Wright, Ian Brown > https://www.w3.org/2014/strint/papers/35.pdf > Abstract: > This paper gives an overview of the privacy issues around the use of link layer identifiers and associated protocols. Whilst the IETF generally specifies IP level protocols it does also address the link layer in protocols such as address resolution, network attachment detection, tunnelling and router redundancy. > The indiscriminate broadcast of a device's MAC address, a unique and effectively personal identifier, allows for unregulated and broad-scale tracking of individuals via their personal devices, whether or not those devices have made use of a particular service or not. These addresses typically remain unchanged for the lifetime of a device, creating a persistent, lifelong tracking capability. The collation of such addresses, primarily WiFi and Bluetooth, has been been gathering pace and is already in use by organisations such as security agencies and advertisers. > Ephemeral addresses are used further up the stack so why not at the link layer? As default devices should use a randomised MAC address and any higher level associations can be maintained as and when approved by the user. > Moreover various other 'performance enhancing' approaches further degrade the privacy of individuals such as proactive discovery of WLAN SSIDs, Detection of Network Attachment (DNA), Wireless ISP roaming (WISPr), name lookups and so on. > All these mechanisms need to be re-examined in the light of pervasive monitoring. > ============================== > 36: Erosion of the moral authority of middleboxes > Joe Hildebrand > https://www.w3.org/2014/strint/papers/36.pdf > Abstract: > Many middleboxes on the Internet attempt to add value to the connections that traverse that point on the network. Problems in their implementations erode the moral authority that otherwise might accrue to the legitimate value that they add. > ============================== > 37: Policy Responses, Implications and Opportunities > Joseph Lorenzo Hall & Runa Sandvik > https://www.w3.org/2014/strint/papers/37.pdf > Abstract: > We raise issues for discussion that lie in the interface between policy and technology. Specifically, we discuss 1) routing, processing and data localization policy mandates (i.e., new laws that may affect how data flows through the 'net; 2) the uncertain possibility of dilution of credibility of IETF and w3c given what we've seen with NIST after NSA-coziness allegations; 3) the claim that strenghtening the internet and web will "help the bad guys" and the dubious need for "lawful intercept" funcationality; and 3) abusive content, cryptography as a controlled export technology, and the need to standardize more anonymity primitives (onion routing, pluggable transport protocols). We also highlight our own work in ensuring that technologists have a voice in policy environments and discuss a few interventions we coordinated over the past year, focusing on software backdoors and NSA surviellance. > ============================== > 38: Is it time to bring back the hosts file? > Peter Eckersley > https://www.w3.org/2014/strint/papers/38.pdf > ============================== > 39: Metaphors matter; application-layer; distribute more > Larry Masinter > https://www.w3.org/2014/strint/papers/39.pdf > Abstract: > 1. Dont say Attack: IETF should stay away from political theatre: changing protocols or workflows not because the change works but just to say you did something. Metaphors matter. > 2. For most relevant threats, traffic analysis is enough, and encyption doesnt mitigate. > 3. The only deployable protection -- if that is what is wanted -- means shifting architecture from client-server to mesh. > ============================== > 40: Levels of Opportunistic Privacy Protection for Messaging-Oriented Architectures > Dave Crocker, Pete Resnick > https://www.w3.org/2014/strint/papers/40.pdf > Abstract: > Messaging protection against pervasive monitoring (PM) needs to cover > primary payload, descriptive meta-data, and traffic-related analysis. > Complete protection against PM, for traffic through complex handling > sequences, has not yet been achieved reliably in real-world operation. > Consequently, this document considers a range of end-to-end, > object-based mechanisms, distinct from channel-based mechanisms. Each > approach offers incremental protection levels that can be provided with > existing, or low-risk, component technologies, such as through the DNS > and MIME conventions. > ============================== > 41: Fingerprinting Guidance for Web Specification Authors > Nick Doty > https://www.w3.org/2014/strint/papers/41.pdf > http://w3c.github.io/fingerprinting-guidance/ > Abstract: > Exposure of settings and characteristics of browsers can impact user privacy by allowing for browser fingerprinting. This document defines different types of fingerprinting, considers distinct levels of mitigation for the related privacy risks and provides guidance for Web specification authors on how to balance these concerns when designing new Web features. > ============================== > 42: Eradicating Bearer Tokens for Session Management > Philippe De Ryck, Lieven Desmet, Frank Piessens, Wouter Joosen > https://www.w3.org/2014/strint/papers/42.pdf > Abstract: > Session management is a crucial component inevery modern web application. It links multiple requests and temporary stateful information together, enabling a rich and interactive user experience. The de facto cookie-based session management mechanism is however flawed by design, enabling the theft of the session cookie through simple eavesdropping or script injection attacks. Possession of the session cookie gives an adversary full control the user’s sover ession, allowing him to impersonate the user to the target application and perform transactions in the user’s name. While several alternatives for secure session management exist, they fail to be adopted due to the introduction of additional roundtrips and overhead, as well as incompatibility with current Web technologies, such as third-party authentication providers, or widely deployed middleboxes, such as web caches. > We identify four key objectives for a secure session management mechanism, aiming to be compatible with the current and future Web. We propose SecSess, a lightweight session management mechanism based on a shared secret between client and server, used to authenticate each request. SecSess ensures that a session remains under control of the parties that established it, and only introduces limited overhead. During session establishment, SecSess introduces no additional roundtrips and only adds 4.3 milliseconds to client-side and server-side processing. Once a session is established, the overhead becomes negligible (<0.1ms), and the average size of the request headers is even smaller than with common session cookies. Additionally, SecSess works well with currently deployed systems, such as web caches and third-party services. SecSess also supports a gradual migration path, while remaining compatible with currently existing applications. > ============================== > 43: STREWS Web-platform security guide: security assessment of the Web ecosystem > Martin Johns, Lieven Desmet > https://www.w3.org/2014/strint/papers/43.pdf > Abstract: > In this document, we report on the Web-platform security guide, which has been developed within the EC-FP7 project STREWS. Based on their research, the STREWS consortium argues that in order to strengthening the Internet (e.g. against pervasive monitoring), it is crucial to also strengthen the web application ecosystem, the de-facto Internet application platform. > ============================== > 44: Pervasive Attack: A Threat Model and Problem Statement > Richard Barnes, Bruce Schneier, Cullen Jennings, Ted Hardie > https://www.w3.org/2014/strint/papers/44.pdf > Abstract: > Documents published in 2013 have revealed several classes of "pervasive" attack on Internet communications. In this document, we review the main attacks that have been published, and develop a threat model that describes these pervasive attacks. Based on this threat model, we discuss the techniques that can be employed in Internet protocol design to increase the protocols robustness to pervasive attacks. > ============================== > 45: Cryptech - Building a More Assured HSM with a More Assured Tool-Chain > Randy Bush > https://www.w3.org/2014/strint/papers/45.pdf > ============================== > 46: Replacing passwords on the Internet AKA post-Snowden Opportunistic Encryption > Ben Laurie, Ian Goldberg > https://www.w3.org/2014/strint/papers/46.pdf > ============================== > 47: End-User Concerns about Pervasive Internet Monitoring: Principles and Practice > Tara Whalen, Stuart Cheshire, David Singer > https://www.w3.org/2014/strint/papers/47.pdf > Abstract: > This position paper will discuss pervasive monitoring on the Internet from the perspective of end users: what are overarching concerns around pervasive monitoring, and what are some steps that could be taken to address those concerns? We begin by exploring a preliminary set of characteristics of systemic surveillance, which can be used to pinpoint dominant concerns of end users that should be addressed through technical means. We then illustrate one specific significant problem facing end users, namely that of certificate errors, which can be exploited to facilitate pervasive surveillance. We suggest that users should not be required to determine whether a certificate error is valid, but instead to block access to websites that generate such errors. We believe this approach would be more effective in protecting end users in an environment of persistent network threats. > ============================== > 48: Developer-Resistant Cryptography > Kelsey Cairns, Graham Steel > https://www.w3.org/2014/strint/papers/48.pdf > Abstract: > "Properly implemented strong crypto systems are one of the few things > that you can rely on" - Edward Snowden. So why is mass surveillance so successful? One (big) problem is endpoint security. Another is that strong crypto systems are sufficiently difficult to implement that often either mistakes are made resulting in catastrophic loss of security, or cryptography is not used at all. What can we do to make cryptography easier to use and more resistant to developer errors? > ============================== > 49: Improving the reliability of key ownership assertions > Kai Engert > https://www.w3.org/2014/strint/papers/49.pdf > Abstract: > A majority of today's secure Internet connections rely on Certificate Authorities not being abused for issueing false certificates (key ownership assertions), which might get abused for interception purposes, despite the risk of detection. I suggest to enhance Internet protocols with protective mechanisms to detect false key ownership assertions. > Ideas: (1) Using a network of proxy services, for example as implemented by the The Onion Router (Tor), consistency checking chould be performed by individual clients, in order to detect assertions that are likely false, prior to allowing a connection (see Detector.io). (2) Extend the idea that notary services provide a second opinion about the correctness of key ownership assertions, by requiring CAs to run such services (kuix.de/mecai). (3) Implement protocol extensions, where client software reports previously seen key ownership assertions to the operators of services, allowing the discovery of false ownership assertions. > ============================== > 50: Mike O'Neill's Position Paper > Mike O'Neill > https://www.w3.org/2014/strint/papers/50.pdf > ============================== > 51: Detecting MITM Attacks on Ephemeral Diffie-Hellman without Relying on a PKI in Real-Time Communications > Alan Johnston > https://www.w3.org/2014/strint/papers/51.pdf > Abstract: > With the recent revelations about pervasive surveillance on the Internet, there is renewed interest in techniques that protect against passive eavesdropping without relying on a Public Key Infrastructure (PKI). An ephemeral Diffie-Hellman (DH) key agreement can provide such protection, but (without authentication) the exchange is vulnerable to a Man in the Middle (MitM) attack. An example of a protocol that has MitM protection for a DH key agreement is ZRTP, RFC 6189, “ZRTP: Media Path Key Agreement for Unicast Secure RTP.” ZRTP provides pervasive surveillance resistant security for Voice over IP (VoIP), video communication, and other real-time communication services. This paper describes the techniques used by ZRTP to detect MitM attacks, and explores whether these techniques could be used to develop a general MitM detection protocol to be used by other non-real-time communication protocols. An example of how ZRTP can provide MitM detection for another protocol, DTLS-SRTP, Datagram Transport Layer Security – Secure Real-time Transport Protocol, is given. > ============================== > 52: Trust & Usability on the Web, a Social/Legal perspective > Rigo Wenning, Bert Bos > https://www.w3.org/2014/strint/papers/52.pdf > Abstract: > (1) The browsers' UIs for security are very technical and seem to > avoid saying anything useful, maybe so that the browsers and CAs cannot be > held responsible. (2) A user wanting to configure security has difficulty > finding the UI and then often discovers that settings are hard-coded or > unclear. (3) The security model is based on trusting a few commercial > entities and mistrusting the user, who ends up without control over his > software if one of those entities is compromised or doesn't share his goals. > Conclusion: We need better UIs, which in turn requires a PKI that has the > metadata and social aspects that help users understand and explore the keys > and the organizations behind them. > ============================== > 53: Hardening Operations and Management Against Passive Eavesdropping > Bernard Aboba > https://www.w3.org/2014/strint/papers/53.pdf > Abstract: > Today within service providers protocols used for operations and management frequently send data in the clear, enabling the data to be collected by passive eavesdroppers. Examples of operations and management protocols include Authentication, Authorization and Accounting (AAA), syslog and Simple Networking Monitoring Protocol (SNMP). Since the publication of "Operational Security Current Practices in Internet Service Provider Environments" [RFC4778], the IETF has developed specifications that enable per-packet confidentiality to be applied to operations and management protocols. By developing updated operational guidance recommending deployment of per-packet confidentiality based on recent IETF Request for Comments (RFCs) and work-in-progress, the IETF can assist in bringing customer and regulatory pressure to bear in improving operational practices. > ============================== > 54: A few theses regarding privacy and security > Andreas Kuckartz > https://www.w3.org/2014/strint/papers/54.pdf > ============================== > 55: Meet the new threat model, same as the old threat model > Eric Rescorla > https://www.w3.org/2014/strint/papers/55.pdf > ============================== > 56: It’s Time for Application-Centric Security > Yuan Gu, Harold Johnson > https://www.w3.org/2014/strint/papers/56.pdf > Abstract: > An 'application' is an organized data/executable-code compound performing a specific function or service. We hold that applications should be protected intrinsically (by obfuscated, tamper-resistant code and data), as well as extrinsically (by encrypted communication, hardened hardware platforms, authenticated access). (1) Cloud-based applications are vulnerable to their hosting services or neighbors. (2) Peripheral-based applications (on phones, pads, PDAs, or more generally in the Internet of Things) are vulnerable because hardware security is inconsistent and very expensive to repair. (3) Browser-based applications are vulnerable because they run on potentially hostile or malware-infected browsers or platforms which we don't control. > Application obfuscations such as homomorphic transforms on data and computation (motto: avoid data or computation in plain form) and increased interdependency (motto: aggressive fragility under tampering) can effectively address these vulnerabilities. > ============================== > 57: Sabatini Monatesti position paper > Sabatine Monatesti > https://www.w3.org/2014/strint/papers/57.pdf > ============================== > 58: Trust problems in pervasive monitoring > Melinda Shore, Karen O'Donoghue > https://www.w3.org/2014/strint/papers/58.pdf > ============================== > 59: Beyond “Just TLS Everywhere”: From Client-encrypted Messaging to Defending the Social Graph > Harry Halpin, George Danezis > https://www.w3.org/2014/strint/papers/59.pdf > ============================== > 60: Network Security as a Public Good > Wendy Seltzer > https://www.w3.org/2014/strint/papers/60.pdf > Abstract: > Network security depends on cooperation of multiple actors in the Internet ecosystem. Standards consortia should support and help coordinate activity to protect the commons. > ============================== > 61: Statement of Interest on behalf of the W3C TAG > Dan Appelquist > https://www.w3.org/2014/strint/papers/61.pdf > ============================== > 62: Improving Security on the Internet > Hannes Tschofenig > https://www.w3.org/2014/strint/papers/62.pdf > ============================== > 63: Protecting customer data from government snooping > Orit Levin > https://www.w3.org/2014/strint/papers/63.pdf > ============================== > 64: Privacy Aware Internet Development Initiative 2014 > Achim Klabunde > https://www.w3.org/2014/strint/papers/64.pdf > Abstract: > Protecting privacy on the Internet requires more than using encryption. Protocols, implementations and applications must minimise the amount of personal data that is distributed and collected. Work is required to develop and disseminate privacy aware design and impmementation techniques to the actual developers. The paper is a call for interest for an initiative aiming to address this need, supported by privacy and technology experts. > ============================== > 65: The Internet is Broken: Idealistic Ideas for Building a NEWGNU Network > Christian Grothoff, Bartlomiej Polot, Carlo von Loesch > https://www.w3.org/2014/strint/papers/65.pdf > Abstract: > This paper describes issues for security and privacy at all layers of the Internet stack and proposes radical changes to the architecture to build a network that offers strong security and privacy by default. > ============================== > 66: Opportunistic Keying as a Countermeasure to Pervasive Monitoring > Stephen Kent > https://www.w3.org/2014/strint/papers/66.pdf > Abstract: > This document was prepared as part of the IETF response to concerns about “pervasive monitoring” as articulated in [draft-farrell-perpass-attack]. It begins by exploring terminology that has been used in IETF standards (and in academic publications) to describe encryption and key management techniques, with a focus on authentication vs. anonymity. Based on this analysis, it propose a new term, “opportunistic keying” (OK) to describe a goal for IETF security protocols, one possible countermeasure to pervasive monitoring. It reviews key management mechanisms used in IETF security protocol standards, with respect to these properties, to identify what changes might be needed to offer OK with minimal changes. The document ends by examining possible impediments to and potential adverse effects associated with deployment and use of techniques that would increase the use of encryption, even when keys are distributed in an unauthenticated manner. > ============================== > 999: The Shadow Internet: liberation from Surveillance, Censorship and Servers > Johan Pouwelse > https://datatracker.ietf.org/doc/draft-pouwelse-perpass-shadow-internet/ > Abstract: > This IETF Perpass document describes some scenarios and requirements for Internet hardening by creating what we term a shadow Internet, defined as an infrastructure in which the ability of governments to conduct indiscriminate eavesdropping or censor media dissemination is reduced. > Internet-deployed code is available for most components of this shadow Internet. > This 18-page document is not available via the STRINT website. > ============================== > 998: Privacy and Networking Functions > Jari Arkko > http://www.arkko.com/ietf/strint/draft-arkko-strint-networking-functions.txt > Abstract: > This paper discusses the inherent tussle between network functions and some aspects of privacy. There is clearly room for a much improved privacy in Internet communications, but there are also interesting interactions with network functions, e.g., what information networks need to provide a service. Exploring these limits is useful to better understand potential improvements. > ============================== > (should this page go down, we have a backup at http://kuix.de:9321/p/strint-abstracts ) > ============================== -- pgp: https://www.ctrlc.hu/~stef/stef.gpg pgp fp: FD52 DABD 5224 7F9C 63C6 3C12 FC97 D29F CA05 57EF otr fp: https://www.ctrlc.hu/~stef/otr.txt

1 0

time to set up the test amplifier script again :)
by Anonymous Remailer (austria) 01 Mar '14

01 Mar '14

damn bunch of fucking luddites.. whine piss and moan about test test test?? I will set up and run my "test amplifier" procmail script from the 1990's just for fucking with the whiners heads! fucking software wimps the "MEDUSA" tentacle #99 ps been way too fucking quiet around here fuckwads are all at the RSA conference selling us out!

2 1

TEST TEST TEST MOTHERFUCKER!!!
by Anonymous Remailer (austria) 01 Mar '14

01 Mar '14

test... got an objection to test? improve your fucking spam filters you fucking idiots

5 5

Gox
by Rich Jones 28 Feb '14

28 Feb '14

Alleged leaked doc from inside Mt. Gox: http://www.scribd.com/doc/209050732/MtGox-Situation-Crisis-Strategy-Draft Nasty lookin', especially that assets and liabilities page! Although I don't understand how the theft could affect their cold storage. Soooooo.. who got burned? R

11 23

Whonix Anonymous Operating System Version 8 Released!
by Griffin Boyce 27 Feb '14

27 Feb '14

-------- Original Message -------- Subject: [tor-talk] Whonix Anonymous Operating System Version 8 Released! Date: Thu, 27 Feb 2014 22:06:23 +0000 From: Patrick Schleizer <adrelanos(a)riseup.net> Reply-To: tor-talk(a)lists.torproject.org To: tor-talk(a)lists.torproject.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Whonix is an operating system focused on anonymity, privacy and security. It's based on the Tor anonymity network, Debian GNU/Linux and security by isolation. DNS leaks are impossible, and not even malware with root privileges can find out the user's real IP. Whonix consists of two parts: One solely runs Tor and acts as a gateway, which we call Whonix-Gateway. The other, which we call Whonix-Workstation, is on a completely isolated network. Only connections through Tor are possible. Download Whonix for VirtualBox ############################## https://www.whonix.org/wiki/Download Download Whonxi for KVM / Qemu ############################## Experimental. See below. Users of Whonix 7 and below ########################### There is no upgrade path from Whonix 7 to Whonix 8, sorry. You have to manually download new Whonix images. Call for Help ############# - - If you know shell scripting (/bin/bash) and linux sysadmin, please join us! There are plenty of ways to make Whonix safer. - - We are also looking for a download mirros. - - For https://www.whonix.org we need some help with css, html, mediawiki, wordpress, webdesign. Download Whonix for KVM / Qemu ############################## Entirely untested! This is only useful if you have a developers mindset! This is the first time .qcow2 images are available (as .tar.gz, qcow2 image must be unpacked): http://sourceforge.net/projects/whonix/files/current/8/ We have unfinished(!) instructions for KVM: https://www.whonix.org/wiki/KVM There are still a few blockers before using Whonix with KVM can be considered sane: https://www.whonix.org/wiki/Dev/KVM Please help out solving them. Whonix also needs a maintainer to support using Whonix with KVM. If you want to upgrade existing Whonix version using Whonix's APT repository ################################################################ Sorry, upgrading from existing Whonix version (0.5.6, 7, etc.) to Whonix 8 is not be possible. Updating from the previous testers-only version 7.7.8.6 or 7.7.9.8 should be possible when you have Whonix's (stable) APT repository enabled. See: https://www.whonix.org/wiki/Whonix-APT-Repository (Whonix 7.7.9.8 is the same version as Whonix 8, just a different version number.) If you want to upgrade existing Whonix version from source code ############################################################### Sorry, upgrading from existing Whonix version (0.5.6, 7, etc.) to Whonix 8 is not be possible. Updating from the previous testers-only version 7.7.8.6 or 7.7.9.8 should be possible, see: https://www.whonix.org/wiki/Dev/BuildDocumentation_8_deb (Whonix 7.7.9.8 is the same version as Whonix 8, just a different version number.) If you want to build images from source code ############################################ See https://www.whonix.org/wiki/Dev/BuildDocumentation. Physical Isolation users ######################## See https://www.whonix.org/wiki/Physical_Isolation. Changelog between Whonix 7 and Whonix 8 ####################################### * Whonix is now based on Debian stable instead of Debian testing. * In new installations, automatic updates of Whonix's debian packages are disabled by default. During first start, users can decide if they want to enable Whonix's APT repository or want to leave it disabled. * Fixed Whonix's Tor Browser download and start script for TBB 3.5. * Fixed physical isolation build script. * Verifiable Builds. Whonix now has a feature which allows the community to check that Whonix .ova releases are verifiably created from project's own source code. Also made ade Whonix's APT repository verifiable (even deterministic!). Please see https://www.whonix.org/wiki/Verifiable_Builds for details. * Made Whonix build script configurable (can now build terminal-only Whonix-Gateway's and/or Whonix-Workstations; 64 bit builds and more) * Improved Whonix News's security. All Whonix News Files are now inside one tarball, which is signed. This stops leaking how many users are using a particular version. * whonixcheck's Whonix News download now checks if Whonix News are still valid (currently up to 4 weeks) and therefore detects indefinite freeze and replay attacks. * whonix_repository tool now has a graphical user interface; added more command line switches. * Set default locale to en_US.UTF-8. * Simplified custom user installation of TorChat, thanks to dummytor. (Protecting from Tor over Tor.) * Removed apper and synaptic from default installation, because they are too confusing / have too many bugs, do not always work in all cases for all users, #104, can still be manually installed if wanted, see also https://www.whonix.org/wiki/Dev/Automatic_Updates * whonixcheck: more configuration options, any function can now be disabled, this is useful for users who wish to disable control port filter proxy, they can disable the check_tor_bootstrap function * whonixcheck: added protection against possibly malicious strings from check.torproject.org (in case of a bug, compromise of check.tpo server or CA compromise), IP strings are now max 50 characters long. User will be warned in case the limit is exceeded. * Whonix-Workstation: no longer installing Tor Browser by default, this simplified implementing verifiable builds (#113), installing iceweasel by default, which can be used to download Tor Browser, added local iceweasel browser homepage saying that iceweasel should not be used for anything other than downloading Tor Browser, unless one knows what one is doing. * Removed galternatives from whonix-workstation-default-applications because galternatives has been (temporarily) removed from Debian testing * Building Whonix from frozen repository, from snapshot.debian.org to make the build script more resistant from upstream changes and also to make Whonix verifiable. * The Whonix Team can now use separate keys for Whonix's APT Repository and Whonix News. * Added technical documentation about keys in Whonix whonix_shared/usr/share/whonix/keys/readme. * new man page: man/whonix_shared/sdwdate.8.ronn * Deactivated Maximizing Windows by dragging them to the top of the screen to prevent users from accidentally maximizing their browser window when they are using resolutions higher than 1024x768. See https://www.whonix.org/wiki/Higher_Screen_Resolution ; https://github.com/Whonix/Whonix/issues/110 and https://trac.torproject.org/projects/tor/ticket/7255 for more information. #108 * added udisks to whonix-shared-packages-recommended for mounting removable drives * KDE settings changes, set to oxygen as suggested by scarp in "[Whonix-devel] Plastique kwin style & Widget Style" * whonixcheck: increased timeout for the tor bootstrap.py utility from 5 to 10 seconds to make it compatible with slow systems as per bug reporthttps://www.whonix.org/wiki/Special:AWCforum/st/id248/whonixcheck%3A_… * whonixcheck: Whonix News File is now deterministic * whonixcheck: Whonix News added timeout for gpg and tar * added secure-delete, because it contains sfill, which can be used to zero out free space, which is required for disk shrinking * Deactivated running update-command-not-found during build, since not deterministic (verifiable). Manually running is of course still possible. * whonix_shared/etc/apt/sources.list.d/torproject.list: removed the "deb http://deb.torproject.org/torproject.org tor-0.2.4.x-jessie main" repository, since that repository has been removed by The Tor Project (Tor is now in their Debian testing repository, which is already added) * fixed a bug reported by scarp, whonix_shared/usr/share/whonix/postinst.d/70_disable_kdm_autostart: was not disabling other display managers other than kdm. Now using the more generic /usr/lib/whonix/display-manager-dpkg-post-invoke. * msgcollector: fix race condition not always closing progress bar when it reached 100% * Whonix-Gateway: Workaround for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732578 https://www.whonix.org/wiki/Download#Connection_Issues_-_Tor_stops_working_… https://www.whonix.org/wiki/Special:AWCforum/st/id287/new_tor_and_debian_up… Set in /etc/default/tor: USE_AA_EXEC="no" Can be commented out when that bug gets fixed. * optionally (opt-in) building qcow2 images, first rudimentary implementation, build target (VirtualBox or qcow2 or both) should probably be configurable in whonix_build script (#122) * Whonix News Blog Download / Whonix News: Whonix News Blogs (Whonix Feature Blog and Whonix Important Blog) are now deployed over the same mechanism as Whonix News. * Whonix-Workstation: better implementation of dummytor using config-package-dev (might break compatibility with Whonix 7) * removed adrelanos' old key; removed whonix_shared/usr/share/whonix/postinst.d/70_legacy (breaks compatiblity with Whonix 7) * Re-implemented uwt and dummytor using config-package-dev instead of custom dpkg-diversions. Breaks compatibly with Whonix 7. * Removed rawdog and pandoc since no longer required. * moved misc scripts (Scripts for managing Whonix's offical repository and Whonix News; debug scripts; developer documentation and deprecated code) to https://github.com/Whonix/whonix-developer-meta-files * whonixcheck: do not show output of gpg for Whonix News verification * whonixcheck: do not start whonixcheck, if whonixsetup hasn't finished yet * whonixcheck: new --verbose / --debug options * whonixcheck: Check that /proc/sys/net/ipv4/ip_forward and /proc/sys/net/ipv6/ip_forward aren't set to 1 to prevent users from shooting their own feet. * whonixcheck: Whonix News can now optionally be signed with two keys, as long as either one is still valid, will be accepted * whonixcheck: whonix_shared/etc/init.d/whonixcheckd: on stop, give whonixcheck time to gracefully shut down so it can close any still eventually open progress bars * whonixcheck: fix, exit cleanly (close progress bar) when killed by other instance of whonixcheck * whonixsetup: start whonixcheck at the end of whonixsetup on Whonix-Workstation * torbrowser: hide output of gpg import; ask "Start Tor Browser yes/no" after upgrading" * torbrowser: added timeout to gpg to prevent endless data attacks * torbrowser/whonixcheck: alternative method detecting locally installed Tor Browser version. When $tbb_folder/Docs/version does not exist, i.e. when the user manually downloaded Tor Browser, try to detect version number from ~/tor-browser_en-US/Docs/sources/versions.; comment * desktop: higher resolution icons for whonix_repository, whonixcheck, contribute and donate, whonix gateway firewall, tb recommend, important blog and torbrowser * ram adjusted desktop starter: fixed lightdm (/usr/sbin/...) auto detection * qcow2 images: added metadata preallocation * qcow2 images: added "-o cluster_size=2M" to "qemu-img" for better performance * build script: fix "sudo: unable to resolve host debian" * build script: added --no-options to gpg to avoid conflict with user's gpg config files * build script: added benchmarking * build script: whonix_build_both: support extra parameter * build script: got rid of grml_config by using grml-debootstrap's new environment variables feature * build script: skip backup-img-after-grml-debootstrap and backup-img-after-meta-package-install build steps by default, can be re-enabled by builder * build script: allow running build-steps.d/2400_convert-img-to-qcow2 without root * build script: improved error handling, when error is detected, wait until builder presses enter before cleanup and exit to make it simpler to read error messages when building in cli * build script: fixed update-locale bug build script: Avoiding "perl: warning: Setting locale failed." as suggested on https://wiki.ubuntu.com/DebootstrapChroot and https://lists.debian.org/debian-amd64/2005/08/msg00249.html by setting export LANG="C" * verifiable builds: new build step build-steps.d/2350_cleanup; Get rid of /dev folder inside the vm image. This is only required for verifiable builds. Otherwise this could be skipped. For example, "sudo sha512sum /dev/xconsole" or "sudo sha512sum /dev/initctl" would run forever. The /dev folder gets recreated by the kernel upon first boot. * Improved messages. * Lots of smaller fixes. * Code refactoring. * For more details, see the git log. -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJTD7beXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2RTk3OUIyOEE2RjM3QzQzQkUzMEFGQTFD QjhENTBCQjc3QkIzQzQ4AAoJEMuNULt3uzxIU9oP/22e7sqG07qwTywxpfA0UVX/ QLtJ5i4KBJIoJUk7VWgt63r6dFlFkWIWD5EGn/CC4OywS/9DPNHA+lgrzJQdSZe2 NduB2cSihcewkxI2Mjb1X+VFcw3okzAokDrZ9EMblWHKjhlunBeoQmfGj9oCKc4p LCebZChFF0vAebk71hBMVcafgQEciHKx4KJKUsJQ+Dmhcbfa3Elba5QM5wKw6Whh DlqRUJ0UM+x/SQ/3dwIE5vMWdf1tj11q6P7BeJN7XUWf68FX0f1Zy/r8JtWwEt8q 5ZN9JXcGO/SAZdzFUvrhMCj93l/uBzTeC595mqLOkP8d700ofg1dVOnDdy1eiwh9 /uGJ+H7983te90WnkHnu8NTBfqwfi/ZmNNR+LBnNVxBUywXQaaUWCTgdHCx59CI9 hs9Wl5wxNLmeRbBvRCCbjNSir+1wbtKCeSb8NTBrsWOqyN/tIioN4vnoA33ls5tq HYxFNdMkaLAsSb6pO/b9oIs2EeXUL8t/E1mc9Jr3H7nkm5FbE+9sClugod+PPXL8 RiGU0o/XiVU/aaT+7iVAaTF7z8wlXFTTsQ1V6/FgsRAAVy9dKJQriPTY+bPcJhLZ 1z+VaTRcxXA+rCSM9VeBBYg1lzFevJP7ExH5y6cFgE8DBLPUtXG5cCISGZFS0A0x NzmZy2053AFzuPNAu5WC =JQiF -----END PGP SIGNATURE----- -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

1 0

Tor @ FinCrypt2014
by grarpamp 26 Feb '14

26 Feb '14

> Tor Weekly News — February 26th, 2014 > Tor @ Financial Cryptography and Data Security 2014 > Mar 03-07 Barbados http://fc14.ifca.ai/ The above is regarding botnets (mevade) using Tor and related network load and availability... a necessary foundation for finance. The FC14 program has an anonymity session, related to bitcoin, whose papers at this time don't appear to relate directly to applied anon FC via anon networks, but are closer to that topic... bitiodine, IP addresses, mixcoin... if that is what you were expecting.

1 0

Re: Telegram vs. Unhandled Expression
by rysiek 26 Feb '14

26 Feb '14

Dnia środa, 26 lutego 2014 02:42:49 Lodewijk andré de la porte pisze: > 2014-02-26 1:44 GMT+01:00 rysiek <rysiek(a)hackerspace.pl>: > > Well, what kind of philantropist would start a UNIX alternative, right? ;) > > That's at least a kind that winds all his costs off on his university. A > very understandable kind. I have no idea how and where to the Telegram crew "winds" their costs. Nor do I care, as long as the communication is secured even from their own potential meddling. So the question is: is it? -- Pozdr rysiek

3 4