48
Bachelor thesis Improving Voice over GNUnet Fakult¨at IV - Elektrotechnik und Informatik Internet Network Architectures (INET) Research Group of Prof. Anja Feldmann, Ph.D. Christian Ulrich July 6, 2017 Pr¨ uferin: Prof. Anja Feldmann, Ph.D. Betreuer/innen: Theresa Enghardt, M.Sc. und Christian Grothoff, Ph.D.

Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

Bachelor thesis

Improving Voice over GNUnet

Fakultat IV - Elektrotechnik und InformatikInternet Network Architectures (INET)

Research Group of Prof. Anja Feldmann, Ph.D.

Christian UlrichJuly 6, 2017

Pruferin: Prof. Anja Feldmann, Ph.D.Betreuer/innen: Theresa Enghardt, M.Sc. und Christian Grothoff,

Ph.D.

Page 2: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist
Page 3: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

Die selbstandige und eigenhandige Anfertigung versichere ich an EidesStatt.

Berlin, den July 6, 2017 Christian Ulrich

Page 4: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist
Page 5: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

Zusammenfassung

Im Gegensatz zu den allgegenwartigen Cloud-basierten Losungen bietet die Telefonie-Applikation GNUnet conversation vollstandig dezentrale, sichere Sprachkommunikationund erschwert damit Massenuberwachung. Das Ziel dieser Arbeit ist es zu erforschen,warum GNUnet conversation unter typischen Internet-Bedingungen momentan mangel-hafte Quality of Experience aufweist.

Nachdem Netzwerk-Shaping und die Initialisierung zweier isolierter GNUnet-Peersautomatisiert worden waren, wurden Latenzmessungen durchgefuhrt. Mit emuliertenNetzwerk-Charakteristiken wurden Netzwerk- Kryptographie- und Audio-Codec-Latenzengemessen und die ubertragene Sprache aufgezeichnet.

Die Analyse der Messergebnisse und eine subjektive Beurteilung von Sprachaufnahmenmachten deutlich, dass in den meisten Szenarien extreme Ausreißer auftreten und dieQoE beeintrachtigen. Außerdem wurde nachgewiesen, dass GNUnet conversation großeLatenzen verursacht, die den Rahmen in dem gute QoE moglich ist einschranken. Inder Messumgebung traten immer mindestens 23 ms Latenz auf, von der ein großer Teildurch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung desVerschlusselungs-Moduls und anderer Komponenten moglich ist. Schließlich wurden dieVoraussetzungen, um gegenwartig gute QoE zu erreichen, bestimmt und Ideen fur weitereNachforschungen prasentiert.

Page 6: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist
Page 7: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

Abstract

In contrast to ubiquitous cloud-based solutions the telephony application GNUnet conver-sation provides fully-decentralized, secure voice communication and thus impedes masssurveillance. The aim of this thesis is to investigate why GNUnet conversation currentlyprovides poor Quality of Experience under typical wide area network conditions and topropose optimization measures.

After network shaping and the initialization of two isolated GNUnet peers had beenautomated, delay measurements were done. With emulated network characteristics net-work delay, cryptography delays and audio codec delays were measured and transmittedspeech was recorded.

An analysis of the measurement results and a subjective assessment of the speechrecordings revealed that extreme outliers occur in most scenarios and impair QoE. More-over it was shown that GNUnet conversation introduces a large delay that confines theenvironment in which good QoE is possible. In the measurement environment at least 23ms always ocurred of which large parts are were caused by cryptography. It was shownthat optimization in the cryptography part and other components are possible. Finallythe conditions for currently reaching good QoE were determined and ideas for furtherinvestigations were presented.

Page 8: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist
Page 9: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

Contents

1 Introduction 3

2 QoE-related metrics 4

2.1 QoS metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Objective QoE assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Subjective QoE Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 GNUnet Basics 5

3.1 Peers and identities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 GNUnet Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.3 The TRANSPORT service module . . . . . . . . . . . . . . . . . . . . . . . 5

3.4 The CORE service module . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.4.1 OTR cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.5 The CADET service module . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.5.1 CADET: routing, transport, security . . . . . . . . . . . . . . . . . . 6

3.5.2 Double ratchet cryptography . . . . . . . . . . . . . . . . . . . . . . 7

3.6 The CONVERSATION service module . . . . . . . . . . . . . . . . . . . . . 8

3.6.1 Audio encoding/decoding . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Methodology 9

4.1 The virtual machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.2 Measurement automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.3 Network shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.3.1 Delay and delay variation . . . . . . . . . . . . . . . . . . . . . . . . 11

4.3.2 Packet loss and low bandwidth . . . . . . . . . . . . . . . . . . . . . 11

4.4 Establishing the topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.5 Audio setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.6 Verifying the setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Measurement tools 14

5.1 GNUnet command line tools . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.1.1 gnunet-conversation . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.1.2 CONVERSATION service and audio helpers . . . . . . . . . . . . . 15

5.1.3 gnunet-cadet, gnunet-core and gnunet-transport . . . . . . . . . . . 16

5.1.4 CADET service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.1.5 CORE service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.2 Separating cryptography delays from the measured RTTs . . . . . . . . . . 18

5.3 Packet sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6 Measurements 19

6.1 Latency by Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.1.1 Determining the encryption and decryption delay . . . . . . . . . . . 20

6.1.2 No network shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.1.3 A closer look at CADET’s delay . . . . . . . . . . . . . . . . . . . . 23

6.1.4 Emulate delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.1.5 Emulate packet delay variation . . . . . . . . . . . . . . . . . . . . . 25

6.1.6 Emulate packet loss . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.1.7 Emulate low bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.2 CONVERSATION ping measurements vs. call delay . . . . . . . . . . . . . 29

Page 10: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

6.3 Evaluation of the recorded calls . . . . . . . . . . . . . . . . . . . . . . . . . 30

7 GNUnet optimization 32

8 Conclusion 33

A GNUnet configuration used for measurements 36

B Usage of the measurement scripts 37

C Output files 37

D GNUnet command-line tools 38

Page 11: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

1 Introduction

In times of global bulk surveillance1 voice communication is one of many surveillance tar-gets[18]. This endangers the right to privacy[1] of individuals all over the world. Evenpoliticians are not safe from surveillance of their confidential communication[16][21]. En-crypted voice communication can help protecting individual privacy and professional confi-dentiality. Unfortunately most of the existing encrypted Voice over IP (VoIP) applicationsemploy a centralized infrastructure. This still allows bulk surveillance of metadata which,compared with the communication contents, in many cases seems to be equally or moresuitable for gaining personal information[24]. In fully decentralized systems metadata donot accumulate in a central database and are not controlled by organizations. Thus masssurveillance is effectively impeded.

Skype has shown that voice communication over p2p networks is feasible and can pro-vide good Quality of Experience (QoE). It never employed a fully distributed archi-tecture though[2] and recently moved into the cloud[6]. GNUnet[10] is a p2p frameworkwhich provides a secure internet stack for distributed applications. GNUnet’s protocolstack works as an overlay on top of traditional transport protocols. In contrast to ubiq-uitous cloud-based solutions GNUnet provides fully decentralized services such as a de-centralized public-key infrastructure[23], a decentralized routing protocol and end-to-endencryption by default[22].

GNUnet conversation is an application that provides secure voice communicationin a fully decentralized way by employing GNUnet for routing and transport, hence it is aVoice over GNUnet application. Making calls is already possible but the voice quality cur-rently tends to be poor in wide-area networks. This bachelor thesis identifies the conditionsunder which bad QoE occurs and examines possible causes. In a measurement environ-ment of two virtual machines calls between two peers were made under different emulatednetwork conditions and the resulting audio recordings were evaluated. Delay measure-ments were done. This allowed determining what shares different GNUnet componentshave in the overall delay and pointing out opportunities for optimization. Furthermore aminimum bandwidth of 200 Kbit/s was found to be required for good QoE.

The delay measurements were restricted to ongoing delays, that is delays that occurduring a call. Another type of delay, namely connection establishment delays, that is thetime difference from the initiation of a call and the beginning of audio transmission, is leftfor future work.

Existing GNUnet services and command-line tools were modified and capabilitiesfor measuring different delays were implemented. Fully automated measurements wereachieved with an architecture comprising a measurement controller and multiple mea-surement workers. This includes initializing the GNUnet peers running on the mea-surement workers and network shaping.

Chapter 2 gives an introduction to QoE-related metrics and presents related work.GNUnet’s architecture and basics of different GNUnet components relevant for the mea-surements are described in Chapter 3. While Chapter 4 explains the measurement environ-ment including the automated network shaping and topology establishment, and the audiosetup, Chapter 5 describes the tools used for the measurements. A detailed description ofthe experiments and an evaluation of the measurement results can be found in Chapter6. Finally Chapter 7 describes recommendation for optimizing Voice over GNUnet andChapter 8 summarizes the findings and presents a conclusion.

1for an overview of revelations of surveillance programs since 2013 see http://projects.propublica.

org/nsa-grid/

3

Page 12: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

2 QoE-related metrics

This chapter gives an overview on how QoE can be assessed and associates the methodologyof this thesis with the described methods (Sections 2.2 and 2.3). As QoE cannot bemeasured directly, Quality of Service (QoS) metrics have to be used for the assessment.Section 2.1 gives an introduction to those metrics.

2.1 QoS metrics

Examples of QoS metrics are delay, packet delay variation (PDV), bandwidth andpacket loss. This thesis focuses on delay.

As explained in the Chapter 1 the delays examined are ongoing delays after the connec-tion is established (i.e. a call is active). These delays can have the components propagationdelay, processing delay and queueing delay (see e.g. [7]). Propagation delay is caused bythe limited speed a signal can propagate through fibers or wires. Processing delay maybe caused by ”actual packetization, compression, and packet switching”[7]. For GNUnetconversation processing delays are also caused by encryption and decryption as explainedin Section 3. Queueing delay is often caused by congestion. Generally all incoming or out-going queues, which are used for several reasons (e.g. for jitter compensation as explainedin [13]) cause queueing delay.

2.2 Objective QoE assessment

QoE in voice applications can be assessed in different ways. As elaborated in [19], objectivequality assessment is possible by analyzing properties of the audio signal such as the peak-signal-to-noise-ratio or by using standardized assessment models like the E-model [3] whichcalculates a quality rating based on measured QoS metrics such as packet loss rate, anddelay.

Extensive objective quality assessment as defined in [19] was not done in the scope ofthis thesis. Instead the QoS metric delay was assessed under different emulated networkshaping scenarios (described in Chapter 6). One requirement for satisfying QoE is asufficiently low mouth-to-ear delay, that is the time difference between the recording at thesender’s microphone and the playback at the receiver’s speaker. ITU-T RecommendationG.114 states that for mouth-to-ear delays of less than 150 ms “most applications [...] willexperience essentially transparent interactivity”[13].

2.3 Subjective QoE Assessment

As explained in [19] subjective assessment requires user ratings of speech samples, eitherabsolute or in comparison to a reference speech recording. An example for absolute userratings is the Mean Opinion Score (MOS). Users are asked to rate a stimuli on the MOSscale, that is from 1 (bad quality) to 5 (excellent quality)[14]. For a reliable assessment”a balanced set of sufficient number of subjects that represent different level of expertise,age groups and gender.”[19] are required.

User studies with multiple subjects were not done in the scope of this thesis. Insteadrecordings of speech transmitted over GNUnet conversation under different network con-ditions were examined for specific anomalies such as silence periods or similar artifacts.This can give hints about the conditions under which good QoE can be achieved.

4

Page 13: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

3 GNUnet Basics

This chapter provides an overview on the general modular architecture of GNUnet andgives an introduction about the GNUnet modules relevant for the measurements describedin Section 6.

3.1 Peers and identities

GNUnet peers are addressed using peer IDs which are EdDSA[4] public keys which arealso used for encryption and authentication. They are base32-encoded and 52 Bytes inlength. In additions applications can use identities which are defined by an ECDSA[15]key pair. These are needed for signing messages or records of the GNU name system(GNS) which is GNUnet’s replacement for DNS.

3.2 GNUnet Architecture overview

The GNUnet modules relevant for this thesis are TRANSPORT, which makes use ofthe Automatic Transport Selection (ATS) module, CORE, Confidential Ad-HocDecentralized End-to-End Transport (CADET) and CONVERSATION whichmakes use the GNU Name System (GNS). Each module provides a service API2 toapplications or other modules. This allows building a stacked architecture: Modules canuse the APIs to “build higher GNUnet layers on top of lower ones”[11]. Figure 1 showsthe service stack used by GNUnet conversation. The modules TRANSPORT, CORE,CADET and CONVERSATION are described in more detail in the following sections.

CONVERSATION

CADET

CORE

ATS

CORE API

CADET API

GNSGNS API

TRANSPORT ATS API

TRANSPORT API

applicationCONVERSATION API

Figure 1: service modules relevant for GNUnet conversation: The application uses onlythe CONVERSATION API which abstracts from the lower layer modules

GNUnet modules are are composed of a service which runs in a separate executableand a client library implementing the service API. The inter-process communication usedbetween service and client part is expected to cause a small amount of delay.

3.3 The TRANSPORT service module

TRANSPORT is the lowest GNUnet layer and is able to use several protocols as an under-lying transport mechanism. While in this bachelor thesis the focus is on TCP and UDP,TRANSPORT may also send packets directly over WLAN or even use HTTP as trans-port protocol. The TRANSPORT service provides a plugin API to add new underlyingtransport mechanisms. TRANSPORT’s functionality includes choosing the best-suitedtransport mechanism, receiving and validating information about other peers from the

2All GNUnet APIs are documented in https://gnunet.org/doxygen/modules.html

5

Page 14: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

network (so-called HELLO messages, which contain the IP addresses of a peer) and es-tablishing connections to known peers. Clients using the TRANSPORT API (the COREservice is usually the only client) are notified about newly established or lost connections.

The TRANSPORT service delegates the decision which transport mechanism to useto a GNUnet module called Automatic Transport Selection (ATS). It informs ATS aboutavailable addresses and ATS determines the best-suited transport mechanism by collectingperformance characteristics, e.g. by measuring throughput and delay. This means thatATS may decide to switch to another mechanism whenever it detects performance changes.For measurements this is not wanted and thus this behaviour has to be disabled in theTRANSPORT configuration.

3.4 The CORE service module

The CORE service uses the TRANSPORT service trough the TRANSPORT API and addssecurity properties (e.g. authentication and confidentiality) to the insecure communicationprovided by TRANSPORT. The cryptographic functions used are based on those used byOff-the-Record messaging (OTR)3.

3.4.1 OTR cryptography

OTR was designed to be used on top of messaging protocols like XMPP and providesauthentication and confidentiality with forward-secrecy. GNUnet uses it already on theCORE layer which is analog to the link layer in the OSI model.

By default the TRANSPORT service establishes communication channels to all peers itknows and provides message queues to the CORE service. The CORE service is then ableto performs elliptic curve Diffie-Hellman key exchange (ECDHE) using the Curve25519curve. Once the session key is exchanged, CORE uses that key to encrypt all outgoingpackets with both 256bit AES and TWOFISH.

OTR provides forward-security by periodic re-keyings, that is performing ECDHE aftera defined amount of time. GNUnet CORE performs these re-keyings after 12 hours.

3.5 The CADET service module

While the CORE service provides secure link-layer communication between two peers theCADET service provides end-to-end encrypted communication using the double ratchetalgorithm described in Section 3.5.2. An introduction to CADET and its terminology isgiven in Section 3.5.1.

3.5.1 CADET: routing, transport, security

CADET finds routes to an other peer using the set of known peers stored in the PEER

STORE and DHT lookups. The DHT used by GNUnet is R5N [9]. Figure 2 shows a CADETtunnel which provides end-to-end encrypted authenticated communication between twopeers. A tunnel can be used by different applications, each opening a channel to the targetapplication on the peer at the tunnel end-point. Like TCP and UDP flows, channels areidentified by a port. If multiple connections (which are established by the TRANSPORTlayer) exist, data sent through the tunnel is multiplexed over multiple routes so thatcompromised or malicious peers along a route don’t see all packets.

3https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html

6

Page 15: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

Figure 2: CADET architecture, source: [22]

3.5.2 Double ratchet cryptography

The double ratchet algorithm [17] (previously known as the Axolotl ratchet) is a cryp-tographic protocol designed to provide end-to-end encryption to asynchronous messagingapplications. Among other properties it provides forward security without the need offrequent re-keying (hence it is suitable for asynchronous communication) and break-inrecovery.

Forward security is provided by making sure every message is encrypted with a uniquemessage key that can be deleted after encryption or decryption. The message keys arethe output of one of two ratchets (the term ratchet describes the process of deriving keysfor encrypting and decrypting in parallel using a key derivation function (KDF)). Thisratchet is called the symmetric key ratchet. An attacker who learns a secret key used inthe KDF at some point cannot decrypt previously intercepted messages, thus the algorithmis forward-secure.

Break-in recovery is provided by combining the symmetric ratchet with a secondratchet, called the Diffie-Hellman ratchet. The key pair used in the symmetric ratchetis replaced regularly with the output of a Diffie-Hellman key exchange. An attacker wholearns a key used in the KDF and uses same symmetric ratchet as sender and receiver canonly decrypt intercepted messages until the next re-keying (Diffie-Hellman ratchet step).

The symmetric ratchet uses a HMAC-based KDF4 for key derivation and CADET usesthe resulting message keys are used for encrypting each outgoing message with both 256bit AES and 256 bit TWOFISH, both in the Cypher feedback (CFB) mode of operation(defined in [8]). For both AES and TWOFISH the same cryptographic operations areused for both encryption and decrypting and thus in theory both cause the same delay.As the decryption for the CFB mode of operation is parallelizable but encryption is not(see [5]), encryption will probably take longer in practice. The double ratchet algorithmadds another factor that might influence the encryption/decryption time ratio. For anencrypted message multiple decryption attempts and thus increase the decryption time.The reason is that message keys may be skipped so that the receiver has to derive a new

4http://www.rfc-editor.org/rfc/rfc5869.txt

7

Page 16: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

message key and try decryption again.Both peers can initiate a re-keying, that is a Diffie-Hellman ratchet step, after the first

message has been sent. As soon as a peer learns about the other party’s new public key,it also performs the ratchet step. The re-keying period CADET uses is configurable. Bydefault CADET performs a re-keying after 1 hour no matter how many messages weresent. If messages are sent a re-keying is performed after 64 messages have been sent.For key exchange CADET uses ephemeral elliptic curve Diffie-Hellman (ECDHE) with aCurve25519 elliptic curve.

3.6 The CONVERSATION service module

The CONVERSATION service uses the CADET API to create a CADET channel when acall is started. In the original CONVERSATION implementation two CADET channel ex-isted, one for audio data and the other for control packets. In the current implementationonly one CADET channel is used for both audio data and control packets. As control traf-fic has to be sent reliably the channel is created with the GNUNET CADET OPTION RELIABLE

option which means that CADET’s flow control and congestion control are activated. Re-liable transmission of audio data is not needed because due to the low-latency requirementit does not make sense to wait for lost packets to be retransmitted before decoding. Inorder to eliminate this unnecessary overhead it is planned to allow a per-packet reliabil-ity switch in the future. Control packets would still be transmitted reliably while audiopackets would not.

3.6.1 Audio encoding/decoding

For audio encoding and decoding in CONVERSATION the libopus implementation ofthe OPUS codec[26] is used. As it is possible to determine the language spoken in theencrypted conversation when using variable bit rates[28], CONVERSATION uses a fixedbit rate (resulting from fixed a sample rate of 48000 Bit/second and a single channel).Another codec parameter is a maximum size for an encoded payload of 1024 Byte. Thisdoes not mean that in calls this packet size is reached. See Section 5.1 for more informationabout the packet sizes. In order to abstract from the codec implementation, genericlibraries exist for audio recording and playback: the MICROPHONE library5 and theSPEAKER library 6. When a microphone or a speaker instance is enabled, a helper, thatis a separate executable is started. The microphone helper outputs audio obtained froma Pulseaudio source to stdout in the OGG format which is then read and routed to themicrophone implementation by the GNUnet HELPER library. The speaker helper readsOGG audio from stdin and sends it to a Pulseaudio sink. This helper architecture isrelevant for the measurement method as described in Section 5.1.1.

5https://gnunet.org/doxygen/d5/d5c/group__microphone.html6https://gnunet.org/doxygen/d4/d62/group__speaker.html

8

Page 17: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

4 Methodology

This section gives an overview on the measurement methodology. Starting with a de-scription of the virtual machines (Section 4.1) the measurement scripts are then described(Section 4.2. The Sections 4.3 and 4.4 describe how different network properties were emu-lated and how different network topologies were established. The audio setup is explainedin Section 4.5.

4.1 The virtual machines

Overall 20 virtual machines were available. The used virtualization technology was KVM.All machines had a virtual dual-core AMD CPU and 1 GB of RAM. The AES hardwareacceleration of the host’s CPU was delegated to the guests. The operating system on allguests was Debian 8 (jessie).

4.2 Measurement automation

Below the virtual machines conducting the experiments described in the previous sectionare referred to as measurement workers, the machine initiating the experiments and col-lecting the measurements is referred to as measurement controller. For automating themeasurements two Python scripts were written: the measurement worker script (mw.py)and the measurement controller script (mc.py). Usage information can be found in Ap-pendix B.

On all workers the directory environment is present which contains the worker script,GNUnet configuration files (e.g. for using only TCP or only UDP as underlying transportprotocols) and other scripts, of which some are called by the worker script. E.g. there arescripts for initializing the virtual machine, reinstalling GNUnet and initializing Pulseaudio.

The experiment specifications used by both controller and workers are written inYAML. The specification files only have to be stored on the controller, the controllerscript takes care of sending it to the workers. Listing 1 shows an example experimentspecification. It contains the topology of the worker peers (in this thesis only directlyconnected peers have been used), the network shaping parameters and parameters for themeasurements, e.g. the count of RTT measurements. mw4 and mw5 are worker IDs whichreference information stored in a separate file (config.yaml). It contains information suchas a worker’s IP addresses and SSH ports.

The procedure of an experiment is as follows:

1. The controller script reads an experiment specification file, extracts informationabout the workers involved: the worker initiating the measurements and the targetworker (e.g. where an echo service for round-trip time measurements is to be run).SSH connections to the obtained workers are established.

2. GNUnet is started on all workers using a remote procedure call to init-gnunet.Which configuration file is used depends on which transport protocol was specifiedwhen starting the controller script. The call returns information about the startedpeer: a GNUnet HELLO message (see Section 3.3), the peer ID and the conversationaddress (see Section 5.1.1).

3. The obtained information is distributed to all involved peers using a remote proce-dure call to set-workers.

9

Page 18: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

4. The experiment is initialized on all workers (using the experiment --init RPC).The worker script does the network shaping (as described in Section 4.3, introducesneighbour peers using HELLO messages (and thus establishes the topology (as de-scribed in Section 4.4), initializes the Pulseaudio sources and sinks (see Section 4.5)and starts command-line tools in listening or echo mode.

5. The experiment is conducted (using the experiment RPC). On the worker side thisincludes starting tcpdump, starting audio playback and audio recording (if conver-sation is involved). Once finished the RPC returns the measurement values and thecontroller stores them to the results directory.

6. The controller fetches additional files, i.e. tcpdump output and the audio recording.

7. GNUnet is stopped on all workers using the RPC shutdown-gnunet.

1 ---

23 worker: mw4

4 topology: [[mw4 , mw5]]

5 shaping:-

67 links: [[mw4 , mw5], [mw5 , mw4]]

8 parameters:

9 latency ms: 80

10 bandwidth kbps: 100000

11 measurements:-

1213 type: conversation delay ping

14 target: mw5

15 count: 1000-

1617 type: conversation delay call

18 target: mw5

19 count: 1000

Listing 1: specification of experiment cv delay 3: topology: mw4 (measuring worker),mw5 (target worker), network shaping: 80 ms delay, 100 Mbit/s bandwidth,measurements: delay measurements using ping method and call method (see Section5.1.2), 1000 measurement values each

4.3 Network shaping

The effects of multiple network properties which were not inherently present in the envi-ronment were to be examined. E.g. the latency between the virtual machines was verylow because all VMs were on the same physical host machine. Section 6.1.2 shows that itwas below 1 ms. Realistic latencies up to 300ms were to be measured, so they had to beemulated.

For emulating delay, delay variation, bandwidth, and packet loss the network emulatornetem[12], which is included in the Linux kernel, was used. It allows to define filter rules forspecific hosts. The measurement worker script extracts the network shaping parametersfrom the specification file and configures netem accordingly. Netem configuration wasdone using the tc command line tool from the iproute2 package7. Examples of how tc wasused can be found in the following Sections 4.3.1 and 4.3.2.

7https://wiki.linuxfoundation.org/networking/iproute2

10

Page 19: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

4.3.1 Delay and delay variation

Delay and delay variation (often called jitter) can be emulated within the same netem filterrule. Because multiple filter rules were to be applied first a classful queueing discipline(qdisc) had to be created. qdisc is the term that describes a scheduler in the Linux trafficcontrol system8. qdiscs are responsible for applying traffic shaping rules to packets. Theprio qdisc was chosen as it allows multiple filters per traffic shaping rule by creating aclass (in the example in Listing 2 the class is 1:1) and assigning filter rules to it. Theexample shows the tc usage for configuring a one-way delay of 60ms± 10ms. tc employsa normal distribution with a mean µ = 60ms and a standard deviation σ = 10ms to varythe delay, so that 68.27% of the emulated delay values are within the standard deviation.Calculating the actual delays for emulation is done by the netem kernel component9.

1 tc qdisc add dev eth0 root handle 1: prio

2 tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 60ms 10ms

3 tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dst\

130.149.221.140 flowid 1:1

4 tc filter add dev eth0 protocol ipv6 parent 1: prio 2 u32 match ipv6 dst\

2001:638:809: ff14 :130:149:221:140 flowid 1:1

5 tc filter add dev eth0 protocol ipv6 parent 1: prio 2 u32 match ipv6 dst\

fe80 ::6011:7 aff:fe51:3c9b

Listing 2: tc usage for emulating a delay of 60 ms with a delay variation of 10 ms. Line1: add qdisc 1, line 2: add network shaping rule to the queueing discipline, lines 3-5:apply network shaping to packets destinated to the target peer’s IP addresses.

4.3.2 Packet loss and low bandwidth

Like delay and delay variation also packet loss and low bandwidth can be emulated usingnetem. All network properties to be emulated have to be added to the same queuingdiscipline in the same call so that the filters for specifying the target IP addresses haveto be added only once. Listing 3 shows a tc call for adding delay, delay variation, packetloss and low bandwidth.

1 tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 60ms 10ms loss 1% rate

200 kbit

Listing 3: tc usage for emulating a delay of 60 ms, a delay variation of 10 ms, a packetloss rate of 1% and a bandwidth of 200 kbps. The network shaping is added to an existingqdisc 1.

4.4 Establishing the topology

Although the specification format described in Section 4.2 allows specifying arbitrarytopologies, the only topology the Python scripts are known to work with and that wasused for measurements in this thesis is a direct connection between two GNUnet peers.In order to isolate the peers it was necessary to disable GNUnet’s automatic learning ofother peers. By default a GNUnet peer learns about new peers in four different ways[27]:

• peer information bundled with the software package

• UDP neighbour discovery in a LAN (IPv4 broadcast, IPv6 multicast)

8http://tldp.org/HOWTO/Traffic-Control-HOWTO/components.html9tc passes a CDF (cumulative distribution function) table to netem which is “generated as part of the

iproute2 compilation and placed in /usr/lib/tc”[20], netem then uses it to calculate the pseudo-randomlydistributed delays for emulation (see function tabledist in net/sched/sch netem.c, linux kernel 3.16[25])

11

Page 20: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

• topology gossiping (already connected peers send information about other peers)

• the HOSTLIST service (getting peer information from bootstrap servers)

Using bundled peer information was disabled using the USE INCLUDED HELLOS = NO

configuration option in the peerinfo section. By default peers introduce themselves totheir network by sending UDP packets to the IPv4 broadcast or IPv6 multicast addresses.This UDP neighbour discovery can be disabled using the BROADCAST = NO option in thetransport-udp section. Topology gossiping is sending peer information to already con-nected peers (TOPOLOGY service). There are also bootstrap servers which provide listsof peers as HTTP download (HOSTLIST service). Both mechanisms can be disabled bynot starting the respective service. The complete GNUnet configuration file used for allexperiments can be found in Appendix A.

After these mechanisms were disabled the link between the two peers was establishedby exchanging peer information out-of-band, that is passing GNUnet HELLO URLs (seeSection 3.3) to the gnunet-peerinfo command-line tool.

4.5 Audio setup

For providing virtual recording and playback devices on the virtual machines the Pulseau-dio commandline tools were used. Listing 4 shows the initialization procedure for botha virtual microphone and a virtual speaker. After (re)starting the Pulseaudio daemontwo null sinks are created. Pulseaudio sinks have monitors which can be used as sources.Thus the output sink is configured as the default sink for applications playing audio andthe monitor of the input sink is configured as the default source for applications recordingaudio.

1 pulseaudio --kill

2 pulseaudio --start

3 pactl load-module module-null-sink sink name=input

4 pactl load-module module-null-sink sink name=output

5 pactl set-default-sink output

6 pactl set-default-source input.monitor

Listing 4: Audio initialization on the virtual machines

For audio playback and recording the commandline tools paplay and parecord whichare installed with pulseadio were used. Listing 5 shows the commands used.

1 paplay --device=input $AUDIO FILE

2 parecord --device=output.monitor --file-format=wav > $RECORD FILE

Listing 5: Playback with paplay and recording with parecord

4.6 Verifying the setup

tcpdump records were stored for all experiments as mentioned in Section 4.2. Randomlychosen records were analyzed in Wireshark in order to verify that the automatic GNUnetconfiguration for exclusively using UDP or TCP worked: By checking in Wireshark thateither only UDP or only TCP packets were sent between the involved machines, it wasconfirmed that the configuration scripts were working correctly.

Ping10 and iperf11 were used to check that the network shaping was in effect for ran-domly chosen experiments. Ping provides statistics about RTT, the RTT’s standard de-viation and packet loss while iperv allows bandwidth measurements.

10https://wiki.linuxfoundation.org/networking/iputils11https://iperf.fr

12

Page 21: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

After the experiment was initialized (that is network shaping was done) a ping andping6 (for ICMPv6) measurement with default parameters was performed between theinvolved worker machines. The measured RTT and packet loss were compared to theemulated delay (which was expected to be half the measured RTT) and packet loss. Inorder to verify the emulated delay variance, that is the emulated delay’s standard deviation(see Section 4.3.1), it has to be considered that the RTT’s standard deviation measuredwith ping contains the standard deviations of two one-way delays (referred to as σ1 andσ2) because delay was emulated in both directions. As the emulation is symmetrical, weassume σ1 = σ2 and thus the measured RTT’s standard deviation and the emulated delayvariation are expected to differ by a factor of

√2:

σRTT =√σ21 + σ22 (1a)

=√

2 · σ21 (1b)

⇔ σ1 =1√2σRTT (1c)

The RTTs, RTT standard deviations and the packet loss rates measured with pingcomplied with the emulated delays, delay variations and packet loss rates. Thus a func-tional shaping of these network properties can be assumed.

For verifying that the bandwidth emulations were in effect, the bandwidth was mea-sured with iperf for the network shapings of randomly chosen experiments. iperf wasstarted in server mode on one peer and in client mode on the other peer. It then trans-fers data for a specified amount of time and the server reports the measured bandwidth inspecified intervals. Measurements were done for the IPv4 and IPv6 addresses (for IPv6 the-V option has to be specified) and using both TCP and UDP in separated measurements.Listing 6 shows an example for measuring bandwidth over TCP using IPv4.

1 iperf -s -i 10 -p 9999

2 iperf -c 172.29.0.5 -p 9999 -t 60

Listing 6: measuring bandwidth with iperf using TCP. Line 1: start iperf in server mode(measured bandwidths are reported in intervals of 10 s), line 2: start iperf in client mode(stop sending traffic after 60 s)

For measuring bandwidths over UDP a bit rate for sending traffic has to be specified.As UDP does not provide congestion control, packets will be dropped if this rate is higherthan the available bandwidth. Thus if the client sends with a bit rates higher than theexpected bandwidth, the server is expected to measure the maximum available bandwidth.For all iperf measurements over UDP 110% of the expected bandwidth was specified at theclient. Listing 7 shows an example of such a measurement for an expected bandwidth of 200kbps. The bandwidth measured at the server was around 194 kbps which is approximatelythe emulated value.

1 iperf -s -i 10 -u -p 9999

2 iperf -c 172.29.0.5 -p 9999 -u -t 60 -b 220K

Listing 7: measuring bandwidth with iperf using UDP. Line 1: start iperf in server mode(measured bandwidths are reported in intervals of 10 s), line 2: start iperf in client mode(for expected bandwidth + 10%; stop sending traffic after 60 s)

The bandwidths measurements using iperf showed the expected results which indicatesthat bandwidths were shaped correctly.

13

Page 22: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

5 Measurement tools

For measuring several GNUnet command line tools and GNUnet services had to be mod-ified. Section 5.1 describes these changes. Section 5.3 gives an overview on the sizes usedfor the ping packets.

5.1 GNUnet command line tools

For most GNUnet modules command-line tools exist for testing, scripting and also mea-surement purposes. The naming convention for these tools is gnunet-<module name>.For instance the command-line tool gnunet-cadet provides information about CADETtunnels and can also be used to establish an end-to-end encrypted connection (by runninggnunet-cadet <peer id> <port>) to a listening GNUnet peer (that is gnunet-cadet

-o <port> was run). Data to transmit is read from stdin and output to stdout at thereceiver, very similar to a telnet client.

All relevant command-line tools were extended to support RTT measurements. Alsosome of the services had to be modified to allow service-internal delay measurementssuch as encryption delay. All modifications made to the GNUnet source code can befound in the improving-conversation branch in the official GNUnet git repository12.The modifications to the GNUnet command-line tools and services are described in thesections 5.1.1 through 5.1.5. The measured values are printed to stdout or written to CSVfiles. See Appendix C for details.

5.1.1 gnunet-conversation

gnunet-conversation is the only one of the discussed command-line tools that is inter-active. Once started it can be controlled with these commands:

Command Description

/help lists available commands or prints help about a specific command/address prints own conversation address/call initiate call using GNS address of a peer/accept accept incoming call on specific line/suspend suspend active call/resume resume incoming call on specific line or resume outgoing call/cancel reject incoming call or terminate active call/status print information about available lines, current calls etc/quit quit the application

The /address command prints an address that is used internally to initiate a call.It consists of two base32-encoded strings: the peer ID which is 52 bytes in length anda 102 characters long string containing the phone line (port equivalent) where gnunet-conversation is listening, and the CADET port. In mainline GNUnet this address canbe used for debugging but not as an argument to the /call command. Instead it is ex-pected to make calls using a GNS13 address (which has the form username.gnu). Usersare expected to store a PHONE record in their GNS zone using the gnunet-namestore

12https://gnunet.org/git/gnunet.git/13GNU name system, see https://gnunet.org/gns-implementation

14

Page 23: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

command-line tool or the GUI application gnunet-namestore-gtk14. gnunet-conversationthen passes the given GNS address to the GNS service which resolves it to a conversationaddress. In order to avoid this procedure each time a CONVERSATION delay mea-surement is initialized the implementation of the /call command was extended. Now itaccepts conversation addresses directly besides GNS addresses (the distinction is done bychecking for a GNS ending, that is .gns or .zkey).

An echo service and RTT measurements were added to gnunet-conversation. Thepackets used for RTT measurements are referred to as GNUnet echo requests as they havethe same role as ICMP Echo Requests. The echo requests contains an identifier and dummydata, so that the average size of CONVERSATION audio packets is met (see Section 5.3).The echo service sends copies of these packets back and thus these are referred to asGNUnet echo responses. The echo service can be activated with the -e command lineoption and the RTT measurement functionality comprise three command line options: -rfor activating it (it will begin when a call starts), -n for specifying the number of RTTmeasurements to be done and -w for specifying a timeout for each RTT measurement. SeeAppendix D for documentation about the existing and newly implemented command lineoptions. Measured RTT values are logged to a file in the CSV format (see Appendix Cfor details about output files).

If RTT measurements were activated when gnunet-conversation was started and acall starts (that is it has been accepted by the receiver; it does not matter which sidehas initiated the call) the current time is stored and the first GNUnet echo request issent. GNUnet echo requests include the timestamp, too. It is used as an identifier forsorting out delayed GNUnet echo responses. If the identifier of an incoming GNUnetecho response matches the last GNUnet echo request, the time since sending it is loggedand the measurement counter is increased. If a timeout was specified and the timeoutvalue is reached, an invalid value (-1) is logged. Lost packets are not considered for themeasurement counter, so that after an experiment has finished successfully, the numberof valid values in the output file equals the specified count (-n option).

GNUnet echo requests are sent in fixed time intervals in order to minimize effectsof different bandwidth usage for different emulated delays (currently the interval is hard-coded as 300 ms, which is at least 100 ms greater than the RTT caused by delay emulation).This means, when an echo response is received, the task for sending the next GNUnet echorequest is scheduled to be executed after 300ms−RTT .

Due to the codec abstraction used in the conversation API the audio data is not pro-cessed in the source code of gnunet-conversation, but inside the MICROPHONE library15

and the SPEAKER library16. This made it necessary for both the echo service and theRTT measurement implementations to create dummy microphone and dummy speakertypes and functions. For the echo service the dummy speaker copies all incoming payloaddata into the dummy microphone by calling the handler for recorded audio data. Forsending GNUnet echo requests the handler for enabling the dummy microphone does notenable the hardware microphone but instead schedules a task for sending a GNUnet echorequest.

5.1.2 CONVERSATION service and audio helpers

Delays were measured not only by sending GNUnet echo requests containing dummy data(referred to as ping method) but also by sending GNUnet echo requests containing actual

14for a detailed tutorial on how to use gnunet-conversation see https://gnunet.org/first-steps-using-gnunet-conversation

15see https://gnunet.org/doxygen/d5/d5c/group__microphone.html16seehttps://gnunet.org/doxygen/d4/d62/group__speaker.html

15

Page 24: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

audio data during a call (referred to as call method). The call method differs from the pingmethod in that audio packets are sent as they are generated by the microphone whereasthe ping method sends GNUnet echo requests in a fixed interval. This results in a higherpacket rate for the call method.

For the RTT measurements the called gnunet-conversation instance has to be operatedwith an enabled echo service (the same one used for the ping method). As the echoservice was implemented using a dummy microphone and dummy speaker, no encodingand decoding happens on the target peer. In order to be able to nevertheless measureRTT, encoding delay and decoding delay in the same run, both the encoding delay andthe decoding delay were measured on the peer that initiated the call. Figure 3 illustratesthis setup.

CONVERSATION (caller)

Microphone

record-helperencoding delay

round-trip time

1. 5.

3.2.

Speaker

playback-helperdecoding delay

CONVERSATION (callee)

Echo service4.

Figure 3: Setup of of the call method : 1. recording playback from input sink monitor, 2.encoding audio data; measuring encoding delay, 3. sending encoded data and receivingreply from echo service; measuring RTT time, 4. decoding audio data; measuring decodingdelay, 5. playback to output sink

For implementing the call method the CONVERSATION service had to be modified.Extending the CONVERSATION API was avoided and thus measuring delay using the callmethod and measuring encoding/decoding delay happens during every call and cannot beswitched on or off from the command line. Instead both measurements can be disabled atcompile time if #define MEASURE DELAY 1 is removed from conversation.h. In functiontransmit call audio() (conversation api call.c) before passing the audio data tothe cadet service using a GNUnet message a timestamp is included into that message.When a packet that was sent back by the other peer’s echo service is handled by functionhandle call audio(), the included timestamp is unpacked and the time difference islogged to a CSV file.

As described in Section 3.6.1 audio encoding and decoding, that is calling the libo-pus API, happens in extra helper binaries. For measuring the encode delay the execu-tion time of the opus encode float() function was measured in gnunet-helper-audio-

record.c, for measuring decode delay it is the function ogg demux and decode() functionin gnunet-helper-audio-playback.c. The audio codec delay measurements, like thecryptography delay measurements described in Section 5.1.4, were done using the GNUNETTIME absolute get duration() function from GNUnet’s TIME library. The measuredvalues of both the encoding and decoding measurements are written to separate CSV files.

5.1.3 gnunet-cadet, gnunet-core and gnunet-transport

Like for gnunet-conversation RTT measurements and an echo service were implementedin gnunet-cadet, gnunet-core and gnunet-transport. The RTT measurement behaviouris the same as for the ping method in gnunet-conversation (see Section 5.1.1), the onlydifference is that the measurement starts soon after the tool was started because unlike

16

Page 25: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

in gnunet-conversation there is no user interaction required to establish a connection tothe other peer. Without user interaction there was no need to write measurement valuesto output files. Instead they are simply printed to stdout. Further information aboutthe GNUnet echo request packets on the different layers can be found in Section 5.3,Appendix D provides documentation about the command-line options, both the existingand the newly implemented ones.

5.1.4 CADET service

While for the RTT measurements on the CONVERSATION layer only the GNUnetcommand-line tools had to be modified, CADET’s cryptography delay required modi-fications of the CADET service. The encryption and decryption delays arise and weremeasured in CADET’s service component and the overall RTT delays was measured inthe application (that is gnunet-cadet). This means that encryption and decryption delaysare contained in the overall RTT delay which is also valid for the echo service side. Theprocedure (which is illustrated in Figure 4) is as follows:

1. At the measuring peer gnunet-cadet generates a GNUnet echo request packet con-taining an identifier and dummy data and passes it to the CADET service (destina-tion: target peer)

2. The CADET service encrypts the packet, stores an encryption delay record andtransmits it to the target peer

3. At the target peer the CADET service decrypts the incoming packet and passes theplaintext to the echo service (within gnunet-cadet)

4. The echo service copies the packet and passes it to the CADET service (destination:measuring peer)

5. The CADET service encrypts the packet and sends it back to the measuring peer

6. The CADET service at the measuring peer decrypts the incoming packet, stores adecryption delay record and passes it to the application (gnunet-cadet)

7. gnunet-cadet calculates the time since the last GNUnet echo request was generatedand stores an RTT record

Measuring worker

GNUnetecho request

Encryption

Target worker

Decryption

Decryption

EncryptionRTT

GNUnetecho response

Figure 4: Setup for RTT measurements on CORE and CADET layer

This means each RTT measured on the CADET layer contains the encryption anddecryption delays of both the measuring worker and the target worker. In Chapter 6 wherethe measured delays are analyzed the cryptography delays were analyzed separately fromthe remaining components of the measured RTTs. Section 5.2 describes the math behindthis separation.

17

Page 26: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

For measuring the encryption and decryption delays at the measuring worker, thecode parts responsible for encrypting and decrypting a CADET packet were identified.The delays those parts cause were measured using the timestamp data type (GNUNET TIME

Absolute) and the function GNUNET TIME absolute get duration() from GNUnet’s TIMElibrary17. The timestamp datatype stores an absolute timestamp in µs as 64-bit unsignedinteger and the function calculates the difference of two such integers. The measured en-cryption and decryption delays in µs were logged into separate files. These modificationsof the CADET service can be disabled at compile time by removing #define MEASURE

DELAY 1 from cadet.h.

5.1.5 CORE service

Analog to the encryption/decryption delay measurements in the CADET service, en-cryption/decryption delays of CORE’s OTR implementation was measured in the COREservice. Removing #define MEASURE DELAY 1 in core.h disables these measurements atcompile time.

5.2 Separating cryptography delays from the measured RTTs

The cryptography delays were measured separately on the CADET and CORE layer asdescribed in the previous sections. For plotting and analyzing them as component ofthe overall delay, twice the encryption delay and twice the decryption delay had to besubtracted from each measured RTT value as described in Section 5.1.4.

As for all RTT measurements on the CADET layer the same payload sizes were usedand the same is true for the CORE layer, the encryption and decryption delay was as-sumed to be independent from the network shaping. This allowed calculating means forencryption and decryption delays over all measurement values separately for CADET andCORE (the resulting means are listed in Section 6.1.1), and subtracting them from eachRTT. This method was used for all plots in Chapter 6 showing separated encryption anddecryption delay.

5.3 Packet sizes

In order to obtain comparable results for delays measured on different layers, the GNUnetecho request packets sent over the network have to be the same size for all measurements.This means for each layer a different payload size had to be determined which considers theheader sizes of all involved layers and encryption overhead (when encryption is involved).

The payload sizes were determined using the command-line tool gnunet-statisticswhich displays usage information that the GNUnet services provide to the STATISTICSservice. Most services provide the sizes of the payloads they send and receive. Table 1lists the resulting packet sizes.

GNUnet layer Payload size in Byte Definition

CONVERSATION 292 gnunet-conversation.c

CADET 300 gnunet-cadet.c

CORE 445 gnunet-core.c

TRANSPORT 663 gnunet-transport.c

Table 1: Payload sizes of GNUnet echo request packets on the different GNUnet layers

17https://gnunet.org/doxygen/d9/d7d/group__time.html

18

Page 27: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

6 Measurements

In this chapter the conducted measurements are described and the results are analyzed.First it is analyzed what shares of the total delay the different GNUnet layers have underdifferent conditions. Section 6.1 describes delay measurements between two peers, withfocus on the network parameters jitter, packet loss and bandwidth. The delays on theCADET layer are treated separately. In Section 6.2 two different methods for measuringRTT delay on the CONVERSATION layer are compared. The evaluation of the subjectiveassessments of the speech recordings can be found in Section 6.3.

6.1 Latency by Layer

Round-trip time measurements were conducted between two virtual machines. In parallelcryptography delays on the CORE and CADET layer and audio codec delays on theCONVERSATION layer were measured. These measurements are described in detail inSection 5.1.

For each experiment 1000 values of each measured quantity were recorded, e.g. in anexperiment on the CORE layer 1000 network RTT values, 1000 encryption delay valuesand 1000 decryption delay values were recorded.

The delay measurements on the CONVERSATION layer differ from those on the otherlayers. As described in Section 5.1.1 delay was measured with two different methods: Usingping packets like on the other layers and during a call using audio data recorded by thevirtual microphone. This was done in order to assess how realistic the results of theping measurements are compared to real conversations. Measuring with both methodsresulted in twice the number of RTT values on the CONVERSATION layer compared tothe other layers. In the plots where different layers are compared the CONVERSATIONdelay always stems from the ping method.

In addition to the RTT measurements separate experiments were conducted for sub-jective QoE assessment, hence the [qoe ] infix in the CONVERSATION column of Table2. For subjective assessment decoded audio data sent over the network once (in contrastto packets sent back by an echo service without decoding) is needed. Thus, in contrastto the RTT measurements described in Section 5.1.2, in these experiments the audio wasrecorded on the target worker (the machine receiving the call).

Table 2 lists the IDs of all conducted ’latency by layer’ experiments. The experimentIDs which are referenced in the plots and the analysis below correspond to the file namesof the experiment specifications in the YAML format described in Section 4.2.

The emulated parameters delay, delay variance and packet loss were chosen in order tomeet scenarios in which devices are communicating over WiFi and broadband connections.E.g. delay was varied in the range 20ms..100ms which are typical delays between devicesthat are both connected over broadband technologies such as DSL or cable. Packet lossrates in the range 1%..5% may occur in WiFi environments under bad conditions.

The range of the emulated bandwidth was chosen by making test calls. The callsshowed good quality at 200 kbps and bad quality at 140 kbps.

Default values were used for shaped bandwidth and delay, that is in experiments wherebandwidth emulation is not specified, an emulated bandwidth of 100 Mbit/s was used, notspecifying delay emulation means that an emulated delay of 20 ms was used.

In the measurement scripts it can be specified whether GNUnet should be configuredto use exclusively either UDP or TCP. In order to not leave the decision up to GNUnetATS (see section 3.3) and risk switching from one transport protocol to the other during anexperiment, all experiments were conducted with either exclusive UDP or exclusive TCP

19

Page 28: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

usage. Considering the separate experiments for subjective QoE assessment this leads to atotal number of 200 experiments: 20 TRANSPORT experiments + 20 CORE experiments+ 20 CADET experiments + 40 CONVERSATION experiments, all conducted with bothTCP-only and UDP-only configuration.

GNUnet layerTRANSPORT CORE CADET CONVERSATION

netw

ork

shap

ing

N/A t ideal 0 cr ideal 0 cd ideal 0 cv [qoe ]ideal 0

dela

y

20ms t delay 0 cr delay 0 cd delay 0 cv [qoe ]delay 040ms t delay 1 cr delay 1 cd delay 1 cv [qoe ]delay 160ms t delay 2 cr delay 2 cd delay 2 cv [qoe ]delay 280ms t delay 3 cr delay 3 cd delay 3 cv [qoe ]delay 3100ms t delay 4 cr delay 4 cd delay 4 cv [qoe ]delay 4

PD

V

5% t pdv 0 cr pdv 0 cd pdv 0 cv [qoe ]pdv 010% t pdv 1 cr pdv 1 cd pdv 1 cv [qoe ]pdv 115% t pdv 2 cr pdv 2 cd pdv 2 cv [qoe ]pdv 220% t pdv 3 cr pdv 3 cd pdv 3 cv [qoe ]pdv 325% t pdv 4 cr pdv 4 cd pdv 4 cv [qoe ]pdv 4

pack

et

loss 1% t loss 0 cr loss 0 cd loss 0 cv [qoe ]loss 0

2% t loss 1 cr loss 1 cd loss 1 cv [qoe ]loss 13% t loss 2 cr loss 2 cd loss 2 cv [qoe ]loss 24% t loss 3 cr loss 3 cd loss 3 cv [qoe ]loss 35% t loss 4 cr loss 4 cd loss 4 cv [qoe ]loss 4

ban

dw

idth 200kbps t bandwidth 3 cr bandwidth 3 cd bandwidth 3 cv [qoe ]bandwidth 3

180kbps t bandwidth 7 cr bandwidth 7 cd bandwidth 7 cv [qoe ]bandwidth 7160kbps t bandwidth 8 cr bandwidth 8 cd bandwidth 8 cv [qoe ]bandwidth 8140kbps t bandwidth 9 cr bandwidth 9 cd bandwidth 9 cv [qoe ]bandwidth 9

Table 2: experiments conducted to determine delay by GNUnet layer. Default network shaping param-eters: 100 Mbit/s bandwidth, 20 ms delay, no delay variation, no packet loss. The prefixes t, cr, cd,cv stand for the GNUnet layers TRANSPORT, CORE, CADET and CONVERSATION, the followingexpression is the emulated metric that was varied

6.1.1 Determining the encryption and decryption delay

As described in Sections 5.1.4 through 5.2 the measured RTT delays contain encryptionand decryption delays and thus in order to calculate the network delays for plotting itwas necessary to measure those delays separately and subtract them from the measureddelays.

The encryption and decryption delays were recorded on the measuring worker in allRTT experiments on the CORE and CADET layers (see Section 5.1.4). A mean andstandard deviation was calculated over all those values. For both CORE and CADETthese sum up to 40000 encryption delay values and 40000 decryption delay values (20experiments using UDP only, 20 experiments using TCP only, 1000 measuring values perexperiment).

Table 3 shows the results. The standard deviations of CADET’s encryption and de-cryption are higher than expected. A look into the dataset showed outliers with bothsignificantly higher and lower delays. Presumably these are caused by packets other thanthe GNUnet echo requests, e.g. packets responsible for CADET’s re-keying described inSection 3.5.2. These may have different packet sizes than the GNUnet echo requests and

20

Page 29: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

thus may cause different encryption and decryption delays.

GNUnet layer Encryption delay Decryption delay

CADET 5.980ms± 1.587ms 1.377± 0.673ms

CORE 0.496ms± 0.057ms 0.501± 0.065ms

Table 3: Mean and standard deviation of encryption and decryption delays calculated over460460 delay values for both CADET and CORE

6.1.2 No network shaping

The first line in table 2 lists delay measurements on the four layers without any networkshaping. As the two virtual machines used for these experiments are on the same hostmachine and communicate over a virtual network bridge the physical network delay isexpected to be very low. An RTT measurement using ping without GNUnet involved wasdone as shown in listing 8. The resulting delay (RTT/2) is 0.230 ms with a standarddeviation of 0.029 ms (12.4%).

$ ping -c 1000 -s 725 172.29.0.5

[...]

rtt min/avg/max/mdev = 0.309/0.460/0.939/0.057 ms

Listing 8: Ping measurement with ICMP ECHO REQUESTs using a count of 1000. Thepacket size 725 equals the one used in gnunet-transport (see section 5.3)

The TRANSPORT layer is expected to add a constant (that is low standard deviation)processing delay to this. ATS as a potential source of unpredictable delays is preventedfrom switching transport protocols by the GNUnet configuration.

TRANSPORT CORE CADET CONVERSATIONGNUnet layer

0

5

10

15

20

25

30

Dela

y in m

s

ideal_00: No network shaping

networkencryptiondecryptionencodingdecoding

(a) TCP only

TRANSPORT CORE CADET CONVERSATIONGNUnet layer

0

5

10

15

20

25

30

Dela

y in m

s

ideal_00: No network shaping

networkencryptiondecryptionencodingdecoding

(b) UDP only

Figure 5: Measured delay (mean and standard deviation) without network shaping

Figure 5a shows the means and standard deviations of the measured delays usingTCP only. The delay TRANSPORT added to the network delay measured with ping isapproximately 0.6 ms (0.85 ms in total) which is low compared to the 22.81 ms total

21

Page 30: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

delay. This can be be considered as processing delay, e.g. inter-process communication asdescribed in section 5.1.1. The delay increase from TRANSPORT to the CORE layer isroughly 2.1 ms. Half of this increase is caused by OTR encryption and decryption. Thesedelays sum up to approximately 1 ms. The remaining 1.1 ms may again result from IPCcommunication. The most drastic increase happens from CORE to CADET. CADETadds 13.5 ms to the total CORE delay. This is the main part of the overall delay seenon the CONVERSATION layer. Double-Ratchet cryptography delays sum up to around7.4 ms. The remaining 6.1 ms are analyzed in chapter 6.1.3. A surprising observation isthat the encryption on the CADET layer takes longer than the decryption. As describedin section 3.5.2 this is not expected, but could be explained by parallelization. This isalso investigated in chapter 6.1.3. The network delay measured on the CONVERSATIONlayer differs only by roughly 1 ms from the overall CADET delay which is in the sameorder as the presumable IPC delays on the other layers. CONVERSATION adds an audiocodec delay of 4.8 ms.

In both the TCP-only (Figure 5a) and the UDP-only (Figure 5b) plot the networkdelays show extreme standard deviations with significant differences between TCP andUDP: e.g. on the CADET layer the standard deviation is approximately 3 ms for TCPbut almost 12 ms for UDP. In cases where UDP shows a higher standard deviations alsothe mean is slightly higher for UDP. This might be a hint that both effects are caused byextreme outliers.

Indeed extreme outliers were found in the datasets: e.g. for UDP at approx. 510 ms(CADET) and 390 ms (CONVERSATION) and for TCP at approx. 260 ms (CONVER-SATION). Audio packets with such an extreme delay can’t be used for an active audiocall and thus would probably be dropped by the codec.

By plotting only the values below the 99th percentile in the figures 6a and 6b it canbe estimated how the delays would look like without the outliers. Here both the TCP-only case and the UDP-only case show very similar means standard deviations betweenroughly 0.3 ms (CORE) and 2.5 ms (CONVERSATION). Thus both differences in themeans between TCP and UDP and the extreme standard deviations seem to be causedby extreme outliers.

TRANSPORT CORE CADET CONVERSATIONGNUnet layer

0

5

10

15

20

25

Dela

y in m

s

ideal_00: No network shaping (< 99th_percentile)

networkencryptiondecryptionencodingdecoding

(a) TCP only

TRANSPORT CORE CADET CONVERSATIONGNUnet layer

0

5

10

15

20

25

Dela

y in m

s

ideal_00: No network shaping (< 99th percentile)

networkencryptiondecryptionencodingdecoding

(b) UDP only

Figure 6: Measured delay (mean and standard deviation) without network shaping (values < 99th percentile)

22

Page 31: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

In most delay measurements extreme outliers were found. Many were in the order ofseconds. It can be speculated that they are caused by CADET’s re-keying described inSection 3.5.2. As no clear evidence for this has been found yet, it has to be left as futurework.

6.1.3 A closer look at CADET’s delay

As discussed in the previous section the delay increase from CORE to CADET is mainlycaused by encryption and decryption. As described in Section 3.5.2 the encryption delaybeing much higher than the decryption delay is unexpected but might be explainable withparallelized decryption.

The functions responsible for encryption and decryption using AES and TWOFISH,GNUNET CRYPTO symmetric encrypt () and GNUNET CRYPTO symmetric decrypt () areimplemented in GNUnet’s CRYPTO library18. They are wrapping calls to libgcrypt19. Aprogram, that calls these functions in two loops was written in C. The input to the encryptfunction was 256 Byte of dummy data. The resulting cyphertext was then passed to thedecrypt function. The time differences these loops cause were measured using GNUNET

TIME absolute get duration() from GNUnet’s TIME library. In a measurement on oneof the virtual machines with 10000 iterations per loop, it was obvious that both functionscause equal delay (see Table 4).

Function Data size Delay

GNUNET CRYPTO symmetric encrypt 256 byte 0.063ms

GNUNET CRYPTO symmetric decrypt 256 byte 0.061ms

GNUNET CRYPTO ecdhe key get public N/A 4.3ms

Table 4: Mean over 10000 delay measurements for GNUnet functions

A closer look into the source code revealed that during encryption (in function GCT

send, gnunet-service-cadet tunnels.c) the function GNUNET CRYPTO ecdhe key get

public is called, which extracts the Diffie-Hellman ratchet public key (DHr), defined in[17], from the corresponding private key. A delay measurement was implemented in C likefor the encryption and decryption functions. The result is listed in Table 4: One call toGNUNET CRYPTO ecdhe key get public takes 4.3 ms. This matches roughly the differencebetween encryption and decryption delay (4.6 ms).

GNUNET CRYPTO ecdhe key get public is called for each outgoing packet although theDiffie-Hellman ratchet key changes after 64 packets have been sent or under the conditionsdescribed in Section 3.5.2. Thus storing the public key instead of calculating it on-the-flywould eliminate the delay caused by this function for most packets.

6.1.4 Emulate delay

The figures 7a and 7c show a collection of measurement results from all experimentswhere delay was emulated, that is the emulated delay was varied from 20 ms to 100 ms.The plotted delays contain the same components as the total delays in figure 5a, thatis they include cryptography and codec delays. For plotting a total mean and a totalstandard deviation, consisting either of network delay and encryption / decryption delay

18https://gnunet.org/doxygen/d5/dfc/group__crypto.html19https://www.gnupg.org/related_software/libgcrypt/

23

Page 32: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

or of network delay and encoding / decoding delay, had to be calculated using Equations2a and 2b. In both cases three delays were involved, so N is 3.

µtotal =N−1∑i=0

µi (2a)

σtotal =

√√√√N−1∑i=0

σ2i (2b)

20 40 60 80 100emulated delay in ms

0

50

100

150

200

dela

y in m

s

{t,cr,cd,cv}_delay[0-4], TCP

TRANSPORTCORECADETCONVERSATION

(a) TCP only

20 40 60 80 100emulated delay in ms

0

20

40

60

80

100

120

140

dela

y in m

s

{t,cr,cd,cv}_delay[0-4], TCP

TRANSPORTCORECADETCONVERSATION

(b) TCP only, values < 99th percentile

20 40 60 80 100emulated delay in ms

0

20

40

60

80

100

120

140

160

180

dela

y in m

s

{t,cr,cd,cv}_delay[0-4], UDP

TRANSPORTCORECADETCONVERSATION

(c) UDP only

20 40 60 80 100emulated delay in ms

0

20

40

60

80

100

120

140

dela

y in m

s

{t,cr,cd,cv}_delay[0-4], UDP

TRANSPORTCORECADETCONVERSATION

(d) UDP only, values < 99th percentile

Figure 7: Measured delay (mean and standard deviation) emulating delay, bandwidth: 100 Mbit/s

As shown in section 6.1.1 the delays caused by cryptography and codec are not varyingmuch over the course of the experiments. This and visual clarity are the reasons why theyare not listed separately in the collective plots in this chapter.

24

Page 33: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

The plots show a linear increase of the measured delays on all four layers for both TCPand UDP. An emulated delay in the range 0 to 100 ms (which is ideal for voice commu-nication) does not result in unexpected behaviour but each layer only adds the constantdelay described in section 6.1.2. It seems that the difference between TRANSPORT andCORE is higher than in the previous plots. The 99th-percentile plot shows very similarproportions to the experiment without network shaping. Thus, the higher mean on theCORE layer is again caused by outliers.

6.1.5 Emulate packet delay variation

When measuring delay with emulated PDV it is expected that the standard deviationof the measured values increases with the emulated PDV increase. The figures 8a (TCPonly) and 8c (UDP only) show that this is indeed the case on the TRANSPORT layer. Forboth cases the standard deviation increases steadily from 0.4 ms at 5% emulated PDV to2.1 ms at 25% emulated PDV. The same cannot be said for the other layers. For examplethe standard deviation on the CADET layer in the UDP case is much higher at 5% PDV(43 ms) than at 10% PDV (2.8 ms). In the TCP case for CONVERSATION the standarddeviation even seems to decrease from 86 ms at the lowest PDV to 41 ms at 20% PDV.Like the high standard deviation in the experiment without network shaping this is causedby outliers. In the described CONVERSATION case one outlier with a value of more than2 seconds exists. Again only the values below the 99th percentile were plotted (figures 8band 8d). Without the highest percentile the plots show a steady increase of the standarddeviations on the layers TRANSPORT and CORE. CADET and CONVERSATION seemto be affected little or not at all by this increase on the lower layers because these standarddeviations are small compared to the delay increase both CADET and CONVERSATIONcause.

25

Page 34: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

5 10 15 20 25emulated PDV in %

0

20

40

60

80

100

120

140

dela

y in m

s

{t,cr,cd,cv}_pdv[0-4], TCP

TRANSPORTCORECADETCONVERSATION

(a) TCP only

5 10 15 20 25emulated PDV in %

0

10

20

30

40

50

dela

y in m

s

{t,cr,cd,cv}_pdv[0-4], TCP

TRANSPORTCORECADETCONVERSATION

(b) TCP only, values < 99th percentile

5 10 15 20 25emulated PDV in %

0

20

40

60

80

100

dela

y in m

s

{t,cr,cd,cv}_pdv[0-4], UDP

TRANSPORTCORECADETCONVERSATION

(c) UDP only

5 10 15 20 25emulated PDV in %

0

10

20

30

40

50

dela

y in m

s

{t,cr,cd,cv}_pdv[0-4], UDP

TRANSPORTCORECADETCONVERSATION

(d) UDP only, values < 99th percentile

Figure 8: Measured delay (mean and standard deviation) emulating PDV

6.1.6 Emulate packet loss

Emulated packet loss was varied from 1% to 5%. The figures 9a through 9d show themeasured delays including the results without emulated packet loss taken from the exper-iments delay tcp 0 and delay udp 0. In both the TCP and the UDP plots a linear increaseof the measured delays can be observed. For TCP the increase per % packet loss on alllayers is roughly 12%, the increase on the CADET layer being a little more fluctuatingthan on the other layers.

26

Page 35: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

0 1 2 3 4 5emulated packet loss in %

0

50

100

150

200

dela

y in m

s

{t,cr,cd,cv}_loss_0, {t,cr,cd,cv}_loss[0-4], TCP

TRANSPORTCORECADETCONVERSATION

(a) TCP only

0 1 2 3 4 5emulated packet loss in %

0

20

40

60

80

100

120

dela

y in m

s

{t,cr,cd,cv}_loss_0, {t,cr,cd,cv}_loss[0-4], TCP

TRANSPORTCORECADETCONVERSATION

(b) TCP only, values < 99th percentile

0 1 2 3 4 5emulated packet loss in %

0

20

40

60

80

100

120

dela

y in m

s

{t,cr,cd,cv}_loss_0, {t,cr,cd,cv}_loss[0-4], UDP

TRANSPORTCORECADETCONVERSATION

(c) UDP only

0 1 2 3 4 5emulated packet loss in %

0

10

20

30

40

50

60

70dela

y in m

s{t,cr,cd,cv}_loss_0, {t,cr,cd,cv}_loss[0-4], UDP

TRANSPORTCORECADETCONVERSATION

(d) UDP only, values < 99th percentile

Figure 9: Measured delay (mean and standard deviation) emulating packet loss

The boxplots in Figure 10 show a lot of outliers, that is measured values outside of1.5 IQR (inter-quartile range). For TRANSPORT there are 1129 outliers and for COREthere are 1241 outliers from 10000 measured values each. The values of most of the outliersare not as extreme as seen in the previous experiments. The vast majority is below 300ms. So in contrast to the previously discussed experiments the outliers are an essentialshare of the measured values and a mean may not be the best choice for getting reliableinformation about datasets with such properties.

Another observation are the extreme standard deviations on all layers (TCP) and onthe layers CADET and CONVERSATION (UDP). As TCP is reliable, it will retransmitlost packets which causes high variance for TRANSPORT and all layers above.

The UDP-only plots have a very low standard deviation for TRANSPORT and a muchlower standard deviation for CORE than the TCP plots. This is because neither thesetwo layers nor UDP provide reliability. gnunet-transport and gnunet-core detected thelost packets after the timeouts described in Section 5.1.3 but no retransmissions that

27

Page 36: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

could have increased the variance were done. CADET’s reliability functionality is in effectthough, because the CONVERSATION service activates it as described in Section 3.6.Thus when CADET detects a lost packet, it initiates a retransmission. This explains thatthe standard deviation is high on the CADET and CONVERSATION layer.

The fluctuations in the standard deviations can be explained again with extreme out-liers: the 99th percentile plots for both UDP and TCP show steady increasing standarddeviations.

101 102 103 104

delay in ms

1

2

3

4

GN

Unet

layers

boxplots of delays from experiment packet_loss_004_tcp

Figure 10: Boxplot of the measured network delays at 5% emulated packet loss; 1:TRANSPORT, 2: CORE, 3: CADET, 4: CONVERSATION

6.1.7 Emulate low bandwidth

Low bandwidth was emulated in the range 140 Kbit/s to 200 Kbit/s in steps of 20 KBit/s.Measurements were done like for the other metrics but the plots are omitted for thefollowing reason.

In all plots (TCP-only, UDP-only, both 100th-percentile and 99th-percentile plots) themean of the TRANSPORT delay was higher than for the next higher layer CORE. Thisclearly indicates a measurement error. As every plots was affected and a very low standarddeviation existed for TRANSPORT and CORE, outlier cannot explain the effect. As thebandwidths are very low considering the codec’s bit rate of 48 Kbit/s and the packetheader and encryption overhead of the four layers it is possible that slight differences inthe effective bit rate can lead to different queueing delays. Such differences between thelayers can only exist if either the ping packets were sent in different rates or if the pingpackets had different sizes. Different rates are not possible because the same hardcodedinterval (300 ms) was used for all command-line tools, using the same implementation forenforcing that interval. So the second statement must be true: The ping packet sizes ofdifferent command-line tools differ in size.

The packet sizes listed in Table 1 were determined using gnunet-statistics. This

28

Page 37: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

seems to be an unreliable method because the number of bytes displayed may be the sumof payloads of multiple packets. E.g. on the CORE and CADET layer key exchangepackets may be sent in between the application data. This may have been summarizedinto one statistics output.

The measurement errors result from wrongly determined packet sizes. This has aneffect on the experiments with low bandwidth emulation because here queueing delaysincrease rapidly when the effective bit rate comes close to or exceeds the available band-width. In the other experiments a large bandwidth of 100 Mbit/s was available, so theeffect of the wrong packet sizes should not be significant.

6.2 CONVERSATION ping measurements vs. call delay

In order to determine how close the RTT measurements are to a realistic scenario, that isa call with speech recorded by a microphone, the RTTs measured using the ping methodwere compared with RTTs measured using the call method (both defined in Section 3.6).

Figure 11 shows the comparison for the TCP-only experiments discussed in the previoussections. For an emulated delay of 20 ms the means for both methods are equal as theplots 11a and 11b show. For increasing emulated delay the delays from both methodsincrease linearly, but with a slightly higher slope for the call method. From the lowest tothe highest emulated delay the measured delays increase by 286% for the ping method andby 405% for the call method. This can be explained by higher queueing delays because ofthe much higher packet rate. For an emulated delay of 100 ms, the measured delay for callmethod exceeds the recommended the recommended maximum mouth-to-ear delay (seeSection 2.2). Thus, bad QoE is expected.

The higher delay values in the packet loss plot can be explained with higher queueingdelay aswell.

The biggest difference between the two methods can be seen in the bandwidth plot.For dereasing emulated bandwidths the delays increase only slightly for the ping methodbut in an extreme way for the call method. Between an emulated delay of 200 Kbit/s and180Kbit/s the increase is 525%. This means that while still potentially suitable for goodQoE at 200 Kbit/s available bandwidth, for little less than 200 Kbit/s available bandwidththe queueing delay becomes unsuitable according to the ITU-T recommendations (Section2.2). This sudden delay increase is an indication for packet loss because of insufficientbandwidth. QoE is expected to be bad for bandwidths of 180 Kbit/s or less.

29

Page 38: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

20 40 60 80 100emulated delay in ms

0

50

100

150

200

250

dela

y in m

s

emulated delay

ping methodcall method

(a) parameter: delay

5 10 15 20 25emulated PDV in %

0

20

40

60

80

100

120

140

dela

y in m

s

emulated PDV

ping methodcall method

(b) parameter: PDV

1 2 3 4 5emulated packet loss in %

0

50

100

150

200

dela

y in m

s

emulated packet loss

ping methodcall method

(c) parameter: packet loss

200 180 160 140emulated bandwidth in Kbit/s

0

100

200

300

400

500

dela

y in m

s

emulated bandwidth

ping methodcall method

(d) parameter: bandwidth

Figure 11: CONVERSATION delays: Comparing ping method and call method (TCP only)

6.3 Evaluation of the recorded calls

The experiments on the CONVERSATION layer for subjective QoE assessment as de-scribed in Section 2 were done separately. Of each experiment two recordings were as-sessed in order to determine QoE tendencies. The audio file (reference audio) used was apoem recorded in a studio by a professional speaker. At the target peer one minute of thecall was recorded.

In a first evaluation four kinds of behaviour was observed. Some recordings had veryshort artifacts, distributed over the whole duration of the recording. These, if not occur-ring too often, left the speech understandable (as in every word could be understood).Other recordings showed longer silence periods up to roughly 3 seconds. This lead to fourdisturbance categories to be examined:

1. up to 5 artefacts of < 1s: Every word could be understood, this might still be asatisfying QoE for many users

30

Page 39: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

2. up to 20 artefacts of < 1s: Almost all words could be understood, but theartefacts occur to often to provide a satisfying QoE

3. up to 5 silence periods of < 5s: Words were left out, not a satisfying QoE

4. more artefacts / silence periods: The disturbances occur to often to understandthe speech content

Table 5 show the assessment results. It is obvious that only very few recordings fallinto the first category. In the delay category only a UDP-only experiment falls into thiscategoriy. The bandwidth category shows that with the same delay and even a lowerbandwidth TCP may perform similarly, though. Thus without assessing a greater amountof recordings it cannot be concluded, whether UDP or TCP performs better at low delays.

Type of disturbanceup to 5 arte-facts of < 1s

up to 5 silenceperiods of < 5s

up to 20 silenceperiods of < 1s

more silenceperiods

dela

y

0 U T1 U T2 T, U3 T, U4 T, U

PD

V

0 T, U1 T, U2 T, U3 T U4 T U

pack

et

loss 0 U T

1 U T2 T, U3 T, U4 T, U

ban

dw

idth 3 T U

7 T, U8 T, U9 T, U

Table 5: Subjective QoE assessment, T: TCP-only, U: UDP-only; the serial numbers correspond to thosein the experiment IDs (see Table 2)

A low packet loss rate (1 or 2%) seems to have less negative effects, when UDP is used.This makes sense as TCP reliability features will increase the delay as shown in Section4.3.2.

For emulated PDV all recordings contain at most 5 silence periods, for two of them atthe highest emulated PDV (20 and 25%) show even small artefacts (first category). ThusPDV seems to affect QoE the least.

In general it can be said that bad QoE, that is more than 20 artefacts of less than1 second or more than 5 silence periods of more than 5 seconds, will definitely occur fordelays of 60 ms or more, for packet loss of 3% and for bandwidths of 180 Kbit/s or less.

31

Page 40: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

7 GNUnet optimization

As shown in Section 6.1.3 an optimization with estimated big effect is avoiding callingthe function GNUNET CRYPTO ecdhe key get public during encryption for each message.Instead it should only be called once a Diffie-Hellman ratchet step was done and storedfor future messages. On the virtual machines this would save 18.6% (4.3 ms) of the overallmouth-to-ear delay.

Moreover a very important task left to future work is determining the GNUnet imple-mentation details that cause the extreme outliers described throughout Section 6 and findmeasures to mitigate the outliers.

Another optimization measure would be to implement the per-packet RELIABLE /UNRELIABLE transport for CADET. This would make it possible to send audio packetsunreliably while continuing to send control packets reliably without the extra implemen-tation overhead of a second CADET channel. A task linked to this would be to implementa way for CADET to influence the underlying transport selection. Currently the RELI-ABLE / UNRELIABLE option in the CADET API only enables or disables CADET’sreliability mechanisms but has no effect on whether ATS selects an unreliable (UDP) or areliable transport (TCP/HTTP, etc.). An application should be enabled to pass a prefer-ence about its reliability and performance requirements to ATS through the API. In theATS API 20 a function for expressing performance preferences already exists and could beextended.

20https://gnunet.org/doxygen/d8/d82/group__ats.html

32

Page 41: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

8 Conclusion

In this thesis delays were measured on the four GNUnet layers the voice applicationGNUnet conversation employs. The fully automated measurements were done under dif-ferent network conditions: A network emulator was used to vary the metrics delay, packetdelay variation, packet loss and bandwidth. GNUnet’s services and command-line toolswere extended to provide measurement features. The security architecture of GNUnetrequired the measurement of encryption and decryption delays on the layers CORE andCADET. Delay caused by the audio codec was measured on the CONVERSATION layer.

Audio recordings were done in parallel in all experiments that involved CONVERSA-TION calls. Separate audio recordings were done for subjective QoE assessment.

The evaluation of the measured delays showed, that on average GNUnet conversationcauses 23 ms of mouth-to-ear delay on top of existing network delay, with otherwiseideal network conditions, that is, a sufficient bandwidth and no jitter or packet loss.In this case the largest part (approx. 60%) is caused by CADET. CADET’s delay ismostly encryption and decryption delay (Double-Ratchet cryptography). We were able toshow that optimization is possible in the encryption part of this delay by not calling theexpensive function GNUNET CRYPTO ecdhe key get public for every message. On systemswith a performance similar to the machines used this would save more than 18% of themouth-to-ear delay most of the time.

Although for increasing delay at the underlying network layer the average delays atthe GNUnet layers were only increased by a constant and for increasing loss of IP packetsonly a slight delay increase could be measured (caused by TCP’s and CADET’s reliabilitymechanisms), the subjective QoE assessment mostly showed bad QoE for typical networkconditions. The reasons are extreme outliers in the order of 1 second occurring in manymeasurements. The GNUnet implementation details responsible for this are yet to bedetermined.

Recommendations for good QoE with the current CONVERSATION implementationcould be determined: CONVERSATION cannot provide good QoE if the delay to theother end is 60 ms or more or the available bandwidth is below 200 Kbit/s. Furthermoregood QoE could only be observed with a packet loss rate of 1% or less.

Important future work includes analyzing CONVERSATION’s behaviour in differentnetwork topologies, such as routes over multiple GNUnet peers or parallel routes withdifferent network conditions. Examining the connection establishment procedure is im-portant for a an extensive QoE analysis too. A task not directly related to this thesis,but which should not be underestimated is to improve CONVERSATION’s user interfaces(command-line and graphical) so secure, distributed voice communication finally becomesusable.

33

Page 42: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

References

[1] UN General Assembly. “Universal declaration of human rights, art. 12”. In: UNGeneral Assembly (1948).

[2] Salman A Baset and Henning Schulzrinne. “An analysis of the skype peer-to-peerinternet telephony protocol”. In: arXiv preprint cs/0412017 (2004).

[3] Jan A Bergstra and CA Middelburg. “ITU-T Recommendation G. 107: The E-Model,a computational model for use in transmission planning”. In: (2003).

[4] Daniel J Bernstein et al. “High-speed high-security signatures”. In: Journal of Cryp-tographic Engineering (2012), pp. 1–13.

[5] Wlodzimierz Bielecki and Dariusz Burak. “Parallelization of Standard Modes ofOperation for Symmetric Key Block Ciphers”. In: Biometrics, Computer SecuritySystems and Artificial Intelligence Applications. Springer, 2006, pp. 101–110.

[6] Peter Bright. Skype finalizes its move to the cloud, ignores the elephant in the room.url: http://arstechnica.com/information- technology/2016/07/skype-

finalizes-its-move-to-the-cloud-ignores-the-elephant-in-the-room

(visited on 2016-10-27).

[7] Jonathan Davidson et al. Voice over IP Fundamentals (2nd Edition) (Fundamen-tals). 2nd ed. Cisco Press, 2006. Chap. 7. isbn: 1587052571.

[8] Morris Dworkin. Recommendation for block cipher modes of operation. methods andtechniques. Tech. rep. DTIC Document, 2001.

[9] Nathan S Evans and Christian Grothoff. “R5n: Randomized recursive routing forrestricted-route networks”. In: Network and System Security (NSS), 2011 5th Inter-national Conference on. IEEE. 2011, pp. 316–321.

[10] GNUnet. url: https://gnunet.org (visited on 2016-10-27).

[11] Christian Grothoff, Bart Polot, and Matthias Wachs. A Tutorial for GNUnet 0.10.x(C version). url: https://gnunet.org/svn/gnunet/doc/gnunet-c-tutorial.pdf (visited on 2017-06-23).

[12] Stephen Hemminger et al. “Network emulation with NetEm”. In: Linux conf au.2005, pp. 18–23.

[13] Rec ITU-T and I Recommend. “G. 114”. In: One-way transmission time 18 (2000).

[14] P ITU-T RECOMMENDATION. “Subjective video quality assessment methods formultimedia applications”. In: (1999).

[15] Don Johnson, Alfred Menezes, and Scott Vanstone. “The elliptic curve digital sig-nature algorithm (ECDSA)”. In: International journal of information security 1.1(2001), pp. 36–63.

[16] Ewen MacAskill et al. GCHQ intercepted foreign politicians’ communications atG20 summits. url: https://www.theguardian.com/uk/2013/jun/16/gchq-intercepted-communications-g20-summits (visited on 2017-05-30).

[17] Moxie Marlinspike and Trevor Perrin. The double ratchet algorithm. 2016.

[18] Morgan Marquis-Boire, Glenn Greenwald, and Micah Lee. XKeyScore - NSA’s Googlefor the World’s Private Communications. url: https://theintercept.com/2015/07/01/nsas-google-worlds-private-communications/ (visited on 2017-05-30).

[19] Muhammad Amir Mehmood. “Impact of network effects on application quality”. In:(2012).

Page 43: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

[20] netem (linux network emulator). url: https : / / wiki . linuxfoundation . org /

networking/netem (visited on 2016-10-27).

[21] Laura Poitras, Marcel Rosenbach, and Holger Stark. GCHQ and NSA Targeted Pri-vate German Companies and Merkel. url: http://www.spiegel.de/international/germany/gchq-and-nsa-targeted-private-german-companies-a-961444.html

(visited on 2017-05-30).

[22] Bartlomiej Polot and Christian Grothoff. “Cadet: Confidential ad-hoc decentralizedend-to-end transport”. In: Ad Hoc Networking Workshop (MED-HOC-NET), 201413th Annual Mediterranean. IEEE. 2014, pp. 71–78.

[23] Martin Schanzenbach. “Design and Implementation of a Censorship Resistant andFully Decentralized Name System”. MA thesis. TU Munchen, 2012.

[24] Bruce Schneier. “Metadata= surveillance”. In: IEEE Security & Privacy 12.2 (2014),pp. 84–84.

[25] The Linux kernel 3.16. url: https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.16.44.tar.xz (visited on 2017-06-24).

[26] Jean-Marc Valin, Koen Vos, and T Terriberry. RFC 6716. Definition of the Opusaudio codec. Tech. rep. 2012.

[27] Matthias Wachs. GNUnet’s HOSTLIST subsystem. url: https://gnunet.org/gnunets-hostlist-subsystem (visited on 2017-06-23).

[28] Charles V Wright et al. “Spot me if you can: Uncovering spoken phrases in encryptedVoIP conversations”. In: Security and Privacy, 2008. SP 2008. IEEE Symposium on.IEEE. 2008, pp. 35–49.

Page 44: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

A GNUnet configuration used for measurements

1 [arm]

2 SYSTEM ONLY = NO

3 USER ONLY = NO

45 [transport]

6 PLUGINS = tcp

7 # PLUGINS = udp

8 # PLUGINS = tcp udp

910 [peerinfo]

11 USE INCLUDED HELLOS = NO

1213 [transport-udp]

14 BROADCAST = NO

1516 [hostlist]

17 AUTOSTART = NO

18 FORCESTART = NO

1920 [fs]

21 AUTOSTART = NO

22 FORCESTART = NO

2324 [nat]

25 ENABLE UPNP = NO

2627 [nse]

28 AUTOSTART = NO

29 FORCESTART = NO

3031 [revocation]

32 AUTOSTART = NO

33 FORCESTART = NO

3435 [set]

36 AUTOSTART = NO

37 FORCESTART = NO

3839 [vpn]

40 AUTOSTART = NO

41 FORCESTART = NO

4243 [PATHS]

44 GNUNET HOME = ./test

4546 [conversation]

47 LINE = 2

Listing 9: The GNUnet configuration without restricted transport (for UDP-only or TCP-only uncomment the respective line)

Page 45: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

B Usage of the measurement scripts

1 Usage: mc.py [options]

23 Options:-

4 h, --help show this help message and exit-

5 c CONFIG , --config=CONFIG

6 config file path-

7 r, --reinstall-gnunet

8 push local gnunet changes to the workers and initiate

9 rebuild / reinstall-

10 m, --manual configure and start the peers and shape the network as

11 described in the given experiment file-

12 e EXPERIMENT , --experiment=EXPERIMENT

13 configure and start the peers and conduct the

14 experiment discribed in the given file-

15 n NUMBER , --number=NUMBER

16 run the experiment n times-

17 t TRANSPORT , --transport=TRANSPORT

18 configure gnunet to use the specified transport

19 protocol (tcp/udp) only-

20 w TIMEOUT , --timeout=TIMEOUT

21 configure the timeout for one experiment , default: 600

Listing 10: Usage of the measurement controller script

1 usage: mw.py [-h]

2 {call ,experiment ,init-gnunet ,shutdown-gnunet ,set-workers ,update-gnunet ,record-conversation ,unshape}

3 ...

45 positional arguments:

6 {call ,experiment ,init-gnunet ,shutdown-gnunet ,set-workers ,update-gnunet ,record-conversation ,unshape}

7 call call a GNUnet peer using conversation

8 experiment start an experiment

9 init-gnunet start GNUnet with the config file from the environment

10 shutdown-gnunet stop gnunet

11 set-workers store information about workers

12 update-gnunet recompile and reinstall gnunet if changes exist

13 record-conversation

14 start conversation with --auto-accept and record to

15 output.wav as soon as the call is accepted

16 unshape remove all network shaping

1718 optional arguments:-

19 h, --help show this help message and exit

Listing 11: Usage of the measurement worker script

C Output files

GNUnet component Output location Descriptiongnunet-conversation conversation rtt ping.csv CONVERSATION RTT values (ping method)CONVERSATION service conversation rtt call.csv CONVERSATION RTT values (call method)gnunet-helper-audio-record conversation encode delay.csv OPUS encode delaygnunet-helper-audio-playback conversation decode delay.csv OPUS decode delaygnunet-cadet stdout CADET RTT valuesCADET service cadet encryption delay.csv double ratchet encryption delay

cadet decryption delay.csv double ratchet decryption delaygnunet-core stdout CORE RTT valuesCORE service core encryption delay.csv OTR encryption delay

core decryption delay.csv OTR decryption delaygnunet-transport stdout TRANSPORT RTT values

Table 6: The measured delays are either printed to stdout or written to a CSV file (filenamecurrently hardcoded); the delays are logged in microseconds, lost packets are logged as -1

Page 46: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

D GNUnet command-line tools

1 gnunet-transport

2 Direct access to transport service.

3 Arguments mandatory for long options are also mandatory for short options.-

4 a, --all print information for all peers (instead of only

5 connected peers)-

6 b, --benchmark measure how fast we are receiving data from all

7 peers (until CTRL-C)-

8 c, --config=FILENAME use configuration file FILENAME-

9 D, --disconnect disconnect from a peer

10 -E, --echo activate echo mode-

11 e, --events provide information about all connects and

12 disconnect events (continuously)-

13 h, --help print this help-

14 i, --information provide information about all current connections

15 (once)-

16 L, --log=LOGLEVEL configure logging to use LOGLEVEL-

17 l, --logfile=FILENAME configure logging to write logs to FILENAME-

18 m, --monitor provide information about all current connections

19 (continuously)

20 -N, --number=NUMBER number of RTT measurements-

21 n, --numeric do not resolve hostnames-

22 P, --plugins monitor plugin sessions-

23 p, --peer=PEER peer identity

24 -r, --measure-rtt measure rount-trip time by sending packets to an

25 echo-mode enabled peer-

26 s, --send send data for benchmarking to the other peer

27 (until CTRL-C)-

28 V, --verbose be verbose-

29 v, --version print the version number

30 -w, --timeout=SECONDS timeout for each RTT measurement

31 Report bugs to [email protected].

32 GNUnet home page: http ://www.gnu.org/s/gnunet/

33 General help using GNU software: http :// www.gnu.org/gethelp/

Listing 12: gnunet-transport command-line options, newly-implemented options in red

1 gnunet-core

2 Print information about connected peers.

3 Arguments mandatory for long options are also mandatory for short options.-

4 c, --config=FILENAME use configuration file FILENAME

5 -e, --echo activate echo mode-

6 h, --help print this help-

7 L, --log=LOGLEVEL configure logging to use LOGLEVEL-

8 l, --logfile=FILENAME configure logging to write logs to FILENAME-

9 m, --monitor provide information about all current connections

10 (continuously)

11 -n, --count=COUNT number of RTT measurements

12 -p, --peer=PEER peer identity

13 -r, --measure-rtt measure round-trip time by sending packets to an

14 echo-mode enabled peer-

15 v, --version print the version number

16 -w, --timeout=SECONDS timeout for each RTT measurement

17 Report bugs to [email protected].

18 GNUnet home page: http ://www.gnu.org/s/gnunet/

19 General help using GNU software: http :// www.gnu.org/gethelp/

Listing 13: gnunet-core command-line options, newly-implemented options in red

Page 47: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist

1 gnunet-cadet (OPTIONS | PEER ID SHARED SECRET)

2 Create tunnels and retrieve info about CADET ’s status.

3 Arguments mandatory for long options are also mandatory for short options.-

4 C, --connection=CONNECTION ID

5 Provide information about a particular connection-

6 c, --config=FILENAME use configuration file FILENAME-

7 d, --dump Dump debug information to STDERR-

8 e, --echo Activate echo mode-

9 h, --help print this help-

10 L, --log=LOGLEVEL configure logging to use LOGLEVEL-

11 l, --logfile=FILENAME configure logging to write logs to FILENAME

12 -n, --count=COUNT number of RTT measurements-

13 o, --open-port=SHARED SECRET

14 Listen for connections using a shared secret

15 among sender and recipient-

16 P, --peers Provide information about all peers-

17 p, --peer=PEER ID Provide information about a patricular peer

18 -r, --measure-rtt Active RTT measurements-

19 T, --tunnels Provide information about all tunnels-

20 t, --tunnel=TUNNEL ID Provide information about a particular tunnel-

21 v, --version print the version number

22 -w, --timeout=SECONDS timeout for each RTT measurement

23 Report bugs to [email protected].

24 GNUnet home page: http ://www.gnu.org/s/gnunet/

25 General help using GNU software: http :// www.gnu.org/gethelp/

Listing 14: gnunet-cadet command-line options, newly-implemented options in red

1 gnunet-conversation

2 Enables having a conversation with other GNUnet users.

3 Arguments mandatory for long options are also mandatory for short options.

4 -a, --auto-accept automatically accepts all incoming calls (for

5 measurement purposes)-

6 c, --config=FILENAME use configuration file FILENAME

7 -E, --echo activate echo mode-

8 e, --ego=NAME sets the NAME of the ego to use for the phone

9 (and name resolution)-

10 h, --help print this help-

11 L, --log=LOGLEVEL configure logging to use LOGLEVEL-

12 l, --logfile=FILENAME configure logging to write logs to FILENAME

13 -n, --count=COUNT number off RTT measurements-

14 p, --phone=LINE sets the LINE to use for the phone

15 -r, --measure-rtt activate RTT measurement-

16 v, --version print the version number

17 -w, --timeout=SECONDS timeout for each RTT measurement

18 Report bugs to [email protected].

19 GNUnet home page: http ://www.gnu.org/s/gnunet/

20 General help using GNU software: http :// www.gnu.org/gethelp/

Listing 15: gnunet-conversation command-line options, newly-implemented options in red

Page 48: Improving Voice over GNUnet · durch Kryptographie entstand. Es konnte nachgewisen werden, dass eine Optimierung des Verschlusselungs-Mo duls und anderer Komponenten m oglich ist