DOCSLIB.ORG

The Gnunet System

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Gnunet System 1 Th`esed'habilitation `adiriger des recherches Universit´ede Rennes 1 Mention: Informatique The GNUnet System Christian Grothoff Soutenue le 10 octobre 2017 devant le jury compos´ede Messieurs les Professeurs: Anne-Marie Kermarrec (Universit´ede Rennes 1) Tanja Lange (Technische Universiteit Eindhoven) George Danezis (University College London) Joe Cannataci (University of Groningen) Saddek Bensalem (University of Grenoble) Au vu des rapports de Messieurs les Professeurs: Tanja Lange (Technische Universiteit Eindhoven) George Danezis (University College London) Saddek Bensalem (University of Grenoble) Revision 1.0 2 Abstract GNUnet is an alternative network stack for building secure, decentralized and privacy-preserving distributed applications. Our goal is to replace the old inse- cure Internet protocol stack. Starting from an application for secure publication of files, it has grown to include all kinds of basic protocol components and ap- plications towards the creation of a GNU internet. This habilitation provides an overview of the GNUnet architecture, including the development process, the network architecture and the software architecture. The goal of Part 1 is to provide an overview of how the various parts of the project work together today, and to then give ideas for future directions. The text is a first attempt to provide this kind of synthesis, and in return does not go into extensive technical depth on any particular topic. Part 2 then gives selected technical details based on eight publications covering many of the core components. This is a harsh selection; on the GNUnet website there are more than 50 published research papers and theses related to GNUnet, providing extensive and in-depth documentation. Finally, Part 3 gives an overview of current plans and future work. 3 Acknowledgements Anne-Marie Kermarrec, Tanja Lange, George Danezis, Joe Cannataci and Sad- dek Bensalem have accepted to participate on the jury for my habilitation. I feel very lucky and honored, and thank them for that. I especially thank Tanja Lange for detailed and constructive comments. I am grateful to and for the GNU project, in particular Richard Stallman and Werner Koch, for their long-standing and loud support for me and my projects. I thank all of the Free Software developers, in particular the hundreds of people that have contributed directly to GNUnet over the years. All parts of this document stem from some type of collaboration and the text is based on the respective papers written with various co-authors, in particu- lar my PhD students Nathan Evans, Matthias Wachs, Sree Harsha Totakura, Bartlomiej Polot, Alvaro Garcia-Recuero and Florian Dold. I thank Hern^ani Marques for proofreading the entire document. I also specifically want to thank developers from other projects sharing our goals and values, in particular I2P and Tor. Our discussions with them have been frequently insightful and I hope we will continue to productively work together in the future. Finally, the GNUnet project would not be where it is today without the support by NLnet, the DFG (ENP GR 3688/1-1) and the Renewable Freedom Foundation. 4 To Torsten Contents I Overview 9 1 Introduction 11 1.1 The need for private communication . 12 1.1.1 Authenticated encryption . 12 1.1.2 Metadata . 13 1.1.3 The client-server architecture . 13 1.2 Decentralized Peer-to-Peer networks . 14 1.3 Objectives for the GNUnet . 15 2 Architecture 17 2.1 Software architecture . 17 2.1.1 Evolution . 23 2.2 Security architecture . 23 2.2.1 Access control . 23 2.2.2 Secure APIs . 25 2.3 Process architecture . 26 2.3.1 Responsible disclosure . 27 2.3.2 Peer review . 27 2.3.3 Verification . 27 2.3.4 Testing . 28 2.3.5 Deployment . 29 2.3.6 Monitoring . 29 2.4 Network architecture . 30 2.4.1 Overlay or underlay? . 30 2.4.2 Structured or unstructured? . 30 2.4.3 Bootstrapping . 32 3 Key contributions 33 3.1 Transport underlay abstraction . 33 3.1.1 Automatic selection and resource allocation . 33 3.1.2 Autonomous NAT traversal . 34 3.2 Byzantine fault-tolerant routing . 34 3.2.1 Secure network size estimation . 35 3.2.2 R5N: A secure distributed hash table . 36 5 6 CONTENTS 3.2.3 CADET: Confidential ad-hoc decentralized E2E transport 37 3.3 The GNU name system . 38 3.3.1 Revocation . 39 3.3.2 Conversation . 39 3.3.3 Protocol translation . 40 II Contributions in depth 41 4 Transport 43 4.1 Introduction . 43 4.2 Semantics of the Transport Abstraction . 44 4.2.1 Security Considerations . 45 4.3 Example: SMTP Implementation (Historic) . 46 4.3.1 Sending Email . 46 4.3.2 Receiving Email . 47 4.3.3 Security considerations for SMTP . 47 4.4 Related Work . 48 4.5 Autonomous NAT Traversal . 49 4.5.1 Technical Approach . 50 4.5.2 Implementations . 54 4.5.3 Experimental Results . 55 4.5.4 Discussion . 56 4.6 Transport selection problem . 56 4.6.1 Objectives for transport selection . 57 4.6.2 Scope . 58 4.7 Transport selection design . 58 4.7.1 The heuristic solver . 58 4.7.2 The linear optimisation solver . 59 4.7.3 The machine learning solver . 59 4.8 Implementation . 60 4.9 Evaluation . 60 4.9.1 Solver scalability evaluation . 61 4.9.2 Solver quality evaluation . 61 4.10 Discussion . 64 4.11 Conclusion . 65 5 Secure routing 67 5.1 Introduction . 67 5.2 Secure network size estimation . 68 5.2.1 Related Work . 69 5.2.2 Our Approach . 71 5.2.3 Security Analysis . 76 5.2.4 Experimental Results . 78 5.2.5 Discussion . 87 5.3 R5N .................................. 88 CONTENTS 7 5.3.1 Related Work . 89 5.3.2 Restricted-Route Topologies . 90 5.3.3 Design of R5N ........................ 92 5.3.4 Experimental Results . 95 5.3.5 Performance Analysis . 103 5.4 CADET . 103 5.4.1 Connectivity . 103 5.4.2 Security . 105 5.4.3 Multiplexing . 106 5.5 Implementation . 109 5.6 Results . 109 5.6.1 Churn Resistance . 109 5.6.2 Latency . 111 5.6.3 Bandwidth . 113 5.7 Related Work . 113 5.7.1 TCP/IP . 113 5.7.2 Tor . 114 5.7.3 net2o . 115 5.8 Conclusion . 115 6 The GNU Name System 117 6.1 Introduction . 117 6.2 Requirements Analysis . 119 6.2.1 Adversary Model . 119 6.2.2 Functional Requirements . 120 6.3 Design Space for Name Systems . 120 6.3.1 Hierarchical Registration . 122 6.3.2 Cryptographic IDs and Mnemonics . 123 6.3.3 Petnames and SDSI . 123 6.3.4 Timeline-based Name Systems . 124 6.4 Practical Considerations . 124 6.4.1 Interoperability with DNS . 125 6.4.2 End-to-End Security and Errors . 126 6.4.3 Petnames and Legacy Applications . 126 6.4.4 Censorship-Resistant Lookup . 126 6.4.5 Case study: Usability . 127 6.5 Design of the GNU Name System . 128 6.5.1 Names, Zones and Delegations . 128 6.5.2 Zone Management with Nicknames and Petnames . 129 6.5.3 Relative Names for Transitivity of Delegations . 130 6.5.4 Absolute Names . 130 6.5.5 Records in GNS . 131 6.6 Query Privacy . 132 6.7 Security of GNS . 133 6.8 Special Features . 134 6.8.1 Automatic Shortening . 134 8 CONTENTS 6.8.2 Relative Names in Record Values . 135 6.8.3 Dealing with Legacy Assumptions: Virtual Hosting and TLS . 135 6.8.4 Handling TLSA and SRV records . 136 6.8.5 Revocation . 137 6.8.6 Shadow Records . 138 6.8.7 Availability and Caching . 138 6.8.8 Intercepting DNS queries . 139 6.8.9 A HTTP SOCKS Proxy for Legacy Browsers . 140 6.9 Applications.
Load more

Recommended publications
  • Libressl Presentatie2
    Birth of LibreSSL and its current status Frank Timmers Consutant, Snow B.V. Background What is LibreSSL • A fork of OpenSSL 1.0.1g • Being worked on extensively by a number of OpenBSD developers What is OpenSSL • OpenSSL is an open source SSL/TLS crypto library • Currently the de facto standard for many servers and clients • Used for securing http, smtp, imap and many others Alternatives • Netscape Security Services (NSS) • BoringSSL • GnuTLS What is Heartbleed • Heartbleed was a bug leaking of private data (keys) from both client and server • At this moment known as “the worst bug ever” • Heartbeat code for DTLS over UDP • So why was this also included in the TCP code? • Not the reason to create a fork Why did this happen • Nobody looked • Or at least didn’t admit they looked Why did nobody look • The code is horrible • Those who did look, quickly looked away and hoped upstream could deal with it Why was the code so horrible • Buggy re-implementations of standard libc functions like random() and malloc() • Forces all platforms to use these buggy implementations • Nested #ifdef, #ifndefs (up to 17 layers deep) through out the code • Written in “OpenSSL C”, basically their own dialect • Everything on by default Why was it so horrible? crypto_malloc • Never frees memory (Tools like Valgrind, Coverity can’t spot bugs) • Used LIFO recycling (Use after free?) • Included debug malloc by default, logging private data • Included the ability to replace malloc/free at runtime #ifdef trees • #ifdef, #elif, #else trees up to 17 layers deep • Throughout the complete source • Some of which could never be reached • Hard to see what is or not compiled in 1.
    [Show full text]
  • Red Hat Enterprise Linux 6 Developer Guide
    Red Hat Enterprise Linux 6 Developer Guide An introduction to application development tools in Red Hat Enterprise Linux 6 Dave Brolley William Cohen Roland Grunberg Aldy Hernandez Karsten Hopp Jakub Jelinek Developer Guide Jeff Johnston Benjamin Kosnik Aleksander Kurtakov Chris Moller Phil Muldoon Andrew Overholt Charley Wang Kent Sebastian Red Hat Enterprise Linux 6 Developer Guide An introduction to application development tools in Red Hat Enterprise Linux 6 Edition 0 Author Dave Brolley [email protected] Author William Cohen [email protected] Author Roland Grunberg [email protected] Author Aldy Hernandez [email protected] Author Karsten Hopp [email protected] Author Jakub Jelinek [email protected] Author Jeff Johnston [email protected] Author Benjamin Kosnik [email protected] Author Aleksander Kurtakov [email protected] Author Chris Moller [email protected] Author Phil Muldoon [email protected] Author Andrew Overholt [email protected] Author Charley Wang [email protected] Author Kent Sebastian [email protected] Editor Don Domingo [email protected] Editor Jacquelynn East [email protected] Copyright © 2010 Red Hat, Inc. and others. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
    [Show full text]
  • N2N: a Layer Two Peer-To-Peer VPN
    N2N: A Layer Two Peer-to-Peer VPN Luca Deri1, Richard Andrews2 ntop.org, Pisa, Italy1 Symstream Technologies, Melbourne, Australia2 {deri, andrews}@ntop.org Abstract. The Internet was originally designed as a flat data network delivering a multitude of protocols and services between equal peers. Currently, after an explosive growth fostered by enormous and heterogeneous economic interests, it has become a constrained network severely enforcing client-server communication where addressing plans, packet routing, security policies and users’ reachability are almost entirely managed and limited by access providers. From the user’s perspective, the Internet is not an open transport system, but rather a telephony-like communication medium for content consumption. This paper describes the design and implementation of a new type of peer-to- peer virtual private network that can allow users to overcome some of these limitations. N2N users can create and manage their own secure and geographically distributed overlay network without the need for central administration, typical of most virtual private network systems. Keywords: Virtual private network, peer-to-peer, network overlay. 1. Motivation and Scope of Work Irony pervades many pages of history, and computing history is no exception. Once personal computing had won the market battle against mainframe-based computing, the commercial evolution of the Internet in the nineties stepped the computing world back to a substantially rigid client-server scheme. While it is true that the today’s Internet serves as a good transport system for supplying a plethora of data interchange services, virtually all of them are delivered by a client-server model, whether they are centralised or distributed, pay-per-use or virtually free [1].
    [Show full text]
  • GNU Build System
    Maemo Diablo Reference Manual for maemo 4.1 GNU Build System December 22, 2008 Contents 1 GNU Build System 2 1.1 Introduction .............................. 2 1.2 GNU Make and Makefiles ...................... 2 1.2.1 Simplest Real Example .................... 3 1.2.2 Anatomy of Makefile ..................... 6 1.2.3 Default Goal .......................... 7 1.2.4 On Names of Makefiles ................... 7 1.2.5 Questions ........................... 8 1.2.6 Adding Make Goals ..................... 8 1.2.7 Making One Target at a Time ................ 9 1.2.8 PHONY Keyword ...................... 9 1.2.9 Specifying Default Goal ................... 10 1.2.10 Other Common Phony Goals ................ 11 1.2.11 Variables in Makefiles .................... 11 1.2.12 Variable Flavors ........................ 11 1.2.13 Recursive Variables ...................... 12 1.2.14 Simple Variables ....................... 13 1.2.15 Automatic Variables ..................... 14 1.2.16 Integrating with Pkg-Config ................ 15 1.3 GNU Autotools ............................ 16 1.3.1 Brief History of Managing Portability ........... 17 1.3.2 GNU Autoconf ........................ 18 1.3.3 Substitutions ......................... 22 1.3.4 Introducing Automake .................... 24 1.3.5 Checking for Distribution Sanity .............. 29 1.3.6 Cleaning up .......................... 29 1.3.7 Integration with Pkg-Config ................ 30 1 Chapter 1 GNU Build System 1.1 Introduction The following code examples are used in this chapter: simple-make-files • autoconf-automake • 1.2 GNU Make and Makefiles The make program from the GNU project is a powerful tool to aid implementing automation in the software building process. Beside this, it can be used to automate any task that uses files and in which these files are transformed into some other form.
    [Show full text]
  • A Generic Data Exchange System for F2F Networks
    The Retroshare project The GXS system Decentralize your app! A Generic Data Exchange System for F2F Networks Cyril Soler C.Soler The GXS System 03 Feb. 2018 1 / 19 The Retroshare project The GXS system Decentralize your app! Outline I Overview of Retroshare I The GXS system I Decentralize your app! C.Soler The GXS System 03 Feb. 2018 2 / 19 The Retroshare project The GXS system Decentralize your app! The Retroshare Project I Mesh computers using signed TLS over TCP/UDP/Tor/I2P; I anonymous end-to-end encrypted FT with swarming; I mail, IRC chat, forums, channels; I available on Mac OS, Linux, Windows, (+ Android). C.Soler The GXS System 03 Feb. 2018 3 / 19 The Retroshare project The GXS system Decentralize your app! The Retroshare Project I Mesh computers using signed TLS over TCP/UDP/Tor/I2P; I anonymous end-to-end encrypted FT with swarming; I mail, IRC chat, forums, channels; I available on Mac OS, Linux, Windows. C.Soler The GXS System 03 Feb. 2018 3 / 19 The Retroshare project The GXS system Decentralize your app! The Retroshare Project I Mesh computers using signed TLS over TCP/UDP/Tor/I2P; I anonymous end-to-end encrypted FT with swarming; I mail, IRC chat, forums, channels; I available on Mac OS, Linux, Windows. C.Soler The GXS System 03 Feb. 2018 3 / 19 The Retroshare project The GXS system Decentralize your app! The Retroshare Project I Mesh computers using signed TLS over TCP/UDP/Tor/I2P; I anonymous end-to-end encrypted FT with swarming; I mail, IRC chat, forums, channels; I available on Mac OS, Linux, Windows.
    [Show full text]
  • NAT Traversal About
    NAT Traversal About Some difficulties have been encountered with devices that have poor NAT support. FreeSWITCH goes to great lengths to repair broken NAT support in phones and gateway devices. In order to aid FreeSWITCH in traversing NAT please see the External profile page. Some routers offer an Application Layer Gateway feature which can prevent FreeSWITCH NAT traversal from working. See the ALG page for more information, including how to disable it. Using STUN to aid in NAT Traversal STUN is a method to allow an end host (i.e. phone) to discover its public IP address if it is located behind a NAT . Using this method requires a STUN server on the public internet and a client on the phone. The phone's STUN client queries the STUN server for it's own public IP and transmits the information it has received in it's connection information in the SIP packets it sends to the SIP server. Enable and configure STUN settings on your phone in order correctly to report your phone's contact information to FreeSWITCH when registering. Unfortunately, not all phones have a properly working STUN client. STUN servers This site contains a list of public STUN servers: https://gist.github.com/zziuni/3741933 stun.freeswitch.org is never guaranteed to be up and running so use it in production at your own risk. There are several open source projects to run your own STUN server, e.g. STUNTMAN Using FreeSWITCH built-in methods to aid in NAT Traversal nat-options-ping This parameter causes FreeSWITCH to regularly (every 20 - 40s) send an OPTIONS packet to NATed registered endpoints in order to keep the port on the clients firewall open.
    [Show full text]
  • The Edonkey File-Sharing Network
    The eDonkey File-Sharing Network Oliver Heckmann, Axel Bock, Andreas Mauthe, Ralf Steinmetz Multimedia Kommunikation (KOM) Technische Universitat¨ Darmstadt Merckstr. 25, 64293 Darmstadt (heckmann, bock, mauthe, steinmetz)@kom.tu-darmstadt.de Abstract: The eDonkey 2000 file-sharing network is one of the most successful peer- to-peer file-sharing applications, especially in Germany. The network itself is a hybrid peer-to-peer network with client applications running on the end-system that are con- nected to a distributed network of dedicated servers. In this paper we describe the eDonkey protocol and measurement results on network/transport layer and application layer that were made with the client software and with an open-source eDonkey server we extended for these measurements. 1 Motivation and Introduction Most of the traffic in the network of access and backbone Internet service providers (ISPs) is generated by peer-to-peer (P2P) file-sharing applications [San03]. These applications are typically bandwidth greedy and generate more long-lived TCP flows than the WWW traffic that was dominating the Internet traffic before the P2P applications. To understand the influence of these applications and the characteristics of the traffic they produce and their impact on network design, capacity expansion, traffic engineering and shaping, it is important to empirically analyse the dominant file-sharing applications. The eDonkey file-sharing protocol is one of these file-sharing protocols. It is imple- mented by the original eDonkey2000 client [eDonkey] and additionally by some open- source clients like mldonkey [mlDonkey] and eMule [eMule]. According to [San03] it is with 52% of the generated file-sharing traffic the most successful P2P file-sharing net- work in Germany, even more successful than the FastTrack protocol used by the P2P client KaZaa [KaZaa] that comes to 44% of the traffic.
    [Show full text]
  • IPFS and Friends: a Qualitative Comparison of Next Generation Peer-To-Peer Data Networks Erik Daniel and Florian Tschorsch
    1 IPFS and Friends: A Qualitative Comparison of Next Generation Peer-to-Peer Data Networks Erik Daniel and Florian Tschorsch Abstract—Decentralized, distributed storage offers a way to types of files [1]. Napster and Gnutella marked the beginning reduce the impact of data silos as often fostered by centralized and were followed by many other P2P networks focusing on cloud storage. While the intentions of this trend are not new, the specialized application areas or novel network structures. For topic gained traction due to technological advancements, most notably blockchain networks. As a consequence, we observe that example, Freenet [2] realizes anonymous storage and retrieval. a new generation of peer-to-peer data networks emerges. In this Chord [3], CAN [4], and Pastry [5] provide protocols to survey paper, we therefore provide a technical overview of the maintain a structured overlay network topology. In particular, next generation data networks. We use select data networks to BitTorrent [6] received a lot of attention from both users and introduce general concepts and to emphasize new developments. the research community. BitTorrent introduced an incentive Specifically, we provide a deeper outline of the Interplanetary File System and a general overview of Swarm, the Hypercore Pro- mechanism to achieve Pareto efficiency, trying to improve tocol, SAFE, Storj, and Arweave. We identify common building network utilization achieving a higher level of robustness. We blocks and provide a qualitative comparison. From the overview, consider networks such as Napster, Gnutella, Freenet, BitTor- we derive future challenges and research goals concerning data rent, and many more as first generation P2P data networks, networks.
    [Show full text]
  • Privacy Enhancing Technologies 2003 an Analysis of Gnunet And
    Privacy Enhancing Technologies 2003 An Analysis of GNUnet and the Implications for Anonymous, Censorship-Resistant Networks Dennis Kügler Federal Office for Information Security, Germany [email protected] 1 Anonymous, Censorship-Resistant Networks • Anonymous Peer-to-Peer Networks – Gnutella • Searching is relatively anonymous • Downloading is not anonymous • Censorship-Resistant Networks – Eternity Service • Distributed storage medium • Attack resistant • Anonymous, Censorship-Resistant Networks – Freenet – GNUnet 2 GNUnet: Obfuscated, Distributed Filesystem Content Hash Key: [H(B),H(E (B))] • H(B) – Content encryption: H(B) – Unambiguous filename: H(E (B)) H(B) • Content replication – Caching while delivering – Based on unambiguous filename • Searchability – Keywords 3 GNUnet: Peer-to-Peer MIX Network • Initiating node – Downloads content • Supplying nodes – Store content unencrypted • Intermediary nodes – Forward and cache encrypted content – Plausible deniability due to encryption • Economic model – Based on credit Query A Priority=20 B – Charge for queries c =c -20 B B - – Pay for responses 4 GNUnet Encoding • DBlocks DBlock DBlock ... DBlock – 1KB of the content – Content hash encrypted • IBlocks IBlock ... IBlock – CHKs of 25 DBlocks – Organized as tree – Content hash encrypted IBlock • RBlock – Description of the content – CHK of the root IBlock RBlock – Keyword encrypted 5 The Attacker Model • Attacker – Controls malicious nodes that behave correctly – Prepares dictionary of interesting keywords – Observes queries and
    [Show full text]
  • A Transport Layer Abstraction for Peer-To-Peer Networks Ronaldo A
    A Transport Layer Abstraction for Peer-to-Peer Networks Ronaldo A. Ferreira, Christian Grothoff and Paul Ruth Department of Computer Sciences Purdue University g frf,grothoff,ruth @cs.purdue.edu http://www.gnu.org/software/GNUnet/ B Abstract— The initially unrestricted host-to-host communica- same peer-to-peer network. In fact, two peers A and may tion model provided by the Internet Protocol has deteriorated want to use differentmodes of communicationon the same link. due to political and technical changes caused by Internet growth. For example, suppose node B is behind a NAT box and cannot While this is not a problem for most client-server applications, peer-to-peer networks frequently struggle with peers that are be reached directly via UDP or TCP. In a system with multiple only partially reachable. We describe how a peer-to-peer frame- transport protocols, A could initiate a connection by sending an B A work can hide diversity and obstacles in the underlying Internet e-mail to B (SMTP) and then have contact via TCP, al- and provide peer-to-peer applications with abstractions that hide lowing A to continue further communication on a bidirectional transport specific details. We present the details of an implemen- TCP connection. tation of a transport service based on SMTP. Small-scale bench- marks are used to compare transport services over UDP, TCP, and We will use GNUnet as our reference peer-to-peer system, SMTP. but it should be clear that the idea of a transport abstraction can be applied to other systems. GNUnet is a peer-to-peer frame- work whose main focus is on security [1], [5].
    [Show full text]
  • The Copyright Alert System: a Potential Unfair Burden on Small Business Owners, 23 J
    Journal of Law and Policy Volume 23 | Issue 1 Article 8 2014 The opC yright Alert System: A Potential Unfair Burden On Small Business Owners Rachel Schneidman Follow this and additional works at: https://brooklynworks.brooklaw.edu/jlp Recommended Citation Rachel Schneidman, The Copyright Alert System: A Potential Unfair Burden On Small Business Owners, 23 J. L. & Pol'y (2014). Available at: https://brooklynworks.brooklaw.edu/jlp/vol23/iss1/8 This Note is brought to you for free and open access by the Law Journals at BrooklynWorks. It has been accepted for inclusion in Journal of Law and Policy by an authorized editor of BrooklynWorks. THE COPYRIGHT ALERT SYSTEM: A POTENTIAL UNFAIR BURDEN ON SMALL BUSINESS OWNERS Rachel A. Schneidman* The Copyright Alert System (CAS) confers on Internet Service Pro- vider’s (ISPs) the power to use “mitigating measures” against alleged copyright infringers in order to discourage piracy. This power is a result of a voluntary agreement between the ISPs, the Motion Picture Associa- tion of America, and the Recording Industry Association of America. Alt- hough the effectiveness of the CAS and the privacy concerns it raises have been analyzed in academic literature, the possible encumbrance of the CAS on small business owners has not been sufficiently considered. This Note argues that while the CAS may be a valuable tool in im- peding online piracy, it has the potential to unfairly burden small busi- ness owners. Specifically, this Note asserts that the CAS’s scope should be expanded to include all broadband users, including residential and business users of every size.
    [Show full text]
  • T U M a Digital Wallet Implementation for Anonymous Cash
    Technische Universität München Department of Informatics Bachelor’s Thesis in Information Systems A Digital Wallet Implementation for Anonymous Cash Oliver R. Broome Technische Universität München Department of Informatics Bachelor’s Thesis in Information Systems A Digital Wallet Implementation for Anonymous Cash Implementierung eines digitalen Wallets for anonyme Währungen Author Oliver R. Broome Supervisor Prof. Dr.-Ing. Georg Carle Advisor Sree Harsha Totakura, M. Sc. Date October 15, 2015 Informatik VIII Chair for Network Architectures and Services I conrm that this thesis is my own work and I have documented all sources and material used. Garching b. München, October 15, 2015 Signature Abstract GNU Taler is a novel approach to digital payments with which payments are performed with cryptographically generated representations of actual currencies. The main goal of GNU Taler is to allow taxable anonymous payments to non-anonymous merchants. This thesis documents the implementation of the Android version of the GNU Taler wallet, which allows users to create new Taler-based funds and perform payments with them. Zusammenfassung GNU Taler ist ein neuartiger Ansatz für digitales Bezahlen, bei dem Zahlungen mit kryptographischen Repräsentationen von echten Währungen getätigt werden. Das Hauptziel von GNU Taler ist es, versteuerbare, anonyme Zahlungen an nicht-anonyme Händler zu ermöglichen. Diese Arbeit dokumentiert die Implementation der Android-Version des Taler-Portemonnaies, der es Benutzern erlaubt, neues Taler-Guthaben zu erzeugen und mit ihnen Zahlungen zu tätigen. I Contents 1 Introduction 1 1.1 GNU Taler . .2 1.2 Goals of the thesis . .2 1.3 Outline . .3 2 Implementation prerequisites 5 2.1 Native libraries . .5 2.1.1 Libgcrypt .
    [Show full text]