March 2015 - cypherpunks - lists.cpunks.org

Cypherpunk Politics
by grarpamp 16 Mar '15

16 Mar '15

On Sun, Mar 15, 2015 at 4:32 PM, <dan(a)geer.org> wrote: > Please don't let this start an exploration of any rat-hole, Well, if so defined, Libertarian vs. Monopoly is a hole. Not clear whether that balance has shifted much yet, but people are finally developing wide recognition, tools, and methods that may bring that effect in the future. The internet and things are still a bit young politically but are growing up fast. Perhaps the first gen cpunk was the base philosophy plus the science of possible tools. Second gen the coding, beta test validation and trial runs. Third gen the application to results... > eternal vigilance is the price of freedom [...] there are no final > victories A truth.

1 0

Cypherpunk Politics [was: REAL-ID Coming]
by grarpamp 15 Mar '15

15 Mar '15

On Tue, Mar 3, 2015 at 5:19 AM, rysiek <rysiek(a)hackerspace.pl> wrote: >> Crypto isn't going to stop the metamining surveillance. And as in the >> subject, standing in line to happily get and show their papers please isn't >> going to stop that either. > > Agreed. > >> Where are that mass of geeks, cryptos, internets... those making >> such technical measures... where are they acting in politics? >> Running for office, bringing issues to their councils, donating, >> and so on. > > There might, or might not, be hackers among us who are trying to hack on > policy level. But those hackers, if they indeed are following (or maybe even > taking part in) the discussions here, might not want to come out with such > information, as the level of hostility towards any persons or organisations > that can be painted as "working with The Man" or "taking the Man's money" is > too damn high™. Who cares, that's up to the cpunk. If the cypherpunk is pure, working with the man to get cpunk shit done is just another hacking skin to hang on their wall. And a highly prized one of social engineering at that. Cpunks should bow the fuck down in respect to such a fellow cpunk, not fling hostile FUD at them just because they're working the system. For that matter, they should join them to add another voice. There are probably more US persons on this list than there are in their entire Congress. Think about that... Now in the other direction of possible hostility... should The Man discover a cpunk within their ranks, well yes, there is a risk there. The usual opsec applies. > In other words, FUD spread by "the Man" and the disinformation campaign, > sowing dissent, creating hostility and distrust within the community, and in > general the divide and conquer approach work wonders. That's why the above masses need to activate and throw the FUD back, and more, at The Man. Two can play that game. Problem is, right now there is only one real player on the field of politics, his name is The Man, and he's not on team cpunk.

10 16

Computer-stored encryption keys are not safe from side-channel attacks
by Eugen Leitl 14 Mar '15

14 Mar '15

http://www.techrepublic.com/article/computer-stored-encryption-keys-are-not… Computer-stored encryption keys are not safe from side-channel attacks By Michael Kassner March 11, 2015, 1:25 PM PST Using side-channel technology, researchers at Tel Aviv University can extract decryption keys from RSA and ElGamal implementations without altering or having control of a computer. Figure A: Tel Aviv University researchers built this self-contained PITA receiver. Image courtesy of Daniel Genkin, Lev Pachmanov, Itamar Pipman, Eran Tromer, and Tel Aviv University Not that long ago, grabbing information from air-gapped computers required sophisticated equipment. In my TechRepublic column Air-gapped computers are no longer secure, researchers at Georgia Institute of Technology explain how simple it is to capture keystrokes from a computer just using spurious electromagnetic side-channel emissions emanating from the computer under attack. Daniel Genkin, Lev Pachmanov, Itamar Pipman, and Eran Tromer, researchers at Tel Aviv University, agree the process is simple. However, the scientists have upped the ante, figuring out how to ex-filtrate complex encryption data using side-channel technology. The process In the paper Stealing Keys from PCs using a Radio: Cheap Electromagnetic Attacks on Windowed Exponentiation (PDF), the researchers explain how they determine decryption keys for mathematically-secure cryptographic schemes by capturing information about secret values inside the computation taking place in the computer. "We present new side-channel attacks on RSA and ElGamal implementations that use the popular sliding-window or fixed-window (m-ary) modular exponentiation algorithms," the team writes. "The attacks can extract decryption keys using a low measurement bandwidth (a frequency band of less than 100 kHz around a carrier under 2 MHz) even when attacking multi-GHz CPUs." If that doesn't mean much, this might help: The researchers can extract keys from GnuPG in just a few seconds by measuring side-channel emissions from computers. "The measurement equipment is cheap, compact, and uses readily-available components," add the researchers. Using that philosophy the university team developed the following attacks. Software Defined Radio (SDR) attack: This comprises of a shielded loop antenna to capture the side-channel signal, which is then recorded by an SDR program installed on a notebook. Portable Instrument for Trace Acquisition (PITA) attack: The researchers, using available electronics and food items (who says academics don't have a sense of humor?), built the self-contained receiver shown in Figure A. The PITA receiver has two modes: online and autonomous. Online: PITA connects to a nearby observation station via Wi-Fi, providing real-time streaming of the digitized signal. Autonomous: Similar to online mode, PITA first measures the digitized signal, then records it on an internal microSD card for later retrieval by physical access or via Wi-Fi. Consumer radio attack: To make an even cheaper version, the team leveraged knowing that side-channel signals modulate at a carrier frequency near 1.7 MHz, which is within the AM radio frequency band. "We used a plain consumer-grade radio receiver to acquire the desired signal, replacing the magnetic probe and SDR receiver," the authors explain. "We then recorded the signal by connecting it to the microphone input of an HTC EVO 4G smartphone." Cryptanalytic approach This is where the magic occurs. I must confess that paraphrasing what the researchers accomplished would be a disservice; I felt it best to include their cryptanalysis description verbatim: "Our attack utilizes the fact that, in the sliding-window or fixed window exponentiation routine, the values inside the table of ciphertext powers can be partially predicted. By crafting a suitable ciphertext, the attacker can cause the value at a specific table entry to have a specific structure. "This structure, coupled with a subtle control flow difference deep inside GnuPG's basic multiplication routine, will cause a noticeable difference in the leakage whenever a multiplication by this structured value has occurred. This allows the attacker to learn all the locations inside the secret exponent where the specific table entry is selected by the bit pattern in the sliding window. Repeating this process across all table indices reveals the key." Figure B is a spectrogram displaying measured power as a function of time and frequency for a recording of GnuPG decrypting the same ciphertext using different randomly generated RSA keys. The research team's explanation: "It is easy to see where each decryption starts and ends (yellow arrow). Notice the change in the middle of each decryption operation, spanning several frequency bands. This is because, internally, each GnuPG RSA decryption first exponentiates modulo the secret prime p and then modulo the secret prime q, and we can see the difference between these stages. "Each of these pairs looks different because each decryption uses a different key. So in this example, by observing electromagnetic emanations during decryption operations, using the setup from this figure, we can distinguish between different secret keys." Figure B: A spectrogram Image courtesy of Daniel Genkin, Lev Pachmanov, Itamar Pipman, Eran Tromer, and Tel Aviv University Any way to prevent the leakage? One solution, albeit unwieldy, is operating the computer in a Faraday cage, which prevents any spurious emissions from escaping. "The cryptographic software can be changed, and algorithmic techniques used to render the emanations less useful to the attacker," mentions the paper. "These techniques ensure the behavior of the algorithm is independent of the inputs it receives." Interestingly, the research paper tackles a question about side-channel attacks that TechRepublic readers commented on in my earlier article, "It's a hardware problem, so why not fix the equipment?" Basically the researchers mention that the emissions are at such a low level, prevention is impractical because: Any leakage remnants can often be amplified by suitable manipulation as we do in our chosen-ciphertext attack; and Leakage is often an inevitable side effect of essential performance-enhancing mechanisms. Something else of interest: the National Institute of Standards and Technology (NIST) considers resistance to side-channel attacks an important evaluation consideration in its SHA-3 competition.

4 4

Using ECC keys in GPG - why is this still deprecated?
by Mike Ingle 13 Mar '15

13 Mar '15

Why is GPG so reluctant to let you use ECC keys? Is it just a backward compatibility thing, or are they not trusted yet? I have the code written to use GnuPG 2.x with Confidant Mail, and I am trying to decide whether to ship GPG 1.4.x or 2.x with the next Windows build. If I ship 2.x and people start using ECC keys, then 2.x is effectively mandatory from then on. What do you think? Mike

2 1

Bitcoin sybils for Compliance/Spying
by grarpamp 13 Mar '15

13 Mar '15

https://bitcointalk.org/index.php?topic=978088.msg10756505 https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_se… http://yro.slashdot.org/story/15/03/13/1325243/ibm-reported-to-be-developin…

1 0

Fwd: [tor-talk] (UK) Parliamentary advice on Tor
by grarpamp 12 Mar '15

12 Mar '15

Cypherpunks can analyze whether it's fishy for world leaders and agencies known spouting FHOTI, going dark, and bitcoin hate... to start stylishly trending 180 on such things. Always beware the sly smile of the politician. ---------- Forwarded message ---------- From: Ben Tasker <ben(a)bentasker.co.uk> Date: Tue, Mar 10, 2015 at 6:56 AM Subject: [tor-talk] (UK) Parliamentary advice on Tor To: tor-talk(a)lists.torproject.org Interesting reading - the Parliamentary Office of Science and Technology (POST) has published it's report on Tor and the (in)feasibility of blocking anonymous access for users within the UK. The document's a PDF, and the layout is questionable, but it's worth a read if you have 5 minutes. http://www.parliament.uk/briefing-papers/POST-PN-488/the-darknet-and-online… http://www.parliament.uk/briefing-papers/POST-PN-488.pdf There are some interesting insights in there, from the perspective of what LEA's see. The overall summary though is - blocking anonymous access wholesale is not an acceptable policy option in the UK, and would impact on non-criminal Tor users. There _might_ be more appetite for legislating against Hidden Services, but enforcing it would be technologically infeasible. -- Ben Tasker https://www.bentasker.co.uk -- 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

2 4

Re: [tor-talk] USB sticks for Tails (write protection switch)
by grarpamp 12 Mar '15

12 Mar '15

On Thu, Mar 12, 2015 at 1:11 AM, Moritz Bartl <moritz(a)torservers.net> wrote: > That's why you need to "wrap" it, as described in the link? -- Exactly > because otherwise anyone can (un)set this. I recall seeing that there are TMP set/unset cmds. And one permanent set cmd. I should have specifically said looking at that in regards to available mechanisms to set that.

1 0

Re: [tor-talk] USB sticks for Tails (write protection switch)
by grarpamp 12 Mar '15

12 Mar '15

On Thu, Mar 12, 2015 at 12:35 AM, Moritz Bartl <moritz(a)torservers.net> wrote: > (**) Nobody has actually proven that you can circumvent the read-only > bit and simply write with modified kernel drivers ("please don't write > ... > The (micro)SD exposes registers for permanent write protection (cannot > be undone) and temporary write protection. If you set TMP_WRITE_PROTECT > and expose the SD card as USB device (not as mmc card), the registers > cannot be accessed from the host, so they cannot be changed. For an > example of this, see https://github.com/Nephiel/sdlocker-tiny . Maybe > there's a nice little SD card USB reader with a firmware that can be > patched for this. I wish to look at this further, but if these are normal mmc / usb / ata / scsi commmand opcodes (not actually requiring a physical burning interface), than you can do this commands over camcontrol freebsd or maybe [h|s]dparm linux without special dongle.

1 0

The .onion Special-Use Domain Name
by coderman 10 Mar '15

10 Mar '15

https://www.ietf.org/id/draft-appelbaum-dnsop-onion-tld-00.txt dnsop J. Appelbaum Internet-Draft Tor Project Inc. Intended status: Standards Track A. Muffett Expires: September 6, 2015 Facebook March 5, 2015 The .onion Special-Use Domain Name draft-appelbaum-dnsop-onion-tld-00 Abstract This document registers the ".onion" Special-Use Domain Name. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 2. The ".onion" Special-Use TLD . . . . . . . . . . . . . . . . 2 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 5.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The Tor network [Dingledine2004] has the ability to host network services using the ".onion" Top-Level Domain. Such addresses can be used as other domain names would be (e.g., in URLs [RFC3986]), but instead of using the DNS infrastructure, .onion names are hashes that correspond to the identity of a given service, thereby combining location and authentication. In this way, .onion names are "special" in the sense defined by [RFC6761] Section 3; they require hardware and software implementations to change their handling, in order to achieve the desired properties of the name (see Section 4). These differences are listed in Section 2. Like other TLDs, .onion addresses can have an arbitrary number of subdomain components. This information is not meaningful to the Tor protocol, but can be used in application protocols like HTTP [RFC7230]. See [tor-address] and [tor-rendezvous] for the details of the creation and use of .onion names. 1.1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. The ".onion" Special-Use TLD These properties have the following effects upon parties using or processing .onion names (as per [RFC6761]): 1. Users: human users are expected to recognize .onion names as having different security properties, and also being only available through software that is aware of onion addresses. 2. Application Software: Applications that implement the Tor protocol MUST recognize .onion names as special by either accessing them directly, or using a proxy (e.g., SOCKS [RFC1928]) to do so. Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion, and SHOULD NOT perform a DNS lookup. 3. Name Resolution APIs and Libraries: Resolvers that implement the Tor protocol MUST either respond to requests for .onion names by resolving them (see [tor-rendezvous]) or by responding with NXDOMAIN. Other resolvers SHOULD respond with NXDOMAIN. 4. Caching DNS Servers: Caching servers SHOULD NOT attempt to look up records for .onion names. They SHOULD generate NXDOMAIN for all such queries. 5. Authoritative DNS Servers: Authoritative servers SHOULD respond to queries for .onion with NXDOMAIN. 6. DNS Server Operators: Operators SHOULD NOT configure an authoritative DNS server to answer queries for .onion. If they do so, client software is likely to ignore any results (see above). 7. DNS Registries/Registrars: Registrars MUST NOT register .onion names; all such requests MUST be denied. 3. IANA Considerations This document registers the "onion" TLD in the registry of Special- Use Domain Names [RFC6761]. See Section 2 for the registration template. 4. Security Considerations .onion names are often used provide access to end to end encrypted, secure, anonymized services; that is, the identity and location of the server is obscured from the client. The location of the client is obscured from the server. The identity of the client may or may not be disclosed through an optional cryptographic authentication process. These properties can be compromised if, for example: o The server "leaks" its identity in another way (e.g., in an application-level message), or o The access protocol is implemented or deployed incorrectly, or o The access protocol itself is found to have a flaw. .onion names are self-authenticating, in that they are derived from the cryptographic keys used by the server in a client verifiable manner during connection establishment. As a result, the cryptographic label component of a .onion name is not intended to be human-meaningful. The Tor network is designed to not be subject to any central controlling authorities with regards to routing and service publication, so .onion names cannot be registered, assigned, transferred or revoked. "Ownership" of a .onion name is derived solely from control of a public/private key pair which corresponds to the algorithmic derivation of the name. Users must take special precautions to ensure that the .onion name they are communicating with is correct, as attackers may be able to find keys which produce service names that are visually or apparently semantically similar to the desired service. Also, users need be aware of the difference between a .onion name used and accessed directly via Tor-capable software, versus .onion subdomains of other TLDs and providers (e.g., the difference between example.onion and example.onion.tld). The cryptographic label for an .onion name is constructed by hashing the public key of the service with SHA1, truncating the output of the hash to 80 bits in length and the resulting hash output is concatenated with the string ".onion". As the number of output bits in generating the .onion name is less than the full size of the corresponding public key, an attacker may also be able to find a key that produces a collision with the same .onion name with substantially less work than a cryptographic attack on the full strength key. If this is possible the attacker may be able to impersonate the service on the network. If client software attempts to resolve a .onion name, it can leak the identity of the service that the user is attempting to access to DNS resolvers, authoritative DNS servers, and observers on the intervening network. This can be mitigated by following the recommendations in Section 2. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, February 2013. 5.2. Informative References [Dingledine2004] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the second-generation onion router", 2004, <https://www.onion- router.net/Publications/tor-design.pdf>. [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014. [tor-address] Mathewson, N. and R. Dingledine, "Special Hostnames in Tor", September 2001, <https://gitweb.torproject.org/torspec.git/plain/address- spec.txt>. [tor-rendezvous] Mathewson, N. and R. Dingledine, "Tor Rendezvous Specification", April 2014, <https://gitweb.torproject.org/torspec.git/plain/rend- spec.txt>. Authors' Addresses Jacob Appelbaum Tor Project Inc. Alec Muffett Facebook ...

3 2

NSA black budget cryptanalysis
by John Young 10 Mar '15

10 Mar '15

The Intercept file on NSA black budget cryptanalysis https://s3.amazonaws.com/s3.documentcloud.org/documents/1683814/black-budge… Included in the Zip file previously posted.

1 0