Big Seven Crypto Study

This Wikibook is the electronical resource of the following open source study and provides the option for editors to add additions to the current revision status V 1.1:

Adams, David / Maier, Ann-Kathrin (2016): BIG SEVEN Study, open source crypto-messengers to be compared - or: Comprehensive Confidentiality Review & Audit of GoldBug, Encrypting E-Mail-Client & Secure Instant Messenger, Descriptions, tests and analysis reviews of 20 functions of the application GoldBug based on the essential fields and methods of evaluation of the 8 major international audit manuals for IT security investigations including 38 figures and 87 tables., URL: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf - English / German Language, Version 1.1, 305 pages, June 2016 (ISBN: DNB 110368003X - 2016B14779)

Another contribution in the crypto-discussion: The two security researchers David Adams (Tokyo) and Ann-Kathrin Maier (Munich), who examined in their BIG SEVEN study seven well-known encryption applications for e-mail and instant messaging out of the open source area, performed then a deeper IT-audit for the acquainted software solution GoldBug.sf.net. The audit took into account the essential criteria, study fields and methods on the basis of eight international IT-audit manuals and was carried out in 20 dimensions. Security researcher David Adams from Tokyo about the published BIG SEVEN CRYPTO-study: "We looked at the seven major open source programs for encrypted online-communication and identified ten trends in the Crypto-Messaging area. One of the important trends is the feature, that the users should be able to define an so-called end-to-end encrypting password by themselfs manually". The software "GoldBug - email client and instant messenger" here was ahead with excellent results and is not only very trustworthy and compliant to international IT-audit manuals and safety standards, GoldBug also scores in comparison and in the evaluation of the single functions in much greater detail than the other comparable open source crypto messenger. Co-author of the study Ann-Kathrin Maier from Munich confirms: "We have then our Messenger study deepened with a detailed audit of the crypto-program GoldBug, which received excellent results for encrypted email and secure online chat. By our code-reviews we can confirm the trustworthiness of this open source encryption in GoldBug." Numerous details have been analyzed by various methods, compared and also strategically evaluated by the two authors regarding the current encryption discussions. The comparatively studied applications include CryptoCat, GoldBug, OTR-XMPP clients such as Pidgin with the OTR-plugin, RetroShare and Signal, Surespot and Tox.

EXECUTIVE SUMMARY: HOTSPOTS FOR THE QUICK READING

"Confidentiality Review & Audit of GoldBug - Encrypting E-Mail-Client & Secure Instant Messenger" - Below the main points of the present study are summarized for an Executive Summary.

The GoldBug Messenger is an email client as well as an instant chat messenger that encrypts all information that is transferred and stored. It uses the Qt framework, a toolkit which is very portable.

Numerous functions complement the two basic functions of chat and email as: p2p web search in a URL database, file transfers, group chat on IRC style - as well as a RSS reader is functional, as well as other tools for encrypting text (Rosetta CryptoPad) or files (Fileencryptor) or the transport of keys are implemented (as the function Echo Publik-Key Sharing (EPCs), Repleo, Buzz, MELODICA for Geminis and Instant Perfect Forward Secrecy (IPFS)).

Thus, the basic needs of Internet users for communication, file sharing and search of information in the web are addressed with this solution for encryption. In addition there is also an open source chat-server and p2p email mailbox function available, so that users can operate their own technology in decentralized structures and not have to depend on third parties.

GoldBug also offers both encrypted, either email and chat within a single application; has an encrypted p2p web search implementation, and technically far more unique innovations such as chat over traditional email server (such as IMAP or POP3 through the POPTASTIC function) or addresses by means of the EPKS function the key exchange problem very innovative - and thus minimizes the risks of otherwise usual key servers. If someone wants to exchange with a new person contact details such as email address or phone number, within the EPKS function simply a password can be named orally, and then on a common server-room the keys are exchanged. Simple words instead of numbers or IMAP domains are sufficient.

The fundamental echo protocol also has a special protection against the collection of metadata in network analysis.

GoldBug is one of the few applications - if not currently even the only client next to the integrated kernel architecture Spot-On - which encrypts the message with the echo protocol not only multiple and/or hybrid, but has - in addition to the normally used encryption algorithm RSA - also implemented further algorithms: ElGamal and: NTRU, which is particularly regarded as resistant against quantum computing.

According to the official NIST technology assessment, RSA applies since 02/2016 no longer as safe and therefore is regarded as broken or insecure (see NISTIR 8105, 2016), so that GoldBug within a comparison with other messenger clients is far ahead of our time or other encryption solutions through its multi-encryption options.

Also in the quantum computing era GoldBug continues to provide confidentiality for encrypted chat and email.

In this audit here the GoldBug Messenger was therefore examined in 20 dimensions based on the essential criteria, study fields and methods on the basis of eight international IT audit manuals.

Relevant risks have not been found after the audit of the GoldBug Communication Suite and our suggestions only relate to an informational status, for example, when it comes to strengthening the safe handling of the user with encrypted technologies on the basis of the detailed manual, e.g. as it could be complemented with updated screenshots or video tutorials.

Numerous strengths in the individual functions of the application could have also been pointed out in the following evaluation analysis within this report.

In the overall view a very high confidentiality and a very high security approach of the Communication Suite GoldBug are to be stated. We have found no complaints that would allow an assumption to the contrary.

The Messenger GoldBug is fully compliant and conform to the available sets of rules, regulations and standards. It can be considered safe and secure in the sense of trustworthyness.

The programming shows very high quality standards.

The audit project has been planned considering time and structure, and includes a comprehensive research to identify all currently relevant open source Crypto-Messenger for chat: For that, a common denominator of five lists from well known Internet portals for cryptologic applications has been built (comp. chapter 2).

Within this audit the following investigated applications are also included for an indicative comparison: CryptoCat, GoldBug, OTR-XMPP clients such as Pidgin with the OTR plugin, RetroShare and Signal, Surespot and Tox, which have proved out of our analysis of 52 open source, encrypted solutions as so called "BIG SEVEN" for an instant messaging context, that means, they belong to the truly open source solutions for encryption, in which also the instant messaging server is open source or the license allows a foreign entity further development.

Non-open-source instant messaging and chat server applications, as well as applications that are only capable of email encryption (for example, according to PGP / GPG) (but not over chat) or have not released any stable version, were not considered.

The numerous XMPP-clients that use all the OTR-plugin for encryption, were grouped in accordance to the entry "OTR-XMPP", of which Pidgin certainly may be regarded as one of the well-known representatives.

The methods of investigation were derived from the eight international standard IT audit manuals, which were then - with this multiple viewpoints within in the 20 audit dimensions - referred to the GoldBug application.

These audit dimensions were also included and indicative reviewed in the context of the further Messengers (comp. Chapter 3).

If you compare and review the elaboration of the security features of GoldBug within the 20 investigated individual dimensions - referring to the international IT audit manuals - with the implementations within the context of the other open source BIG SEVEN Crypto-Messengers, then you find for GoldBug Messenger a scoring according the documented method in 20 audit dimensions, which is twice as high as in other comparable open source messengers for encryption (compare in detail chapter 4 as well as the corresponding graphic at the end of the study).

As a recommendation for all seven Crypto Messengers respective for the open source encrypted applications in total, the following suggestions can be expressed: that the encrypting functions should be better documented, that scientific analysis should always include function-related comparisons also to other messengers in these features, and that the newer landscape of encrypting applications needs more practical and research reports, which should include the perspectives of bloggers and software portals and other interdisciplinary experts in particular - and should not only come from the analysts of cryptologic or mathematical disciplines (compare also the references in chapter 5). From this study, ten trends in the Crypto-messaging area can emerge, which are described summarized at the end of the study with an infographic.

To build an own opinion about encryption methods and applications, to discuss with other friends and then in particular to document your experience and findings, is a duty of every citizen, who is engaged for the structural necessity of the protection of private communications and for the fundamental principles of freedom in the sense of the absence of excessive surveillance and control.

The now following two chapters 2 and 3 explain the derivation and conduction of this audit in the various review fields, and include also per each chapter a reference to the contextual indications of other Messengers.

INTRODUCTION

For the audit of the application "GoldBug - Encrypting E-Mail Client and Secure Instant Messenger" the follwing text describes, how the analytical procedure for this review and audit has been derived.

The objective is to examine both, the application as a whole, as well as selected functions of the software in depth, so that the usual dimensions, methods and fields of IT audits are taken into account in width.

For that eight major international audit manuals have been compared in their respective key issues and a common denominator of these IT audit manuals will now be referred to the application GoldBug. After a brief introduction to the Communication Suite GoldBug we first state our motivation, why to work out free of charge and outside of our professional context an audit in our sparetime for GoldBug: We would like to contribute, that encrypted solutions can be analyzed and compared more extensively. Open source crypto applications are particularly at our hearts. Then it comes to the investigation scope and the objectives of the audit. The confidentiality and the functioning of the, for many years now existing software should be analyzed with this audit in greater detail.

We collect here no status on seclusion, but know that first, further investigation fields and methods are advised well in an increased viewing angle, and secondly, that any study field with further detail and even greater comparative study can be continued including other applications.

In preparation, we have referred not only to the methods, we have learned professionally and used in practice, but deliberately wanted also to create an extensive documentation, how an audit framework could be formed out of standard references of the eight major audit manuals, and which questions we are deriving out of this for GoldBug. We hope to find with that a common denominator of the standards, which can also refer to further audits in the future of other software applications in the field of encryption.

We provide our report as open source texts to all readers, so it remains also for further revisions editable by everyone and also the texts of the report can be hosted by everyone on the web. Therefore, we will provide our audit report in the end to the developers of the projects of GoldBug and the included architecture Spot-On, because it is senseful in this contextual environment of the project, to make the content of the report available for the users of GoldBug for their further usage.

To merge the field of cryptology and the area of software audits, causes not only to consider the common standards of the audit manuals, but to highlight also specific comments from this intersection, which applied to us for this audit as well as a standard, or could be seen as an important principle for us. Also these findings we illustrate continuing further.

Planning and conduction are summarized in a documented time- and project-plan at the end of our chapter here. In particular, our supporters we provide then again explicitly cordial thanks for their help.

***

The future of encryption needs role models to explore

Who wants to encrypt communication for the internet, remembers surely one or two or even more terms or tools, which refer to options to encrypt.

Since 2013 and the publications of Edward Snowden regarding massive surveillance of communication over the Internet and also the monitoring options of mobile smart phones, encryption has proven to be not only one ideal way for privacy and human rights, but it also has shown business enterprises in the use of Internet and mobile technology, how much the economic success, not only of individual companies, but the entire economies, depend on functional and unbroken encryption.

It is also evident, that traditional methods of and tools for encryption need to be subjected in terms of a revision, and you have in some parts also to say urgently good-bye to these! Hence, passwords and keys have been created longer and/or refreshed more frequently, web-browsers and search-engines have announced their intention to support no longer or just in a limited way unencrypted websites: they are to be transferred to a safe standard, as we know it from online banking.

Then it was also discussed that the new mobile communication forms of email and chat increasingly merge with each other. The end of the popular e-mail encryption with PGP (Pretty Good Privacy) was pronounced (compare for example Schmidt 2014), because it was regarded first as too complicated and in addition it also primarily refers within the clients only to e-mail.

At the same time since 2013 numerous classic and mobile Messengers have been newly developed or further developed with natively, from the outset integrated, encryption. Other Messengers tried encrypting more or less perfect and practicable with plugin solutions as a retrofit. Also companies with financial gain interest have brought non-open source encryption applications on the market, which partly shoot as mushrooms and are marketed.

Goal definition:

In this environment, we have decided, to also contribute to the consideration of an open-source
communications solution, that includes both if possible, e-mail and chat, and can encrypt
the referring communication.


We have created in a first step an overview of open source applications for encryption, as the following explanations below also document.

The GoldBug Communication Suite is known to us in this context since 2013 as a good practice model, because it is open source, converts encryption natively and some initial reviews of various analysts, experts and bloggers are already known today. Likewise, it also offers highly innovative features in the field of encryption of email and chat. And: It is one of the few applications, that encrypts a message multiple times.

GoldBug is thus an e-mail client as well as a chat messenger that fundamentally offers for all functions encryption. With the development of newer technologies, the encryption of both, e-mail and chat, within one client can be seen as a new paradigm, so that a modern application, respective an encryption procedure, should offer both. Therefore we have not focused here on encryption or applications, which only encrypt email and do not contain a chat feature. Furthermore, with GoldBug a file can be encrypted or sent to a friend in an encrypted way.

Also a group chat can be performed. Finally, the application also contains an URL database that is shared with others in a peer-to-peer style and thus an encrypted web search is created for the user. This is especially interesting in restrictive environments where information and autonomous learning through the reception of information is censored (such as in China).

GoldBug and other applications, respectively the functions contained therein, can offer therefore for the future important models for encryption of our communication and for digital learning resources, if we explore, use, check and develop open source today. Due to the cryptologic functionality GoldBug was for us and is an ideal application, in order to examine it more extensively as model and in its functions.

***

Inventory taking & Motivation: Why we like open source

The motivation for the execution of a confidentiality review and audit based on the essential foundations of the established manuals for an IT audit is for us as authors based on the fact, that we, first, as a private user - considering the wealth of applications and options for encryption of private communications available on the market - wanted provide us an own overview, and secondly, wanted to create a depth analysis of one open source application. The numerous Messenger lists that exist on the Internet or in the Wikipedia in many places, are very extensive in part, but not all applications listed there have encryption!

The year 2013, after the publication of the fact that all the major part of Internet communication of all citizens is monitored by interested parties, providers and administrators can be considered also for us as a turning point towards the necessary recognition, that Internet communication has to be encrypted in the standard. It motivated us, to find out, with which tool this ideally can be done right.

Even though there are numerous applications for encryption, and a few dedicated lists or overview comparisons of encrypted communications solutions, many are though not open source, or focus only on one special platform such as mobile phones or a particular operating system - or refer still to the traditional duality of email or chat and do not develop a solution that ideally considers both. The variety appears to consumers often as confusing.

In particular, the aspect of open source plays for us as auditors and end users a decisive role. Only when the application is open source, the source code can be viewed by all, can be evaluated and improved. In the source code closed crypto applications require confidence in the provider as the sole quality characteristic and drops out for end-users, at least for us, therefore completely.

It is an attitude of being able to find out for yourself and check yourself, how the application works - and not to depend on confidence-building measures of third parties. The sovereignity of the citizen begins for cryptography with open source. The option of being able to look into the source yourself is so essential as to be able to vote with your own voice or to be allowed to drive a car on your own.

Also it was remarkable to us, that some media lined up the news regarding research and development of cryptography very multiplicative - that means, some projects with financial support of known or unknown sources are repeatedly mentioned in the news and at community events - without including other or open source projects in a substantive review as well. We have therefore decided for the methodological selection, to consider all currently developed messenger applications, that are open source - and based it on five, in the net not unknown portals, which formally or informally list Crypto-Messengers in their wikis.

Here the aim was to carry out an inventory in the first step.

Through further considerations such as the grouping of applications and exclusion of isolated applications, which only encrypt e-mail - but not chat -, it was found that seven open source crypto solutions crystallized. (For the derivation and overview of these seven open source applications see in detail below).

Out of these applications, we then chose the project GoldBug for our review, as this is an open source application, which encrypts e-mail and chat, offers innovative features and in addition has already numerous blog and portal reviews with analyzes from experts, and now may undergo - formally and from a content perspective - further evaluation by this audit in the light of the criteria of established IT audit manuals.

At the same time we did not want to omit the other, alternative and comparable open source messenger and instead - if not in depth, but rather indicative - involve these also in the analysis context of reviews of the functions, processes and the code of GoldBug.

This is therefore not the comparison of two or more messengers, but a broad and in-depth analysis of the GoldBug Messenger, that also includes the further promising proposals of other projects - not as an individual comparison, but as an indicative and certainly to be deepened overview within a good-practice context.

***

Goals & Scope of our Audit of GoldBug Messenger

With regard to the objective and scope of this audit can be stated:

The purpose of this review and audit of the GoldBug Communication Suite is to refer the existing

• Standards for IT security, and therein regularly contained
• methodological principles and processes and also
• content dimensions and criteria

ideally in a comprehensive and exemplary way to the application GoldBug, and analyze and evaluate the program accordingly to identify solutions for security issues.

So shall

• the risk for potential weaknesses be evaluated (vulnerability and risk analysis)
• and in particular suggestions for improvement in these aspects of the described contexts and functions be shown - also as a benefit for other communication applications in general (continuous improvement analysis).

Also the

• designation of the strengths
• and appraisal and recommendation of good practice in comparison to other comparable applications

should, where possible, help to get an overview of possible reductions of vulnerabilities in messengers in general. The following audit frameworks have us then delivered a content width of study fields, dimensions and methods, which we have bundled to a common denominator, and finally referred to the application GoldBug. Our investigation scope therefore was derived from the various audit manuals.

***

Standard references, methods and deducted questions

The policies and action plans proposed by many security experts in the field of IT security are very extensive. Thus, besides the

• ISO / IEC 27001 (see BSI Group 2013) also the
• ISO / IEC 27002 (see ISO 2005) exists and the
• British BS 7799, which is underlying these standards (see Völker 2004).

Then there are the

• security architecture X.800 (CCITT 1991),
• the IT Grundschutz catalogues of BSI (BSI 2005ff, 2013: chap. 1.1.),
• the procedure library ITIL (see Cabinet Office 2011) and
• the ITSEC criteria (see ITSEC 1990).
• Also, the Audit Manual Open Source Security Testing Methodology Manual (OSSTMM) of the Institute for Security and Open Methodologies (ISECOM 2010) provides valuable context clues.

The IT security itself is subdivided often in three core values

• Confidentiality through Encryption: Confidential information must be protected by encryption, for example, against unauthorized disclosure,
• Integrity (Information Security) through Authenticity: correctness, freedom from manipulation and integrity of information systems, IT processes and information. Here, the authenticity is in particular to consider (that is, the authenticity, accountability and credibility of information),
• Availability: services, functions of an IT system or information are at the required time available.

Then security analyzes can contain the following measures:

• Security scans using port scanners like Nmap, sniffers like Wireshark, vulnerability scanners like Nessus and other tools: all vulnerability assessment (VA) products,
• checking the access control in applications and operating systems plays as well a role like

Other methods to determine security vulnerabilities are for example

• Penetration tests: They can form an integral part of an enhanced IT security audit. Here, external attacks (from the Internet) as well as within the local network are simulated. This process is often called "friendly hacking" and the auditor as a "white-hat hacker".
• the concept of assumed expectations or collected information by interviewing users regarding risks and improvements to aspects of social engineering can also provide valuable information as well as analysis of the
• Description of Processes and Functions: They are essential for understanding and proper use of the application.
• Review of Documentation: The documentation provides both developers, auditors and users vital clues to the correct application of the program and its functions as well as references to the programming of these functions. The presence of written documentation has to be recognized as essential for an audit process as well as for a service to users.
• Involvement of other audit reports of other communication programs: it makes sense for an audit to get an understanding of the solutions available at the market and to have an overview of good practice - also to clarify or to generate this understanding. Only in the context of the knowledge - for example, how other applications administer their chat server, manage friends lists or implement methods for forward secrecy - the "State of the Art" can be understood and the extent and quality of the implementation of functions can be traced.
• Data Analysis: Statistical analysis of the data, or the examination of the data with different tools should generally be considered as methods in the IT sector. In regard to encryption this can for example be related to the ciphertext or as well to the plain text - as well it can be referred to other statistical tests for encrypted or to be encrypted data - or to be stored or to be transferred data.
• search engine queries: It is to examine, how confidential and sensitive data can be possibly spotted unnoticed by search engine queries. The range of so-called "security nuggets" ranges generally from private information like credit card numbers, social security numbers and passwords, and files stored like internal auditing reports, password hashes or log files via insecure open services such as OWA, VPN and RDP to the disclosure of numerous exploits and vulnerabilities of related websites (Nessus, sniffers).

The Audit Manual Open Source Security Testing Methodology Manual (OSSTMM) of the Institute for Security and Open Methodologies (ISECOM) differs according to the possible attacks then five categories of security interaction, also called channels (Herzog 2008):

From the good practice we know that

• default settings at hardly configured routers, firewalls, web servers, etc.
• and especially simple, unencrypted and / or default passwords (according to factory setting)

include the most common vulnerabilities (compare e.g. McClure 2008). In order to meet the objectives and dimensions of investigation of these individual manuals, this audit combined analysis of data and relevant documentations with code reviews and analysis of the main functions of the application GoldBug;

These distinctive features, methods and criteria of the above-mentioned IT audit manuals should find all a use case. Thus it was sought in the application GoldBug for functions and test possibilities to apply this range of audit methods with the given functions and code.

As follows, therefore the audit dimension (first column) can be assigned to a core feature in the Messenger GoldBug (second column), and thirdly, formulate a question that should convey in this respect of audit methodology and core function our research question to the application.

Table 01: Referring of methodical audit-dimensions to functions of the programm GoldBug, each with a question for research

Audit-Method /
Audit-Dimension
To be related function
in GoldBug
Question for a test & an investigation #
Confidentiality through encryption Multi-Encryption How can confidentiality be generated by hybrid or multi-encryption? 3.01
Integrity (information security) through authenticity Authenticated E-Mails How is authenticity implemented in the e-mail function in order to ensure information security? 3.02
Availability P2P-HTTPS How is the connection availability ensured over a P2P-HTTPS network connection? 3.03
Security Scan Transferred Ciphertext How can a proof of a transfer of ciphertext and not of plaintext be provided? 3.04
Access Control Login into the App (Method) What are the security features of the two provided login methods and wherein they differ? What security aspects does the built-in virtual keyboard offer? 3.05
Acces to the system Encrypted databases Can an upload of the installation files contribute to an easier access to weaken the encryption? 3.06
Penetrationtest Account-Firewall Is the account function for networking nodes as a firewall stable respectively penetrable? 3.07
Revision of the Documentation Usermanual at wikibooks Covers the manual the essential features of the application? 3.08
Involvement of further audit reports of other communication applications Comparisons with other open source applications What other applications perform a similar function, and how is this comparable in various respects as according to their audit reports? 3.09
Descriptions of processes and functions The example of the data transfer How can the data transmission described as process, analyze and possibly improve considering the Magnet URI standard? 3.10
Descriptions of processes and functions POPTASTIC E-Mail-Client How can the process POPTASTIC be explained, analyzed and, if necessary improved in addition to the echo protocol? 3.11
Data Analysis Encryption Process How can the decryption process be explained, analyzed and improved, if necessary? 3.12
Security Nuggets Key Handling Comparison of the safety of keys and their transmission respectively providing keys by conventional methods e.g. a key server 3.13
Physical Interaction GUI-Kernel-Interaction How is the communication of the kernel with the user interface protected? 3.14
Analog Communication Gemini, Goldbug & Forward Secrecy, Nova How do analog (for example oral) communication or transmission of a symmetric key by the user create more security and what risks can arise here? 3.15
Packet Communication Adaptive Echo-Test How are data packets forwarded in a setting of the adaptive echo? Test of the security of the exclusion of a node from the receipt of data packets. 3.16
Wireless interaction Bluetooth Listener Considers the wireless echo-communication via Bluetooth security aspects? 3.17
Social Interaction SMP: Socialist-Millionaire-Protocol What scenarios are conceivable in a social engineering attack on the Socialist Millionaire Protocol (SMP)? 3.18
Default Settings Default Crypto values for key generation Do the default values for key generation correspond to current security standards? 3.19
Passwords Account-Password Are password-provided accounts securely protected in its firewall function against connecting a user who does not have the account password? 3.20
Files Delivered Files Are the files correct and from which library are they referring from? 3.21

Source: Own referencing.

The research questions raised have been comprehensively and deepened analyzed and evaluated and are summarized on the following pages with their analyzes and assessments. In each section a further detailed scientific study would be possible as documentation. Even the wording of the text-chapters tries to address the summaries in each case also to a reader, who wants to learn more extensively in the field of software programming and cryptography.

The aim of the audit is also to pick up on different audit methods and apply them as examples for the selected application: Every possible viewing angle of an audit method should be applied to the GoldBug Messenger, than just to look through all the functions of the application with only one point of view.

Furthermore, an audit shall always give suggestions to the reader, how to update the found research areas and issues in their own studies in depth (and at a later point of time).

Context embedding: Why other Messengers than my well known Messenger?

The investigations in this broad consideration of methods and numerous functions and processes of GoldBug should also consider the diverse, now available additional encryption applications in terms of a context of comparable applications and in terms of an exchange community of "Good Practice".

Five greater blogs can be found on the Internet with lists of encrypting applications (Messenger):

• The portal "You broke the internet" (YBTI) published a list of more than three dozen encrypting communication tools. 12 of these are open-source applications. The focus of the filter criteria of this portal is here based on e-mail clients, and encryption and anonymization basics (see YBTI 2014).

The first editing of this list took place in February, 2014.

• The German study-group "Arbeitskreis Vorratsdatenspeicherung" (AKV) and the Alliance "Freedom Not Fear" lists in its Wiki - which can be extended by any Internet user - more than 20 communication tools for encryption, of which 12 applications are open source. It is thus a corresponding wiki-list, which is a comprehensive edition by the community connected to the study-group "Arbeitskreis".

Here is value placed on key criteria like: open source - namely the application software as well as the chat server software -, furthermore, if (manual editable) end-to-end encryption is implemented and also the criterion of encryption type and method is underlined. The first editing of this list took place in May, 2014.

• Peter Eckersley of the EFF listed in his list more than 30 communication tools for encryption, of which only 12 are open source. As essential criteria are in the foreground, that the application is open source, that an end-to-end encryption with Forward Secrecy is implemented, and a security audit has been conducted. Unfortunately, the audit reports are not linked and also only a few open source applications are mentioned. The first editing of this list took place in November, 2014.
• Blogger Peng Zhong expanded his list of tools, intended to limit surveillance, within the portal "Prism Break" (PB) since June 2013 continuously. This list also includes encryption tools, 18 are open source. Many of these applications, however, are specified as a separate entry for each operating system, so that, for example, PGP is considered individually as OpenPGP and as GNUPG for each operating system such as Android, Windows, Mac, Linux. In the following they are listed here as a cluster, because they are tools or plug-ins, that do not constitute an own private e-mail client, and also reflect chat only occasionally.
• Also Schneier Blog (SB) has published a list, which we will discuss in detail later.

It turns out that, firstly, many brand names differentiate, because they refer to only one operating system, and secondly, many applications use the same protocol respectively the same encryption method: If we sort all available open source messaging tools and eliminate duplicates from all five lists,

• group XMPP clients and
• PGP tools and
• tools, that require an underlying rooting network like Tor, Gnunet or I2P,

this results in the following summary overview of open-source Crypto-Messenger. Some applications also

• have no release available, so they are in the planning stage or
• are in code-parts then not open source (e.g. for the chat server) or
• open source applications are under a proprietary license so that a fork or an own development of the existing code base is not allowed.

Within this audit, those Messengers should be included as an extended context that

• substantially provide both, chat, as well as possibly e-mail messaging: this means to allow chat or messaging also to offline friends (marked in the table with "Reference 1" chat encryption is not present, such as in some PGP tools) and
• are completely open source (that means also the chat server ("Reference 2a": open source nature of the IM server or certificate server is not the case, such as in Telegram) or
• are not using a proprietary license ("Reference 2b": proprietary license is the case, such as in Silent Phone & Silentext) and
• have published first binary release or are judged as "productive" by the developer or a functioning test server is given ("Reference 3": No productive binary release available or no test server infrastructure exists, is the case for example at Briar or Pond and Jericho Comms).

As additional notes it should be mentioned that the Messenger TextSecure was another name for today's Messenger Signal. And: that Telegram is labeled in some portals as open source, though the Chat server is not open source. Furthermore, that programs like Threema and others are in the media often mentioned, but are also not open source and therefore do not constitute a serious open source alternative and can not be considered further here, because the research-context is intended to refer to only complete open source messenger.

Table 02: 52 Open Source Crypto-Applications & -Tools out of several Blog-Portals

# in
alphabetical order
(OPEN SOURCE)
APPLICATION
YBTI AKV EFF PB SB SOURCE / COMMENTS
URL / Reason for no further consideration as context within this audit:
1 BitChat https://github.com/ TechnitiumSoftware/ BitChatClient - Reference 2a (Server).
2 BitMail http://bitmail.sf.net - Reference 1 (no chat available).
3 Bitmessage https://github.com/ Bitmessage/PyBitmessage - Reference 1.
4 Briar https://code.briarproject.org/akwizgran/briar - Reference 3 (not productive).
5 CryptoCat https://github.com/cryptocat/cryptocat
6 Folpy https://bitbucket.org/folpy/folpy - Reference 1.
7 GoldBug http://goldbug.sf.net/
Security Review Audit within this study
8 GPG for E-Mail
8a APG http://www.thialfihar.org/projects/apg/ Reference 1.
8b Enigmail https://www.enigmail.net Reference 1.
8c GNU Privacy Guard https://www.gnupg.org/ Reference 1.
8d GPG for Android https://github.com/guardianproject/gnupg-for-android Reference 1.
8e Gpg4win http://www.gpg4win.de Reference 1.
8f GPGTools/Suite https://gpgtools.org/ Reference 1.
8g Mailvelope https://www.openkeychain.org Reference 1.
8h OpenKeychain https://www.openkeychain.org Reference 1.
8i + 19 other E-Mail-Apps & Plugins of SB-Portal-List See Footnote 1 in the PDF-Layout-Reference: Due to often Beta or Plugin status counted as one entry.
17 Jericho Comms http://joshua-m-david.github.io/jerichoencryption Reference 3.
18 Mailpile https://github.com/mailpile/Mailpile Reference 1.
19 OTR & XMPP
https://otr.cypherpunks.ca/
19b OTR & BitlBee-Plug in IRC http://bitlbee.org/
19c OTR & Bombus http://bombus-im.org
19d OTR & Coccinella http://coccinella.im
19e OTR & Gajim http://gajim.org
19g OTR & Kontalk http://kontalk.org
19h OTR & Kopete http://kopete.kde.org
19i OTR & MCabber http://mcabber.com
19j OTR & Monal http://monal.im
19k OTR & Pidgin https://otr.cypherpunks.ca/
19l OTR & Profanity Console http://profanity.im
19m OTR & Psi / Psi-Plus https://otr.cypherpunks.ca/
19n OTR & TKabber http://tkabber.jabber.ru
19o ChatSecure https://github.com/guardianproject/ChatSecureAndroid
19p Conversations https://github.com/siacs/Conversations
19q FireFloo QXMPP http://firefloo.sf.net/ Qt-XMPP-Chat-Client
19r Jitsi Ostel https://jitsi.org/
19s SecuXabber https://jitsi.org/
19t Xabber http://www.xabber.com/
39 Pond https://pond.imperialviolet.org – Reference 3
40 RetroShare
http://retroshare.sf.net/
41 Routing Overlay Nets
41a Cables https://github.com/mkdesu/cables Reference 1.
41b Freemail https://freenetproject.org/documentation.html#freemail - Reference 1.
41c I2P-Bote http://i2pbote.i2p.us/ Reference 1.
41d Secushare http://secushare.org/ Reference 1.
41e Ricochet https://ricochet.im/ Reference 1.
41f TorChat http://github.com/prof7bit/TorChat Reference 1.
47 Signal
https://github.com/WhisperSystems/Signal-Android
48 Silent Phone & Text https://github.com/SilentCircle/silent-text-android - Reference 2b (License)
49 Spot-on http://spot-on.sf.net Alternative GUI for GoldBug.
50 SureSpot
https://github.com/surespot
51 Telegram https://github.com/telegramdesktop/tdesktop - Reference 2a (Server)
52 Tox
https://github.com/irungentoo/toxcore
Listed entries of all
common available entries

YBTI
12/52
=23 %
AKV
13/52
=25 %
EFF
11/52
=21 %
PB
20/52
=38 %
SB
51/52
=98 %

It appears from the overview that bloggers often designate only 1/4 or maximum just over a third of all available encrypting and privacy enabling communication tools for encryption for chat and e-mail in the year, 2014. The analysis in Schneier Blog (SB) based on a scientific collection (2016) achieved nearly a full survey for the chat messengers.

The portal YBTI highlights at the end of their list, that their list goes back to a draft of the development group "Open Technology Fund", that also brings out its own secure application, so YBTI enlarged the list by their own development (since the original creator for some reason had no interest in enlarging the list or in giving full transparency). That means possibly that any list creator has "some biased views on the topic, as everyone prefers to maintain their own version of these lists" (YBTI 2014).

As a recommendation from the YBTI index and their published critical remark can therefore be deduced, that further bloggers should also carry out comparative overviews from their own perspective, but

• leave non-open source crypto solutions disregarded
• include comparisons with a reference to all the currently existing open source applications in order to involve in none fact of a limited perspective, a "biased view".

Turning now to the 52 listed Messenger of five known blogs, so remain - after sorting out

• not open source applications
• grouping of brands and operating systems,
• E-mail tools, that support no presence chat
• as well as tools, that require complicated to install routing networks (not necessarily with an increase of encryption) -

only a handful relevant open source Crypto-Messenger. From the above overview thus seven open source communications applications result, that have the feature "chat" and open source encryption:

These we will call BIG SEVEN and reference each indicatively to the audit of a GoldBug function. If this is now subsequently examined whether the applications are developed by volunteer programmers (and not by a company with economic interests) and if they run not only on mobile applications (but classically are also on a laptop or desktop PC as an independent client operational) remain not many comparable applications left: CryptoCat, GoldBug, OTRinXMPP, RetroShare and Tox.

In February 2016 published Bruce Schneier in his blog (Portal SchneierBlog: "SB") a study collection - already carried out in 1999 at the George Washington University - and identified then 856 encryption tools worldwide, that affect both: software as well as hardware, and: proprietary and open source applications. Among these are in the first revision level 67 open source chat applications (Message-SW-Free-OS), 23 open-source e-mail applications (mail SW-Free-OS), and 8 open source applications (multi-SW-free OS ), which are marked with the type of "multi" and unspecified relate to chat and email. Amoung these GoldBug Messenger is also listed.

Taking out the redundant entries, this list adds 14 further messengers to the already found 38 messengers of the other four portals. So, all above mentioned 52 applications of the other portals are also included in this list of the SB-Portal. (For a further referencing regarding these three categories (Multi-SW-Free-OS), (Message-SW-Free-OS) and (Mail-SW-Free-OS) see the Footnote 01: Survey of Encryption Products (Chat / E-Mail / Multi) - SB-Portal-List in the PDF-layout: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf )

If you analyse as in the following table the code uploads in purely quantitative terms (so-called "commits") to each of these BIG SEVEN projects, so arises for each project a lead committer, which accompanied most commits within a development team.

Table 03: Group of the „Big SEVEN“ - to be compared open source Crypto-Messengers

e.g.
APPLIKATION
Main
Committer
Last time
activity of the
Main Committer
average #
of commits
per Year
Win Mac Linux Mobile
Cryptocat arlolra Contributions in the last
year 673 total
Feb 8, 2015 – Feb 8, 2016
673
GoldBug Spot-On Contributions in the last
year 2,445 total
Feb 8, 2015 – Feb 8, 2016
2.445 TBD
OTR+XMPP goldberg N/A N/A
RetroShare csoler Contributions in the given
time: 498 total
Aug 1, 2015 – Feb 8,
2016 (191 days)
951 TBD
Signal moxie0 Contributions in the last
year 986 total
Feb 8, 2015 – Feb 8, 2016
986 browser
based
browser
based
browser
based
SureSpot 2fours Contributions in the last
year 31 total
Feb 8, 2015 – Feb 8, 2016
TBD TBD TBD
Tox irungentoo Contributions in the last
year 946 total
Feb 8, 2015 – Feb 8, 2016
946

Source: GitHub statistic function.

These frequencies of the annual contributions of each main developer are also very limited in significance and only to use indicative, since it can not be clear whether someone contributes code in larger tranches, how much projects they support and if also a financing or leisure activity stands behind. Someone who implements the code contributions both, professionally and as a paid programmer, possibly have more posts than when someone contributes this in his spare time only.

It is here therefore only indicative apparent, that SureSpot has deployed no large code activity in the last period. Also OTR (as well as CryptoCat) code developments are on the back burner respectively the commits are not hosted at Github and remain therefore only estimate in the statistical analyzes. OTR is considered for many years as established and has though not implemented many development perspectives yet.

Signal and Surespot have so far also only mobile applications, respectively allows the browser implementation at Signal indeed a function of the Messenger then on all operating systems, but remains absolutely dependent on a mobile furnished account. A fast browser implementation without own clients to develop for each operating system - that is also reflected then in less code contributions.

Also the qualitative analysis considers not, if anyone has developed a significant innovation, or exchanges with their code commit only a single graphic. And the consideration only of the main developer also hides the additional contributions from the project team, if given.

We have decided to document this analysis, yet to show, that background analyzes should be thought out varied and we at least indicative wish from this analysis, that, e.g., the Surespot development does not fall asleep, and OTR with XMPP as well also is leaving the achieved comfort zone to develop XMPP solutions, that lie beyond plugin risks, missing file transfers & group chats in OTR, and the lack of options at enhanced asynchronous respectively ephemeral keys.

Further, for example, show the team commits e.g. at Retroshare approximately 11 users with more than 5 commits (https://github.com/ csoler / Retroshare / graphs / contributors). In Tox there are 41 users with more than 5 contributions and 147 contributors altogether only for the Tox-Core (https://github.com/ irungentoo / toxcore / graphs / contributors). While it can be assumed that a small team of developers can coordinate the team better, and also quality reviews of the code are better coordinated, for RetroShare one can already speak of an extended team, so the code possibly has numerous styles of personal code writings and hence vulnerabilities or coordinating necessities can reveal.

In contrast, the development of Tox can be indicative rather called promiscuous pool´: everyone may at times install something in the code, which can contribute to high vulnerability and a high need for code reviews.

However, these remain under mostly, when quality management does not come out of a hand of a smaller or in reviews specialized team.

As a result of this research, the wish or the request remains on the multipliers and accompanying community members of the developers, that portals with listings about Crypto-Messengers remove the closed-source applications and develop (or add) especially in detail written reviews in their list of open-source applications - or at least link the existing literature references and audit reports properly.

Ideally there are in the near future portals for Crypto that provide information exclusively on open-source programs for encrypted messaging. Again, the information policy can not be left to only a handful of players, but requires instead analysis and knowledge exchanges of many people. Bloggers should fulfill the encountered state of a lack of transparency for the particular source-open solutions for encrypted communication with light. In regard to further or future developers the wish remains, to support the teams of the existing source-open applications, or - having read this - to develop their own new source-open applications. It also remains to be hoped, that developers come from numerous nations and countries - to reserve the development of Crypto-Apps not only to few nations (see also Schneier et al. 2016).

We cordially recommend auditors, as well as students and scholars, to read more comparative and deeper about these BIG SEVEN applications and/or compare the different functions in particular qualitatively in regard of their relevance for specific problems and issues.

***

References to our further core audit principles

The audit process was thus carried out as described above with regard to international audit standards and, in particular, specific IT-standards, guidelines and principles in order to achieve a comprehensive picture from as many angles. The assessments and conclusions are based on both, the established process models and content areas, as well as on the basis of a comprehensive employment, analyzing and comparing created within these topics - like they were found at the time of conducting the audit. This is not to be understood as a completed process and standard, but should explicitly postulate further research and research needs, in which the following principles of an audit should find a reflection:

• Timeliness: Only when the processes and programming is continuous inspected in regard to their potential susceptibility to faults and weaknesses, but as well with regard to the continuation of the analysis of the found strengths, or by comparative functional analysis with similar applications an updated frame can be continued.
• Source openness: It requires an explicit reference in the audit of encrypted programs, how the handling of open source has to be understood. E.g. programs, offering an open source application, but not considering the IM server as open source, have to be regarded as critical. An auditor should take an own position to the paradigm of the need of the open source nature within cryptologic applications.
• Elaborateness: Audit processes should be oriented to certain minimum standard. The recent audit processes of encrypting software often vary greatly in quality, in the scope and effectiveness and also experience in the media reception often differing perceptions. Because of the need of special knowledge on the one hand and to be able to read programming code and then on the other hand to also have knowledge of encryption procedures, many users even trust the shortest statements of formal confirmation. Individual commitment as an auditor, e.g. for quality, scale and effectiveness, is thus to be assessed reflexively for yourself and to be documented within the audit.
• The financial context: Further transparency is needed to clarify whether the software has been developed commercially and whether the audit was funded commercially (paid Audit). It makes a difference whether it is a private hobby / community project or whether a commercial company is behind it.
• Scientific referencing of learning perspectives: Each audit should describe the findings in detail within the context and also highlight progress and development needs constructively. An auditor is not the parent of the program, but at least he or she is in a role of a mentor, if the auditor is regarded as part of a PDCA learning circle (PDCA = Plan-Do-Check-Act). There should be next to the description of the detected vulnerabilities also a description of the innovative opportunities and the development of the potentials.
• Literature-inclusion: A reader should not rely solely on the results of one review, but also judge according to a loop of a management system (e.g. PDCA, see above), to ensure, that the development team or the reviewer was and is prepared to carry out further analysis, and also in the development and review process is open to learnings and to consider notes of others. A list of references should be accompanied in each case of an audit.
• Inclusion of user manuals & documentation: Further a check should be done, whether there are manuals and technical documentations, and, if these are expanded.
• Identify references to innovations: Applications that allow both, messaging to offline and online contacts, so considering chat and e-mail in one application - as it is also the case with GoldBug - should be tested with high priority (criterion of presence chats in addition to the e-mail function). The auditor should also highlight the references to innovations and underpin further research and development needs.

This list of audit principles for crypto applications describes - beyond the methods of technical analysis - particularly core values, that should be taken into account, and auditors from our point of view should reflect in their reports.

Figure 01: Eight Principles of a Crypto-IT-Audit

Source: Own presentation.

In summary, according to a self-reflection of an auditor therefore as well for this audit can be stated:

The present review audit study is a private audit without influence from commercial or financial interests and checks the open source program GoldBug, which is implemented according to the website of the developers also without any financial impact of third parties as a hobby spare time project.

The conduction of this audit and the present documentation was made therefore by the two authors, who made this financially independent and in leisure without the use of their membership of a professional audit institution. As mentioned before also this audit of GoldBug is based in knowledge and in consideration of the numerous derivatives of the above-mentioned audit-standards, -rules and -principles. Numerous analyzes and investigations have been made accordingly, like the following 21 areas of investigation in the next chapter 3 will show subsequently and will address all these eight IT-Auditor-principles.

***

Planning, Support, Conduction & further Hosting

We have created our analyzes as mentioned without authority and financial backgrounds or promotions. At the same time we provide the texts of our study under open source license and therefore they are free of copyright available. So any user or blogger and each portal may refer to this study and is able to continue this. We will make this study subsequently available as well for the GoldBug project e.g. for hosting / downloading. So particularly the users of the application have these reviews and analyzes as information available. The conduction of the audit we have provided with a project management plan to coordinate the individual steps and the inclusion of additional testers and machines.

The individual audit steps can be documented in a schedule as follows:

Audit Key Steps of GoldBug v.2.7 / v.2.8 / v.2.9
Planning completed August 2015
Comparison of Audit manuals completed September 2015
Field research for open source Crypto-Messengers completed September 2015
Structuring Audit Methods to main features of GoldBug Messenger November 2015
Research in these features, testing, code review, evaluation November / December 2015
Comparison to Big-7-Crypto-Messengers completed December 2015 / February 2016
Final report completed March 2016
Translation to English & German Language April / May 2016
Release of the Report June 2016

"Acknowledgments" The two authors responsible for this audit would like to thank cordially those individuals, who contributed to this study, and particularly, friends who provided testing and comments as part of this audit. Thanks also to the GoldBug project, that agreed in course of completion of our research to establish an URL as an archiving download option for our report.

FINDINGS AND RECOMMENDATIONS

The following sections of this chapter 3 contain the individual examinations and assessments of the previously in Chapter 2 executed central research methods and areas as joint investigation consensus from the various audit manuals as they are referred to the features in GoldBug Messenger. After a brief derivation, content and processes of the referring GoldBug function are described, subsequently a procedure for our assessment is presented, then the results of our investigations are summarized - which always contain a code review, but not in every chapter a code quote respectively a snapshot is included. Afterwards, the various findings are presented. We provide the audit issues with the security considerations in a relevant practical case, where one can illustrate the findings - potential risks and suggestions for improvement as well as the client's strengths - and general considerations in a handy example: Good Practice Insights. Finally, it is also about embedding the content of the section with an indicative, contextual comparison among the in chapter 2 recognized seven major open source messenger applications with encryption (BIG SEVEN).

***

Confidentiality through Multi-Encryption

In order to achieve confidentiality over the Internet, various methods can be used.

If a text has been encrypted once, why not encrypt this one more time? Or a file to be sent, can, before it will be sent, as well be encrypted - and here again there are various possibilities, the encrypted file can be sent through an encrypted channel (or possibly even within a non-encrypted one). This designates multi-encryption: Chipertext is again converted into ciphertext. As widely known and briefly summarized here for beginning readers - fundamentally we can differ symmetric keys from asymmetric keys:

• In case you use a symmetric key, a jointly shared, secret password is known only to the two participants, which exchange messages. The password should consist out of at least 32 randomly distributed characters - including upper and lower case, numbers and special characters.
• In asymmetrical encryption, a public key and a private key for each user is used. Both parties must exchange their public keys. The public key of the communication partner is then used to encrypt the message, and private and public keys are then used in combination after the transfer of the encoded message in order to decrypt the encrypted message at the side of the receiver. This works by mathematical operations and is based on the prime factoring, which would take for sufficiently large keys - even using fast computers - many years to complete, if you do not know the private key.

It is a common standard in cryptography, that symmetric keys are transmitted under use of other encrypted channels. The same applies to temporary, so-called ephemeral keys (which can be symmetric as well as a-symmetric keys).

The GoldBug Messenger combines the established, and standardized methods of encryption into a smart process. So new temporary keys are optionally prepared by asymmetric keys or symmetric keys, and the new communication can be run either with complementary asymmetric encryption as well as with pure symmetric encryption.

Under hybrid encryption it is now understood to have a combination of asymmetric and symmetric encryption. Here, a random symmetric key is created, which is called session key. With this session key the data to be protected is encrypted symmetrically. Afterwards the session key is asymmetrically encrypted using the recipient's public key. This approach solves the key distribution problem and sustains also the speed advantage of the symmetric encryption.

Inventory taking, structural analysis and descriptions of the functions

The encryption in GoldBug - making use of established encryption libraries like OpenSSL and libgcrypt - applies multiple encryption and hybrid encryption, which can be graphically depict as a capsule:

Figure 02: GoldBug – Encrypted Message Format within the Echo-Protocol

Source: Own graphic, comp. referring format in the GoldBug manual for GoldBug 2.8 (Edwards, Scott (Ed.) et al., 2014)

The figure shows from inside to outside the process of how the encrypted capsule is formed in the context of Echo Protocol:

First layer of the encryption: The ciphertext of the original readable message is hashed, and subsequently the symmetric keys are encrypted via the asymmetric key - e.g. deploying the algorithm RSA. In an intermediate step the ciphertext, and the hash digest of the ciphertext are combined into a capsule, and packed together. It follows the approach: Encrypt-then-MAC. In order for the receiver to verify that the ciphertext has not been tampered with, the digest is computed before the ciphertext is decrypted.

Third layer of the encryption: Then, this capsule is transmitted via a secure SSL/TLS connection to the communication partner.

Second layer of encryption: Optionally it is still possible, therefore to encrypt the capsule of the first layer in addition with an AES-256, - comparable to a commonly shared, 32-character long symmetric password. Hybrid Encryption is then added to multiple encryption.

GoldBug has implemented a hybrid system for authenticity and confidentiality.

Keys for encryption can usually be secured with other keys, called signatures. Then in particular there is evidence that the used keys for encryption belong to an authenticated person. When signatures are added to the actual encryption, the process, which has been shown above simplified and vividly illustrated, has to be enhanced accordingly in a technical explanation: One portion of the system generates per-message authentication and encryption keys. These two keys are used for authenticating and encapsulating data. The two keys are encapsulated via the public-key portion of the system. The application also provides a mechanism for distributing session-like keys for data encapsulation. Again, the keys are encapsulated via the public-key system. An additional mechanism allows the distribution of session-like keys via previously-established private keys.

Digital signatures are optionally applied to the data. As an example, please consider the following message:

EPublic Key(Encryption Key || Hash Key) || EEncryption Key(Data) || HHash Key (EPublic Key(Encryption Key || Hash Key) || EEncryption Key(Data)).


The private-key authentication and encryption mechanism is identical to the procedure more deeply discussed in the encrypted and authenticated containers section of the projectr documentation of the source code (Project documentation Spot-On 2013).

Selected method for studying and function reference

As method of investigation should first be worked quite fundamentally here, that means to determine from the known information and the source code, how the encryption works in principle respectively is implemented procedurally. It involves an analysis of whether the encryption process is transparent and understandable.

It's not about - and that can an audit in this way also not afford - whether an encryption layer discloses another layer of encryption by various decoding attempts. The aim of our review is not to try to break the RSA encryption. (For example, here is therefore only referred to the appropriate tests, for example, using the "Adaptive chosen-ciphertext attack (abbreviated as CCA2)" (compare further the authors: Bleichenbacher 1998, Fujisaki et al. 2004, Cramer 2004, Hofheinz 2007) as well as the NIST publication by Chen et al. 2016).

The basic principles should be here clarified and understood, in order to assess whether the encryption complies with the standard principles of software libraries used, and these have to be judged accordingly.

Conduction and findings of the examinations

Based on our code-review the individual sections of the functions of the encryption process are clearly structured, integrate the used libraries and are accordingly related to each other.

The relevant programming can be found in the file: spot-on-crypt.cc. Because the process consists of several steps and references in the source code, here only a selected code passage should be inserted: the hash-digest-comparison; and then furthermore pointed to the inspection in the mentioned references.

As a result of our review we can state to have found respectively identified no particular disorders and that we were able to validate the mapping of the individual process steps for the encapsulation of the message.

It's not just about the illustration of the process in machine language, but also about getting the idea behind the encrypted capsule, when the user applies this encrypting Messenger:

If the hash of the ciphertext, which is converted from ciphertext by my client´s deposited keys, is identical with the supplied hash-digest of the original ciphertext, then an indicator is given, that I have the cipher converted properly (with any of my (from friends) available keys) - and a human beeing can read this as well.

The conversion process is - also in its process sequence - clear to understand, when reading the source code.

Figure 03: Source Code for the Hash Comparision memcmp in spot-on-crypt.cc

Source: for the detailes source snippet see: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

With regard to the code implementation there are no findings from our side. The strength of the protocol lays in the multiple respectively hybrid encryption, and in an intelligent hash comparison to detect a message addressed to the own person: a human being can read it - when the hash comparison is consistent.

As shown below at the types for the so called "Calling" (compare Pure Forward Secrecy for e-mail or in chat: Calling with Forward Secrecy), it is also possible, to systematically "play" with the use of symmetric and/or asymmetric encryption, (e.g.

* first encrypt multiple, then encrypt hybrid, and respectively vice versa
* first encrypt symmetric and then encrypt asymmetric and vice versa, respectively
* alternating from asymmetric encryption to pure symmetric encryption).


This optionality is given in the encapsulation of the echo protocol in the version of the examined application 2.8 (2015) and 2.9 (2016) for additional symmetric encryption during chat in particular by means of a so-called Gemini-Call (using an AES-256): That means, with a call in a chat an AES is as symmetric encryption always added to the asymmetric encryption (compare layer 2 in the graphic above).

Mind you, it is not about the development of a proprietary algorithm or a homemade encryption, instead only about the procedural application of existing standards from the existing crypto libraries. As with the Mac-then-Encrypt or Encrypt-then-Mac procedure one can define with a call, respectively with multi-encryption, whether first an asymmetric, and then a symmetric encryption is performed (or vice versa) or whether ephemeral (temporary) new keys are then transferred through existing symmetric or asymmetric channels.

GoldBug can therefore be considered not only as the founder and pioneer of the age of a modern client-side hybrid and/or multi-encryption and their numerous variations.

With the echo protocol - which refers to the incorporated architecture of the Spot-On kernel since 2011 - this crypto-network-concept can be considered as the first theoretical and practical elaboration in an application, which introduced the paradigm of crypto-keys as network-address (instead of the previous IP-addresses), and thus indicates avoidant against metadata analysis.

Table 05: Description of findings 3.01

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
Potential for Improvement ./. ./.
3.01.4.B Strength The strength of the hyrid encryption lays in the several layers of encryption, which makes it harder to get to the core of the capsule: the original message. High

Appraisal of good practices in comparison with other similar applications

The encryption process of each application by the seven to be compared open source messengers is different in each case.

The multiple packing of a text in a new encryption process as multi-encryption respectively as hybrid-encryption, that uses both, asymmetric and symmetric methods, and identifies the proper decryption via the hash digest of the message, can so far be found only in the GoldBug client.

Table 06: Indicative BIG SEVEN context references 3.01

CryptoCat No usage of hybrid or multi-encryption.
GoldBug Usage of multi layers of encryaption: Hybrid Encryption. Different methods for encryption, e.g. asymmetric and symmetric encryption.
OTR+XMPP Usage of sessionbased keys within the OTR process.
RetroShare No usage of hybrid or multi-encryption.
Signal Usage of ephemeral keys transferred over the messenger.
SureSpot No usage of hybrid or multi-encryption.
Tox No usage of hybrid or multi-encryption.

At the same time, today also in other applications newer development approaches show up to protect the encrypted message through multiple keys and various encryption methods.

This opens up another area of research, to carry out this comparison in the appropriate level of detail in the next few years again, to compare the then current status regarding multiple or hybrid encryption of message texts in these or newly arrived open source applications.

GoldBug has presented an excellent model, how hybrid- respectively multi-encryption can be implemented, and will certainly influence the other Messengers with only one layer of encryption in their further development.

For example, after the term of "Calling" for a to be manufactured end-to-end encryption was established by GoldBug and the underlying architecture Spot-On since mid-2013 (compare for detail as well section 3.15), subsequently other research papers have applied the to GoldBug / Spot-On referring Concept of Calling in Cryptology (see Spot-On Project Documentation 2013) for the preparation of a (a)symmetrical, possibly ephemeral (temporary) end-to-end encryption (e.g. as van den Hooff / Lazar / et. al 2015 in their Paper "Scalable Private Messaging Resistant to Traffic Analysis", which plagiarized without referencing the aspects of the echo protocol in part, and in particular for the Crypto-Calling: "When receiving a call via the protocol, the recipient needs to identify who is calling, based on the caller's public key", as cited, MIT-CSAIL 2015).

Also the draft of “Matrix” of Erik Johnston (08/2014) contains backings to the Echo protocol, also if not in the same manner and coding environment.

Furthermore also the draft of the "noise" detailed specifications of Trevor Perrin (2016) (first Github code-commit 08/2014 and the website domain creation and registration according to Whois was on 2016-04-01) overtook the idea of the Super-Echo Modus of the echo protocol from many years before.

The Echo-Protocol represents so far the Original Noise of the Matrix´ and is the inventor of both, cryptographic routing´ and the term calling in cryptography´ for instant renewable end-to-end encryption.

Table 07: Good Practice Insight # 01

# 01 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case If RSA could no longer be considered as secure e.g. due to quantum computing, would multi-encryption then be a solution?
Solution GoldBug encrypts not only multiple, but also hybrid: symmetric and asymmetric encryption is combined. Also, you can renew different levels of encryption at any time instant.

Source: Own Case.

***

Integrity & Security of Information through Authenticity

The integrity and security of information respectively data transmitted is marked in particular by authentication. In information security authenticity refers to the characteristics of the originality, accountability and trustworthiness. The verification of an alleged characteristic is called authentication (compare as well Shirey 1987). Through authentication of data origin is proven that data can be assigned to the claimed sender, which can be reached by digital signatures.

As can be demonstrated with the problem of Byzantine generals, one can examine many questions about the authenticity of information: The adjective Byzantine refers to the problem of Byzantine generals. In this scenario, several generals, who do not trust each other, raided Byzantium and send messages to each other. Therefore algorithms for secure transmission and verification of these messages are needed, because the sender or an entire message can be forged by another, messages can be intercepted by trapped couriers or can be replaced by fake notifications.

It is thus a problem of agreement to resolve, which is that the commanders must decide unanimously whether to attack an enemy army or not. The problem is complicated by the spatial separation of the commanders; so they need to send couriers back and forth. Then there is the possibility that among the generals traitors can be located, which can send a deliberately misleading information to the other generals (compare Dolev 1982).

The further publication with solutions to the problem of the Byzantine generals then is referred back to Lamport, Shostak and Pease in 1982 (ibid). They led back the problem to a "commanders and lieutenant" problem, where all loyal lieutenants must act in harmony and must match its actions with the orders of the commander, if he is loyal. An illustrated solution considers the scenario, in which messages are faked. As long as the proportion of traitorous generals is less than one third, this solution should be tolerant in regard of a Byzantine fault.

A second solution requires non-counterfeit-able signatures - what is now achieved in modern computer systems through public-key cryptography.

The authentication characteristic is thus the characteristic, with which a user can be authenticated by a protected system.

This feature can be referred to knowledge (password, PIN, parole), to possession (key, card) or on an attribute (biometric feature such as voice, iris image, fingerprint) or an original signature - or beeing a combination of these features.

Dynamic authentication is possible when the operational context is included. Then, the authentication factors are recognized by itself in a predetermined explicit context.

In cryptography, the authenticity of a message is created by digital signatures. A digital signature, as well digital signature method, is an asymmetric cryptosystem, in which a transmitter calculates with a secret signature key (the private key) a value in regard to a digital message (that is for any data), which is also called digital signature.

This value allows anyone using the public verification key (the public key) to check the non-deniable authorship and integrity of the message. To assign a signature generated with a signature key to a person, the corresponding verification key of this person must be assigned unambiguously. For the data to be signed and the private signature key, the signature is computed by a unique computational rule.

Different data have thus lead to almost certainly to a different signature, and the signature must result to another value for each key.

In deterministic digital signature process, the digital signature is uniquely defined by the message and the key. In probabilistic digital signature process random values in the signature calculation are integrated, so that the digital signature of a message and a key can have many different values.

For a digital signature therefore the private key usually is not applied directly to the message, but their hash value using a hash function (such as SHA-256) calculated from the message. To prevent attacks, this hash function must be collision-resistant, that means, it must be practically impossible to find two different messages, whose hash value is identical.

Since in the RSA signature method - the digital signature method most commonly used - the operations used are almost identical to the RSA encryption, is sometimes spoken in the creation of a digital signature of the "encryption" or "decoding" of the hash value (compare also Wikipedia).

This terminology, however, is inappropriate, since a signature creation syntactically is something other than an encryption or decryption. For most digital signature schemes (e.g. as for DSA) this equation therefore does not apply. There in the verification, the ("encrypted") hash value is not reconstructed from the signature.

Inventory taking, structural analysis and descriptions of the functions

GoldBug encrypts the various possible messages not only - that it is a chat message, a group chat posting or an email, or sending a file or some URLs -, but can also optionally add a digital signature. So the message or file package is uniquely referred to a particular sender or encryption key. This function is embedded in GoldBug optionally, that means the user also has the option to send an e-mail without a digital signature.

In the options of GoldBug can be controlled very decidedly whether a function should include signatures or not, for example, E-mail:

• Reject Letters without signatures
• Sign Letters.

Figure 04: Usage of Digital Signatures for e.g. E-mail-Letters defined in Options

Source: Screenshot of Goldbug Options 2.9

Correspondingly, the receiver of the message has the option, to not allow e-mails in their e-mail inbox, when they were sent without a signature.

Alone this architecture or option wealth shows, that information security and integrity through the use of authentication considers a high status in the Messenger GoldBug.

Selected method for studying and function reference

To investigate this, we will conduct a corresponding practical test: Two GoldBug instances were interconnected, and tested the e-mail function in different variations.

Once was the instance of Alice examined with and without signature when sending e-mails, as well as the receipt of e-mails with and without signatures was approved. The same has been created for the node of Bob.

Conduction and findings of the examinations

The following combinations have therefore result in our practical tests of the e-mail function with and without digital signatures:

Table 08: GoldBug Authentification Matrix for Digital Signatures

GoldBug Authentication Matrix for Digital Signatures Alice allows receiving E-Mails without Signature Alice requests receiving E-Mails with Signature Bob allows receiving E-Mails without Signature Bob requests receiving E-Mails with Signature
Alice sends E-Mails with Signature ./. ./. Transfer OK Transfer OK
Alice sends E-Mails without Signature ./. ./. Transfer OK NO E-Mail shown
Bob sends E-Mails with Signature Transfer OK Transfer OK ./. ./.
Bob sends E-Mails without Signature Transfer OK NO-E-Mail shown ./. ./.

Source: Own table.

In our tests, we were able for all above-mentioned cases to confirm correct operation of the reception and transmission of e-mails with or without digital signature. Also the following cases important to information integrity were confirmed:

• Alice expects an e-mail signature, but Bob does not send a signature: The e-mail will not be delivered or displayed.
• Bob expects an e-mail signature, but Alice does not send a signature: The e-mail will not be delivered or displayed.

GoldBug allows further during key generation also to define the entities for digital signatures manually.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

Our evaluation due to the practical test shows no reason weaknesses or risks to assume. Also in the code review, we found no irregularities.

Table 09: Description of findings 3.02

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
Potential for Improvement ./. ./.
Strength ./. ./.

GCM is not supported in digital signatures, because the Spot-On kernel and the corresponding user interface also refers to compilations, that might include an older version of the library gcrypt - even if the latest version is always distributed in the releases.

Appraisal of good practices in comparison with other similar applications

The manual switching on or off of signatures for each individual function is not possible in any other messenger. Also the manual selection of the specifications in the creation of signatures is not existing in any other messenger.

Table 10: Indicative BIG SEVEN context references 3.02

CryptoCat Has no option to send messages with or without digital signatures.
GoldBug Offers the choice to use or not use digital signatures. Offers also the choice which dedicated digital signature should be generated.
OTR+XMPP Has no option to send with or without digital signatures.
RetroShare Has no option to send messages with or without digital signatures.
Signal Has no option to send messages with or without digital signatures.
SureSpot Has no option to send messages with or without digital signatures.
Tox Has no option to send messages with or without digital signatures.

Table 11: Good Practice Insight #02

# 02 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case I want to use a modern P2P e-mail system to make me more independent of central e-mail providers: How do I know that an email is actually from my friend?
Solution GoldBug offers optional digital signatures for each email - this refers to both, POP3/IMAP E-Mail, as well as for the integrated P2P e-mail-system. So authenticity is ensured. Also, on every email a password can be placed - a so-called "GoldBug" - so that only the authenticated recipients are able to open the email.

Source: Own Case.

***

Availability: Decentral P2P - HTTPS

An audit should as well assess the availability of the IT infrastructure respectively the services and also the continuity and peculiarities in the administrative service. Included should be here also the feedback from administrators and experts, who mediate this as a multiplier of technology to others. So it's not just about the technical availability of one wire, of one encryption, a connection or a server, but also about the support that others can give and want to give, and about the basic ease of the learning about the usage of this technique from the perspective of supporters. How is the availability of technology and social support to assess?

Inventory taking, structural analysis and descriptions of the functions

In GoldBug Messenger basically uses a decentralized architecture. This means that each user is able to set up their own chat server with simple means.

It is not only strategically crucial that each user can set up their own IT infrastructure and services, and therefore the decentralized structures can be available as an alternative in the context of potential attacks by surveillance entities.

Also in the context of assessing cryptological processes, it is critical, that the technology does not make the data and metadata of the user so easily accessible to a potential attacker through e.g. decentralized infrastructure options.

GoldBug uses therefore an architecture that is based on the hard blockable HTTPS protocol, when a client addresses to a listener or chat server. This only needs to be accessible from the port and can be created either way, on the web (for example, through the ports 80, 8080, or 443, or 4710) as well as by another user at home (with any port or default 4710). If necessary, therefore a simple port forwarding on the router at home is required.

By the decentralized structure thus very easy growing peer-to-peer networks or decentralized server services can be created to establish the service for an own team. The stability of the kernel is just as crucial as the HTTPS connection and thirdly the presence of a chat-server or connectivity solution, which is supported in the community or by your own circle of friends. Furthermore, there is also over the below (in Chapter 3.10) described POPTASTIC function - that is, to operate the encrypted chats as well as secure e-mail via a POP3 or IMAP server - an option, with which this stability of the services is given by further professional e-mail mailbox providers (in addition to a p2p embodiment of the email-function or -communication via a dedicated server or via the project-server given by GoldBug). Finally, the complementary networking option exists, that server administrators connect among each other, to connect various remote chat servers and their users together. In a fifth option the possibility also exists to design the entire system for a local group via a Bluetooth listener. Here no cable or internet is used, but an administrator just opens a Bluetooth listener and within the about 25 meters the present users e.g. of a LAN- or Crypto-Party or in a lecture auditorium of the school or university can connect wirelessly to the service and communicate with each other, share files, or contribute p2p to the URL Web search.

Selected method for studying and function reference

For this portion of the assessment is to be investigated, how a user, who uses the software for the first time, connects to a server. For this, the software on the three operating systems Linux (Ubuntu), Windows and MAC OS X is downloaded respectively compiled and provided with the necessary installation files.

Then should be examined, whether in each system a stable connection to the available chat-project-server can be established. The method consists in the comparative embodiment of the processes on different operating systems in order to test whether the stability of the application for different users is the same performance and can be judged as "stable availability".

The details of the test chat server provided by the project will be loaded automatically during installation out of the file "spot-on neighbors.txt" and then used in the client for a connection. This server will be provided by the project for scientific test purposes.

Although experienced users can and shall build their own server, two first-time users, who want to use the application without much effort, are dependent on the reliable availability respectively especially the proper functioning of the import of these server details.

The project server data is therefore not stored in the source code, but are loaded initially at startup out of of the above-mentioned file.

It is a text-file, that is located in the path, in which the binaries are also to be found, and which by everyone can be viewed with in regard to the stored server details (server address and port).

Thus, the initially to be loaded chat server can be adjusted individually e.g. in a re-distribution of the installation-zip to a group of friends, because the initial project server has not been defined in the source code.

Figure 05: Neighbor connection to the project server

Source: Own screenshot of GoldBug.

Conduction and findings of the examinations

To carry out this assessment it is therefore intended, to install the software on Windows with the installation zip, on the operating system MAC OS X via the DMG installation file and on Linux Ubuntu over the existing Debian package.

As well on the Windows system, as well on the MAC OS X system and even under Ubuntu Linux, the file with the server details is included in the respective installation file.

After installing the application, after key generation and kernel activation, the connection with the project chat server is in the tab "neighbors" shown.

Both, the data for a IPv4-connection, and also IPv6-connection are available there. So that means that in the presence of the project server, the installation procedure for a connectivity indicates no deviations: that functionality is given on all tested operating systems.

The availability of the project server was given at any time and can be enriched with appropriate, additional servers from friends or for the own institution.

Also by the availability of listeners for IPV4 and IPV6 the security of the availability of an existing server as well as the scaling to more, other servers can be confirmed.

Thanks to the architecture and the integration of the server details not through the source code, but by an installation file, the initial server can always be adapted without the application having to recompile.

(Compare for example the encrypted application CSpace by Tachyon Technologies, that had programmed in an Indian server service. After turning off the server, the program was not only as a service no longer available, but also the use of all installers was made impossible - until the application - but again not the chat server - was documented as open source after many years without the service).

Therefore it can be stated an excellent result from the investigation of the program GoldBug on three different operating systems for the here examined process architecture, server availability, possibility of remote provisioning of servers and easy addition of chat servers by friends.

Even without the chat server provided by the project, the architecture also can be made available decentrally in an easy way and without modifications in the source code.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

The strength of the examined application GoldBug lies in its option, that not only each user can create a decentralized listener, but the chat server can also be created very easily. Besides the ease of use, it is an additional plus, that the server software is already integrated in the application GoldBug.

Table 12: Description of findings 3.03

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
3.03.4.A Potential for Improvement Decentral servers are possible for local teams even over Bluetooth. Informational
3.03.4.B Strength Server Software in the client: Already integrated and easy to set up. High

Appraisal of good practices in comparison with other similar applications

Comparing this with the difficult and mostly only by experts executable installing of a XMPP chat server, it is obvious, that for XMPP servers custom software and detailed administration skills must be available, however, also these chat clients permit the addition of decentralized chat servers.

CryptoCat permits as well server alternatives. However, the server software also relates as well to server software installable only with expertise.

RetroShare is substantially comparable with GoldBug concerning the availability and decentralization of chat servers, but when you first install RetroShare, it is required from the user to add a neighbor with a key, search the friend in the DHT and then trying to connect. If the friend, however, has not set up a listener port, the initial connection is not or only partially functioning.

Table 13: Indicative BIG SEVEN context references 3.03

Application
CryptoCat Central Server since many years, availability given.
GoldBug Both, decentral and central model since many years, a project test server is given and stable. Fast availability of connections.
OTR+XMPP Decentral services, availability depending on server admins.
RetroShare Decentral service, uses a DHT, no central server. DHT availability depending on configuration and environment.
Signal Central Server, stable, no decental servers. Many recommendations to use this central server availability.
SureSpot Central Server, stable & available.
Tox Usage of a DHT. Connection process depending on configuration and environment. Stun-Process and connection-process might take a time to connect.

Although Tox offers different user interfaces, the kernel as well as the chat server software in use by the user is rather slight. Signal and SureSpot use essentially a central IM server, which also can not be installed from a user so easily without further modifications - if this would be even desired by the two projects at all.

As an improvement and outlook is thus in summary to realize that further from the community provided server may of course correspondingly increase the connectivity of users among each other.

As a recommendation can be therefore expressed, that the IM servers of the examined application are possibly preferable in regard to a XMPP chat server, because XMPP servers are not designed for exclusive encrypted traffic like a GoldBug chat server.

Moreover GoldBug communication servers are much easier to administer and contain also an email server: IMAP and POP3 server can be replaced easily and in a decentral way.

A note to the messenger Signal with its central server architecture is that in both, in the mobile version and in the desktop version, first, it is always necessarily to conduct a telephone number verification via SMS and thus also an identity check, and - secondly, even more astonishing, is that at the same time on the mobile version all the contacts of the user are uploaded.

Here is as well (as in Whatsapp) a comprehensive database by the supplier created, according to the pattern: who-knows-who. Anyone wishing to use the desktop version, must have necessarily previously registered with their phone under the disclosure of their full contact list.

After public discussion in the field of cryptology, that backdoors in open source programming can be built only with difficulty into the encryption (Nakashima 2015), and that a ban on encryption would not only cripple the economy and the financial sector of each country, but rather has to be considered as a nonsense, like "mathematics to ban" (Wales 2015), the strategy does not seem to be to look at encryption, but to save the meta data of the social networks and to collect and to save all contacts of the users.

That the friends list or telephone list of Apple and Android phones now also may be uploaded by any application. or also by the providers of the operating system, demonstrates a possible, to be assumed, underlying strategy: We can not get into the crypto, so it is for us more essential, to record, with whom you communicate. What you have to communicate, we possibly can ask for or get to know over other ways. It is important for us to know your network - with whom you communicate.´ For this, one have not even to break Crypto.

The change of paradigm from breaking crypto towards of bulk copying of private social contacts of users seems obvious.

It is a procedure, that will be implemented not only by the non-open source and non-encrypted Messenger "Whatsapp", but procedurally also by the encrypted messenger "Signal" - and therefore one can only warn against clients like these: E.g. compared to SureSpot, in which although the user sends also its public key to a central server, the user's friend must be notified in this Messenger still manually about the own nickname.

This indicates for SureSpot that there contact lists are not matched respectively uploaded via automatic access to your own phone, to save, to collect and to analyze these - for business and, if applicable, governmental access.

For this important analysis area, to be able to operate an own chat server for a permanent availability of the service - which is the topic of this assessment chapter -, are therefore RetroShare, GoldBug or XMPP-OTR and Tox the definitive preferable Crypto-Messenger clients. In the end remain concerning the simpler manageability of an own server GoldBug, and, with inclusion of a DHT, respectively RetroShare and Tox left.

Therefore these are crucial questions e.g. to the Messenger Signal,

1. firstly, why not allow independent, decentralized server and
2. secondly, why the contacts of the user are completely uploaded each time you install - and why with this process they are stolen and
3. thirdly, why not contact options via this Messenger are possible without to announce the own phone number to others or to the central service. Aside from the ultimate
4. fourth question, why the user can not use manually definable symmetrical end-to-end passwords together with their chat friend.

Meanwhile, it is also reported that the Messenger Whatsapp, associated with Facebook, wants to introduce, an end-to-end encryption.

The protocols of the Signal application respectively their developers should support it: this can also be seen as a strategic market agreement to prevent a supposedly encrypting Messenger to the date unencrypting Messenger takes pride of place: Indeed, both Messenger are unanimous into their technical processes about wanting to get hold of all the metadata of the social network of a user and to record it massively. ("These applications stores your messages, content and contacts", compare Jacobs 2016).

Facebook has quickly recognized the strategic importance of Whatsapp, when it has purchased this Messenger for an unlikely excessive sum of USD 19 billion (Albergotti 2014).

The state can not save all the communications, data and metadata of the people, it needs companies for it. These may generate earnings from the government within demand cases as well, if they give out data (or it is only about to have the power, to be able to look it up).

The monopolization processes are certainly obvious: The objective seems then to push large masses of users to a few or just two large cooperating Messenger services, that know the friends lists of all the participants and so the metadata "who-knows-who" can be evaluated, if necessary at any time. Facebook and Whatsapp Messenger of the same company of the operator Mark Zuckerberg have 800,000,000 plus 900,000,000 = 1.700 billion users - while the world has only 7.125 billion inhabitants (compare Wikipedia in 2013).

A messenger provider has thus approx 1/4 of the world population under his wing - a "giant" (Kannenberg 2016). And despite other own statements (Marcus 2015) now both Messenger merge their functions increasingly together (Santos 2016).

Thus the paradigm of pseudonyms is transferred for Facebook not only into the rule of real names coercion, but rather extended in an identity card certified identity, because cell phone numbers are only granted upon identity verification. And with the linking of Facebook with Whatsapp the real names coercion is introduced not only through the back door, but also identity checked by means of the identity card!

The vision to uniformly use the number of the social security card as phone number and chat ID respectively email address and therefore to make every citizen identifiable and thus controllable with each utterance is therefore not far away.

The idea of a crypto network rather than an IP network is transferred to a lifetime valid and federally registered citizens numbers, which any communication packet and any friend contact will be unprotected against accesses?

Beneficial for the deal could also be the reasons, why the project Signal and its company Open Whisper Systems has received also greater financial investments from various sources (Knight Foundation 2014) and shall develop end-to-end encryption in cooperation with Whatsapp (Floemer 2016): analysis of friends lists and the pushing of users to a central monopoly supplier could be to be regarded with more priority - than the breaking of cryptography.

Whatever the development status of these "verified end-to-end encryption" (Floemer 2016) out of this cooperation might look like: it will remain the further questions for this client,

1. if the processes of the authentication could also correspond to the Socialist Millionaire Protokol and also,
2. if the paradigm of deniability - the deniability of the communication from the past (compare OTR) - will be made possible by ephemeral keys - and,
3. if it is an end-to-end encryption, which safeguards users consistently from user to user - and not only from user to a central server.

In the case of Whatsapp no one can verify it more accurate, because it is not an open source messenger, and therefore can not and should not be considered here in greater detail. The portal Heise Security referred encryption into Whatsapp therefore as a "gesture" (Scherschel 2015). As mentioned, the issue of registration of lists of friends is strategically more significant than the entire crypto debate!

Meanwhile Whatsapp has released the end-to-end encryption. It is prozessural as constructed in Telegram (see also chapter 3.09.5 and the criticism of it respectively Whatsapp 2016).

It is true, encrypted communication is given (compare e.g. Scherschel 2016), nevertheless arise questions: Who all gets a key? Can the symmetrical end-to-end key also be created and inserted manually by the user? How strong the key is protected, with which the temporary key is transmitted?

It remains - as with Telegram - to continue to suspect, that WhatsApp has a possibility of picking up the symmetric key; the symmetric key can not be defined and edited manually by the user and third, the transfer of the symmetric key is possibly not sufficiently protected - and especially the user cannot use oral agreement as a method to transfer the key.

Encryption will now be standard as in Telegram, but more out of the necessity to let no other Messenger come up - and because it is not open source, this monoculture is no safe solution against open source and verifiable alternatives!

The security expert Fabian Scherschel (2016) summarizes: "A certain residual risk remains, of course:.. WhatsApp is not open source .. Users therefore can never be sure that their service provider imputes no malicious app, which undermines the encryption. In addition WhatsApp-server still collect metadata "- that means: who is communicating with whom.

The same questions therefore exist ongoing within this (audit)context for the interdependent Signal Messenger, and here are enlightened user decisively, which can not be fooled for an U a X.

Furthermore, the actors are to be asked, which should trigger a marketing hype for the Messenger Signal: the manufacturer of Signal, OpenWhisperSystems, sets currently two prominent activists and two prominent scientists of the Crypto-area to the front page of the website with the phrases: Use only these monoculture, use this every day, it is the first choice and has great programming, that brings tears even in the face of experts. What kind of a message is that to the user: Do not think about it and leave the review to the experts, - you enjoy instead unquestioningly exclusively our products?´

("Use anything by Open Whisper Systems." Edward Snowden, Whistleblower and privacy advocate / "Signal is the most scalable encryption tool we have. It is free and peer reviewed. I encourage people to use it everyday." Laura Poitras, Oscar winning filmmaker and journalist) / "I am regularly impressed with the thought and care put into both the security and the usability of this app. It's my first choice for an encrypted conversation." Bruce Schneier, internationally renowned security technologist / "After reading the code, I literally discovered a line of drool running down my face. It’s really nice." Matt Green, Cryptographer, Johns Hopkins University, cited according to Website, 2015).

We have learned in science to always designate an alternative, science should conduct especially comparisons and thirdly prove objective facts, not tearful outbursts.

It is not clear, why the above analysis of the practice of mass picking up of private contact lists and the intended establishment of a centralized monoculture of chat servers does not arise in those minds, which from the public so far are seen as lawyers or even as experts for users of encrypted communications solutions.

Should the assumed goal of not controlling of the speech contents, but rather of the social contacts and metadata also be found in the judgment of the thought processes of the users, would be subsequently to wonder, whether the four multipliers have been promoted for their statements financially or with other bonuses?

A statement thereto has been especially so far not been presented by Edward Snowden, if he was promoted for his mono-culture advertising financially by Signal from Open Whisper Systems or has possibly got in his case implicitly promised mitigation of sentence, e.g. by continuing to assist that his former employer can understand the social networks of each user through agreements with intermediary companies?

Especially since it was reported within the research for this analysis, that Edward Snowden was asked to give his comparative technical expertise for several different messenger. He has chosen for specific reasons, that may lie not only in a technical analysis, for a mono propaganda.

Otherwise remain overlooked, that the Messenger without metadata attack opportunities are only CryptoCat (with decentral server), GoldBug due to the utilized Echo protocol and RetroShare operated over the Tor network (seen apart from as susceptible to be designated graph chain: OTR-XMPP-Tor-XMPPSERVER-Tor-XMPP-OTR, with consideration the Tor network as the more observable, the more Tor nodes are into one's control).

This leads then not only to the provided technical or strategic issues, but ultimately also moves an entire community, which sets a focus on a necessary comprehensive review of the acting persons and experts in the public.

First critical analyses are in the rise already: There are complains about the central server model of these mobile messengers (Öberg 2016, Kumar 2016). And: Also with the in the meanwhile established end-to-end encryption (compare for Whatsapp the chapter before) the - in case of closed source non-answerable trust question - still remains, if the encryption key, which is not able to be defined manually by the user, can be tapped at the central server.

And: in the end also the metadata will always be revealing (Teicke 2016). Furthermore a group of security researchers has pointed out still more central questions in regard of the security of the Whatsapp end-to-end encryption (Bolluyt 2016, Postive Technologies 2016, Fadilpašic 2016).

Also exist especially in the legal sense some problems, which depend on the SMS-authentification respectively on the upload of all friend-contacts from the phone of the user: “Especially this is (- at least -) according to the EU law forbidden: Who wants to forward Data of third persons, has in Europe to get the agreement of the persons, who own the data. If someone has saved 200 contacts with phone numbers and mail addresses in his contact book, then he would require exact 200 written declarations of agreement, before the Whatsapp application could be established on the smartphone” – says Peter Burgstaller, Chairman for IT and IP-Law at the faculty for Informatic, Communication and Media of the Fachhochschule in Hagenberg (cit. acc. to Könau 2016).

That is “why every Whatsapp-user can sue every other Whats-user at the data protection authority. Should now also consumer protection agencies sue Whatsapp, could this mean the end for this service in Europe”, summarizes IT-Laywer Christian Solmecke the legal situation. So why are consumer protection organizations and agencies in charge for data security still sleeping?

Considering this background, even at network meetings within the IT community it is to recommend not to get the supposedly established "Heros" and "luminaries" a request for giving a presentation, but in particular the little alternatives and young scientists.

And, a contribution should be given also to "criticizing nest aspersers" - which would be a term from the perspective of focused activists and participants more unmatured from technology and life experienced. (Compare in this regard also Levin 2014, who received personal accusations, when he announced, that many Tor servers, Tor activists, Tor operators and Tor developers are sponsored by governmental money donations, in order to be able to control the exit nodes. The thesis of Tor as honeypot community was then thought a step too far).

Many technology enthusiasts show therefore, that it is often difficult to say goodbye to a technology tool, with which they have learned and have grown up with, respectively it is hard to perceive alternatives for testing and learning. Even if it is just for activists with high ideals difficult, to move the thinking in the round head in a different direction, if an erosion of the role models and community multipliers should be questioned, idealizations from technical tools or their representatives should be (well as in religion) avoided - regardless of whether they have dreadlocks, keen on visiting for free and are present on each cat fair, or live in exile.

Tools should not be a religious question and coexistence is widely regarded as the learning objective for unilaterally focused activists.

Currently, the user community is looking for secure communication solutions: These search and discovery processes should not be done strategically under monoculture propaganda (as with the bloggers for Signal) nor under denunciation of other clients (as with the developers from CryptoCat, see below).

Only in the common technical comparing and questioning of technical solutions based on defined criteria and a mutually supportive community of developers, there can be several, encrypting communication solutions.

Among the criteria of a technical comparison belong firstly source openness and secondly, the assessment of the decentralization of the server infrastructure to avoid the collection of metadata and thirdly, the manual definability of encryption values, or in particular of end-to-end encrypted symmetric passwords.

However, from these contextual analysis of the latest developments of further clients a fourth paradigm can be derived: Everyone, who writes about encrypted applications, should include at least two more applications into a technical comparison.

Otherwise, the attribution of the idea of subjectivity, of a bias and a strategic promotion due to suspect reasons (e.g. for monoculture of a centrality or for the culture of the mass capturing of metadata or the concealment of financiers and their interests) cannot be kept any longer in distance and is highly topical.

The comparison of open source and encrypting Messengers should be a topic for each blogger and active user in the internet.

Table 14: Good Practice Insight # 03

# 03 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case On my site I can not use other messengers like Pidgin or Retroshare because of port restrictions. What options remain, to communicate with friends?
Solution GoldBug uses the HTTPS protocol. If the Web is accessible with a browser, GoldBug can also be used at any time. A chat server with a corresponding port is subsequently at any time reachable. Installing GoldBug requires no admin rights and can be portably operated out of a path or from a stick.

Source: Own Case.

***

Security Scan of the transferred Ciphertexts

The scan of the transferred data is also another regular action to find out any irregularities, respectively also to prove, that except ciphertext no readable plaintext was transferred. To view the transferred content, not even have to be used the most frequently used tool Wireshark, like we have done in the investigation of the GUI-kernel-interaction (compare Section 3.14). For the monitoring of the transferred data of the connection between two instances of GoldBug over the Internet thereby a simple Web browser is sufficient, which is set to the local host. The aim is to examine the information sent over an Internet connection regarding the integrity of encryption and to scan the chiphertext.

Inventory taking, structural analysis and descriptions of the functions

The data sent by GoldBug can be easily viewed by any user. For this purpose it is not necessary to use special tools: In the user-manual it is described, how to utilize a simple browser. Normally two GoldBug clients build their connection with a self-signed TLS/SSL certificate via a HTTP connection. That means, HTTP is configured as a HTTP-S.

Since this can then only connect clients like GoldBug with a corresponding key, the sent ciphertext can not be viewed in a Web browser. If, however, we dispense of the additional layer of encryption of the HTTPS channel, the still persistent encryption within the message capsule can be displayed in a web browser. For this purpose only the listener of the GoldBug node must be set up via HTTP. Then in the browser via HTTP on localhost also the corresponding port is entered. In the following the browser shows subsequently the transferred ciphertext.

Figure 06: Encrypted Message of GoldBug shown in a web browser

Source: Own screenshot of GoldBug and Webbrowser.

Selected method for studying and function reference

As method to view the transferred information of a GoldBug client, should thus a scan be used. Using a browser and a listener configured within GoldBug to HTTP this was viewed and recorded.

Conduction and findings of the examinations

For the conduction we have used different standard browsers like Firefox and also the Dooble Web browser. The screenshot shows the IRON web browser, which we used instead of Firefox (it is a fork of Chrome and exempt from certain tracking code that otherwise affect private information, compare IRON browser project). As a result, we can say that even in the absence of HTTPS encryption only ciphertext (the message capsule) was sent by the established channel to another peer of GoldBug. The figure above shows the structure of the transmitted content as an example.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

Weaknesses or risks were not detected as a result of this investigation, also potentials were not seen according to the investigations for this topic in the specific application. The strength is certainly the additional encryption layer that is built up through the HTTPS channel.

Thus, one can apply GoldBug anytime even in more restrictive environments (such as specific country or corporate firewalls) - and possibly other messengers not, like OTR-XMPP (e.g. Pidgin) or Retroshare due to specified protocols and ports.

GoldBug is therefore because of the universality of the HTTP protocol always to prefer - like it is basically to create always an accessible website for the blind or like students of the newer generation learn right from the start as a standard, that new Underground stations are basically to be provided with features for the orientation of the blind.

Table 15: Description of findings 3.04

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
Potential for Improvement ./. ./.
3.04.4.A Strength Additional layer of encryption over HTTPS channel provided. High

Appraisal of good practices in comparison with other similar applications

All mentioned, comparable open source applications send ciphertext over the Internet. Feature in particular for GoldBug is to use the HTTPS protocol, and the establishment of this additional encrypting, secure channel for the existing ciphertext.

The ciphertext of the other applications is also dependent on key size, the selected algorithm and the architecture of the application.

This can not only comparative, but should especially be investigated in depth in the process and within the respective architecture elsewhere. Although each app sends at the end ciphertext, this must also be seen in conjunction with the relevant crypto-specifications in each application.

Table 16: Indicative BIG SEVEN context references 3.04

CryptoCat Sends out ciphertext, further investigation is needed as an addition to the given audit reports.
GoldBug Sends out ciphertext, uses additionally the http protocol and secures it with TLS/SSL.
OTR+XMPP Sends out ciphertext, further investigation is needed as an addition to the given audit reports for OTR and several clients. The cooperation of host and plugin has to be considered for security analyzes.
RetroShare Sends out ciphertext, further investigation is needed.
Signal Sends out ciphertext, further investigation is needed.
SureSpot Sends out ciphertext, further investigation is needed.
Tox Sends out ciphertext, further investigation is needed.

Table 17: Good Practice Insights #04

# 04 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case I want to protect my communications and everything leaving my laptop, either e-mail, chat or a file transfer should be encrypted.
Solution GoldBug sends either chat, and emails, as well as transferred files encrypted. The transmission takes place as ciphertext, which is transmitted like a website with the HTTPS protocol.

Source: Own Case.

***

Access-Control: Login into the Application (Method)

The entry of a password for starting an application is extremely crucial. With this, for example, the encrypted containers will be released and loaded into the temporary RAM memory to enable the necessary decryption e.g. through the private asymmetric key.

Inventory taking, structural analysis and descriptions of the functions

The GoldBug Messenger maintains basically all user data in an encrypted way. If someone would remove the hard drive; on which the installation is saved, and look at the files, no relevant user data would be revealed. In particular, of course, no data will be published, which would give you clues about the components necessary for encryption. To enable the necessary cryptographic components, a master password is required, that must be entered at the start of the application.

This password is not used as it is defined, but it is converted via a hash function in a new password string - so that a much longer passphrase is generated, in which in addition also further random characters - known as cryptographic salt - are added.

Furthermore, there are in principle two methods for GoldBug login provided: Once you can define and enter a passphrase, also there is the possibility to define a question and answer phrase. Both methods do not save the password itself on the hard disk, but only the generated hash values; and, in the question-answer method more random values are additionally supplemented further (compare the user manual for the technical process).

By maintaining both login methods, a potential attacker it is made further more difficult, as they do not know, which of the two methods has been used by the user. Thirdly - and this is here the assessment to be subjected function - the user can use for the input of his password respective his Q and A phrases also a virtual keyboard.

Figure 07: Virtual keyboard of the GoldBug application

Source: Screenshot of Goldbug

For example, it is conceivable, that an attacker has installed on the machine of the user a key logger or might sniff in real time the keystrokes. Then, with access to the system, they could copy the installation of the software and find the login password via a keyboard log and control the application.

"If you encrypt end-to-end, the attacker is forced to use specific monitoring (rather than mass surveillance), for example, by bugging keyboards", confirms the American scientist James Bamford (2015).

Since this therefore with functioning encryption often is the only realistic target for a third party, the users should enter their passphrase to open up the application possibly always with the Virtual Keyboard (VK)! For this purpose just the mouse is used and no keylogger can track any keystrokes, because the mouse only generates a "click".

The virtual keyboard is part of the application, and not a plugin or a predetermined part out of the operating system. Comparing it with a virtual keyboard on a mobile operating system, one would also point out, that the keyboard should come out of the application, because it remains independent of the operating system. The virtual keyboard of an operating system could record inputs unnoticed, so that a virtual keyboard of an application - if it exists - is preferable.

Selected method for studying and function reference

The selected examination is intended to refer to the operation of the virtual keyboard in GoldBug. The question consists in two aspects: first, could a key logger record the input of the virtual keyboard, and second, works the virtual keyboard also in different operating systems and languages versions? The research method of this example is to show, that access to the system and application should be a key element of an audit. As explained above, this examination is especially for encrypted applications a linchpin, to complicate for attackers the possibility of obtaining an attack on the security of the entire application.

Conduction and findings of the examinations

Ad 1: We have installed a keylogger on a Windows system. In order not to promote key-logger tools, the concrete used tool should not be further specified here. Then the virtual keyboard of the application was used. The results showed, that the key-logger could not record keyboard characters when entering the passphrase by the virtual keyboard.

Ad 2: Further, a GoldBug installation was created with the language files on a German operating system and the log-in process using the virtual keyboard was performed, which led to the correct result. Then, the application has been closed and we deleted at the file level in the installation path "/translations" the German language file "german.qm". Then, the application has been started again and the language switched automatically to English as a default language version (because the German translation file was no longer present). Now the password has been entered also via the virtual keyboard and also the application opened accordingly.

This test shows clearly that the support for international language characters has been implemented correctly according UTF-8.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

The implementation of the login process can be regarded within the GoldBug application as extremely mature: First, there are two methods to define the login, further is - regardless of the method chosen - not used the selected password, but a longer passphrase is generated, which is derived by a hash function, and provided with additional random values.

Then there is the possibility to enter the passphrase without specifying a keyboard by the hardware or the operating system: The GoldBug application provides its own virtual keyboard.

If you compile the application for a Windows-10-tablet or laptop with touch screen, which can execute a Win32 executable, it can be seen, that the virtual keyboard is freely movable as a pop-up window and not as by the operating system given virtual keyboard attached at the bottom of the screen.

This is merely a layout or habituation question, to find besides the virtual keyboard of the tablet also the in the application predefined virtual keyboard.

Table 18: Description of findings 3.05

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
Potential for Improvement ./. ./.
Strength ./. ./.

The following method can be also recommended as an improvement of logins: The usage of a file as a key file to generate the password for login from the derived hash of the file. However, this process makes only sense, if the file is not on the system - since an attacker would rehash all files on the disk and then try the thousands of trials. Since an USB dongle with a key file as login would be not as practical as one in the head stored password, should this recommendation not be indicated as a finding, but only be addressed briefly here.

Appraisal of good practices in comparison with other similar applications

Comparing the ability to record the password for the other six open source messengers, it is clear, that none of the below mentioned other comparable applications offers a virtual keyboard on the application side.

Although CryptoCat works as a browser plug-in, a key logging would also be possible here (also for a planned Desktop version). RetroShare even offers the possibility, that the user stores the login password. This can certainly be a user decision, which takes place more or less at own risk without warning at the login procedure. However, the application can then be executed by any other attacker directly, when an unauthorized copy of the installation has been made.

Authentication measures, such as the Socialist-Millionaire-Protocol (SMP), get therefore a decisive role as complementary verifying the authenticity of the other person with manually entered passwords.

This is so far only given at OTR-XMPP clients, which procedures of logins - for example, through various methods and the addition of cryptographic salt - are not subject of this investigation.

First, such an investigation would turn out - considering the high variety of OTR-XMPP clients - possibly as divers´ and furthermore study an architecture at the applications, which is not aligned with encryption: The encrypting element (OTR) is introduced only through a plug-in variant with these clients. It therefore concerns only the transfer of the message - but not whether the plugin hosting client (the XMPP-chat-application) stored the texts obtained possibly again in plain text after decoding in the local databases of the XMPP-cient.

The OTR usage is no guarantee, that the chat client stores the buddy list or received messages on the hard disk encrypted, and also does not provide information about whether a login into the chat application can easily be eavesdropped or which login-key-strength lies behind it.

Thus, OTR is a plug-in solution, which is to be assessed as critical in conjunction with a host: Java, for example, was as a plug removed from browsers and abandoned (Dalibor 2016) and crypto solutions are seen as a plugin in the browser as extremely critical (compare Ptacek 2011, Arcieri 2013).

The encryption with the plugin OTR in an XMPP-host thus says nothing about a login, which was to examine in this section, and its security standard for the Messenger host.

GoldBug uses with a password with a minimum length of 16 characters and the underlying conversion using the hash function in consideration of cryptologic salt an excellent procedure to secure the login. The virtual keyboard for entering the password is an ideal additional protection as a supplement.

Table 19: Indicative BIG SEVEN context references 3.05

CryptoCat No virtual keyboard given. CryptoCat is a browser-plugin.
GoldBug High requirements for the password-length, two different login-methods, consideration of cryptographic hash-functions, existence of a virtual keyboard, which is independently given from the application.
OTR+XMPP No virtual keyboard given.
RetroShare No virtual keyboard given. Emerging risk due to the decision of the user to use the option to save the login-password for an auto-login process. No awareness notification to the user in this process.
Signal No virtual keyboard given. Does not meets the standard of 16 characters for a minimum requirement regarding the password length.
SureSpot No virtual keyboard given.
Tox No virtual keyboard given.

As further research consists the investigation of the minimum requirements of the password length in each application as well as the strength and method of the hash and other cryptographic functions, which will be considered in the login process for the comparable applications.

It is desirable that also other applications consider different login method and a virtual keyboard in the future, since the protection of access to the own system plays an increasingly important role, if online connections, certain operating systems and hardware components are not tustworthy, to not copy the password entries and handing it over to third parties. Compare also the discussion in the San Bernardino case where the login password should be unlocked of the phone of a Murderer by Apple: Because after 10 times incorrect entering the login password, all user data on the phone will be deleted.

But Apple refused to the FBI, to change this lock in future phone production, as this could be a gateway then for anyone. The user therefore also spoke of a future #FBIOS - not of Apple's "iOS", but an operating system, that will be programmed with a governmental monitoring institution. (Https://en.wikipedia.org/wiki/ FBI_v._Apple & https://en.wikipedia.org / wiki / 2015_San_Bernardino_attack). The monitoring of a telephone during operation and of data, stored in the cloud by the operating system vendors, is another risk aspect, that needs to be differentiated in the context of access to systems.

In addition to protecting the own login passwords therefore hardware and software is also to be investigated regarding possibly inserted so-called "source telecommunication surveillance / Telephone Tapping" (in German language Telephone tapping is abbreviated as: Q-TKÜ), that means, to take the recording, where it is entered: at the interface of the user in plaintext.

Due to the technical possibilities of the "listening in real time" (Simonite 2015) and usage of operating systems or (any) apps for that, encryption is to be regarded now as a human rights issue, when everyone can be a subject of monitored online communications and this is a mass phenomenon (compare also Amnesty International 2016): If everyone is potentially monitored, and their communication is structurally always recorded, everyone should not only secure the own system and application access with passwords, but also encrypt the online transfer of their communication - with a manually and together with the communication partner secretly defined end-to-end password.

Again, the end-to-end encryption does not mean to follow an automatic process, but manually typing the symmetrical password, which consists out of 32 random characters. And this also applies to login passwords with regard to access to the application.

Privacy advocates and security experts recommend regional hardware and the use of an open source operating system, so a Linux system. The three action measures in the age after Snowden thus are: 1. Encrypt your online communication, 2. Keep your passwords secret and 3. Learn and use the Linux operating system, as this guarantees even with the random number generators, which play an essential role in the encryption process, a transparent process.

Table 20: Good Practice Insights #05

# 05 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case My laptop has been stolen yesterday. How can I prevent in the future, that others use my communications instances?
Solution It is crucial to equip the login in the communications application with a password. GoldBug uses a 16-character long password that is then converted into an even longer hash string. Furthermore GoldBug offers two different login methods, to make it extremely difficult for attackers to log into your communication application.

Source: Own Case.

***

The access to the IT system will develop in the future as one of the largest gateways to infiltrate encrypted environments. It is therefore not so much about breaking the math behind the encryption, it will prove to be access-proof with the right algorithms and with multi-encryption - but the access to the hardware, to the storage of passwords and private keys, or even the unnoticed install of keyboard loggers, will be exploited as potential weaknesses, as already explained for the login password in the section above.

Thus, it is crucial for encrypting applications, that, when the hardware is lost, no one can get data and identifications out of the encrypted application. Particularly in the mobile operating systems for tablets and phones it has been clarified, that operators like Google, Apple or Microsoft - if encryption out of the data is available - have full access to all data on the phone - because these operating systems most fundamentally must be operated with an Internet connection to the manufacturer.

Three quarters of phone users of the operating system Android do not encrypt their hardware (2014). Although newer versions should allow encryption for the mobile operating system, it is not excluded, that the provider retains still an access key for it or that the password entries can be tapped in addition.

Therefore, a "Crypto-War" should not be based on the question, whether we encrypt or not, but better on which operating system the user data is better encrypted and stronger protected against access by suppliers and third party: Apple, Windows, Android or Linux. The division of society in digital security arises, when citizens were not able to learn the secure Linux and encryption. Therefore, it is important to store the personal data also in encrypted containers - on the mobile system as also on a laptop or desktop.

Thus, not only the research field of the storage in and encryption of data in databases such as SQLite or PostgreSQL and further is opened, but also the search in encrypted databases will remain an interesting field of research as a perspective.

Inventory taking, structural analysis and descriptions of the functions

GoldBug Messenger installs itself such that any use of data and as far as possible the initialization information is stored encrypted.

Hereinafter, the storage and filing of transferred and to be transferred user data is intended to be explored in depth and assessed: The data in GoldBug is stored in encrypted SQL databases. These are individual files, that can indeed be viewed with a SQL-browser, but then only contain ciphertext. Content is thereby protected.

Encrypted and authenticated Containers: Relevant data, that the application retains locally, is stored in encrypted and authenticated containers. CBC and CTS encryption modes are used with a variety of block ciphers. Encryption and authentication occur as follows:

1. If the size of the original data is less than the specified cipher's block size, the original data is re-sized such that its new size is identical to the cipher's block size. A zero-byte pad is applied.
2. Append the size of the original data to the original container.
3. Encrypt the augmented data via the selected cipher and specified mode.
4. Compute a keyed-hash of the encrypted container.
5. Concatenate the hash output with the encrypted data, HHash Key(EEncryption Key(Data || Size(Data))) || EEncryption Key(Data || Size(Data)).

The architecture of GoldBug also includes a mechanism for re-encoding data, if new authentication and encryption keys are desired (also compare the project documentation in the source code, 2014).

Selected method for studying and function reference

As method for the investigation of the databases should be sought the access with appropriate tools into these databases, to check, whether there usage-content is available, which is not encrypted.

While chat will be exchanged directly from the kernel to the user interface, it is, for example, for e-mail, required, to store received and sent e-mails on the hard disk. Because here we have to consider a greater amount of data and longer retention periods, especially the file "email.db" should be analyzed within this assessment.

The file is located in the sub-path of the GoldBug communicator: ./spoton/email.db. As tool a helper application is here considered, so that each reader can repeat this test at any time. The Mozilla Web Browser Firefox offers an addon plugin, which allows to introspect SQL databases: SQL Browser. With that tool we looked into the encrypted file email.db.

Conduction and findings of the examinations

The SQL tool we have installed within the version 3.8.11.1 of the Firefox browser with the Gecko engine version 42.0. By setting up and using the POPTASTIC email function an e-mail inbox has been loaded into the GoldBug client, so that the file "email.db" has itself increased accordingly on disk level.

The file has been then opened within the SQL Browser (compare Figure). It is found as a result, that the tables are only filled in the file structure with ciphertext. There is no user data, which is not encrypted. The code review for opening the database and in turn also encrypting the database (by the application) shows a clean implementation of the process.

Figure 08: Database email.db with ciphertext

Source: Own screenshot of SQL Browser.

Outook: This section refers to an evaluation of the encryption function of the e-mail database. The application GoldBug has furthermore within other databases also a search functionality - for example, in the "URL.db, within which the data for the p2p URL website search is stored.

This shows, as at the beginning already explained, further research needs how a search in chipertext can be successfully designed. This field of research offers additional theoretical questions for universities, as that this issue could be further developed theoretically within a review process. The audit process therefore relates to the encryption of information to be deposited within SQL databases, as it was practically examined for both, email.db and for urls.db.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

Risks and weaknesses have not been found while conducting the analysis of the storage of the encrypted e-mails in the database SQLite. It is an advanced implementation and also an adequate claim, to deposit all relevant user data only encrypted on the hard disk.

One of the strengths of the application is, that this is done automatically and without major installation effort for the user, certainly also by the adaptive configurability of the implemented SQLite databases, in addition to PostgreSQL.

Table 21: Description of findings 3.06

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
Potential for Improvement ./. ./.
Strength ./. ./.

Appraisal of good practices in comparison with other similar applications

The encryption of user data should be a fundamental issue for the further open source Crypto-Messengers. An analysis was already deepening extended within another previous chapter with regard to the data of the login, which needs special protection. Not all further here involved, open-source Messengers consider in their documentation in an elaborated way their options of the encryption of data, which is to be stored on the hardware.

Table 22: Indicative BIG SEVEN context references 3.06

CryptoCat No sufficient information about encrypting the saved data and applied databases in the documentation
GoldBug GoldBug encrypts the saved data and has a technical specification about the process. Compatibilitiy to SQlite and PostGres databases.
OTR+XMPP No sufficient information about encrypting the saved data´, depending on the chosen client, no common standard for the different clients.
RetroShare Retroshare encrypts the saved data, e.g. of partial files.
Signal No sufficient information about encrypting the saved data and applied databases in the documentation.
SureSpot No sufficient information about encrypting the saved data and applied databases in the documentation.
Tox No sufficient information about encrypting the saved data and applied databases in the documentation.

The aim of this section is not to analyze the code base of the further Messengers, but to pick and indicatively to involve within each study context the existing information from the projects - here: regarding encrypted storage of the user data on the hard disk. It is evident from the documentations, that only sparse information is given from the further to be compared Messengers - how data is stored: encrypted and to what extent.

The search function in an encrypted database has to be assessed besides GoldBug in the client RetroShare as more advanced or at least in a richer perspective than in the other clients.

The raising of consciousness not only in terms of enhanced documentation in general, but at this point of the encrypted storage of data in particular, therefore can be attributed to all clients. It provides in particular for students an ideal research area for further comparative study.

Table 23: Good Practice Insights #06

# 06 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case I've sold my old hard disk, there was still a GoldBug installation on the hard drive. Can now the buyer read my communication?
Solution No. Compared to numerous other programs is at GoldBug all personal data, that is written to the hard disk, stored in encrypted databases. Even the search of the data in the operation is carried out in the encrypted data indexes.

Source: Own Case.

***

Penetrationtest: Account-Firewall

The connection to a neighbor should be on the on hand for a new user or tester of the software easy to manufacture. This is given in GoldBug clients by a predetermined project server connecting each participant. Later, then everyone within his circle of friends also should have the option to build an own chat-, e-mail- or URL-server. The contribution of each user to create a custom listener for his friends is to be understood in the sense of creating a decentralized network.

In addition to the simple creation of a stable connection to a neighbor, it is on the other hand also about, when someone offers a connection through an account on their server, that here the connection is only available to those, who are authorized to connect. For that, in GoldBug clients will be offered the option for an established listener, to create an account for a specific user.

An account is characterized by a username and a password. Regarding the password design the connection to the network for users of this important element is investigated in more detail in the last chapter evaluation (3.20).

It should firstly go in the sense of the previously described contents in terms of accessing the system about the blocking of connection attempts, that may be exercised by users without appropriate account access.

Inventory taking, structural analysis and descriptions of the functions

If a listener as a chat server was created in the client GoldBug and was changed to account-based formats, then the account functions as a firewall. Only for users with the appropriate account name and password, it is possible to connect.

The Accounts procedure is as follows:

1. Binding endpoints are responsible for defining account information. During the account-creation process, an account may be designated for one-time use. Account names and account passwords each require at least 32 bytes of data.
2. After a network connection is established, a binding endpoint notifies the peer with an authentication request. The binding endpoint will terminate the connection if the peer has not identified itself within a fifteen-second window.
3. After receiving the authentication request, the peer responds to the binding endpoint. The peer submits the following information: HHash Key(Salt || Time) || Salt, where the Hash Key is a concatenation of the account name and the account password. The SHA-512 hash algorithm is presently used to generate the hash output. The Time variable has a resolution of minutes. The peer retains the salt value.
4. The binding endpoint receives the peer's information. Subsequently, it computes HHash Key(Salt || Time) for all of the accounts that it possesses. If it does not discover an account, it increments Time by one minute and performs an additional search. If an account is discovered, the binding endpoint creates a message similar to the message created by the peer in the previous step and submits the information to the peer. The authenticated information is recorded. After a period of approximately 120 seconds, the information is destroyed.
5. The peer receives the binding endpoint's information and performs a similar validation process, including the analysis of the binding endpoint's salt. The two salt values must be distinct. The peer will terminate the connection if the binding endpoint has not identified itself within a fifteen-second window.

Selected method for studying and function reference

As method here should be created a practical verification of the firewall, which is implemented by an account. Can anyone else connect to a listener, as the one, who has the account information?

If a connection to the listener on the specified port is possible, so to say to break unauthorized into the system, should be checked with a penetration test. Thus the penetration test determines the sensitivity of the system to be tested against such attacks.

The term penetration test is sometimes used mistaken for an automatic vulnerability scan. While this is done mostly automatically, it requires in a real penetration test manual preparation in the form of sighting of the test piece, plan the test methods and objectives, selecting the necessary tools and finally the implementation. The security scan again differs from vulnerability scanning through the manual verification of the test results.

The penetration testing can be supported by various software products. These include port scanners as Nmap, Vulnerability Scanner as Nessus, sniffer like Wireshark, packet generators as HPing 2/3 or Mausezahn and password crackers as John the Ripper. In addition, increasingly are more tools available, that are designed specifically for security testing, often due to the verifiability of the source code from the open source segment and tailored to very specific test areas: ARP0c for example is a link Interceptor, another example of such a special tool is Egressor, to check the configuration of Internet point-to-point routers (compare also Wikipedia).

The German Federal Office for Information Security (BSI, as quoted) has developed a classification schema, how to describe a test. Essentially six different aspects are considered as: information base, assertiveness, scope, approach, technique, starting point. Based on these criteria an individual test then can be put together with an administrator.

Our penetration test of an account in the program GoldBug should therefore be carried out as a further empirical part of our review.

Figure 09: GoldBug – Account Firewall for Accounts and IP-Addresses

Source: Own Screenshot of Goldbug

Conduction and findings of the examinations

To perform a connection to the account-based listener within GoldBug, we first looked at the processes in the user interface as well as the programming within the code base (compare Section 3.20).

It was then first tried to establish a connection with an account, of which we knew the account name and password. The connection succeeded.

Further attempts with the wrong account information were not successful. Even with a port scanner it failed to address the system using the account-based listener default port, such that a communication of a user might have worked.

The corresponding protocol of the TLS connection also provides further reassurance, that no such unauthorized connection can be established. The same procedure was also performed with a GoldBug client, which did not connect via the HTTPS protocol, but only had a HTTP configuration. Again, it did not succeed to connect without account details.

The account firewall has successfully kept state against the here attempted connection tries.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

With regard to the account function to prevent unauthorized connections, there are from our tests no weaknesses or risks to describe. Also, in the code review no objection has to be pointed out.

Table 24: Description of findings 3.07

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
Potential for Improvement ./. ./.
Strength Authorization concept, that is not linked to a key Informational

Potential improvements were not identified. The strength of the implemented account function is in an authorization concept, that is not linked to a key that encrypts the message (compare Retroshare).

Appraisal of good practices in comparison with other similar applications

Compared to the other messengers it turns out, that they can not be aligned on a P2P structure. They are all client-server based using an account, so that connection attempts from unauthorized peers can not arise, if they are not to be understood as a direct attack.

Only the two clients Retroshare and Tox rely on a DHT, in which numerous IP connections in addition to the account-based connection to the host or clients used occur.

Table 25: Indicative BIG SEVEN context references 3.07

CryptoCat Password based login, no option to run the application in a p2p network.
GoldBug P2P and F2F Modus. Server and Client, and also Client-Client-Modus. Web-of-Trust over accounted Listeners - independent from encryption key. Works as firewall for connection-attempts without authorization.
OTR+XMPP Account based architecture. No option to run the application in a p2p network.
RetroShare DHT Usage with stun-technology and NAT hole punching for DHT-Peer-Connections. Firewall build upon a Web-of-Trust architecture tied to the encryption key.
Signal Password based login, no option to run the application in a p2p network.
SureSpot Password based login, no option to run the application in a p2p network.
Tox DHT Usage with stun-technology and NAT hole punching for DHT-Peer-Connections.

Table 26: Good Practice Insights #07

# 07 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case I run a chat server for friends, who use GoldBug. I want only these friends and no one else to use my server.
Solution GoldBug has the function, to create a chat server, integrated into each client. A so-called listener can be made in the P2P-Modus for all users, or using the account function in the F2F mode only for friends. Friends will receive then a username and password to log in.

Source: Own Case.

***

Assessment of the Documentation: Usermanuals e.g. hosted at Wikibooks

Further up the function was addressed by the example of another application, with which it can be convenient for users, to store in the installation path of the application the password to login into the application permanently (in plain text).

Now, if an attacker uploads a copy of the installation, or otherwise can tap it as is, any certainty about the application and the private key used has gone.

It is therefore important, as this example shows, to educate users on how to use the functions and document functionalities within manuals and handbooks. Likewise, almost all presented at the beginning IT-assessment-manuals require in each assessment a study of the existing documentation and operating instructions of a software. Furthermore, an essential element in particular the DIN-certifications is to evaluate, how far consciousness (the awareness) of users is promoted to deal with the particular system or an organizational, prozessural or electronically illustrated IT-context.

Therefore, the user-manual for GoldBug within this assessment section should be examined in detail.

Inventory taking, structural analysis and descriptions of the functions

GoldBug is an application, that has to this open source project so far English and German-language documentaries because of the voluntary contributions. The documentation is given in many ways:

• The most extensive documentation consists within the source code of Spot-On itself. The code is not only written within machine language, but also contains many readable comments and advice on how certain functions or next steps are to be understood.
• There is also a technical documentation in the source repository to the cryptologic, mathematical and programming-language-oriented processes and functions. This is attached at any installation of GoldBug Messenger next to the source code. So anyone, who downloads the installation files, obtained at the same time the source code and its documentation supplied.
• For the project are in addition to the technical project documentation also two user manuals for the end-users given. These are open source and editable within the "Wikibooks"-project of the Wikipedia placed and also on the homepage of GoldBug Messenger available - and include (in the single-column layout) about 50 manuscript pages of reading material to get deeper read within the cryptologic functions of GoldBug.

Both, the English-language as well as the German-language user manual are current. Since the manual was written in German, and the English translation seems to possibly represent an automated translation (by google) and at present time a not yet fully proofread version, should the analysis related to the current, very comprehensive and detailed user manual within German language.

The German-language user guide, which serves as the basis for further analysis within this assessment, is found in the path "/documents" of each installation file from GoldBug in current status and at Wikibooks:

Figure 09: GoldBug – Handbook and User-Manual of GoldBug Messenger

Due to the ongoing development of the software, the English as well as the extensive German user manual is considered as "work in progress".

Selected method for studying and function reference

Because the application Goldbug not only offers encrypted chat, but also secure e-mail within a full functioning e-mail client, and besides that also file-transfer, plus Web search within a URL database - besides numerous options for each end-to-end encryption - , the manual should be checked, to see, if it provides a complete overview within the essential main features of the application. As well as: If the information relevant for the encryption functions is also explained extensively in detail.

Conduction and findings of the examinations

The German user manual has been printed thereto corresponding to the Wikibooks-text once in a one line respectively one column layout and came up with more than 50 pages.

We then counted the lines and figures per main function to analyze a quantitiative distribution:

Table 27: Allocation of function, number of pages & screenshots in the manual

Function & Key
of GoldBug Application
Key Type Number of pages
in the Manual
Number of
Figures & Screenshots
in the Manual
Chat a-symmetric pages 18-24 &
42-44 = 12
6
E-Mail a-symmetric 25-29 = 4 3
Poptastic a-symmetric 30-32 = 3 1
URLs a-symmetric 39-41 = 3 5
Rosetta a-symmetric 45-46 = 2 1
Magnet for StarBeam-File-Transfer symmetric 34-38 = 4 4
Magnet for Groupchat symmetric 33 = 1 1

Source: own overview.

The quantitative analysis shows, that the essential functions for each key are described in the User Manual in detail and the features are also iluustrated for the user by numerous pictures and screenshots.

For a qualitative analysis, the individual sections were read accordingly and rated from the content: There is no significant functional section, which may be referred to the substantive examination as incomprehensible or qualitatively poor. Rather, a good reader guidance and derived explanation of the functions is given in many places, so that it can also be understood well by a user without in-depth technical skills.

The comparison with the English manual on the other hand looks a little incomplete, it is yet to provide further translation respectively proofreading work in some sections of the original German document. However, since the manual should be supplied to the audit in the language, within which it seems to have been worked out primarily, this remains a side note. More translations are also desirable within other languages and can by any user created through an entry in Wikibook by means of own contribution.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

For the German user manual therefore remain after our review of quantitative and qualitative review no improvements. Basically every reader wishes depending on prior knowledge here and there a some deeper description, in our estimation, however, is any significant main function of the client described comprehensively and within sufficient depth and also very understandable.

In a recommendation - and this is true in principle and separated from the rated application - it is always desirable to be able to find the changes also regularly in the current user manual for each new release. Furthermore, the changes in new versions of the application are also shown in full detail within the release notes of the source documents.

Table 28: Description of findings 3.08

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
Potential for Improvement ./. ./.
Strength ./. ./.

Appraisal of good practices in comparison with other similar applications

The installation files of the to be compared programs have basically integrated no documentation or even source code. Some programs documented within a short FAQ or Wiki the essential questions, however, a detailed documentation of the encryption and the process functions in a format understandable for end users is not, hardly, or only rarely given.

GoldBug Messenger has a very detailed user manual in comparison to further open source messengers. The explanation of crypto functions therein is also documented extensively. The further applications have their cryptologic functions based - as part of the full documentation - only less in an integrated approach of documentation and remain therefore only fair to poor within our review.

Table 29: Indicative BIG SEVEN context references 3.08

CryptoCat https://github.com/cryptocat/cryptocat/wiki - 14 short article pages in a wiki.
GoldBug https://de.wikibooks.org/wiki/Goldbug - over 50 pages as documentation of a tutorial.
OTR+XMPP https://developer.pidgin.im/wiki/Using%20Pidgin - 8 categroies as FAQ one e.g. with up to 75 questions andshort answers, resulting in several pages. Less description text in terms of a tutorial or for crypto content.
RetroShare http://retroshare.sourceforge.net/wiki/index.php/Documentation - 36 Wiki Articles including tutorials.
Signal http://support.whispersystems.org/hc/en-us - hundred questions and short sentences as answer resulting in a few, circa 10 FAQ pages. Articles or tutorials or technical documentations are mostly rare.
SureSpot https://www.surespot.me/documents/how_surespot_works.html - circa 3 pages with 3 chapters and one FAQ with 23 questions.
Tox https://wiki.tox.chat/doku.php - circa 11 pages documentation including a few questions in the FAQ.

For the other applications it has to be pointed out, that many ad-hoc required information or questions from users are stored within other forms of communication e.g. in a wiki (Tox) or a forum (Retroshare) - or is stored in the archives of a mailing list, but does not systematically open up this as an information resource and often remains high under the standard of a manual documentation, as created by users of the community of the project GoldBug.

The strongest Messengers in terms of documentation are Retroshare and GoldBug and some OTR-XMPP clients, in particular the most well-known client Pidgin presents an equally detailed documentation, but consisting only of FAQs and containing no dedicated crypto chapter or tutorials.

Table 30: Good Practice Insights #08

# 08 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case I have heard in this study for the first time of GoldBug, and would like to gladly read in depth about Crypto-Messaging. Where can I do that?
Solution GoldBug has deposited an extensive manual at Wikibooks and the project site. The texts are also like the program all open source, so that users can also translate into their referring languages.

Source: Own Case.

***

Inclusion of other Audit-Reports & Comparison with other Open-Source Messaging Software

An audit should never be done isolated only for a particular application, but an auditor - as well as a developer and a community member, who feels close to an application - should include ideally the "neighborhood", the context to the further, comparable developments, and a state-of-the-art at least for two comparable applications into the research, field testing respectively development proposals.

Below should therefore on the basis of already written audit reports to the similar, possibly comparable open source messenger applications first

• initially put together an overview of available audit reports. Here is certainly to be considered, that for applications, that already exist for several years, relevant audit reports may already be given (including inventory taking of given audit metrics).
• Second, is to be investigated, whether the relevant audit reports, the texts of other assessments are included by the auditors (view of the auditors). It should be noted, that many auditors get only active, when there is a financed contract. Often with just a few pages of text, the application-brand is then revalued for marketing purposes with the brand of the audit-company. Thus, free and gratuitous auditors are therefore to promote and requested, that they include comparisons to other audits and applications in a dedicated audit particularly. A funded audit will though rarely embed comparisons.
• Third, also should an impression be examined and combined, whether this claim is also lived by the developers and teams of the comparable Crypto-Messengers: contributing to a good-pratices sharing community, respectively being committed to reflect and document options for innovation: How is the community networking within this (even special) field of Crypto-Messengers? And will the in the communities praised and supported products being able to replace the unencrypted applications soon?

Innovations, successful integrations, good-practices models should be shared jointly and valued - and not sacrificed quietly as plagiarism. The shared learning takes place by mutual reviews, community contacts and evaluations and verifications in regard to the common approach - this is technically e.g. created by bridges, conversion-options or standardization of certain functions; and also this spirit is created by auditors bringing good practice models respectively blogger mentioning various alternatives within their references.

References and mutual credits are the principle of a woven web as well as mutual learning. It is therefore difficult to understand, why, for example, the word "Torrent" should not be mentioned on various edonkey-boards or even not linked with an URL - while nobody complains about censorship!

Inventory taking, structural analysis and descriptions of the functions

For the GoldBug Communications Suite consists far besides the manual by Scott Edwards (Editor and other authors, 2014) numerous reviews and analysis assessments of the functions by editors, experts and bloggers (compare e.g. Cakra 2014 / Constantinos 2014 / Demir 2014 / Joos PCWelt 2014 / Lindner 2014 / Security Blog 2014 / Weller 2014, Dragomir 2016, et al.).

These contexts we have considered for the planning of this audit.

The written source code, the programming of the functions as well as the detailed release changes ("release notes") provide valuable additional information on the dimensions, that an audit can address. In addition, applied should be also standard methods and implications issued by the guidelines of the audit manuals.

The audit - as carried out here and derived within the first two chapters - should cover not only a code review and the essential functions of the application, but also include the essential audit areas, instruments and methods of the international prevailing IT-audit-manuals with the aim of to achieve maximum inspection width.

As seen, it is then not just

• about mathematical, cryptologic or programmed functions particularly in a code review, but e.g. also
• about an opinion regarding the awareness of the user, to be able to use functions with awareness of the corresponding set-up or
• about the contextual relationship of the individual functions in relation to transparency, confidentiality, proper implementation of an interaction, where necessary, and not least
• about an assessment also of process and operator safety
• as well as about an indicative assessment of the environment of the other, comparable applications, in which the to be investigated application is being audited,
• and many more ..

In our self-reflection, we note, that this audit has spent a lot of time on a broad-based research, and that the documentations, that are available about the client GoldBug, include numerous references and links.

Selected method for studying and function reference

To examine the developmental activity of the application GoldBug, the project should be examined therefore in terms of the source code, the release notes and existing documents, which passages are to be considered for the now present audit. The chosen method is therefore a document analysis, which should relate to three areas: This relates to the reflection of our own work as auditors: Have we included enough broad references?

Likewise, should on this basis, the reflection of the developers of the application and the kernel examined, whether they indicate, that learning, reviews and audit reports of other applications or theoretical concepts from the literature have been included in the development. Finally, the existing audit reports and texts are used of the further comparable open source applications to evaluate their processes in terms of reviews, learning and creating a contextual environment.

Conduction and findings of the examinations

As shown above, there are numerous reviews of GoldBug on the web (see above), which provide a first basis for further parts of an audit report. Moreover, in addition to an external review as well the processes of internal self-assessment by the developers shall be included:

The development of the GoldBug client shows a significant commitment in the sense of a research project. Both, the architecture of the kernel spot-on and each interface, Spot-On GUI as well as the here corresponding GoldBug GUI, are developed by the developers as a hobby in their free time. There are according to their statements on the websites no third financial resources available and the development is made possible by the investment of private time. The project test server should have been funded also by private funds.

The source code has many existing standards implemented and also with newer ideas (and partly for the first time worldwide) taken much forward, to mention e.g.

• the magnet URI standard was based on cryptologic functions and values,
• Introduction of the concept of Callings for end-to-end secured (a)symmetrical communication,
• use of numerous solutions in terms of the key transport problem (Geminis, Instant Perfect Forward Secrecy (IPFS), Repleo etc.)
• Implementation of Socialist Millionaire Process (SMP),
• encryption using the NTRU algorithm & ]]w:ElGamal_encryption|ElGamal algorithm]] next to RSA,
• possibility of communication between users of different encryption algorithms (for example, RSA to ElGamal)
• Supply of ephemeral Forward Secrecy keys in the existing email-client of GoldBug,
• Chat via e-mail server (POPTASTIC)
• P2P-URL-network for a web search, the data will be encrypted and stored as it is not yet comparable,
• Groupchat based on symmetric encryption,
• Possibility of [{w:Hand#By_hand|manual]] definition of end-to-end passphrases for encryption (and not only for an authentication function as within the SMP function)
• network-oriented examination method for decoding within the echo protocol to minimize metadata recordings,
• encrypted chat and file transfer via Bluetooth,
• and further, to name just a few innovations.

In addition to the innovations, the references to existing libraries, concepts and comparable models are sufficiently well referenced and documented, so it can be concluded, that the developers are trying to consider the state of the art relatively good and to implement the developments, that are not yet included in other clients, in an innovative way.

It can thus be concluded that the project development from GoldBug respectively the Spot-On kernel includes numerous references for market standards and innovation options. Thus, due to the range of functions within GoldBug, certainly further research is needed to expand the fields mentioned above and also to compare our review dimensions within special (respectively even dedicated) reports.

We as auditors have us accordingly familiarized also with other similar open source applications - such as already presented above - and carried out a search for their audit reports: With the question of whether these have put out their feelers for some context variables.

Therefore should for the each said seven applications - our BIG SEVEN - also the following chart of audit metrics be created about conducted audit reports respectively therein referenced findings:

Table 31: Open Source Crypto Messenger Applications and their Review Reports

Application Authors of Security Review Audits etc. # of
Findings
# of
ext. refs/lit
Extent /
# Pages
CryptoCat Thomas (2013).
Wilcox (2013).
Diquet et al. (2014).
Green (2014) [Blog-Entry].
1
7
17
several.
5
10
13
12
1
27
35
1
GoldBug Edwards, Scott (Ed.) et al. (2014).
2014/2015: Reviews as given (aaO).
2016: This Review & Audit.
./.
as given.
as found.
50
12
see Lit.
50
as given.
as found.
OTR+XMPP Usage-Study by Developer GoldBerg et al. (2008)
Green (2014) [Blog-Posting]
Quarkslab SAS (2015)
./.
0
14

20
5
./.
10
40
RetroShare ./. ./. ./. 0
Signal Bader et al. (2014) several. 49 17
SureSpot ./. ./. ./. 0
Tox Developer-Comment from
„Ex-Contributor“ (2014)
1 0 1

Source: Own collection and research, to be further extended.

Very few of the audit reports reflect references respectively comparisons, benchmarks or good-practice models specified in detail for other similarly open source, and thus comparable, messengers for the reader. Also not all audit reports refer to referencing literature; that are mostly not over a dozen citations.

Also for the variety of proprietary, non-open source Messengers such as Threema (Cnlab 2015) and further are security audits of so-called "peers" available, that supposedly may have looked through the closed source code. However, these are often only brief and consist of up to 10-15 pages (in the case of Threema even only one (!) text page) and thus remain just a formal confirmation, that a peer has seen parts of the application. An audit of a closed source crypto-application is not replicable and scientifically therefore not acceptable! It remains a Black-Box.

These - not open source applications and audits - should from our view be excluded for a professional involvement and a practical application, because "Cryptology" with "non-open source" is incompatible. Their auditor reports rather have a formal seal function for the marketing of non-open-source applications. Also the IT-media brings up from time to time and depending on the application also reports of non-open-source crypto messengers without naming corresponding open-source alternatives, or to point at the issue of non-accessible source code of such crypto applications.

• Considering OTR merely as key exchange protocol or tube, and CryptoCat as a created symmetric key chat room, seem RetroShare and Tox to have the greatest proximity to GoldBug with all its advanced security features. Although both have no audit report respectively OTR and CryptoCat as clients with a particularly long history have correspondingly different investigation reports, they should be renewed in order to include the recent developments in the market and to the standard. These reviews for OTR and CrypoCat are therefore more likely to be called bug fix reports or feasibility studies and should actually be repeated in the post-Snowden-time - with the following angles:
• Regarding CryptoCat particular on the feasibility of the use of decentralized chat server and symmetric encryption (including the problem of transporting the key online); as well ...
• ... regarding OTR in particular the inclusion of asynchronous methods, the use also of other algorithms besides RSA and safety of plug-in solutions and the introduction of a standard to encrypt the host of plugins (e.g. regarding login key length or encryption of data to be stored on the hard disk);
• regarding RetroShare it is also desirable due to the long development time to include a comprehensive and current audit with context references (for example, to GoldBug).

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

Regarding the development of GoldBug, we have no reason to note or to recommend that more external contexts and references should be included. For our own audit, we tried by the appropriate analysis, derivation and the inclusion of other open-source applications to consider this ambition: to focus not isolated on one application alone.

Table 32: Description of findings 3.09

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
Potential for Improvement ./. ./.
3.09.4.A Strength This Audit shows indicative references to other comparables Messengers Medium.

Appraisal of good practices in comparison with other similar applications

In this partial section we now want to continue to make an assessment based on our research, how far the comparable BIG SEVEN Messengers include references and context variables and innovative developments.

Table 33: Indicative BIG SEVEN context references 3.09

CryptoCat New development goal to offer also a desktop client next to the browser plugin. Addresses the goal to lead the market in comparision to XMPP.
GoldBug Good references to other libraries, integrated approach of new innovations. Development includes code review tickets in other projects.
OTR+XMPP OTR has a long history, development seems to be established or slowing down or even being stalled. Newer developments in encryption present a better approach (e.g. Perrin 2014).
RetroShare Includes a common learning within the development community.
Signal Tries to be innovative and establishes with many marketing references on the market.
SureSpot Shows a good practice and established model, though with less references to other developments.
Tox Does not solve needs of others and ignores external context variables due to internal co-developers references.

Consolidation of Inclusion of References

The Messenger market appears in the community between the various development projects in our assessment of the development communities and their willingness to involve contexts and external references in their development, to be quite widely, partly fragmented and competitive:

Cryptography and app development has been very dominated by a few individual experts. The further community as multipliers wants to celebrate their developers and projects partly as their "Messiah". This means that the further end users are steered. Second, it must be noted, that a further established reputation propaganda is also dependent on the financial facilities of the respective projects.

Currently, in the era after the Snowden publications there are numerous crypto-messenger projects, that compete in particular for the non-open source field among each other and have appeared on the market.

Thus, also for the remaining open-source crypto messengers and their users, it is particularly important to consider critical messages also from non-specialists references, and also to make themselves on the way to learn in the different areas, to judge the relationships to the individual development projects themselves and to not have only the functioning or non-functioning of the application respectively the source code in the view.

So we also hope with the conduction of our audit to interest a broad audience, because in a few years, the brand name of the Crypto Messengers will be more present at the end-users and be judged by how much the applications are elaborated.

Three levels of internal Crypto-Wars
The much-quoted crypto war thus appears initially to take place by incorporating appropriate elaboration of the functions in the applications at the level of the development of crypto projects themselves.

For example: a browser plug-in or a mobile messenger is to be published as a desktop version or the encryption should be supplemented by other types of symmetric respectively asymmetric encryption.

Then it comes at a second level to the community of multipliers and cryptologic experts, who advocate for specific applications - or not - or choose to ignore or even let Wikipedia entries delete *). Here the expressions of opinion emerging in blog and mailing lists are to be distinguished from written documentaries, that have a scientific or popular-scientific descriptive, but also comparative claim.

 *) In the case of GoldBug is e.g. the German-language Wikipedia entry proposed to extinction its existence
by the user "Hanno" (aka Hanno B.) in the third year (compare also Teets in regard of this at Twitter 01/2016:
As arguments were raised the in the Wikipedia often used, but very vague categories of "relevance" and "writing
style" (related to two quoted sentences). Behind the user is a free IT journalist with cryptologic school
knowledge, which would have been perfectly able to improve the wikipedia entry or to evaluate the functions of
GoldBug professionally even in a separate post. After one week the three years existing entry has been deleted,
a day later, however, the text page was acquired in another wiki.

URL: http://marjorie-wiki.de/wiki/GoldBug_(Instant_Messenger)

From a scientific perspective, we feel this is less constructive in regard of a contribution to the
accumulation of knowledge, and when cryptologists propose cryptologic tools to extinction, we consider this not
only scientifically obsolete, but also as writing experts we see this reserved to a so-called bias. Is GoldBug on
the way to be a "Sacre du Printemps"? It therefore remains only to suggest, that new generations of learners
conduct the comparative analysis with more commitment and from a neutral point of view, than to deliver themselves
to a destruction, based on whatever strategic motives.



Thirdly, the education process in a few years will have transported knowledge also to the user level, so that anyone can evaluate the technology of encryption over the Internet (and possibly even learned to compile it under Linux). Many dedicated participants and speakers on Crypto-Parties contribute to the BIG SEVEN Messengers to be tried in practice; that one finds an interested counterpart for a test. First locally, then remotely.

It is therefore an object, not to ignore the modern functional developments, and it remains nonsense, to insinuate other plaintext scandals or to delete accumulation of knowledge - in the hope, that the popularization of cryptologic knowledge would develop slower or that the knowledge would lose quality or respectively, that other applications would have more time for qualitative developments, such as the following case studies illustrate. Only a broad public discussion helps, when supposed experts share their knowledge exclusively in alleged expert circles. We are on the way, that cryptologic expertise will be commonplace. Also, this shows still an indicator of the digital division of our society.

Influence of the public Crypto-Wars on the internal Crypto-War

With these three stages of the crypto-war the crypto-war is therefore initially considered as an internal self-destruction of the individual projects, which would not be necessary. The external crypto-war, which is defined by privacy advocates and in political discussions, may perhaps also influence the internal development of the crypto-projects, if (induced) funds and marketing options are made available for the projects.

It is therefore necessary to look closely each, why a corresponding crypto solution, reporting or community steering in the public perception exists or is advertised.

BIG SEVEN Crypto-Parties as a decentralized solution out of the Crypto-War

From our recommendation decentralized crypto-parties, organized by many individual people, are one ideal way to bring up contextual references: if these, for example, introduce at the beginning here said BIG SEVEN Messengers and then present the participants not only the individual applications and encryption methods, but also explain the available functions and methods, and how it can be learned, how these can be assessed in comparison to other encryption tools by themselves.

Crypto-parties should not have the aim to serve one application, or to understand encryption methods, but the learning goal is to learn methods for comparative evaluation in the crypto functions! In further course of time, while there may be a consolidation that e.g. all crypto applications have installed a SMP process, and all applications hold in addition to chat an e-mail client, or enable chat via e-mail-server, and hold native encryption without plug-ins - because this denotes precisely the current exchange and learning processes in the community, that this audit section wants to take also in the viewing angle.

Examples regarding of attempts of confidence shocks and marketing strategies for some crypto messenger projects

Therefore the following examples may be documented as examples for the current behavior in the community:

Case: Signal & Co.
An example is given with the Twitter exchange between the on the server non-open source (and therefore here not considered) Messenger Telegram and the (also only with a central server available) Messenger Signal.

A first message came from Signal Messenger over their account OpenWhisperSystems, in which it was informed, that all messages from Telegram would be stored in plaintext on the Telegram server (which is not really open source) and thus the supplier can eavesdrop on it!

This message has been resent from the user "Ptacek" as a retweet and repeated again as an own statement. Also this message was again forwarded to hundreds of times by his readers to others. Then commented Edward Snowden, who is also praising the Signal Messenger as the only true Messenger on their website (see also remarks in a previous section), not the original message of OpenWhisperSystems, but the message from the user "Ptacek".

Snowden was then forwarded more than thousand times by his readers, among others, also by the other alleged followers and heroes of the crypto-scene, possibly without questioning the origin and the strategic implication of the message. Because: It makes a difference, whether it is a descriptive statement, that a server save messages, or whether it is a statement, that has been launched as an attributed weakness by competitors.

https://twitter.com/whispersystems/status/678036048815906818
Open Whisper Systems ?@whispersystems  Dec 19
@CTZN5 @timcameronryan By default Telegram stores the plaintext of every message every
user has ever sent or received on their server.

Thomas H. Ptacek Retweeted
Thomas H. Ptacek ?@tqbf  Dec 19 Austin, Chicago
By default Telegram stores the PLAINTEXT of EVERY MESSAGE every user has ever sent or

Jacob Appelbaum and 1 other Retweeted
Edward SnowdenVerified account ?@Snowden  16h16 hours ago
Edward Snowden Retweeted Thomas H. Ptacek
I respect @durov, but Ptacek is right: @telegram's defaults are dangerous.
Without a major update, it's unsafe.

Thomas H. Ptacek @tqbf
By default Telegram stores the PLAINTEXT of EVERY MESSAGE every user has ever sent or  received on THEIR SERVER.
1,092 retweets 836 likes
Like 836



The background is that the messenger Telegram was represented at that time very much in the media, and supposed to have been used by terrorists. In addition it is developed in Germany by a Russian, and thus the users are not in the U.S. access.

Through clever retweeting and forwarding of tweets as rumors and personal views, the initiator of the message and its underlying objective is obscured. The messenger Signal possibly wanted the messenger Telegram attributing a confidentiality gap, so it was not considered as a direct attack, but intermediate multipliers have been used. One must not have a common plot suspect behind, but it shows on the one hand quite unfriendly marketing effects, that will redound to alleged vulnerabilities in other applications for detriment, and secondly, on the other hand also shows the role of supposed experts, who can be more interpreted as community-strategists.

Would this mean, that chats, that do not run on American servers, are particularly safe? And that now an envy-debate among the messenger itselves is created, if they are "terrorist"-approved (Stahl 2016)? and then, that the stakeholders have sacrificed their neutral technical expertise of membership in strategic agreements?

Nevertheless: Telegram provides good reasons to believe, that something is wrong with the faith in a non-open source messenger. An open source Messenger requires no faith, because it is verifiable. Nevertheless, we want here only to briefly touch on this non-open source messenger:

The Telegram messenger explains in its FAQ section of the website, for example, that the client-to-server connection is regularly not encrypted, and also the end-to-end client-to-client encryption is explained, in which a symmetric key over the Diffie-Hellmann method (EDH) is sent.

The users should compare the symmetrical end-to-end encryption passphrase on the smartphone with the same on the phone of a friend. If it is the same, one could be sure, that the connection is secret – so the technical documentation according to the webstite. But this is not the case, because the criterion is that the passphrase is not known with third parties, such as Telegram. In addition, the user has no way to manually edit the end-to-end encrypting passphrase or to determine it.

The transmission protocols in Telegram and the implementation of the Diffie-Hellman method is not revisable and justified by open-source code.

In addition, the connection is created via a chat server, which is also not open-source.

The public key of the asymmetric encryption for the transfer of the symmetric key is at this messenger also not reviewable. Also is not explained, where the private key is stored (at the company or on the telephone of the user). Likewise, nothing is stated about the encryption respectively the protection of the private key for EDH. It is therefore to be regarded as highly critical, that Telegram should have according to own words no copy of the symmetric key available.

Also, the end-to-end encryption is a permanent one, which the user therefore cannot like in GoldBug renew instantly – by means of "Instant Perfect Forward Secrecy" (IPFS) at any time. A manual definition and immediate renewability of symmetric keys in GoldBug are a unique proposition!

Telegram reminds one of the sleight of shell game gamblers on holiday: compare both keys and assume that you're safe. But whether Telegram has a copy of the between two friends in secret shared key, remains the secret of the not open-source protocol and not open-source chat server. On the contrary, the above indications suggest, that Telegram could receive a copy of the key and the user is not really free, to manually create a secret, symmetric passphrase and to share it with a friend in secret.

Willfully foist an encrypting messenger a plaintext affair as matter-of-fact-presumption, as addressed by Signal to Telegram, can in itself be deemed a strategic communication, such as to communicate a farmer's milk would be pure hydrogen cyanide.

Even if such plaintext-gaps may occur, as with Enigmail - where it was over 10 years not discovered that the BCC mails are not encrypted (Scherschel 2014), or as in CryptoCat where certain cryptographic functions have not been properly implemented (the Group Chat was decipherable (Thomas 2013)! and also the authentication model was inadequate (Diquet 2014)) - but it is rather the aggressiveness with that here strategy and policy is translated and must be accordingly assessed and considered.

Dealing with code improvements in neighboring projects is here in Signal used for pure strategic marketing purposes and apparently not claimed to conduct in the developer community something like "common assistance". Many developers are highly individualized people, who think with the point input by the return-key at the end of their source-code sentence to define the world very powerful.

Example: RetroShare
Many users rise the question, whether the data transfer of the messenger RetroShare, which is predominantly oriented to FileSharing, is secure: No, it should be not, because each file, respectively chunk of a file, that is passed through a friend, shows each node the hash of the file, so state even the developers in its internal community.

Since the file search is working over this hash, each file, that is passed over my own node, has to be regarded as critical (in the sense of questionable) and identifiable.

Likewise, the chat applications, that use only a central server, could be assessed in this regard as potentially unsafe. Remain in this consideration therefore only OTR-XMPP-server, GoldBug, CryptoCat and Tox, while OTR is not designed for file-transfer respectively file-sharing and XMPP-servers were not originally designed for continuous end-to-end encryption.

Case: Tox Messenger
Socially responsible cooperation amongst projects should be fostered by a successful crypto project and not be mistaken for strategic alliance agreements in the multipliers community, that can often also have financial backgrounds.

So was also the criticism of the Co-Developer meant (Contributor 2014), who left the main developer of the project of Tox, because he refused to implement certain innovations and security enhancements.

If it were even deeper scientific analyses in addition to our indicative documented examples, one would possibly come to the conclusion, that only three out of our BIG SEVEN Messengers are friendly to each other involved in an extended community: RetroShare-, Tox and GoldBug developers are also on the road in other context-projects, to fix bugs, to provide each other mutual assistance, and jointly bring the projects and their own forward.

Although many developers are active in numerous sub-projects in the OTR-XMPP community, is the willingness to deal with anything other than OTR and XMPP is yet to be assessed for many especially in this community rather than low.

OTR can not be regarded as savior for the security questions, that the hosts of this plugin can not standardize in a common response despite various manifest attempts (Saint-Andre 2014, Schmaus 2016).

Possibly one must then also take away no longer compliant clients the XMPP status, or establish a new brand like "NTRU-XMPP", to guarantee native encryption, or find an account solution in the server programming, that throws off unencrypted transfers and does not allow a connection of unencrypted transfers (and also requires password lengths and key sizes as the minimum standard for a NTRU-XMPP).

Then also posted the CryptoCat developers regarding XMPP a message, that is likely to be understood as an attack: that he was preparing a development to see "Pidgin dead soon":

https://twitter.com/kaepora/status/670725803404075008
Cryptocat rewrite is native desktop client, no web, no mobile. Uses Axolotl, has buddy lists.
Goal: kill Pidgin.



Postscriptum: This tweet has been deleted after the initial release of this study.

The succinctness of this message may not just the 140-character limit to be owed by Twitter, but each message is indeed a matter of information about one's own self-image - and also on the possibly rightly so expressed and in part above described serious problems of OTR-XMPP-encryption.

Our statement:
All may have given their valid contribution and in the professional world and in community meeting also all want to receive honor - and finally all somehow have to finance. But our recommendation is to readers and end-users, to recognize the critics of the glorified, and the strategic relationships within the scene and funded marketing better - and possibly to make even better a bow around the all-too-familiar faces of the scene:

It must not at every IT-community-meeting speak a supposed "Star", but unknown experts, that make a technical contribution, or persons, which are critical to existing systems, procedures, or strategic and financial contexts, should be payed much more attention.

Activists, who need a stage, and have not been known from their technical comparative writings and are only known from the stage, are to be regarded as critical, when they promote their messages.

It appears currently that with mutual accusations of vulnerabilities the community should be frightened in order to damage the image of individual applications.

One conclusion is, that there should be a process of education and learning for each participant in order not to be dependent on so-called experts and multipliers. It therefore seems to be more than necessary, that every user can make professional decisions for or against an encryption solution independently and with appropriate knowledge and can recognize strategic marketing initiatives - to become more independent of multipliers and so-called experts within crypto.

Ideally, everyone should test several alternative applications and make their own image by investing the own time in reading the manuals and audit-reports of the applications, as we have undergone this process for documenting our findings also time-consuming during the analysis.

It depends on the in part easily recognizable attitude, that an expert member show in thier paper about crypto solutions for a community, whether it is a benevolent and balanced teaching or in the malicious sense represents a burning criticism without comparisons and constructive solution perspectives. Just to offer own assistance in what is criticized, should still be commendable.

Also speakers on a crypto-party are therefore to provide logically always the question of what further functions, encryption types and alternative messenger they have now not presented, are even not sufficiently familiar with or why they rated a tool as insufficient - respectively why not a focus on open-source processes is placed.

A crypto-party should be in our view "BIG SEVEN APPROVED", that is, therefore to consider all the above-identified open-source applications at an initial course to exploratory involve the participants in learnings about the different configurations and functions. Other auditors, we would like to encourage, to also create references to other applications, if they are allowed to write independently and without financial loss for an audit.

Table 34: Good Practice Insights # 09

# 09 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case I have now tried different applications. Although the user interface is habituation needy in any program, I want to use the product for my safety, which is regarding the safety orientation modern and technically excellent. Where can I get more information about other applications and their technical quality approach?
Solution Each program offers on the website numerous information. Some applications also have more in-depth instructions for encryption and security aspects. Some also link an audit study. GoldBug is aligned with its processes extensively to encryption and has these documented accordingly in the open source-code, in the project documentation, as well as in user manuals.

Source: Own Case.

***

Description of Process and Function: POPTASTIC E-Mail-Client

POPTASTIC is a function, which creates within the application on the one hand a regular and also encrypted e-mail client and beyond that also introduces a so far innovative function: the presence chat over a regular (POP3 or IMAP) email account.

Inventory taking, structural analysis and descriptions of the functions

POPTASTIC enables direct encryption of e-mails and uses POP3 e-mail server for both, e-mail, as well as for chat.

This not only means, that messaging is now bundling offline and offline friends, but also, that the encryption is provided continuously by default and requires only a one-time key exchange with own communication partners. Second, it must not no longer any individual communication be manually encrypted with a key and possibly signed, instead the effort for the user is reduced to a minimum without loss of security! After the one-time key-exchange any communication through GoldBug will be encrypted continuously.

With regard to the chats with POPTASTIC this means, that the regular e-mail server based on POP3 and IMAP also can be used as a chat server (see also Lindner 2014).

Principally, there are then no special chat servers, no XMPP- or any proprietary IM servers no longer necessary! Even with those encrypting Messengers, that make the chat client open source, but not offering the chat-server open source, it is getting clear, that the existing infrastructure easily and efficiently can be used for e-mail and chat for encrypted communications.

By a flag or through the appropriate key (see below) for the encrypted chipertext the receiving client is informed, whether to decipher the text in an e-mail-message or a chat-message and then displays the message to the user, either in the chat-tab or in the e-mail-tab. Another advantage is, that the port for email is enabled almost in every firewall and you can therefore chat and mail-out encrypted from almost any environment - and even attachments can be sent encrypted.

To activate the POPTASTIC function it is only necessary - like in any other e-mail client as well - to deposit the POP3- or alternatively IMAP-Server-details in the settings to send and receive e-mails.

Then, with the exchange of the POPTASTIC key between two friends, the encryption is installed within one step, and, from this time on, it is possible - without further processes - to communicate easily and securely with each other.

Figure 11: POPTASTIC Settings

In addition to encryption via adjacent nodes over the echo protocol of the messenger, POPTASTIC is added as a second protocol, that enables encryption using the existing infrastructure: POP3- and IMAP-servers. The function and operation of POPTASTIC is documented in detail in the user manual. As it always comes to the inclusion of manual documentation during an audit, this aspect should be included with the example of the POPTASTIC function in this assessment.

Selected method for studying and function reference

To test the POPTASTIC function, the user manual as process description should be used and assessed, whether a user being aware of this manual description can enter the e-mail server account details within the POPTASTIC function.

Conduction and findings of the examinations

The POPTASTIC function was tested qualitatively with three users, without that they knew the GoldBug application previously. At the beginning everyone was allowed for 15 minutes to read the user manual for the corresponding function, and the e-mail usage. The setup of the application was carried out jointly, as it is here focused only on entering the server details in the POPTASTIC function and as well the understanding and application of the process.

All three users could enter the server details within a few minutes after reading the manual. Helpful was the button of the test function in the settings, with which the correctness of the entered server settings is confirmed. The server-details regarding domain and port for the own e-mail-account should of course be known by the user. The exchange of keys with a different user was then just a simple process and the three subjects could each start an encrypted chat.

POPTASTIC uses - also verified in a further analysis of the source code - therefore its own POPTASTIC key pair for the chat, and also the permanent e-mail key. Both keys are included in the key transfer, so that both, chat and e-mail, will get functional. For the emerging friend in the chat tab the e-mail address will be displayed with the @ symbol, and therefore differs also chat-friends with a chat-key of chat-friends with a POPTASTIC-key.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

In an evaluation it can be said, that all three subjects were able to implement the process description of the manual for the application of the POPTASTIC function very well and succeeded completely, to apply the function. The technical-procedural analysis and the source code show transparently the use of another key pair for the POPTASTIC function.

By chat friends, who are displayed with an email address within POPTASTIC, this function is also indicating transparently in the user interface. Further, the e-mail function is also explained in greater depth in the manual.

Table 35: Description of findings 3.10

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
3.10.4.A Potential for Improvement Update of Screenshots in the manual to the current version of the application. Informational
3.10.4.B Strength E-Mail and chat in one application, incorporating the existing infrastructure of IMAP and POP3 e-mail server,
Own key for this feature.
High

As a suggestion for improvement has been identified by the subjects, that the screenshot used in the manual of the POPTASTIC function is not quite up to date in the layout, so the recommendation to give is to continuously update the user manual also in this screenshot to the referring software version.

All in all, with POPTASTIC next to the echo protocol a second innovative protocol is given in GoldBug Messenger, that is - taking into account the user manual - easily to understand and allows encryption for both, for e-mail and for chat, over POP3 and IMAP servers.

Appraisal of good practices in comparison with other similar applications

Compared with the other selected open source encryption applications, there is no application that allows a chat over an e-mail server and no application that can send an email - whether encrypted or unencrypted - over an IMAP- or POP3-server.

Here is particularly the GoldBug Messenger to attest a strength that it is incorporating over an intelligent and innovative way existing infrastructure in the processes of encryption.

Compared to the regular given email encryption exists the advantage that each e-mail is provided by default for encryption, the user does not have to start an encryption process for each e-mail manually.

An e-mail-related function contains only the application RetroShare, but it does not allow sending e-mails to friends, which are offline.

The e-mail of RetroShare does not work, when either friends are offline, or in other words, it only works, if both parties are successful in proceeding a handshake, so if both are online. But then you could also chat and transmit the message via presence chat.

The RetroShare email function is therefore in development, as it actually shows an online chat in an inbox instead of in a chat window (based on the latest revision).

Also RetroShare does not utilize an own e-mail-key, but instead sends the e-mail-message ongoing through the only available chat-, respective application-key.

Table 36: Indicative BIG SEVEN context references 3.10

CryptoCat No support for POP3 or IMAP for message transfers.
GoldBug Implementation of POP3 and IMAP in the Poptastic function with its own key. Innovative chat function via e-mail servers.
OTR+XMPP No support for POP3 or IMAP for message transfers.
RetroShare No support for POP3 or IMAP for message transfers. UI for e-mail, but transfer only, if both participants are online. No specific e-mail-key.
Signal No support for POP3 or IMAP for message transfers.
SureSpot No support for POP3 or IMAP for message transfers.
Tox No support for POP3 or IMAP for message transfers.

To understand messaging holistically - that is, the transmission of messages to chat-friends and e-mail-partners - it makes sense, that the here encountered standard of IMAP and POP3 is possibly considered to be included also in the other open-source encrypting applications.

GoldBug as a client emphasizes with this the core competency to integrate within one application both, e-mail and chat, as it can not be found in almost any other comparable application. Rogers illustrates in his book "Diffusion of Innovations" (1962, 2003) the processes how innovation first by a group of the so called "innovators" and then by a group of "early adopters" is tested.

The POPTASTIC function is a worldwide first implementation, in which you can send chat (and e-mail) via e-mail-server - and also still encrypts everything. Therefore, it makes sense to relate this theoretical construct of phased interpenetration of ideas through communication in the social system as a perspectivistic issue as well for one of the main innovations in this client.

Figure 12: Diffusion of POPTASTIC Innovation as theoretical construct

Source: Diffusion of Innovations, Rogers 2003.

The graph shows that a group of innovators is needed during the beginning of innovation, which provide and test a new technology via different communication channels, before it is tested by other people from the group of early adopters: the scientists, the curious thinker, the questioners, the communicators, the ones who ask, the librarians, the archivists etc. ... .

POPTASTIC is not just chat via e-mail, but rather at the same time encrypts regular e-mail accounts too.

Actually, the solution after which each one is currently looking for regarding e-mail?

One will over time also be able to analyze with this example, if communication about how we communicate (e.g. via POPTASTIC), also a first social penetration in the other group of "adapters" constitutes - or due to the existing multifarious options of communication channels this innovation will be considered as a niche – and/or only, if it comes to default encrypted communication, one recognizes, that chat and email can ideally run through e-mail servers also in this bundle.

Table 37: Good Practice Insights #10

# 10 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case I want to transfer a file encrypted to a friend, how to proceed?
Solution GoldBug provides once with the File Encryption tool the option to securely encrypt a file with high encryption values. Then the file can be sent through any channel or be stored in a cloud. Another option is the file transfer of the file within the Messenger. Each file will be always transmitted in encoded form. It is also possible to place an additional symmetric encryption with an AES-256, on the file - so to speak: a password. Furthermore an encrypted file can be send as an attachment of an e-mail via a regular e-mail account, which is set up with the POPTASTIC function within GoldBug.

Source: Own Case.

***

Description of Process and Function: Example of a File-Transfer with StarBeam

The StarBeam function within GoldBug messenger describes the file-sharing respectively file-transfer function. By means of a link in the magnet-URI standard - that means similar to an Edonkey-ED2K-link or a Torrent or Gnutella-link, now encrypted files can be transmitted securely and safely.

Inventory taking, structural analysis and descriptions of the functions

The data transfer can be easily understood: Either the file is transferred in the tab StarBeam (SB) - there you will find the sub-tabs: "downloads", "uploads" and "define magnet" - or the file is even easier transmitted in a Chat-Pop-up window with a simple mouse click.

The StarBeam function can be explained as follows: A magnet-URI is a standard, which is known from many file-sharing programs (it has been widely used in the Gnutella network) and in the operatings also corresponds to an eDonkey / eMule ed2k link or a torrent link.

The development of the magnet-URI standard through the GoldBug messenger underlying Spot-On library is the embodiment of the magnetic-URI with encryption values. Magnets are thus used to create a package of cryptologic information and bundling it together.

Thus between the nodes in the echo network an end-to-end encrypted, symmetric channel is created, through which a file can then be sent.

It can then also be sent any other file. The magnet is thus not allocated to a specific file, but only opens a secure channel. The SB-magnet can therefore be seen as a channel, through which an instance can constantly and permanently send files. - Or it is created a one-time magnet, which is deleted immediately after a single use. Then each magnet corresponds to only one file. Through this dual-use effect a magnet can not be assigned to a single file or a specific IP address. Also a specific file-name does not appear in the SB-magnet (- as even it is yet the case for the more advanced links - for example, by OffSystem or RetroShare - compard to Gnutella, eMule and Torrent links). Thus it is clear, that in StarBeam no specific file is swapped, instead there are basically swapped only encrypted channels.

The use of magnets is very simple and the user interface automates the magnet transfer in the chat window: a single click sends a file via the "Share" button to the chat friend.

Figure 13: GoldBug – File Transfer in the Chat Pop-up Window

Abbildung 13: GoldBug Messenger Chat Pop-Up Window mit File-Transfer

Technically, the magnet URI standard, which has been extended by cryptographic values in GoldBug clients, can be explained in detail as follows:

Figure 14: Example of Magnet URI-Link for StarBeam-File-Transfer

Source: Own case.

Table 38: Overview of the Magnet-URI-Standards for cryptographic values

Short Example Description
rn &rn=Spot-On_Developer_Channel_Key Roomname
xf &xf=10000 Exact Frequency
xs &xs=Spot-On_Developer_Channel_Salt Exact Salt
ct &ct=aes256 Cipher Type
hk &hk=Spot-On_Developer_Channel_Hash_Key Hash Key
ht &ht=sha512 Hash Type
xt=urn:buzz &xt=urn:buzz Magnet for IRC-style Chat
xt=urn:starbeam &xt=urn:starbeam Magnet for File-Transfer
xt=urn:institution &xt=urn:institution Magnet for E-Mail-Postbox

Source: own collection from the GoldBug Manual (2014).

As a SB-magnet transfers the file on the network to each node, which knows and has deposited the magnet, a passphrase for symmetric encryption can additionally protect the file. This function for, respectively Password on, SB-magnets is called: Nova.

Before sending a specific file via the SB function, the option is offered, to protect it with a password via the Nova function. So what is called "GoldBug" within email: the password that encrypts the e-mail - is during the StarBeam-Upload called: "Nova".

The receiving friend thus only can open the file when the Nova password is entered. It is an additional symmetric encryption to secure a file-transfer. Thus it can be prevented, that a friend is forwarding the magnet for the requested file to any other person - they would have also to pass on the Nova.

The release of the password for the file therefore takes in this case place at a time, when the transfer of the file has already been completed. This nuanced consideration of setting a Nova password to a file should be left aside in this assessment for a first transfer and the function investigation.

Selected method for studying and function reference

To an audit belongs checking, whether the processes described in the manual may be conducted in practice. As stated above, this is to be analyzed by the POPTASTIC process and now the StarBeam file transfer.

While at the POPTASTIC function in the chapter above three subjects were employed to comprehend the description process in its qualitative grade, should here the description of the StarBeam function be based on the analysis of the team of authors and be tested in practice.

Conduction and findings of the examinations

In the experimental setup a chain of four nodes was formed:

• Alice connects to Mary and
• Mary to Ed and
• Ed to Bob. Bob now tried to send a file to Alice.

In the practice first a file from the chat pop-up window has been successfully transferred and then the same file again from the tab for the StarBeam file transfer function.

As a result, it can be said: The file has been transferred to 100% in both cases from one user to another successfully. The transfer was carried out according to the user manual and this describes the process adequately.

As there is additionally the analysis tool "StarBeam Analyzer" given, an attempt was made to repeat this experiment with it as follows: For this purpose the node of Ed was connected to three other users, which connected to his listener. These users now tried to transmit via the node of Ed also larger files. The goal was to increase the packet loading so that packets get lost in a simultaneous transfer from Bob to Alice.

Then Alice would have been able to check her resultant file with the StarBeam-Analyzer tool, which was possibly transferred to only 98%, and to define the missing blocks in a magnet, she sends to Bob. If Bob enters this magnet in his node and repeats the file transfer, only the missing blocks will be supplied - and not again the whole file.

However, in this repetition of the data transmission from Bob to Alice, the transmission was 100% accurate, so that the StarBeam-Analyzer-tool did not have to be used.

The data transmission via an e-mail attachment is in GoldBug Messenger as well possible, but at this point not element of an assessment. Larger files should be better transmitted in chat or using the StarBeam function.

As an improvement proposal it can be stated, possibly to complete the process of the usage of the StarBeam-Analyzer-tool a little more in detail with a pictorial representation, so that the initial user is more aware of how the analysis of the transmitted blocks can be visualized (figure of a screenshot in the manual). If a file once has not been successfully transferred, this can be checked with the StarBeam-Analyser tool.

The file would itself also complete, if the transmitter sends it e.g. three times a day over the echo with the "Rewind"-function (= "Send again").

Note, that existing files in the download path (mosaic path under the installation path) will then be renewed, if no one-time magnet was used and the file is sent again to the same channel - as a magnet is a channel. A new shipment of the file by the uploader will overwrite the file obtained thus again, if the receiver does not set the lock option in the transmission table. With the check box "lock" in the transfer table, the file, that is being transferred, is then not deleted.

With respect to a source-code assessment the process is found starting in the code-lines of "StarBeam-Analyzer.cc" file at the VOID "Analyze":

Figure 15: Assessment of Codelines of spot-on-starbeamanalyzer.cc See code-snipet i the original PDF Layout at: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf

Source: for the detailes source snippet see: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf

The source code shows no irregularities.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

In our overall assessment the process for sending data via the StarBeam function according to the manual documentation is fully understandable.

Table 39: Description of findings 3.11

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
3.11.4.A Potential for Improvement StarBeam-Analyzer could be shown with screenshots in the manual. Informational
3.11.4.B Strength Development of the Magnet-URI-Standard with crpyto-values by the applied architecture of the GoldBug messenger is regarded as one strength. High

Appraisal of good practices in comparison with other similar applications

Compared to other open source messengers files can be transferred with XMPP+OTR depending on the client's choice as well as the program Tox and RetroShare. Specifically RetroShare plays here fully with its core competencies: not only the file-transfer, but also the file-sharing is there an inherent function. In addition, the applications that are available only for mobile devices, are often limited in the transfer of files, that are outside the normal file types, such as image or video.

Table 40: Indicative BIG SEVEN context references 3.11

CryptoCat Files and images can be transferred fast and simple to friends.
GoldBug Elaborated File-Transfer and File-Sharing with the enhanced Magnet-URI-Standard. E-Mail-Attachments und convenient 1-Click-Transfers out of the Chat-Windows.
OTR+XMPP Plugin-Encryption. File-Transfer depends on the XMPP-Client. Encryption has to be evaluated in reference to the plugin-architecture.
RetroShare Elaborated core competencies in regard of File Sharing and File-Transfer. The transferred file is - due to its indicated hash - known in all nodes of the path in the p2p network.
Signal File-transfer is offered since Version 2.0.
SureSpot File-Transfer for restrictive file types (images) possible.
Tox File-Transfer is possible.

As perspective it can be noted, that the encrypted data transmission possibly represents a decisive criterion in the usability of a communication application. Applications available exclusively for mobile platforms should be tested for the usability of all file types. As well: Particularly in encrypting applications, that enable file transfer only via plugin solutions, it should be further examined sustainable, if the file encryption is performed in a continuous process with no gaps in the encryption and not refers only to the transmission of text messages.

Table 41: Good Practice Insights # 11

# 11 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case At my workplace I have no opportunity to use a messenger. My current Messenger has also no e-mail function. How can I send people an encrypted message or file out of my Chat-Application, even if they are offline?
Solution Nevertheless, in restrictive IT-environments the email function or the corresponding port is mostly enabled for POP3 and IMAP. With GoldBug you can send either chat and e-mails to online and offline friends through e-mail server like POP3. E-mail-servers turn to a chat-server with the innovative POPTASTIC function. With POPTASTIC one can send out of the chat-application GoldBug both, encrypted text messages and encrypted files, to friends, which are currently offline.

Source: Own Case.

***

Data Analysis: Statistic Function in GoldBug

To analyze available data is also a relevant element of a review. In GoldBug various data are processed and stored in appropriate databases. They are found on the hard disk in the installation or user-specific sub-path under "/.spoton". As seen before e.g. in section 3.6 on the example of e-mail storage, data contained therein are stored in encrypted form.

As a further basis for a possible analysis of data, the status and the process data of the application come into question, especially the one of the kernel.

These data are listed in the application GoldBug in a specially defined statistics area.

Inventory taking, structural analysis and descriptions of the functions

GoldBug has not only for the URL-Import-function of the RSS/Atom-reader a dedicated statistic captured and indexed, and then also for the p2p-web-search imported URLs. Also for the other functions and in particular data of the kernel are the user extensive information visible. They are shown in its own window for statistics.

Figure 16: Statistics Window of GoldBug

Source: Own Screenshot.

In addition to specifying "Uptime", that means how long the user is with the kernel already online, as well as the indication to the written and read data, one finds further information e.g. about the number of exchanged URLs at this time. Thus, for example, the performance of a kernel for this function in each client can be explored, such as the per minute with friends exchanged URLs.

Selected method for studying and function reference

Based on two machines the research should explore now, how the statistics vary in performance, and also if possibly aspects for the assessment of the application in regard of trustfulness could be derived.

Thus methodologically is to implement a practical examination in different environments, in order to be able to assess the transferred data and data flows from the values obtained.

Conduction and findings of the examinations

To carry out the analysis and the comparison, GoldBug has been installed on two machines each running Windows, one with a I5-CPU and one with a stronger I7-CPU. The kernel was in each case successively connected to a third node and the statistical values were read off after ten minutes. During the ten minutes the statistical curves were kept as well an eye on.

Table 42: Analyzing and comparing the statistcs after a practical monitoring test

DESCRIPTION VALUE MACHINE
i7 - 3612 QM
Intel CPU
@ 2,10 GH
VALUE MACHINE
AMD - A10 5750M
AMD CPU
@ 2,5 GH
Active Buzz Channels 1 1
Attached User Interfaces 1 1
Congestion Container(s) Appr. KiB Consumed 2 KiB 3 KiB
Congestion Container(s) Percent Consumed 0.53 % 0.52 %
Database Accesses 8.541 9.881
Display Open Database Connections 1 1
Ephemeral Key Pairs 1 1
Live Listeners 0 0
Live Neighbors 1 1
Open Database Connections 1 1
Total Neighbors KiB Read / Written 8545 KiB / 8.818 KiB 10.290 KiB / 9.145 KiB
Total UI KiB Read / Written 22 KiB / 32 KiB 27 KiB / 38 KiB
Total URLs Processed 264 URLs 339 URLs
URL Container Size 0 0
Uptime 10 min 10 min

The results show a good overview of the most relevant data, functions and processes that arise in the operation of the client GoldBug with its kernel.

Disorders during the test and monitoring of data in the ten-minute frame were not found. In particular, the data for Uptime, written data, as well as transferred URLs clearly show the greatest activity. Other information, such as the value for "Congestion container(s) Percent Consumed" remain relatively stable.

The data provide important information to the user about how intensively something is processed inside the application. The shown statistics increase the familiarity with the application like an information board allows a car drivers as well not only the possibility of the information and, if necessary, steering of the processes, but also makes the users with the processes familiar. Therefore, the data analysis is also used to support, to increase confidentiality and the consciousness of the user for the performed functions and processes.

The comparison of the data shows a different expression for some values, that are subject to continuous processings. Other findings don´t result from different values, which depend in particular on the performance of the CPU.

The statistics function can also be accessed via the console, as shown in following table for an operation of GoldBug on a Raspberry Pi computer:

Figure 17: Console Statistic Function

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

The overview of the statistics is a valuable complementary function. Weaknesses or risks were not found. On the contrary, the user receives an information that fosters transparency and the usage the application with awareness.

As improvement is seen, that the statistical data from the RSS / Atom newsreader could be displayed as well in the overall statistical summary. One strength is that the kernel performance for the user is revealed.

Table 43: Description of findings 3.12

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
Potential for Improvement RSS-/Atom-Statistics could also be shown in the main stats panel. Informational
Strength Strength due to focus also on kernel statistics. Medium

Appraisal of good practices in comparison with other similar applications

Compared to other open-source applications such detailed statistics as in GoldBug were there not found. The graphical user interfaces of the other, in particular of mobile applications, provide only little information about functions, data and processes of these messengers to the user.

Also in this section remains GoldBug to be judge as the messenger, which presents the most statistical variables transparently to the user. This contributes to improve the use, the trustfulness and last not least the security of this application.

Table 44: Indicative BIG SEVEN context references 3.12

CryptoCat No statistics window.
GoldBug Comprehensive statistics window. User has an overview of main processes and the activity of the tool.
OTR+XMPP No statistics window (in regard of encryption, resp. per client).
RetroShare Some statistics are given in the GUI.
Signal No statistics available.
SureSpot No statistics available.
Tox No elaborated statistics available.

Table 45: Good Practice Insights #12

# 12 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case From my file sharing clients I know the statistics function. Can you read relevant statistics values in a program for encryption?
Solution Yes. GoldBug has its own statistics page, in which the various core processes with values are stored, in which users can read about the performance of their program.

Source: Own Case.

***

Search-Engine-Requests & Security Nuggets: Key Handling & P2P-Websearch-Engine Code Review

The audit topic of the method of search engine queries respectively to get general information about encrypted applications over search engines (discovery of so-called "security nuggets") refers to the fact, that in the web deposited, smaller content is often detected by search engines and therefore - with a corresponding research - websites or information may be disclosed from protected areas, which would be otherwise available only with an authorization concept. Smaller snippets of information give then insight into potential vulnerabilities or may reveal the (public (asymmetric) or symmetric) key in regard to of encryption.

This topic of the assessment in this section is to be transmitted from two perspectives on the GoldBug Messenger, with respect to an external search engine such as Startpage.com, DuckDuckGo.com, YaCy.net as well as Google.com (external view), and: also in regard to the internal p2p search engine GoldBug itself (internal view).

The external search engines should be investigated with the focus, if they could theoretically record the public key of the application GoldBug, because the Key-handling process would be a part, in which the user publicize their public key - even if it is called per sé as public: Thus, the public key of the asymmetric encryption is public, yet there are many users who want to see this not be published in public.

As seen earlier, GoldBug provides therefore the protective function of the Repleo, with which the own public key can be encrypted.

Furthermore, there is also criticism of PGP key servers that they are actually insecure if someone wants to find the key for encryption of a friend by name or email address: Often the key is incorrect, outdated and everyone can create an key-entry with any e-mail address, that needs not to belong to the owner.

How is an investigation processes in this context to design and how to evaluate the innovations provided by GoldBug for this?

Then the following statements should relate in a second step also to the built-in websearch-engine of GoldBug, whether it could reveal security information available from the client to others in the network, which is relating to the safety of its own instance.

Inventory taking, structural analysis and descriptions of the functions

External websearch-engines: like Startpage.com, DuckDuckGo.com, YaCy.net or Google.com

Goldbug as communication network with flow of information from one node to another is designed from scratch to encrypted transactions and sends the information always multi-encrypted.

Therefore, no external, conventional search engine such as Startpage.com, DuckDuckGo.com, YaCy.net or Google.com can index portions or information of GoldBug, which could reveal unencrypted internal and security-related data.

Even if two nodes refrain of the connection using SSL/TLS in HTTPS and would build only an HTTP connection, the transmitted information remains ciphertext - this is the encrypted messages capsule.

It is thus excluded, that in GoldBug internal information of the user would be found in an external web search engine. The part, which the user possibly shows themself publicly, is mainly the public key. With regard to these above-mentioned problems of the public key must be noted that public keys are indeed basically public.

If anyone prefers though to transfer the public keys protected, exist in Goldbug at least three methods to be able to transfer the keys secured:

1. A user can thereto use the Repleo-function in GoldBug, as described at another section: If I get a key from a friend, my own public key with this can already be encrypted, so that it is protected during transmission.
2. Furthermore, there is also the possibility to transmit the key (or new keys) over an existing buzz respectively private IRC-like channel of the group chat feature in GoldBug.
3. After all thirdly, also offers the EPKS function - Encryption Public Key Sharing, found in the main menu under Tools - the possibility of transferring the key in the EPKS feature via a so-called community in GoldBug. The community name is a symmetrical end-to-end encryption password. Then, the own public (asymmetric) key is transmitted via a symmetrical end-to-end encrypted communication channel, while the password is known only to both participants and (possibly even prior verbally) agreed upon.

The asymmetric and public keys are therefore kept in the application Goldbug with different methods for a transfer very well confidential. In particular, the EPKS function has great potentials to complement the conventional key servers - if not even replace their disadvantages.

Figure 18: EPKS – Echo Public Key Sharing

Quelle: Screenshot of GoldBug

Internal P2P search engine: GoldBug Web Search

Since the contents of the communication between two users as well as the contents of a public key as security nuggets in ordinary external Web search engines are not given within the GoldBug client - or only in theory extremely unlikely could occur (unless users release the keys, consciously and voluntarily, e.g. in a web forum, which can be detected by search engines) - the area of spying on smaller information through search engines hereafter should no longer be based on the external Web search engines.

Instead, in addition should the examination question also be transformed from the external Web search to the in GoldBug as well implemented p2p web search: Are there security risks, when someone uses the function of URL indexing for own web search, which could reveal the communication-content of the other GoldBug communication-functions?

The Web search in GoldBug is an extension of the functions in regard to encrypted communication. With the web search exists the option to conduct a search for a keyword in an encrypted URL database on the own machine of the user.

It is thus requested no remote database as a web service and other nodes in the peer-to-peer network are not queried with the search word. Thus no so-called "QueryHit" in other nodes, as it would be the case e.g. in the p2p web search YaCy. The architecture of these two p2p web searches differentiate by the fact.

The search results the Web search of GoldBug are displayed to the user locally from the database - currently the most recent links are displayed on the first place, so with a simple sorting. Even AND and OR associations with several different key words are possible.

The URL database (SQLite, or optionally PostgreSQL) on the user's hard drive is fully encrypted - like all other databases of the application Goldbug as well!

The URLs get into the local database of the own node by friends and neighboring nodes of the peer-to-peer network. To that extent shared and new URLs are to be distinguished.

The import of new URLs in the own Goldbug client is carried out by manual page imports from the Web browser Dooble (another application), via the Web crawler Pandamonium (other application) or through the RSS function in the Goldbug client (accessable via the main menu of Goldbug as a separate Window). The RSS function allows to add URLs in a large amount to the own client (new URLs). More links then are added through the online connection of friends with whom one has swapped the URL key (shared URLs).

Figure 19: RSS-Function in the GoldBug client

Selected method for studying and function reference

To investigate the separation of the URL Web search from the other communication functions, a code review should be provided as well as a process-review. With the code review of the URL and RSS function is to ensure that content from the areas of communication such as chat, group chat, and email not enter the field of web URLs.

With the processes review is to ensure that both, the structure (e.g. of the functions or especially of the databases, in which the information is stored), as also by the user clicking routines no confidential information in the URL indexing is added and is possibly spread inadvertently to other friends or subscribers.

The method of investigation of safety information, which could end up as so-called "security nuggets" in external search engines, has been excluded above by theoretical assumptions and as well by a code review.

Both approaches of a judgment as to whether an external search engine or the internal search engine of Goldbug might tap security-related information from the client, therefore come to the following conclusion:

Conduction and findings of the examinations

The case, whether external Web search engines could record the communication of two users of the client GoldBug, is almost impossible. The investigation of these "security nuggets" of unprotected portions has therefore then been based in a second perspective on the Websearch feature, which is implemented in GoldBug itself internally. For this purpose a code review and a process analysis of the user interface has been conducted.

Figure 20: Code for the URL-Database Distribution to other participants

Source: for the detailes source snippet see: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf Source: Source Code of GoldBug.

The review of the code in this regard in the chat messenger respectively in the e-mail client area and in particular in the function of the Web search of GoldBug shows no irregularities, from which a risk is to assume, that the separate functions of the private communication transmission could interfere in the URL database respectively in the Web search, or even could be found in the URL data exchange to a peer. The URL web search shares with the neighbors just URLs. Furthermore the URL database can also be operated locally without a network connection.

Also the user interface with its click and process routines remained without any idea of an incorrect operation, that could cause that private information could fraudulently brought into the functional area of the p2p URL database. The path that a chat message enters in the URL database respectively website function is therefore highly unlikely.

While researching we looked also at the global external web search engines, which Top 10 search results they produce for the keyword "GoldBug Messenger". Essentially, there are software review portals, which are reflected in the ten relevant URL results. The average rating of the URL location by web search engines of the respective portal, we have shown in the following table.

It should be noted, that this only the sorting of the search engine algorithm was analyzed, it says no statement about the continuous adaptation of the portal to the latest version of GoldBug, about corresponding download numbers or even editorial quality of the review and reporting contribution.

Downloadportals are able to significantly develop in the subject area of the Crypto Messenger, if they report in an editorial and qualitative style about software - and not mirror only a download option of a file.

Table 46: Within Top 10 search results of main search engines for query: GB Messenger

URL TO
WEBSITE OF
AVERAGE POSITION START PAGE METAGER & YACY DUCK DUCKGO GOOGLE BING YANDEX BAIDU
Sourceforge 2,1
Softpedia 3,5
Softonic 5,0
Heise DL 5,3
Soft 82 7,3
Qt Showroom 7,3
Shareware 7,5
FF Betanews 7,8
Afterdawn 8,0
UptoDown 8,0
Freewarefiles 8,3
Majorgeeks 9,2

Source: Own research.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

The opposite way, that an URL found in the GoldBug web search can be sent to a friend via a simple click through the e-mail function of GoldBug, is possibly in contrast most desirable (and not yet implemented at the time of the audit in GoldBug).

The URL database in GoldBug could therefore provide a function for sharing the URLs via chat or e-mail in order to forward them e.g. with a comment.

Table 47: Description of findings 3.13

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
Potential for Improvement ./. ./.
Strength ./. ./.

Security risks or weaknesses from were not found for this assessment part.

Appraisal of good practices in comparison with other similar applications

All said other communication solutions have integrated no URL database or Web search - except of RetroShare. Thus it is also not possible to send bookmarks or URLs from one friend to another for a search indexing.

The extent to which other communication solutions have separate areas of activity, that a function does not reveal another function sensitive information, respectively the programmings of the individual functions are clearly separated from each other, can not further and not deeper be compared in the context of this audit. For this purpose individual audits of each application should be performed.

RetroShare as well provides the function of a link-, respectively URL-sharing to existing friends. This is offered for individual URL bookmarks with a comment and scoring function, is so far technically be regarded even as an advanced solution in these two features.

However, the URL search does not include indexing with keywords, also including website content for indexing is not given and the function shares the URLs with friends only, if they click manually on each individual URL and confirm an sharing with friends.

In the absence of the implementation of URL filtering (URL Distiller function) the URL function therefore at Retroshare can only be described as rudimentary respectively as equipped with a different focus than for a web search. It is more a shared link list with comments between only two friends.

Also at RetroShare is no browser-import available, and no web-crawler respectively the compound of the RSS function to the URL-sharing available.

The p2p web search in GoldBug is therefore conceptually possibly meaningful to compare with the established p2p web search YaCy - even if both p2p web search engines have experienced different elaborations based on previous history and practical usages.

Table 48: Indicative BIG SEVEN context references 3.13

CryptoCat Has not been assessed in terms of lacks of so called security nuggets left to external web search engines. Has no own p2p websearch function.
GoldBug Secures the information to external search engines. Even one possibly public element, the public key, is secure-able. Has an internal p2p-Websearch engine, which is well separated – as a code review shows.
OTR+XMPP Has not been assessed in terms of lacks of so called security nuggets left to external web search engines. Has no own p2p websearch function.
RetroShare Has not been assessed in terms of lacks of so called security nuggets left to external web search engines. Local database to manually share bookmarks to one hop friend but not filter distiller implemented.
Signal Has not been assessed in terms of lacks of so called security nuggets left to external web search engines. Has no own p2p websearch function.
SureSpot Has not been assessed in terms of lacks of so called security nuggets left to external web search engines. Has no own p2p websearch function.
Tox Has not been assessed in terms of lacks of so called security nuggets left to external web search engines. Has no own p2p websearch function.

The following analysis in this context of the above-mentioned Download portals should be as well documented:

Focussing an essential DownloadPortal as key player - because it is manually created and maintained, provided with its own test screenshot and reviews - one finds in the category "Instant Messenger" 59 Programs, of which 24 Messenger have published a release since 2013, so can be considered as active projects.

Table 49: Overview of other Messengers in the Portal Majorgeeks

The survey clearly shows that GoldBug not only in the user review, but also in the number of downloads of the respective license category has high relevance.

Looking at this background of numerous articles, blogs, and reviews of the download portals, is the discussion for a Wikipedia entry or its deletion, as have happened in history, with the criterion "Relevance" incomprehensible.

GoldBug has has among the BIG SEVEN messengers an important high relevance in terms of popularity among users, in the number of downloads of this portal as well as compared to the BIG SEVEN Open Source messengers: Here are not the Messenger Tox, SureSpot, Signal in this exemplary Download-portal listed. Nevertheless, the relevance of an innovative and cryptologic evaluation of processes and programming should be considered as well. It is about the judgement of the quality of the tool, e.g. its codings, and not about the popularity.

The Portal Major Geek has thus listed for approximately 50 Messenger 5 Messenger offering encryption. The XMPP-Messenger Pidgin and Miranda offer encryption only over a retrofit e.g. with an OTR-plugin, the three native encrypted open source applications are therefore again: GoldBug, RetroShare and CryptoCat.

Even if the download numbers speak only for this site and each application generates Downloads in other portals or release paths, is the qualitative assessment that GoldBug beside Retroshare and CryptoCat plays an essential role, and additionally the only messenger is, that offers both, encrypted chat and e-mail.

Pidgin as popular XMPP representative is also open source and possibly therefore not sorted quite right in the freeware Categorie, however, the download figures are there referred to a version without encryption plugin. The number of users of Pidgin with the OTR plugin is therefore unknown. Nor are there any efforts at XMPP, natively and necessarily predetermine the encryption in XMPP clients from default setting.

In the German-speaking area, we have made at this time an additional assessment based on the renowned and excellent maintained download section of the portal Heise.de: Thereafter GoldBug achieved a download ranking of 5513, OTR-XMPP e.g. with the OTR-integrated client ChatSecure a value of 6529, SureSpot is at 9162 and on the last places is Retroshare with 11340 and CryptoCat with 17130 brings up the rear. (For Signal and Tox exist there no download options).

This also shows, taking into account that the clients offer also on their respective web page downloads, at least indicative, that users, who want to explore this download portal, again at the BIG SEVEN Crypto messengers put their interest also in GoldBug.

Assuming that the user wishes to continue to use in future elaborated programs, in Goldbug is noted in a strategic assessment in this regard a clear perspective of an "Unique Structure Proposition" (USP) - a base for the anticipated, maximized usage-characteristics due to the previously developed functional scope compared to other applications.

Table 50: Good Practice Insights #13

# 13 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case I do not want, that my public key is known to other persons or search engines than to the friends I communicate with. How can I protect the key?
Solution In GoldBug you need not to make your public key public. There are numerous protective measures and ways to be able to send the key securely to a friend. One possibility is e.g. the use of the Repleo function. With this, your own key will be already encrypted with the key obtained from the friend. As another option, it is recommended to exchange the own key within GoldBug, e.g. in a private chat room of the Buzz-IRC-function. This works with symmetric encryption and with the friend is simply a password to share, that opens then private room. Also the EPKS function is given with a similar proxess.

Source: Own Case.

***

Physical Interaction of Components: e.g. GUI-Kernel-Interaction

A classical approach to app-programming is that a kernel and a user interface are used. So the stability-oriented kernel may perform its tasks and functions and the user interface is independent of it and can be created in different variations.

As an example of a physical interaction the GUI-kernel-interaction should be regarded, since two physical binaries exchange data on a machine via a secure connection.

Inventory taking, structural analysis and descriptions of the functions

There are thus correspondingly two binaries for GoldBug available, which keep the application functioning: On the one hand the kernel ("spoton-kernel.exe") and the user interface ("goldbug.exe"), also GUI (Graphical User Interface) called.

In this architecture exists especially with deployed encryption of course the need to securely connect the interface with the kernel. This should be taken into account in the present review.

GoldBug uses a local TLS/SSL connection between the GUI and the kernel. The kernel is therefore not influenced by attacks from the middle - a user can only log in with the appropriate login data in the kernel and sees there also the status information, if the kernel is tied with a secure connection.

Figure 21: GoldBug - Tooltip for the encryption of GUI to kernel

Source: Own screenshot of GoldBug.

The figure shows the prominent at first glance status information via a tooltip, if the kernel is connected safely or not. Additional safety information can as well be read from it.

Selected method for studying and function reference

As analysis the mentioned physical interaction of the GUI should be examined with the kernel. For this, the traffic is recorded with the tool Wireshark on the local machine. Furthermore, it was also looked in the source code, how the kernel-GUI-connection function is implemented.

Conduction and findings of the examinations

When analyzing the Wireshark records, it is shown, that the recorded traffic consists exclusively of ciphertext.

From the code review appears that the encryption of the connection is established from the GUI to the kernel via the established standard crypto libraries and its result in the slot "slotKernelSocketState" with these following lines of code in the tooltip summarized is represented.

The code review shows no irregularities.

Figure 22: Code-Review for the encryption of the GUI Kernel connection

Source: for the detailes source snippet see: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

The kernel is attached securely to the user interface. No risks or weaknesses were discovered. With regard to the implementation of the function this is felt to be adequate, that is, there is no need to obtain improvements. One strength of the GUI-kernel connection can be seen in the strong and modifiable encryption.

Table 51: Description of findings 3.14

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
Potential for Improvement ./. ./.
3.14.5.A Strength Strong and adjustable connection of GUI and kernel as a strength of GoldBug. High

Appraisal of good practices in comparison with other similar applications

Only Tox uses in comparable programs to GoldBug an explicit GUI-kernel architecture. Here, various interfaces are available for the kernel. A security audit of the there given user interface has not yet been carried out and the documentation of the Tox project considers this aspect also very limited.

For OTR + XMPP applications a plugin is given with OTR, which needs to be questioned as well in all XMPP applications, respectively should be evaluated and audited in regard of the connection of the plug to the hosting application - as well, whether all the functions then will run then via this plugin.

So it occurred for example as known already in the application Enigmail as encrypting plugin for Thunderbird e-mail, that it was discovered only after years, that only the direct e-mail was encrypted, but not the BCC-copies of the e-mails (Scherschel 2014).

Table 52: Indicative BIG SEVEN context references 3.14

CryptoCat Plugin in the browser to the underlaying processes.
GoldBug Authenticated and encrypted GUI-Kernel-Interaction. Transparent to the user.
OTR+XMPP OTR is a plugin referring to the XMPP client. Per client no or different approaches to secure the connection to the host.
RetroShare Local server and GUI implemented in one binary.
Signal Local client addressing to a central server.
SureSpot Local client addressing to a central server.
Tox GUI-Kernel-Interaction. Security depends on the referring and chosen GUI.

Table 53: Good Practice Insights #14

# 14 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case I have a GoldBug respectively Spot-On kernel running on a server, and thus set up a chat server respectively e-mail mailbox. How can I make sure that this kernel nobody can change through the user interface?
Solution The connection of the GUI to the kernel is encrypted in GoldBug as well. This is displayed as a tool tip in the status bar. The GUI can be set as well in a "LOCK" status, or can be closed. Then no one can operate the kernel respectively listener.

Source: Own Case.

***

Analog Communication: Gemini, GoldBug, Nova and Instant Perfect Forward Secrecy (IPFS)

GoldBug uses so far no options to transmit data packets in an analog communication, such as e.g. over beeps as we know it from a modem and this constituted still the regular way to the Internet a few years ago.

The use of the analog communication can then exist among users of GoldBug, when they e.g. want to commuicate a password orally to their friends. In the following therefore should the relevant part of the audit be layed on the inclusion of possible options of the analysis of analog communication, e.g. of the verbal communication of the end-to-end encrypted passwords.

Inventory taking, structural analysis and descriptions of the functions

GoldBug has its strength especially in the option of a manual creation of a symmetrical end-to-end encryption passphrase and in the numerous methodological ways that exist for the transmission of the end-to-end passphrase.

This means, users can define a passphrase, which should ideally exist out 32 really random characters, by themself or by using a randomly generated AES string of 32 characters and, if desired, replaces the characters at certain positions by other characters. Finally, there are several ways to transmit the created end-to-end encryption passphrase to own communication partners.

Because each message in the echo protocol (see the first section at the beginning) is fundamentally multi-encrypted - asymmetrical as well as possibly also additionally symmetrically encrypted -, the end-to-end encrypted password can also be delivered to the communication partners online through this secure way.

The manual shows the following different ways to transmit the encrypted symmetric passphrase. The end-to-end passphrase is described as so-called "Gemini" in the client.

Gemini is the Greek word for twin and refers here thus to the symmetry that both users must store the secret passphrase to secure the communication channel. It is a symmetric cipher, as each twin at opposite quasi sees the self in the mirror, both need to know the end-to-end encrypted passphrase.

So you can in a transmission of a new passphrase choose basically, if you want to send the new passphrase by the existing symmetric channel encryption (thus the existing Gemini), or rather choose the asymmetric encryption, the encryption key e.g. for chatting provides.

The transmission of an end-to-end encrypted password is named in the GoldBug client "Calling". By the used architecture of the kernel Spot-On in the client, the concept of "calling" has been introduced in the field of cryptology.

Basically it can be differentiated here into the following types of transmission of a new Gemini:

• During asymmetric Calling the end-to-end encryption password is transmitted over the public key e.g. of the chat function. This uses as to remember a public and private key and thus represents an asymmetric encryption.
• The Forward Secrecy Calling uses the asymmetric key from the chat or e-mail and first sends temporary keys. Through this new, temporary (ephemeral) key a new end-to-end encrypted passphrase is sent then.
• The symmetrical Calling means giving the new passphrase by an existing end-to-end encryption, thus by a symmetric encrypted channel.
• The SMP Calling runs as the regular asymmetric Calling, with the only difference that no AES or manually generated password of 32 characters is used, but that the password used in the Socialist-millionaire-process by means of a hash function will generate a passphrase. This then is not based on AES, but is derived from the password manually selected for the SMP-authentication of the two users. (should the AES process once deemed as unsafe, this would be an appropriate alternative). During SMP Calling the generated password with the same hash method must on both sides also not be transferred. GoldBug thus here has a standard established, which can not be found in almost any other client: Symmetrical end-to-end encryption, which is derived from a zero-knowledge process. The transmission problem of symmetric keys over the Internet (due to the interception of these keys when no truly secure connection could exist) also offers by the here introduced process great development and research perspectives.
• With the 2-Way-Calling, finally, the 32 characters for the end-to-end encrypted passphrase is divided into two parts, meaning that both users generate 16 characters, the first part of jointly defining the password is then used from the first user and the second part from the second user.

The following table shows - in addition to the manual definition of the end-to-end encrypted passwords - the different ways of the automatic generation and of the transfers of passphrases with 32 characters:

Table 54: Overview of the different Calling-ways in GoldBug with referring criteria:

Criteria Asymmetric
Calling
Forward Secrecy
Calling
Symmetric
Calling
SMP-Calling 2-Way-Calling
Ephemeral asymmetric Chat-Keys NO NO NO NO NO
Forward Secrecy as precondition NO NO YES NO NO
Secret SMP-Password as Gemini NO NO NO YES NO
Half symmetric AES as Gemini
(50 % AES of User A+ 50 % AES of User B)
NO NO NO NO YES
Instant Perfect Forward Secrecy as a result YES YES YES YES YES
Usage of the permanent asymmetric Chat-Key YES YES YES YES YES
Symmetric AES-Gemini as Channel NO NO YES NO NO
Usage of TLS/SSL-Connection, if forseen YES YES YES YES YES

Source: GoldBug Manual (Edwards 2014)

A Gemini can thus be generated at any time new and transmitted over the one or other way. The paradigm of "Perfect Forward Secrecy" has therefore been developed into the paradigm of "Instant Perfect Forward Secrecy (IPFS)". For the chat is in the context menu of the GoldBug Messenger also an activity button given, to perform this instant while chatting: the end-to-end encryption is replaced immediately through the asymmetric chat key with a new symmetrical end-to-end encryption.

This menu item is called MELODICA,
and is named: „M“ulti „E“ncrypted „Lo“ng „Di“stance „Ca“lling.



As illustrated in Chapter 3.01, the calling-function and -wording respectively even aspects of the echo protocol in the crypto logical research were then also adopted by other publications. Furthermore, there is in the GoldBug client since the beginning of the first releases for the functions e-mail and file transfer through the StarBeam function the option, to set an end-to-end encrypting password to the e-mail or file.

Within the e-mail function (so as well as for the attachment file, if given) this password is called "Goldbug" (so the same as the application is called). And: For encrypting a file this is called "NOVA". This has the consequence that the recipients can only open the message or file, if they enter the correct password at the password prompt. The transmitter has the receiver thus (possibly oral) to inform, what the password for the file or email is.

Then there is also the option as already mentioned briefly above, to generate so-called ephemeral keys: These are asymmetric keys that are used only temporarily. This means the new Gemini passphrase for end-to-end encryption is not transferred through the existing permanent chat key, but it is a temporary, asymmetric key used. This has the advantage that even with a compromise of the private chat key the somewhere in the past used ephemeral keys are not broken.

This implementation has been made for the chat function as well as the e-mail function. For the e-mail function GoldBug builds with the integrated Spot-On architecture worldwide a first end-to-end encrypting email client, that operates based on ephemeral keys with both, symmetrical and asymmetrical encryption - this means to cover both methods. Due to our knowledge both methods have so far not been implemented elsewhere yet for email.

For the process flow of generation and transmission of ephemeral keys, reference is made to the explanations in the manual. Here again it is again possible to send the new key through the forward secrecy key or encrypted in the conventional encryption of the echo protocol (see above) to transfer. It is spoken of "Pure Forward Secrecy" in the e-mail function if keys are sent through a temporary ephemeral key or the e-mail message uses this route.

Figure 23: GoldBug - E-Mail-Client with Forward Secrecy for ephemeral E-Mail-Keys

Quelle: Screenshot of Goldbug .2.9

All these end-to-end encryptions, mentioned above, are made online and digital. Subject of the assessment here will now be the option, to transmitted an end-to-end encrypting password orally to the receiver: for example, on the phone or in a personal meeting.

Selected method for studying and function reference

According to the underlying audit manuals the analog communication is to include, as it may occur in the system or application environment. A similar example of social dialogue can be found in the description of the password for the Socialist-Millionaire-Protocol (SMP) (see section 3.18).

In this section should now be described the oral communication of the end-to-end password for an e-mail. An environment of two users is selected as a test, in they send an email over the client and select the additional end-to-end encryption by a "GoldBug"-password, that the two users set on the individual e-mail.

Analyzed should be further the practical operability; as in each of the present assessment sections, the implementation of the function in the source code; and thirdly should be analyzed theoretically, which attacks and risks could arise when an end-to-end password on an email orally is transferred.

Conduction and findings of the examinations

For the conduction a simple setting of a connection between two devices was created over a third server. For this, a listener was built on a Web server, to which the two participants connected as nodes.

Both participants then exchanged their e-mail key, and sent an e-mail, which was transferred with no additional end-to-end encryption over the GoldBug function. Then was prepared in a node another email, on which the password "secret" was set as a password.

This password has now been passed on in an oral telephone call to the receiving party. The participant asked if the password starts with a capital letter. When the transmitter denied and the receiver typed the password in the correct spelling, she could read the email. The function was successfully tested in practice without findings for improvement potentials.

Also, the source code implements this function adequately, as the example of the use of the e-mail-GoldBug-password shows on attachments of an e-mail:

Figure 24: Source-Code quotation of the GoldBug Password on E-Mails

Source: for the detailes source snippet see: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf

The function test was therefore carried out successfully and the source code inspection showed no irregularities.

For the analog communication of the password is still the usual option in speech shown, to not properly understand the password or possibly to write it wrong. Since this was clarified on demand of the receiver with respect to the capitalization of the first letter, there were no complaints in this test.

Theoretical attacks on a Goldbug password that was put on an e-mail, can therefore only exist in the interception of the transmission of the end-to-end encrypted password. This would have to be avoided, by the two parties agreeing one or more passwords, if they are alone to each other and entering the passwords without observation respectively entering it with the in the application enclosed virtual keyboard.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

Nevertheless, oral communication always provides the risk, that passwords are not properly understood and written down by the receiver. It is therefore important to note the recommendation in the user guide, to share a password within analog communication letter for letter.

Table 55: Description of findings 3.15

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
3.15.4.A Potential for Improvement Pointing out in the manual, that the end-to-end password should be spelled in case of an analog /oral transfer. Informational
Strength Six methods to create and transfer an end-to-end passphrase. High

Also should be noted that a telephone connection can be intercepted and therefore the personal transfer of end-to-end encrypted passwords is more preferable in a face-to-face situation with no third persons.

If a passphrase must be submitted online, then only through a secure channel. The example of MIKEY-SAKKE clearly shows, how keys can be stored over differing paths-processes and inclusion of intermediate servers of third parties.

For secure voice communications over the Internet (VoIP) the CESG (the information security department of the British service GCHQ), recommends a technique called Secure Chorus, which uses a proprietary algorithm called MIKEY-SAKKE (Sakai-Kasahara Key Encryption in Multimedia Internet KEYing).

The vulnerability in MIKEY-SAKKE was exposed at that time and lies in the key exchange over an unsecured channel, that needs to take place before a secure end-to-end encrypted connection is established.

In contrast to many chat programs, which generate a secret key on the Ephemeral Diffie-Hellman method (EDH) to each account (at GoldBug corresponds EDH to the term Forward Secrecy Calling), produces Sakke secret keys for the conversation partners on the central service provider and sends this to them.

This means that operators have all secret keys under their control and can decrypt all conversations in a large scale of a passive mass surveillance (Murdoch 2016 and see also Heise). Same or similar could also the not open source server of the Telegram Messenger operate and pick up keys?

In fact such a protocol has been developed for voice encryption – Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) – (MIKEY-IBAKE).

It should also be noted that the keys come here from a central server, while the German Federal Office for Information Security (BSI) has also characterized - based on the example of Skype for Business - all encrypted chats over a third party or foreign server to be unsafe.

It could not be excluded due to the proprietary Skype protocol that similar processes as in MIKEY-SAKKE also happen on Skype servers: Because the keys for Encryption are owned by Microsoft, which is why in principle the parties may access the contents of the transmission.

For safety-critical and business-related information also Fraunhofer ESK therefore does not recommend Skype - just like classical unencrypted telephony (Fraunhofer ESK / Messerer 2016).

Thus, the solution is also in this example, again in the exclusive use of open source software as well as clients that include a manual configuration of the end-to-end encrypted password by the participants themselves - and not generate or transmit it by remote, third server of the provider.

Thus, it is crucial not only to be able to define the end-to-end password manually, but also to be able to share it analog, without a digitization by oral transmission. The analog key handover, the "De-Digitalization of the Ephemeral Key Transfer" (DDEKT)) is therefore a simple and still effective method to an EDH transmission. Back to the roots: the verbal agreement of passwords sounds like "retro", but still seems to be an excellent alternative.

GoldBug offers as shown above besides EDH or Forward Secrecy Calling also key transmissions in the symmetrical fashion over 2-Way-Calling or using a zero-knowledge process (over SMP). Here in GoldBug email client the whole keyboard is played on methodologies of secure key transfer - the menu item MELODICA is therefore also symbolic of the calling function more than suitable. And our source code review shows that this melody is not a cacophony - quite the contrary.

Appraisal of good practices in comparison with other similar applications

Apart from the SMP process, which also for OTR+XMPP offers the opportunity, to (possibly manually) define a common password and previously to agree upon verbally or by phone, none of the further comparative applications has the option, to define an end-to-end passphrase manually and to transmit it through an analog communications, e.g. in an personal meeting.

(Perfect) Forward Secrecy, Instant Perfect Forward Secrecy, the Forward Secrecy Calling or the manual selection of a symmetric password for continuous end-to-end encryption should be taken into consideration and strengthened in more detail in all other alternatives.

The numerous safeguards for the online transfer options in GoldBug client establish as shown standards in the "applied" cryptology.

Table 56: Indicative BIG SEVEN context references 3.15

CryptoCat No option for manual creation of a symmetric End-to-End encryption passprase e.g. for an E-Mail or Chat-Message available.
GoldBug Option for manual creation of a symmetric End-to-End encryption passprase e.g. for an E-Mail or Chat-Message available. Also more than five different methods to securely transfer the passphrase.
OTR+XMPP Option for manual creation of a symmetric passprase only for the SMP-Process in OTR available.
RetroShare No option for manual creation of a symmetric End-to-End encryption passprase e.g. for an E-Mail or Chat-Message available.
Signal No option for manual creation of a symmetric End-to-End encryption passprase e.g. for an E-Mail or Chat-Message available. Asymmetric ephemeral keys for the chat session.
SureSpot No option for manual creation of a symmetric End-to-End encryption passprase e.g. for an E-Mail or Chat-Message available.
Tox No option for manual creation of a symmetric End-to-End encryption passprase e.g. for an E-Mail or Chat-Message available.

Table 57: Good Practice Insights #15

# 15 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case If I want to share with my communication partner a password, should I say this better orally or transmit it over one of the available secured online channels?
Solution The online channels are appropriately secured in GoldBug with encryption. Especially when it comes to the immediate renewal of additional encryption layers (such as during the Instant Perfect Forward Secrecy) they are on offer. If it comes to arrange with a friend a password on the e-mail ("GoldBug"-password) or on a file-transfer ("Nova"-password) also a verbal message is recommended.

Source: Own Case.

***

Packet-Communication: Test of the Adaptive Echo (AE)

While the in GoldBug applied echo protocol is stating - shortened - that firstly each data packet is encrypted, and secondly each node sends a respective data packet (further) to each connected node, the Adaptive Echo (AE) offers the possibility to exclude nodes in the distribution of data packets - this refers to nodes that do not have a cryptographic token, which is similar to character string of a passphrase.

Inventory taking, structural analysis and descriptions of the functions

The echo protocol is a very simple protocol: it does not contain any routing information. Each node simply sends the encrypted data packet to all of its online connected nodes further on its own. This does not happen as forwarding, but each node tries to unpack the package and to decrypt it - failing this, the package is re-packaged and re-sent - as its own action of the node.

To routing or forwarding belongs also the understanding of the existence of a goal, a destination address, and, the carry-on belongs to be done on behalf of a sender. However, both is not given in the echo protocol! The node tests whether it can decrypt the data packet, and if no readable text comes out, the node packs the whole again and sends it to all connected nodes further, which try the same then. This is just an illustrative description step; the data is not actually repackaged: it is each provided to all available neighbors - except the neighbour, which the data originated from. For the Adaptive Echo (AE) however, a long password or cryptographic token in each node of a defined path of a graph has to be deposited.

Messages that are sent from a so-defined node to another nearby node are then not sent to other nodes, which do not know this token. This makes it clear that the participants can exclude other nodes in a link chain with the AE token to ever receive a message that passes along.

This works over adaptive learning of the nodes: messages of nodes with a certain AE token are only to be forwarded to those nodes that have the same AE token. All other connected nodes are excluded and do not receive this message forwarding.

Hence the AE token has be inserted via the complete graph of connections, otherwise a node without further connection to an AE token will switch back to the normal echo-protocol, which means, that the data packet is sent again to all connected nodes.

For example, if Alice wants to communicate via the hubs of Bob and Ed with Maria, the four persons must deposit the AE token in their application. It is then ensured, that other, further nodes from Bob and Ed or Maria do not receive the message from Alice.

Adaptive Echo tokens are composed of authentication and encryption keys as well as details about the choice algorithms. If configured, binding endpoints are able to permit or restrict information-flows based on the content of the data.

As an example, peers that are cognizant of a specific Adaptive Echo token will receive data from other cognizant peers whereas traditional peers will not. Binding endpoints therefore selectively-echo data.

The Adaptive Echo behaves as follows (comp. also Spot-On Developer Documentation 2014):

1. A binding endpoint defines an Adaptive Echo token. The information must be distributed securely.
2. A networked peer having the given Adaptive Echo token generates HHash Key(EEncryption Key(Message || Time)) || EEncryption Key(Message || Time) where the Encryption Key and Hash Key are derived from the Adaptive Echo token. The generated information is then submitted to the binding endpoint as “Message || Adaptive Echo”-Information.
3. The binding endpoint processes the received message to determine, if the message is tagged with a known Adaptive Echo token. If the message is indeed tagged correctly, the Time value is inspected. If the Time value is within five seconds of the binding endpoint's local time, the message is considered correct and the peer's presence is recorded.
4. As the binding endpoint receives messages from other peers, it inspects the messages to determine if the messages have been tagged with Adaptive Echo tokens. This process creates a network of associated peers. Because peers themselves may be binding endpoints, the Adaptive Echo may be used to generate an artificial trust network.

(An alternative way - to create a web of trust within GoldBug - consists in the account creation for a listener, on which connected peers thus will spread the message again to all other connected peers. The term "web-of-trust" has not only been implemented in the client GoldBug on the physical layer of IP-connections, but also it was differentiated for cytological peer-addresses (e.g. the chat key, which also can be defined over Adaptive Echo Tokens within a web of trust, as described above)).

Selected method for studying and function reference

As a method of investigation, a practical test setup shall be used, which is annexed in the documentation for the echo protocol of the application. To explain the Adaptive Echo a classic example of the fairy tale of Hansel and Gretel and its structure formation in an AE network grid is used.

Figure 22: Adaptive Echo - Hansel, Gretel and Wicked Witch example

Source: Spot-on Developer Documentation 2014

In the above-described AE-Grid the persons Hansel, Gretel and the Wicked Witch are highlighted as nodes. Now Hansel and Gretel reflect, how they can communicate with each other - without the Wicked Witch noticing this.

According to the "Hansel and Gretel"-tale they are in the forest of the Wicked Witch and want again to escape from this forest and mark the way with "bread crumbs" and "white pebbles".

This fairy tale content can now illustrate and demonstrate also in the grid pattern above the Adaptive Echo and at which points of the grid respectively of the communication graph a cryptographic tokens called "white pebbles" can be utilized:

If node A2, E5 and E2 use the same AE token, then node E6 will not receive a message that will be exchanged by the node A2 (Hansel) and node E2 (Gretel).

The node E5 learns respective evaluates over the known token "white pebbles" not to send the message to the node E6, the "Wicked Witch". A learning, self-adjusting and proving ("adaptive") network.

An "Adaptive Echo" network reveals no target information (see also the other hand "ants routing"). After all - as a reminder: The mode of "Half Echo" sends only one hop to connected neighbors and "Full Echo" sends the encrypted message to all connected nodes via an unspecified hop count.

While "Echo Accounts" help or hinder other users almost as a firewall or authorization concept in connecting, "AE tokens" provide graph- or path-exclusivity - to be regarded for messages that are sent over connected nodes, which also know the AE-token.

Chat server administrators can exchange their token with other server administrators, if they trust among themselves and thus define a Web-of-Trust ("Ultra-peering for Trust").

In network labs or at home with three or four computers one simply can try out the Adaptive Echo and document own results (compare GoldBug-Manual of Edwards, Scott (Ed.) 2014).

Conduction and findings of the examinations

For a test of the Adaptive Echo a network has been formed with ten computers and then the following exemplary sequence was implemented. We have used four laptops to map the actors in the grid and further nodes on other desktop machines were installed, including Raspberrry-Pi computer as a simple kernel-hoster. For our assessment of GoldBug we have adjusted this following experimental setup:

1. First Create a node as a chat server.
2. Create two nodes as clients.
3. Connect the two clients to the chat server.
4. Exchange keys between the clients.
5. Test the normal communication skills among both clients.
6. Set an AE token on the server.
7. Test the normal communication skills among both clients.
8. Now use the same AE token in a client.
9. Write down the result: The server node stops sending the message to other nodes, which do not have the AE-token or don’t know it.

(To launch multiple program instances of GoldBug on a single machine and connect to each other also "SPOTON_HOME" as (suffix-less) file in the binary directory may be used.)

Because also the Wicked Witch and Gretel have swapped their chat keys - they therefore can receive messages of each other in the normal echo mode - it is indicated, based on the application of AE tokens into the appropriate nodes, that then the Wicked Witch does not get the message.

Optional: Because all this has been tested with HTTPS connections, and the certification of non-obtaining the message at the Wicked Witch has been pointed out by the fact, that the message does not appear (because it is not received and therefore cannot be decrypted), you can of course also adjust this experimental setup with HTTP without TLS/SSL connections.

It only has to be defined the respective Listener without SSL.

Then it can be seen for the node of the Wicked Witch within any browser, which is set to localhost port 4710, which encrypted messages the Wicked Witch receives.

If one would record this and also record the messages, that are sent from Gertel´s node, so it will be noted here, that the broadcast of Gretel´s ciphertext physically does not appear in the node of the Wicked Witch.

Source: own graphic.

As a result, it can be said, that the Adaptive Echo - when using the AE-token - secures a connection graph as above tested with three actors in an enlarged node network. Nodes can be excluded from the route, so they will not see certain messages.

This is an important safety option for persons who, for example, create a chat server (listener) for a group, and the Admin of the chat server wants to assure two communicating people exclusivity in their communications. That means all other neighbors, which are related to this listener, will not be included in the exchange of encrypted data packets from people, who know the AE token.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

This function of the Adaptive Echo has to be regarded as highly innovative and offers many practical experimental examples and analysis options in all, the topic of graph theory, as well as network management, or the cryptographic tokens.

Risks or weaknesses are not seen. It must be ensured, when a longer graph to the respective communications partner is regarded, that all to be defined nodes have to enter the AE token.

With respect to the routing definition is also to be regarded, that a connection between two echo nodes can, for example, also be routed through the proxy function (e.g. via the Tor network). This remains to point out further research and development as a question for further investigation, how an AE connection can be evaluated through the Tor network, respectively an input-proxy and exit-node.

This view also shows the good equipment of the client, that a proxy can be defined, so that the software can be utilized behind a firewall respectively a proxy - e.g. also over the Tor network.

Table 58: Description of findings 3.16

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
3.15.4.A Potential for Improvement The user must be aware to transfer the AE Token within a secure environment. Informational
3.15.4.B Strength Adaptive Echo excludes other nodes from receiving information. This has to be regarded as very innovative compared to the state of the art in other communication solutions. Adaptive Echo is able to create an artificial Web of Trust for your crypto key. High

Appraisal of good practices in comparison with other similar applications

Compared with other open source applications, it is in no other application possible to store cryptographic tokens to define a path through various graph options.

The comparable crypto-messengers usually define a centralized star-like model that means, all clients connect to a central chat server (from the vendor).

The option to create a private, independent chat server - for instance in a students dormitory or at a LAN party - is not so easy given in most other applications such as in GoldBug Messenger. Here is just to define a listener with a few clicks - and this can be set up even without internet or a cable via Bluetooth.

Table 59: Indicative BIG SEVEN context references 3.16

CryptoCat No networking across multiple servers possible, no cryptographic token for routing, and no proxy function.
GoldBug Optional cryptographic token for networking across multiple nodes. Suggestibility of the graph and routing. Proxy-capable and can also be used over Tor. AE token can create an artificial web of trust.
OTR+XMPP No cryptographic tokens available. Some proxy enabled clients.
RetroShare Web of Trust with connections over friend to friend. No option to leave any friend out. Proxy since version 06.
Signal No networking across multiple servers possible, no cryptographic token for routing, and no proxy function.
SureSpot No networking across multiple servers possible, no cryptographic token for routing, and no proxy function.
Tox No networking across multiple servers possible, no cryptographic token for routing, and no proxy function.

The ability to address a proxy is not well introduced in all other applications. RetroShare has this option built in since version V06. The proxy capability and the ability to control the graph over different nodes by the use of cryptographic tokens are yet only given in the Messenger GoldBug.

Table 60: Good Practice Insights # 16

# 16 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case I use a chat server of a friend, but would like that my encrypted messages there are not distributed to other neighbors, but only to my friend. How to do this?
Solution GoldBug offers within the Echo protocol the option to use a cryptographic token. Thus the echo protocol is changed to the mode of the Adaptive Echo (AE): In this case a message will be distributed only to nodes, that have the token. Secondly, there is the possibility to use the mode of the Half Echo, in which the message is sent only as a single hop to the next machine. Otherwise, any message in the echo protocol is sent on to any connected neighbor and can therefore be better protected against network and metadata analysis.

Source: Own Case.

***

Wireless Interaction: Creating a Bluetooth-Listener

The connection of the message sending clients with a server or with a listener of another clients can operate in different ways over the Internet, but also - separated from the Internet and dissociated from a local cable - over a local Bluetooth radio connection.

Inventory taking, structural analysis and descriptions of the functions

While we of course consider today a constant availability of an Internet connection, this cannot be assured for any time, any place and possibly even not in special situations.

Thus, alternative connections become more central, that do not run through the usual channels. Also from a point of view for the protection against attackers is a network of clients over alternative routes and ports meaningful.

The GoldBug messenger not only offers the possibility of connecting a neighbor over TCP, UDP or SCTP, but also to create a chat server or listener via Bluetooth.

This characterizes not only the ability to connect local participants at the Internet loss, but also e.g. the simple use case to join the participants at a trade show, a congress or a LAN party wirelessly. Due to the Echo protocol it is needed at the end of the network possibly just a single node, which connects via another neighbor into the Internet, so that all by Bluetooth connect nodes participate then also in the global network again. The Echo Protocol is mesh-capable.

Although Bluetooth connections of smartphones become more common, for example with your own car, Bluetooth community servers need to experience at conventions still deepening until the technology is naturally, as when someone extends a LAN cable or connects their equipment battery to an electrical outlet.

The non-open-source and only mobile application FireChat had large gatherings of people by local wireless connections in Hong Kong, Ecuador and Iraq during their demonstrations while social crisis and protests times without Internet (compare Wikipedia).

Bluetooth is provided over the implementation into the application GoldBug for all communication processes and incorporates Bluetooth libraries via the Qt framework.

Under Qt 5.5 is currently a working Bluetooth connection enabled only under Linux, so that the following investigation refer to two Linux machines with the GoldBug messenger.

Selected method for studying and function reference

In the present assessment therefore is also the Bluetooth function to tested by means of a practical application. The aim is to create a connection between two nodes via a Bluetooth connection and the correct transfer of a chat message.

Conduction and findings of the examinations

For this purpose a listener with Bluetooth is created on a compilation of the GoldBug messenger on a Linux (Ubuntu) machine. Then on a second laptop - as well with Linux (Ubuntu) - another client is created and connected via Bluetooth to the Bluetooth listener.

Figure 27: Creating a Bluetooth Chat-Server / Listener

Source: Own screenshot of GoldBug, Chat Server Tab with Bluetooth Listener, on an Ubuntu Linux compile.

The two clients exchange each the key for encryption. The result shows that both clients are connected to one another over the Bluetooth connection, and can communicate.

A data transfer was initiated by the popup chat window and transmitted at a relatively high bandwidth. The result of the Bluetooth connection is correct and also the speed of a file transfer is more than satisfactory.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

As improvement may be noted, that the connection involves regular security levels for the Bluetooth. These are displayed in the client, but not documented in the manual, which was as version based for the audit. The short description of the establishment of a Bluetooth server in the manual might has the reason that a Bluetooth connection is rather a special case for a research question of a research group.

End consumers will certainly offer more as a multiplier or administrator at a conference or a meeting such a connection, but do not connect regularly at home two nodes via Bluetooth. Therefore, there is in here to be assessed subject no risks or potential for improvement, but only the wish that Bluetooth connections are further evaluated scientifically respectively that wireless communication options are also available for conferences and meetings, to involve participants into learnings.

Table 61: Description of findings 3.17

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
3.16.4.A Potential for Improvement Documentation of the security level of Bluetooth in the user manual. ./.
Strength ./. ./.

The following chart was discussed on Twitter and presents a model of a graph by the project, which is connecting the participants in two workshop or class rooms with a Bluetooth listener. With this a kind of "Buetooth-Freifunk" is created - as with the German term "Freifunk" a free wireless WLan-offer is described, which is made available through the user community.

Figure 28: Graph-Example including Bluetooth-Chat Servers in a classroom

Also the wireless options, to connect two GoldBug nodes via a radio link (Hamradio or shortwave) or a WiFi mesh network are shown.

The here interesting Bluetooth function can thus provide especially for workshop situations the functions such as group chat, private chat, email and URL-Search. It is an alternative to WLAN access points and a simplification to set up a simple laptop for both, WiFi receiving as well as a BT server - which might reduce the configuration of WLAN routers or repeaters on additonal hardware.

Appraisal of good practices in comparison with other similar applications

GoldBug is currently - according to the provisional assessment to the comparable applications - the only client that can hold a neighboring connection via Bluetooth or can act as a Bluetooth server.

Although this is a rare use case, and currently just provided by the Qt-framework for linux machines, it shows - in addition to the applicability of the SCTP protocol - an advanced status next to the consideration of connection alternatives to TCP and UDP, as well as an interesting variance for research questions.

Table 62: Indicative BIG SEVEN context references 3.17

CryptoCat No Bluetooth available.
GoldBug Chat-Server and Connection over Bluetooth is possible.
OTR+XMPP No OTR key transfer over Bluetooth available.
RetroShare No Bluetooth available.
Signal No Bluetooth available.
SureSpot No Bluetooth available.
Tox No Bluetooth available in evaluated version.

Table 63: Good Practice Insights #17

# 17 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case Next week we have a meeting and I would like to offer a group chat for the participants and also transfer some files to these. My laptop is connected over the WLAN in the internet and my Bluetooth module is expected to host the chat of participants as a server. How can I deploy this?
Solution To use GoldBug as a Lan Messenger with chat, e-mail, group chat and file transfer is simple. This is a wired solution.

Who wants to do without cable, can provide also over WLan an appropriate communication server. GoldBug allows for in experiments interested users furthermore also (currently with the Qt framework 5.5. only) on Linux, to create a chat-server via Bluetooth. So each user can chat with each other wirelessly.

Source: Own Case.

***

Social Engineering: SMP - Socialist-Millionaire-Protocol

The Socialist Millionaire Protocol describes a method, by which it can be demonstrated, that both chat participants have entered the same password without transmitting the password itself over the Internet.

A shared secret or a common phrase can therefore help to authenticate the chat friend. It is an additional security feature.

This object is originally known as Yao's millionaire problem (compare Yao 1986, Loannis 2003): Two millionaires want to determine who is the richer, without disclosing their account balances. A variation of this is the so-called Socialist Millionaires' problem (compare Jakobsson 1996), in which the two are only interested in whether their wealth is equal.

Formal in both cases is a way requested, how Alice and Bob can determine a function value f (x, y, ...) without any of them obtaining (x, y, ...) additional information about the input values.

A process with these characteristics is called a zero-knowledge protocol. If the result of f is a truth value, then it is a zero-knowledge proof. Furthermore, a protocol is called fair, when neither party can terminate it with a significant information advantage (compare also Hallberg 2008).

A method according to the above principle was later implemented by Borisov et al. (2004) under the name "Socialist Millionaires' Protocol" (SMP) for the off-the-record program.

Off-the-Record enables encrypted communication over instant messaging clients predominantly based on XMPP.

In this case, the method outlined above is suitable in particular, because the communication partners are often familiar with each other, but usually do not have an existing channel for secure key verification (compare Hallberg 2008).

For friends, who know each other from a public group chat like IRC virtually, OTR is offering not much more, because modern protocols also allow a key transfer and other functions via secure channels.

Figure 26: Socialist-Millionaire-Protocol in the graphical user interface of the GoldBug Messenger

Source: Screenshot of Goldbug 2.8, compare Edwards, Scott (Ed.) et al. 2014.

Inventory taking, structural analysis and descriptions of the functions

In GoldBug Messenger sign regularly both participants the messages with the RSA algorithm (or another to the available algorithms) to verify, that the key is used by the original sender.

For the (possibly unlikely) case, that a machine has been compromised or if the encryption algorithm would be broken, with the Socialist-Millionaire-Protocol-(SMP)-process a friend can simply be identified or authenticated by entering the same password on both sides.

The idea is to ask in chat to a friend a question like: "What is the name of the city that we visited together in the last year?", or to ask a question like: "What is the name of the restaurant, where we met the first time?" etc. (compare GoldBug Manual of Edwards, Scott (Ed.) et al. 2014).

Selected method for studying and function reference

A review of the SMP function can be done in a practical, technical and theoretical level.

On a theoretical level, you can think through various communication scenarios to achieve a common password for both parties, so that an attacker remains undetected. This would e.g. concern the theoretical assumption that a partner is communicating with an attacker and the attacker can view the keystrokes.

On a technical respectively mathematical level the individual steps of a zero-knowledge proof are defined and follow this graphical process flow chart shown below, which is provided by the developers in the documentation. The process graphics has been later also adopted by the Wikipedia.

Figure 30: Socialist Millionaire Protocol – State Machine Process

The following table illustrates then the mathematical calculations per step.

Table 64: Steps of the Socialist Millionaire Process

Alice Multiparty Bob
1 Message ${\displaystyle x}$
Random ${\displaystyle a,\alpha ,r}$
Public ${\displaystyle p,h}$ Message ${\displaystyle y}$
Random ${\displaystyle b,\beta ,s}$
2 Secure ${\displaystyle g=\langle h|a,b\rangle }$
3 Secure ${\displaystyle \gamma =\langle h|\alpha ,\beta \rangle }$
4 Test ${\displaystyle h^{b}\neq 1}$, ${\displaystyle h^{\beta }\neq 1}$ Test ${\displaystyle h^{a}\neq 1}$, ${\displaystyle h^{\alpha }\neq 1}$
5 {\displaystyle {\begin{aligned}P_{a}&=\gamma ^{r}\\Q_{a}&=h^{r}g^{x}\end{aligned}}} {\displaystyle {\begin{aligned}P_{b}&=\gamma ^{s}\\Q_{b}&=h^{s}g^{y}\end{aligned}}}
6 Insecure exchange ${\displaystyle P_{a},Q_{a},P_{b},Q_{b}}$
7 Secure ${\displaystyle c=\left\langle \left.Q_{a}Q_{b}^{-1}\right|\alpha ,\beta \right\rangle }$
8 Test ${\displaystyle P_{a}\neq P_{b}}$, ${\displaystyle Q_{a}\neq Q_{b}}$ Test ${\displaystyle P_{a}\neq P_{b}}$, ${\displaystyle Q_{a}\neq Q_{b}}$
9 Test ${\displaystyle c=P_{a}P_{b}^{-1}}$ Test ${\displaystyle c=P_{a}P_{b}^{-1}}$

Note that:

{\displaystyle {\begin{aligned}P_{a}P_{b}^{-1}&=\gamma ^{r}\gamma ^{-s}=\gamma ^{r-s}\\&=h^{\alpha \beta (r-s)}\end{aligned}}}

and therefore

{\displaystyle {\begin{aligned}c&=\left(Q_{a}Q_{b}^{-1}\right)^{\alpha \beta }\\&=\left(h^{r}g^{x}h^{-s}g^{-y}\right)^{\alpha \beta }=\left(h^{r-s}g^{x-y}\right)^{\alpha \beta }\\&=\left(h^{r-s}h^{ab(x-y)}\right)^{\alpha \beta }=h^{\alpha \beta (r-s)}h^{\alpha \beta ab(x-y)}\\&=\left(P_{a}P_{b}^{-1}\right)h^{\alpha \beta ab(x-y)}\end{aligned}}}.

Because of the random values stored in secret by the other party, neither party can force ${\displaystyle \scriptstyle c}$ and ${\displaystyle \scriptstyle P_{a}P_{b}^{-1}}$ to be equal unless ${\displaystyle \scriptstyle x}$ equals ${\displaystyle \scriptstyle y}$, in which case ${\displaystyle \scriptstyle h^{\alpha \beta ab(x-y)}~=~h^{0}~=~1}$. This proves correctness.

It must be assessed as unlikely that the mathematical calculation may be changed, and secondly, the calculation is a programmed basis in both clients.

That leaves only the practical level to manipulate password entries:

In most cases for an intrusion into a foreign computer system to view confidential data something is used, what is called "social engineering" (compare Harley 1998); one then speaks also of social hacking.

The basic pattern of social engineering shows e.g. up in bogus phone calls as follows: The social engineer calls a company's employee and pretends to be a technician, who need the credentials to complete important work.

Already in advance such an attacker has collected from publicly available sources or previous calls small pieces of information over procedures, daily office talk and corporate hierarchy, which help him in his interpersonal manipulation, to impersonate as insider of the company.

In addition, he confuses his opposite, which technically may not be such an expert, with jargon, builds with Smalltalk over seemingly common colleagues sympathy and uses authority respect by threatening to disturb a superior in case the victim neglects cooperation.

Under certain circumstances, the social engineer has been collected in advance information that a particular employee has even really requested technical assistance and already actually expect such a call.

Despite its apparent banality happen with the method again and again spectacular data breaches: This enabled e.g. an American student in 2015 to be able to open the private e-mail account of the acting director of a large organization, and had three days access to it (compare NZZ 2015 and Wired 2015).

In the following, therefore, on a practical level of communication should once a (theoretically possible) dialogue be simulated, with the examination question, whether a whatever kind of dialogue can lead an online friend to enter the password, which is requested by an attacker instead of the real friend.

Conduction and findings of the examinations

Thirdly, therefore, on a practical level, one would have to try through skillful communication at the online communication in messenger with several people, to enter the supposedly common SMP password also in the right way - as it should be thought out in the following for an attack in a theoretical example of a practical attempt of manipulation for the use of a messenger:

Suppose Alice and Bob have married in New York City. Alice assumes for her online communication, that at the other end of the line is also Bob. Suppose further, an attacker has managed to take over the infrastructure of Bob:

Bob has been pulled away his chair from the desk from behind and the functioning and opened machine is now available to the attacker. The attacker knows some things from the lives of both people in the conversation. Thus, the attacker e.g. found out, that both have married in New York and Alice uses this password even with two of the major webmail providers.

Alice prefers now to insure herselves once more, if really Bob sits in front of the computer at the other end and therefore asks in the online chat to Bob as follows:

Alice: Hello Bob,
Bob (aka Attacker):  Hello Alice, how are you?
Alice:  Thank you, I am fine. Before we start with our chat,
we should authenticate over the SMP-protocol.
Do you remember still, in which city we have married?
Bob:  Sure, of course, you mean, we should use the city name
as a Password für the Socialist-Millionaire-Protocol?

`

Alice deposited her password "new york" and asks Bob to do it equally. The attacker enters also the password "New York".

The SMP process fails.

Alice is clear that maybe not the real Bob is sitting at the other end of the line, because with him she had arranged once in a private session, to enter all passwords always only in lowercase letters and without spaces.

The process makes it clear, that the attacker can respond to the Socialist-Millionaire-Process-(SMP)-protocol only successfully in the situation, when Alice's question for a password is predictable and always the same password is used in daily chat.

At the same time, the attacker must know the content of the possible answers to Alice's SMP question. Thus, it is an absolutely unlikely event that a foreign attacker can enter the correct SMP-password. Anything else would clairvoyance or brainwashing. The daily communication and the large number of possible ideas that a communication partner could question, makes it almost impossible to guess the password.

The password is technically not transferred between the two. If the password of Alice could not be found out by a Social Engineering Process e.g. as described above, is ultimately left only the interception of the keystrokes of Alice, so that the password can also be entered on the side of the computer of Bob.

Also at this point, therefore, should be pointed again to the possibility of using the virtual keyboard, which is built-in in the client GoldBug and which excludes the regular records of keystrokes.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

Since the probability to guess a password input through a dialogue can be considered highly unlikely, is here at the correct application of the optional SMP security feature to see in a review no risk, but rather on the other hand: the application of the SMP feature increases even more the confidentiality respectively authenticity.

Generally processes of consciousness and cognitive processes must be fostered as measures for the users, not only about what the SMP security feature is, what it offers and how it works, but also to be mindful, to make the process creative and varied with own communication partner (compare also Weßelmann 2008).

The messenger referenced for comparison - except of some selected OTR-XMPP clients - have no or no such pronounced SMP-function and the manual input of the individual to enter password is not such to be found.

Table 65: Description of findings 3.18

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
3.19.4.A Risk Theoretical Social Engineering atempts Informational
3.19.4.B Potential for Improvement Function develops awareness processes at the side of the end-users Informational
3.19.4.C Strength GoldBug uses stronger SHA-512. Medium

Appraisal of good practices in comparison with other similar applications

Only OTR-XMPP Messenger have depending on the client possibly an SMP-function by the OTR protocol installed, as described for OTR in a modification.

The GoldBug Messenger has installed the SMS function as well and allows the manual definition of the password.

Technically shows our code review that Goldbug makes use of a SHA-512, and AES 256 and a 3072 bit key (SMP accurs within the chat dialog), while on the other hand OTR uses only the SHA-256, AES 128-bit and for the Diffie-Hellman key exchange 1536 bits - in regard from the cryptographic strength OTR is therefore only half as secure as of the implemented Socialist-Millionaire-process in the application GoldBug in all three cryptologic factors.

Moreover, in particular the by OTR used low AES-128 has been officially designated as "not safe" by the NIST (compare NIST 8105, 2016) - so OTR must apply in all XMPP clients as obsolete and potential security risk: In stormy Quantum times the OTR-dike breaks all too quickly and urgently needs a new manifesto for all XMPP clients!

Table 66: Indicative BIG SEVEN context references 3.18

CryptoCat No Implementation of the Socialist-Millionaire-Protocol.
GoldBug Elaborated Implementation with a pleasant user interface, elaborated Documentation, as well with manual choice of the password. Usage of SHA 512, AES 256 and 3072 bit for the key.
OTR+XMPP Elaborated Implementation only in selected XMPP Clients with OTR, extended documentation. Usage of SHA-256, AES 128 and 1536 bit for the key.
RetroShare No Implementation of the Socialist-Millionaire-Protocol.
Signal Usage of a less documented own development ("home-brewed approach to encryption") als extension of OTR (Perrin 2014). No manual choice of the password. SHA-256, AES 256, 256 bit Curve25519 key.
SureSpot No Implementation of the Socialist-Millionaire-Protocol.
Tox No Implementation of the Socialist-Millionaire-Protocol.

Cryptocat, RetroShare, SureSpot and Tox (compare Ticket #1271) have the Socialist-Millionaire-protocol not implemented with manual password choice.

For a summary and contextual evaluation can be summed up that

• Messenger, which have not yet implemented the SMP process, should incorporate this possibly,
• that it is to be welcomed, to explore the developing SMP process and also OTR implementations further (e.g. in terms of the protocol or the implemented cryptographic values strengths) and that this is continued,
• and thirdly, that it is good for the user as well as the development community - in spite of financial funds for Crypto-projects of public and private side as well-initiated marketing hype - to explore alternatives and scientifically to promote, which are not placed by financial support and multipliers stimulation on everyone's lips, but rather remain as independent, as it is the case at several above mentioned projects.
• The individual definition of cryptologic values (key size or manually entered passwords) increases confidence in the own configuration of the security while using the applications.

The often wrongly judged informal rule, that new ways, methods and processes are to be avoided in cryptography, is not to quote in the first place in use of established libraries and computing procedures.

Anyway, it is therefore incomprehensible that the "homebrewed"-crypto Axolotl is experiencing a hype - it is even seen as a winner against OTR - and also other improvements as "privacy" be shrugged off. So-called experts seem here to want rather to keep their power of definition. "Homemade" inventions also provide an opportunity to scientifically open up comparisons and professional judgments.

At the same time the development of the good is of course always a threat to the established: XMPP is now in severe hardship, to position itself as an encrypted messenger, when asymmetric crypto provides the forehead to the old and on the one hand mature, but on the other hand slightly not further developed OTR.

XMPP as Foundation had to call all clients with a manifest, to implement OTR (Saint-Andre 2014) and after the turn to an asymmetric-ephemeral paradigm to recognize, that almost a second manifesto had to be proclaimed - based on PGP (Schmaus 2016) - while nevertheless security experts plead to "letting die PGP" (compare e.g. Schmidt 2015), because it was deemed as too complicated and as encryption for the masses called as not able to establish.

Because not encryption in the client OTR-XMPP is the advantage, here XMPP does rather hard: First, all XMPP clients were to "OTR" driven (2014), then to Omemo-XEP (Gultsch 2015), and now to "OX" (Schmaus 2016). Will it be rather Axolotl or EDH instead of OTR? Or an SMP Calling or FS Calling as in GoldBug?

Another way of encrypting messages over XMPP server is described in section 3.1 and lays in the use of the capsule encryption known from the echo protocol.

So the Echo protocol is, for example, in the XMPP-client of the Indian XMPP-developer Manjeet Dahiva, who founded and developed the XMPP library for the Qt framework (QXMPP), implemented, and to find as a hybrid application under firefloo.sf.net.

If one now uses a key from the application GoldBug for the encryption of a message before it is sent over XMPP, one could speak of the method or model named "Orientated Kapsule Encryption of Echo (OKEE)" - the encrypted message capsule of the Echo protocol is then only sent to a dedicated XMPP chat friend.

The following table illustrates the possible encryptions of XMPP, with which numerous decentralized developers explore various ways.

Table 67: Encryption options for Jabber / XMPP

Also, the news portal Golem confirmed (03.09.2016): "Meanwhile OTR is however a bit getting old. One problem is that it is thus not possible to send encrypted mail, if the other party is offline", that is, if the partner is offline, the message is no longer encrypted or sent. In addition, discovered Markus Vervier of the company X41 D-Sec in an analysis of the code of libotr an integer overflow, which has been closed since version 4.1.1 (Vervier 2016).

The security vendor Sophos advertises encryption with the phrase: "Be able to dance as if no one is watching you" (compare website Sophos, 2015.). Nevertheless, it will be difficult - to continue the metaphor - not to discover a dinosaur like XMPP dancing, for whether it is more a tailspin, remains to be seen: Instead, the decentralized chat server rather remain the advantage of XMPP. And there remains the basic problem of XMPP encryption that it always dependent on plugins (see Dalibor 2016).

The possibility of establishing a decentralized infrastructure provides as well the completely from the basic layout for encryption designed GoldBug Messenger. This is even more much easier to implement than a XMPP server in the technical operational capabilities and administrability. And: the clients RetroShare or Tox operate via DHT even completely without means of an external, dedicated server (with the disadvantage that unknown IP addresses connect to the private port).

Since of these four mentioned applications Retroshare and Tox are the only applications, that have not yet implemented the user-authentication by the Socialist-Millionaire-protocol, remains that on the expected wishlist for further development especially of these decentralized clients.

Table 68: Good Practice Insights # 18

# 18 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case If I use no digital signatures, how can I determine that at the other end is really my friend?
Solution GoldBug has implemented next to digital signatures also the Socialist-Millionaire-Protocol. Thus, a user can also be authenticated. Please simply ask your friend to enter a common password in the pop-up chat window, as you also do. If the passwords, which are not transmitted over the Internet, match, you're both real!

Source: Own Case.

***

Default Settings: Default Crypto Values for the Creation of Encryption Keys

The key of security regarding cryptographic processes is on the one hand the generation of random numbers, that are generated on the machine, but also the variance of used methods and numerical values plays a major role in making it difficult for attackers, to not beeing able to operate only with one particular method or values-assumption. Furthermore, the key size used should be sufficiently large as well as all other cryptographic values should always be set manually.

Here it gets again clear, that non-open-source software cannot be considered for cryptographic operations, because one can not verify the number of methods, the choice of the methods and the default preset values for the encryption.

It is still even with open-source applications the alpha and omega, that the user can define and modify these values himselves and manually.

No one is interested in a car, in which they cannot steer, cannot speed up and brake or can not define their preferences for color, engine and equipment when buying. Anything else would be the monoculture of universalism with referring consequences!

Even if cars are driving now according to an algorithm: There is no algorithm that overtakes a choice of the car according to own preferences regarding brand, design, technical equipment or color.

The manually not influenceable, universal software - all users use the same numbers values and methods for key generation - should be in cryptography exactly the same taboo as the use of non-open source software.

On the contrary: A high degree of manual definitions in crypto-Apps strengthens confidence in the respective application. This we want to examine below, how many setting values, the user can manually set at GoldBug and how many there would be indicative in the other applications?

Inventory taking, structural analysis and descriptions of the functions

The GoldBug-Messenger has not only during an operation a number of manually changeable values and passwords e.g. for end-to-end encryption, but also for the asymmetric encryption at the key establishment during Initial Setup of (or repeating key-generation in) the application by the user, numerous values can be manually defined by himself.

Next to

also the algorithm for encryption and for the signature itself can be chosen each. Currently, RSA, ElGamal and NTRU are implemented as methods.

NTRU is interesting because this algorithm is particularly resistant to the calculations of the powerful quantum computers.

Figure 31: Currently available Algorithms in GoldBug Messenger & E-Mail Client

Source: GoldBug User-Manual, Edwards, Scott (Ed.) et al. 2014.

At the time of assessment, the algorithm McEliece was not yet implemented, but rather is already noted in the ToDo list of the source code of the project for future implementation. This too is like NTRU especially regarded as resistant against the calculations of the powerful quantum computers (Chen/NIST 2016), because:

with McEliece a special type of error-correcting code, called a Goppa code, may be used in step 3 of the key generation. The original parameters suggested by McEliece were n = 1024, t = 50, and k = 524. Based on the security analysis of McEliece encryption (cited according to Menezes 1996:317), an optimum choice of recommended parameter sizes for this Goppa code - which maximizes the adversary’s work factor - appears to be n = 1024, t = 38, and k = 644 instead.

Although the encryption and decryption operations are relatively fast, the McEliece scheme suffers from the drawback, that the public key is very large. A (less significant) drawback is, that there is message expansion by a factor of n/k. For the recommended parameters n = 1024, t = 38, k = 644, the public key is about 219 bits in size, while the message expansion factor is about 1.6 (Menezes 1996:317).

For these reasons, the scheme receives until now little attention in other clients - GoldBug at least has it scheduled for an implementation in the sooner future.

Then finally, the user can decide on own key size. Default RSA key size of 3072 bits is set, which is considered by today's standards as sufficient. It can furthermore also key sizes of

• 4096
• 7680
• 8192 and
• 15360

be set by the user.

GoldBug Messenger offers a high variety of options, to define its own security: various key sizes, different algorithms and numerous other cryptographic values can be defined by the users themselves, as in no other clients.

Selected method for studying and function reference

The method for the assessment of the choice and definition of individual encryption values is to be structured as follows: Two users to communicate with each other, whose keys are different in size.

Once a key size of 3072 and once a key size of 8192 was created - under otherwise identical further values for ciphertype, hashtype, iteration count, salt length.

In a second experiment, a RSA and ElGamal key was then once created - also tested whether both parties can chat with each other despite different encryption algorithms.

Practical tests of setting individual encryption options should therefore be evaluated and then compared with other clients, whether they provide as well such option varieties or if the user is affected by uncontrollable settings and it is therefore made a potential attacker easy to have to focus on only one scheme.

Conduction and findings of the examinations

Two laptops were used for carrying out the assessments, they have been prepared for a key exchange. One laptop has generated a listener, to which the other machine then connected.

In the first experiment, two different-sized keys (3072 bits / 8192 bits) were used - and in the second experiment keys were used with different encryption algorithms (RSA / ElGamal).

In both experiments, participants were able to successfully communicate with each other. The setting of different encryption methods and values is therefore available and also works properly in accordance with this practical test.

Figure 32: Individual adjustable crypto values within GoldBug

Source: Screenshot of Goldbug.

Also, two key different algorithms can communicate in GoldBug to each other, which is based on the architecture of the echo protocol and its encryption manner. In our test, an RSA user could also establish a communication to an ElGamal user. The analysis of the source code shows furthermore after our review a clean implementation of different crypto libraries.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

The GoldBug client is a user interface (GUI) that should intuitively affiliate with the kernel in a simplistic way for the user. It contains in addition to a minimal GUI also an extended GUI, so that users can select an option in the main menu between various simplifications.

Those, who prefer it even more complex and with more configuration options, can choose the initial user interface of "Spot-On", which is also the kernel of GoldBug. It is attached to the installation ZIP.

In this approach for simplification within the GoldBug GUI, it is provided, that at the first initial setup, the user can not select different encryption algorithms, but only ciphertype, hashtype, iteration count and salt length and the key size.

Only after the login password has been created, with a renewed or repeated key generation, the recourse to other algorithms as RSA is possible in the user interface.

That means for initial setup RSA is given and then the user can create other keys e.g. with ElGamal or NTRU. This setting is designed to simplify at the very first installation.

Because the choice of algorithms is available only in the maximum user view, which is clickable after the initial installation.

This selection offering is therefore adapted within the user interface to the usability of the first installation.

Furthermore, no findings in the process chain of the initial installation are to be described.

Table 69: Description of findings 3.19

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
3.19.4.A Risk Breakling RSA with Quantum-Computers needs further research. Informational
3.19.4.B Potential for Improvement Implementation for McEliece scheduled. Informational
3.19.4.C Strength GoldBug supports currently three algorithms: RSA, ElGamal, NTRU. High

Appraisal of good practices in comparison with other similar applications

The most important finding of the studies in this section is, that key size, algorithm and cryptographic values should be defineable also manually.

None of the other listed comparable open source applications provide such freedom of the user to define his values in all three areas himselves.

Individual clients have options, it would be desirable, if all comparable Messengers would offer the user at least an own choice for the key size.

Table 70: Indicative BIG SEVEN context references 3.19

CryptoCat No own definition and variety of options as in GoldBug.
GoldBug Key size, Algorithm and kryptographic Values can be defined manually. New Keys can be re-generated within the applikation.
OTR+XMPP No own definition and variety of options as in GoldBug. The SMP Process offers a manual Insertion of the password in some clients.
RetroShare No own definition and variety of options as in GoldBug. Keys are oriented according to PGP basics and allow variety.
Signal No own definition and variety of options as in GoldBug.
SureSpot No own definition and variety of options as in GoldBug.
Tox No own definition and variety of options as in GoldBug.

Table 71: Good Practice Insights #19

# 19 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case Can I decide myself which key size I use for encryption and whether this should be with ElGamal, RSA or NTRU?
Solution Yes, GoldBug allows the user to configure an own Crypto-DNA. GoldBug has no compulsion to use only RSA.

Source: Own Case.

***

Passwords have in encrypted applications such as already previously expressed a crucial role: passwords are used for authentication, but have in addition to the role of "identifying persons", the use to detect certain permissions: Who the password knows (the correct code) is considered to have access.

The Federal Office for Information Security (BSI, as mentioned) recommends for WLAN access passwords of at least twenty characters. If the password does not consist of uniformly distributed random characters, even significantly longer strings are needed to achieve the same security.

By the way: Each repeated use of the password also increases the risk, to reveal the password in an unencrypted transfer or spying measures (such as through keylogging or phishing).

A password can also be made more secure, with the use of characters, which do not exist on the keyboard, for example, "®, ¤ ©". These characters are often ignored at brute force attacks. For typing you then use under Windows Alt+0174, Alt+0164 and Alt+0169. The numbers must be typed, when the Num Lock on the numeric keypad is active. The virtual keyboard of the GoldBug client was further above already mentioned for the login procedure as a particularly reliable input method.

Wie will fous now by the example of the account password in particular the code review of this method for assigning permissions.

Inventory taking, structural analysis and descriptions of the functions

Anyone, who wants to connect in GoldBug to a neighbor, so to listeners or to a chat server, can do this with HTTP, with HTTPS or even with the additional use of accounts. Accounts are usually offered by the chat server operators, that want to allow only certain people to access their infrastructure.

It could therefore be regarded as a Wi-Fi password. As seen above, recommends the German Federal Office for Security a password length of at least 20 characters. In contrast GoldBug requires a minimum of 32 characters.

The increased safety requirement of GoldBug clients by the length of account passwords is certainly a fact in the note of the Federal Office bearing in mind, that the password-choice of users often does not consist of random characters, which include special characters on the keyboard or untraceable characters (see above), but rather include many words, that are easy to find in dictionaries.

This means a 20-character password is to be cracked quickly depending on the configuration by means of a so-called brute-Fore-trial: That is, it tries all possible combinations and also uses all the words that knows a dictionary.

The account name in GoldBug therefore must be at least 32 characters.

(At explained above password procedure for logging into the application, a comprehensive 16 character password is demanded, that is then converted to a longer hash string).

Figure 33: GoldBug – Account Names and Passwords with at least 32 characters

Source: Own Screenshot of GoldBug.

Accounts are - apart from the password length - not just an ideal design of the access permissions, but provide in other words a type of firewall, which was thereby implemented in GoldBug: Who uses accounts, may exclude other users from the access or allow access only to defined and authorized users.

In addition, can be formed with accounts also a kind of virtual Web of Trust.

What was previously just know from friend-to-friend connections (F2F) by means of a key for encryption (for example, in the client Retroshare) has been decoupled in GoldBug from the encryption key for a server-model or p2p network. No one has to associate an instance and therefore also the own IP address with the key for encryption.

Accounts are an important type of granting permissions, if you want to use them. Similar to the Freifunk (as Free Wifi, cited above), you though also can advocate, that everyone shoudl be able to connect at any time, in order to communicate (which speaks for account-less listeners of a p2p network).

It is also possible to send a one-time account in a user GoldBug. This is operating for only one connection attempt. After a user has connected to this account, the account of the listener can no longer be used. Over this way you can grant guests a one time access for the use of the server.

Selected method for studying and function reference

As method for the investigation should take place again a classic code review. The programming for the account password is created in the functions

• void spoton_neighbor::process0050(int length, const QByteArray &dataIn) sowie
• void spoton_neighbor::process0051(int length, const QByteArray &dataIn)

and the code has been reviewed by us as in the other investigations of the individual functions as well.

Conduction and findings of the examinations

The conduction of the investigation relates here therefore especially to the review of the programming code of the application and specifically under close observation of the lines of code for the function of account passwords and their privileges to be granted.

Figure 34: Code for the Account Authentification in file Spot-on-Neighbor.cc

Source: for the detailes source snippet see: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf

In programming, no irregularities were found which provide information on risks or weaknesses. The programming steps have been well commented accordingly, so that it is clearly structured, and not just in the flow, but also in the content guidance of a code reader, it can be considerd as "clean" code.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

One strength is certainly the length of the chosen password, since it exceeds the safety recommendations of the Federal Office.

Table 72: Description of findings 3.20

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
Potential for Improvement ./. ./.
Strength ./. ./.

As improvement of the account password procedure can possibly be noted that it makes sense because of the password length, to constitute the account-access in form of a [[w:Magnet_URI_scheme|Magnet-URI-link}}, to help users to access the account with a single link, which just has to be entered.

Also the implementation of various methods - such as those addressed in this audit, like for the login - might make it more difficult for attackers of accounts to log into an account without permission.

Appraisal of good practices in comparison with other similar applications

Only the applications GoldBug, OTR+XMPP, Tox and Retroshare, allow to set up an own server, which may also with an authorization concept exclude or authorize users. While this is regulated at RetroShare over the encryption key, GoldBug is with its minimum requirement of 32 characters for both, the account name and password the again front runner of all above mentioned apps and refers OTR-XMPP clients in the specifications for accounts and account to places behind.

At Tox there are no user-accounts and no servers in this client-server sense, since it implements a DHT similar to RetroShare. But the DHT also has drawbacks: it notifies all participants about the own ID and the own local IP and breaks through the own firewall to allows to connect to the Unknowns to the own Tox-client. In RetroShare the implementation is here more advantageous, as the key is also longer than in Tox.

Table 73: Indicative BIG SEVEN context references 3.20

CryptoCat No accounts, which have to be passed along in a manual way.
GoldBug Accounts with comprehensive Password-length at decentral servers or nodes are possible.
OTR+XMPP Accounts at decentral Servers are possible. Minimum length of a password is depending on each client and different and questionable. No standard for the various clients.
RetroShare Accounts in a DHT via a sufficient long key for a Web-of-Trust / Friend-to-Friend-Network.
Signal One Account only possible at a central Server possible. Account creation and login grabs private information, e.g. contact list.
SureSpot One Account only possible at a central Server possible.
Tox Usage of a DHT with a relative short ID-abbreviation.

Table 74: Good Practice Insights #20

# 20 Good Practice Insight with GoldBug Multi-Encrypting Communication Suite
Case I've heard that passwords are pretty quick to crack. Are the passwords in a Messenger sufficiently long enough?
Solution GoldBug provides at various functions such as login, or account password etc. a minimum length for a password. In addition, the passwords are secured with a cryptographic hash function and cryptologic salt, so further random characters.

Source: Own Case.

***

File Analysis for the GoldBug Installation ZIP

In addition to the code analysis finally also a file-analysis shall be performed to verify the files of an install-Zip by a manual examination by knowledge, as well as by various virus scans on correctness.

Inventory taking, structural analysis and descriptions of the functions

GoldBug has provided for Windows no installation exe, but is provided in the form of a ZIP. This has the confidence-building advantage that the user can see what is in the ZIP before unpacking it and even before a binary executable file is run, as it is often a standard for other installations and in case for Windows - for example by means of a NSIS installer.

The existing ZIP files relate to the program GoldBug and Spot-On as a kernel and required files for encryption-libraries and the Qt-framework. Subpaths for Qt-plugins, sound and translations, and database-related files supplement these. The installation thus creates no entries in the Windows registry nor links on the desktop or in the Start menu will be created.

The user therefore has to start manually by double-clicking the application on GoldBug.exe in the unpacked path.

Selected method for studying and function reference

As investigation method we will look at each of the supplied file in the installation ZIP manually, and index each file, and add references to the source as well as a description comment.

Then should be automated with two virus scanners the currently actual GoldBug Version 2.9, as well as both previous versions 2.8 and 2.7, be investigated. We used therefore Kasperski and Avira.

Thirdly, and finally also in the web a search was carried out, whether independent providers as well as download portals have verified the integrity of the files with common analysis tools. In the last two steps thus also the hash sum integrity of each distributed file has been verified.

Conduction and findings of the examinations

Goldbug 2.9 contains the following files and library files that we examined individually and manually:

Table 75: List of the files from the GoldBug Installation ZIP

File / Path Originates from the library Description
GeoIP.dat Maxmind.com GeoIP Legacy Country Database Installation
GoldBug.exe GIT Source Code of GB Compiled result of the source code
icudt53.dll http://site.icu-project.org/ International Components for Unicode
icudt54.dll http://site.icu-project.org/ International Components for Unicode
icuin53.dll http://site.icu-project.org/ International Components for Unicode
icuin54.dll http://site.icu-project.org/ International Components for Unicode
icuuc53.dll http://site.icu-project.org/ International Components for Unicode
icuuc54.dll http://site.icu-project.org/ International Components for Unicode
intl.dll Microsoft dynamic link library that is a part of Microsoft Driver component
libcurl.dll Sun Microsystems, Inc., Macromedia, Inc. And Google The cURL is a command line tool for transferring files with Uniform Resource Locator (URL) syntax, supporting FTP, FTPS, HTTP, HTTPS, TFTP, SCP, SFTP, Telnet, DICT, FILE and LDAP.
Libeay32.dll http://www.openssl.org/related/binaries.html binary distribution of OpenSSL for 32bit Editions of Windows
libgcc_s_dw2-1.dll part of GCC Dynamic linking with libgcc_s_dw2-1.dll is necessary to throw exceptions between different modules, such as between two DLLs or a DLL and an EXE
libgcrypt-20.dll Libgcrypt – The GNU Crypto Library This files belongs to product libgcrypt
libGeoIP-1.dll libgeoIP This file is Dynamic-link Library
libgpg-error-0.dll libgcrypt libgpg-error-0.dll is loaded as dynamic link library that runs in the context of a process. It is installed with a couple of know programs. Related to libgcrypt.
Libiconv.dll gnu.org LibIconv converts from one character encoding to another through Unicode conversion. It is useful if your application needs to support multiple character encodings, but that support lacks from your system.
Libidn-11.dll GNU IDN Library - Libidn GNU Libidn is a fully documented implementation of the Stringprep, Punycode and IDNA specifications. Libidn's purpose is to encode and decode internationalized domain names.
libntru.dll NTRU library Provides the NTRU encryption.
libpq.dll PostgreSQL dynamic library for PostgreSQL
librtmp.dll RTMP streams librtmp is a library made from RTMPdump, a toolkit for RTMP streams
libspoton.dll Libspoton for the URL Import e.g. from Dooble Web Browser Build due to source code.
libssh2.dll OpenSSL Toolkit SSH
libssl32.dll OpenSSL Toolkit SSL
libstdc++-6.dll From MingGW distro MingW to compile C++ code on Windows
libxml2.dll XML C parser and toolkit libxml2 can be found on the xmlsoft.org server
libxslt.dll LibXslt: library and tools for applying XSLT to XML-documents
Microsoft.VC90.CRT.manifest Microsoft Visual Studio manifest or policy file
msvcr90.dll dynamic link library / Microsoft Visual Studio for windows system
msvcr120.dll dynamic link library / Microsoft Visual Studio 2013 for windows system
pandamonium.exe Pandamonium Web Crawler GUI Due to given source
pandamonium-kernel.exe Pandamonium Web Crawler Kernel Due to given source
qt.conf Qt Framework Contains path for Qt Plugins
Qt5Bluetooth.dll QT Framework Qt Bluetooth
Qt5Core.dll QT Framework Qt Core classes — always needed!
Qt5Gui.dll QT Framework Qt Graphical User Interface Classes
Qt5Multimedia.dll QT Framework Qt Multimedia
Qt5MultimediaQuick_p.dll QT Framework Qt Multimedia Quick
Qt5MultimediaWidgets.dll QT Framework Qt Multimedia Widgets
Qt5Network.dll QT Framework Qt Network
Qt5OpenGL.dll QT Framework Qt Open GL
Qt5Positioning.dll QT Framework Qt Positioning
Qt5PrintSupport.dll QT Framework Qt Print
Qt5Qml.dll QT Framework Qt QML
Qt5Quick.dll QT Framework Qt Quick
Qt5Sensors.dll QT Framework Qt Sensors
Qt5Sql.dll QT Framework Qt database driver library
Qt5WebChannel.dll QT Framework Qt Web
Qt5WebKit.dll QT Framework Qt Webkit
Qt5WebKitWidgets.dll QT Framework Qt Webkit Widgets
Qt5Widgets.dll QT Framework Qt Widget Classes
SctpDrv.SctpSocket.dll SCTP Driver SctpDrv (dll) is a package which provides an SCTP (Stream Control Transmission Protocol) driver and SCTP library for Microsoft Windows.
SctpDrv-12.05.0.exe Windows Driver Installer for SCTP SctpDrv (exe) is a package which provides an SCTP (Stream Control Transmission Protocol) driver and SCTP library for Microsoft Windows.
sctpmon.dll SCTP Driver SctpDrv (dll) is a package which provides an SCTP (Stream Control Transmission Protocol) driver and SCTP

library for Microsoft Windows.

sctpsp.dll SCTP Driver SctpDrv (dll) is a package which provides an SCTP (Stream Control Transmission Protocol) driver and SCTP library for Microsoft Windows.
Spot-On-Server.exe Spot-On-Chat-Server GUI Due to given source
Spot-On-Kernel.exe Spot-On-Kernel for GoldBug Due to given source
spot-on-neighbors.txt Project Chat Server Due to given source
sqlite3.dll SQLite Database DLL file SQLite Database
ssleay32.dll Binary distribution of OpenSSL OpenSSL for use in the OpenSSL Toolkit (http://www.openssl.org/)
zlib1.dll Official build of zlib as a DLL: http://www.zlib.net/ http://www.gzip.org/zlib/zlib_faq.html
/Documentation Several text and PDF files Descritions, Manuals, etc.
/Plugins Plug-ins for Sound, Media Qt environment files
/Sounds 5 wav sound files WAV Sounds
/SQL 3 PostgreSQL Resource Files SQL / PostgreSQL specific files
/Translations Several Translation files QM / QRC Generated by Qt

Source: Own listing based on GoldBug version 2.9.

There are no files given whose inclusion or origin were striking.

We have then scaned the installation files from versions 2.7. / 2.8 and 2.9 with different virus scanner and also found no complaints. The virus scanner Kaspersky and Avira were used. The files are "clean" - there were no complaints found in our further and doubly checked automated tests.

In the history, there have been also for previous versions of GoldBug already appropriate security scans, that are published also partly on the web. For example also the scanning of "Reason Core Security" is published on the net and this examination called GoldBug as well as "clean" under the following URL, as the screenshot of the website shows.

Figure 35: Reason Core Security Scan of GoldBug

Further analysis specific to GoldBug 2.9 have been carried out according to our Web search also on other portals, such as by Portal "Download 3K" under the URL:

There, the security is indicated even over five different scanner-suppliers as follows:

Thus it can be stated in summary that

• our own handpicked sighting of the supplied installation files of GoldBug,
• our investigation from which library-reference the files come from and
• our conducted virus scans and fourthly
• the statement, that all external security scans mentioned above see the various GoldBug versions of this Messenger continuously for all latest versions as "clean",

are all good evidence, that the installation can be regarded as trustworthy.

Goldbug can therefore be certified as safety: It does not contain badware.

As shown, there have been these security scans by other external third parties as well for numerous versions of GoldBug, so that even in the time-series-analysis occurred no complaints. For a good overview therefore also the released versions of GoldBug should be referenced here for this section:

Table 76: Release History of GoldBug Messenger based on Spot-On Architecture & Echo-Protocol

Version Date Changes
2.8 December 25, 2015 Pandamonium Webcrawler Release (XMAS-Release).
2.7 September 26, 2015 Forward Secrecy in Email & Chat Release.
2.6 August 1, 2015 Serverless Key Share-Release.
2.5 June 19, 2015 URL-Websearch-Release.
2.1 April 20, 2015 Virtual-Keyboard-Release.
1.9 February 23, 2015 Socialist-Millionaire-Protocoll-(SMP)-Release.
1.8 January 24, 2015 E-Mail-Client-Release: Plaintext-Emails over POP3/IMAP.
1.7 December 6, 2014 Poptastic-XMAS-Release: Encrypted chat over POP3.
1.6a November 9, 2014 2-Way-Instant-Perfect-Forward-Secrecy: "2WIPFS"-Release.
1.5 October 10, 2014 Alternative Login-Method Release
1.3 September 30, 2014 NTRU Release
1.1 September 9, 2014 Vector Update Release
1.0 September 7, 2014 File-Encryption Tool Release
0.9.09 August 20, 2014 Smiley Release
0.9.07 July 13, 2014 Adaptive Echo Release
0.9.05 May 31, 2014 Added Example Project Chat Server Release
0.9.04 April 22, 2014 SCTP & Institution Release.
0.9.02 March 13, 2014 StarBeam Analyzer Release
0.9.00 February 7, 2014 Tablet Gui Release.
0.8 December 23, 2013 Rosetta CryptoPad Release.
0.7 December 19, 2013 StarBeam Filesharing Release
0.6 October 24, 2013 El-Gamal Release
0.5 September 16, 2013 Signature-Keys Release
0.4 September 3, 2013 Kernel-Improvement Release
0.3 August 26, 2013 Geo-IP-Release
0.2 August 22, 2013 SSL-Release
0.1 July 27, 2013 based on the release of the same day of the Echo/Chat-Kernel-Servers and Application http://spot-on.sf.net, going back on another previous research project.

Evaluation of the results with regard to weaknesses, risks, potentials for improvements and strengths

Therefore, there arise no weaknesses or risks in regard to the distributed files from GoldBug. A particular strength like it to be seen that the further files are based on established frameworks and libraries, and that the installer is a ZIP, so that the user receives complete transparency of the distributed files.

Table 77: Description of findings 3.21

# Area Description of the finding Valuation

Severity Category / Difficulty Level / Innovation & Improvement Class / Strength Dimension

Weakness ./. ./.
Risk ./. ./.
Potential for Improvement ./. ./.
3.21.4.A Strength Usage of files from established libraries and frameworks in the installation ZIP. Medium

Also we have build the GoldBug.exe and the included Pandamonium.exe of the webcrawler, respectively the Spot-On-chat-server.exe representing the original GUI for the kernel Spot-On-Kernel.exe, from the source code using the Qt compiler.

The hash sum is adapted to each build, because in the GUI the compiling-date is included (compare Login-tab). Due to the in seconds precise time and date each binary compile from the source has its own hash sum.

The deposit of the hash sum at Hoster SourceForge for the distributed file would indeed offer seemingly more security, but would concern only the certainty that the download of the binary files in the Zip during the transfer would have been changed. For the established platform SourceForge and the Internet providers during a download process this should at a first glance not be assumed, because: Finally, everyone has with simple means the ability to build their own binary from the source code (at GitHub), when someone wants to compile the binary available for downloading.

Therefore we judge this aspect not as a potential improvement, because instead of downloading a binary file also each user can create the binary file from the source code at any time himself without having specific specialist knowledge.

The compilation process with the Qt framework is easy and described either in the project documentation and also in the user manual: click the referring "goldbug.win.qt5.pro" file in the Qt-Creator-compiler and press the "Compile" button. Nothing could be simpler, if someone wants to create their own binary and one should not trust the above mentioned five virus scanners.

CONCLUSION

The main objective of this audit was to determine the GoldBug Messenger with its features, its code and its documentation to undergo a review, which integrates essential dimensions and methods of international IT audit manuals.

Thus, the individual areas of analysis were not only described and evaluated, but also made references for further generally comparative open source Crypto-Messenger.

These BIG SEVEN Crypto-Messengers have been found from various lists of encrypted communication programs as the essential to compare open source applications.

In the overall view a very high confidentiality and a very high security requirements of the Communication Suite Goldbug has been shown up. We have no complaints found that would allow an assumption to the contrary.

The Messenger Goldug is fully compliant and conform to the available sets of regulations, policies and standards. It can be considered secure in the sense of comprehensively trustworthy.

The methods of investigation were derived from the international standard IT audit manuals, which were then based on the Goldbug application in diverse angles.

Compared to other applications, there are clear strengths of Goldbug Messenger that relate not only to the programming, the functionality and the available innovations and current standards, but highlight also in the analytic dimensions in comparison to similar functions of other Messenger.

Significant risks or weaknesses we have not found in Goldbug Messenger. The following measures, we propose, in order to prevent any shortcomings and only theoretically assumed risks in Goldbug Messenger preventively:

• update the screenshots in the manual and translation of the manual into other languages,
• Recommendation of the spelling of passwords in cases of oral transmission,
• Creation of video tutorials for the use of the application to make the users in particular through visual learning using the software even more confident.
• Only theoretically possible scenarios that passwords in the Socialist-Millionaire-Process (as with OTR) be obtained or guessed due to social engineering in the dialogue;
• The programming of the functions should be further elaborated in order to give users also advice for their purpose.

Table 78: Evaluation-Matrix of possible risks & continuous improvements suggestions

With regard to highlight the innovations and strengths of the application we noticed the following points in our audit:

• Use of hybrid multi-encryption with additional TLS / HTTPS channel,
• encryption of email and chat in one application with very simple standard procedures of established crypto libraries
• functions with numerous implementations such as group chat, file transfer, URL-web search, encryption tools or even individual elaborations as multiple login methods or the authentication by the Socialist-millionaire protocol,
• innovating the chat via e-mail server with the POPTASTIC function
• Numerous methods for the transmission of keys for an end-to-end encryption,
• Deployment of Cryptologic token for the AE mode (Adaptive Echo)
• development and application of the magnet-URI-standard for encryption values,
• Compared with other applications usage of secure hash values and comprehensive key variables, for example at login or within the SMP function,
• And many more individual perspective rich innovations as they were worked out in the individual inspection chapters.

Regarding the indicative comparisons in the reference frame of the BIG SEVEN open source Crypto Messenger, the following general recommendations for all development projects can be derived:

• The need for elaboration of each client with additional functions,
• standardization of clients in terms of safety-related aspects such as Login password encryption (key size), SMP implementation, usage of different keys for different functions, etc.,
• expanding the use of ephemeral keys and asynchronous methods,
• Provision of decentralized chat servers,

• Provision of an infrastructure that also allows to eliminate a DHT,
• More investment in the solution of the key transport problem over the introduction of numerous secured online ways,
• setting of standards of native, from the beginning implemented encryption without plugins,
• Manual definition and establishment of a symmetrical end-to-end encrypting password,
• Introduction of symmetrically encrypted group chats,
• Detailed documentation of the aspects for encryption particular in regard to comparative references to other clients.

Even if the references regarding the other crypto messenger are not based on a dedicated audit of the respective messenger by us authors - here the application GoldBug was deeply and in a broad analysis examined - indicatively a comparative evaluation can be given based on:

• the engagement with the individual audit fields,
• the total acquired knowledge base about Crypto Messenger
• as well as the investigation into the comparative Messenger.

Therefore, the following overview should be created, in which audit fields a particular application to which extent elaborates the investigated functions.

As seen methodically are the 20 fields of investigation not strengths of GoldBug, but were systematically derived from the various international IT-audit-manuals, so that the comparison is not only examined with GoldBug, but the other Crypto-Messenger are also referred to one interpretation of the audit fields of the international IT audit manuals. The assessment should be made on the following scale:

Table 79: BIG SEVEN Crypto-Messenger comparison scale

Points Scale Description
0 Function or Standard has not been implemented. Audit-Dimension not given in this client. Undetermined.
1 Several aspects are given, but others have more elaboration within this field. Does not meet our expectations of the given and found standards.
2 State-of-the-Art-Standard: The implementation in other applications is on the same level as the implementation within at least one other application. This standard meets our expectations - as well for the other open source Crypto-Messengers, due to the comparable investigations we have done indicativly.
3 The given context is definitely more elaborated than in other comparable clients or is a good practice model in general.

Taking into account the analyzes and statements in the individual audit areas, one can create an only indicative to consider point-overview for each open source Crypto-Messenger. Here we document our evaluation as follows:

Table 80: Indicative comparison of contextual assessments on the BIG SEVEN Crypto Messengers

# Chapter CryptoCat GoldBug OTR+XMPP RetroShare Signal SureSpot Tox
3.1 Hybrid / Multi Encryption,
e.g. IPFS, ephemeral keys etc.
0 2 1 0 0 0 0
3.2 Hybrid / Multi Encryption,
e.g. IPFS, ephemeral keys etc.
1 3 2 2 1 1 1
3.3 Availability, e.g.
decentral Servers / DHT
1 2 3 3 1 1 2
3.4 Ciphertext-Scan 1 2 1 1 1 1 1
1 3 1 0 1 1 1
3.6 Encryped DB, all stored
data natively encrypted
1 3 2 3 1 1 1
3.7 Accounts for
connections
1 1 1 1 1 1 1
3.8 Manuals, e.g. length,
Book or FAQ etc.
2 2 2 2 1 1 1
3.9 Other Audits 2 1 2 0 1 0 0
3.10 E-Mail Poptastic 0 3 0 1 0 0 0
3.11 FileSharing, encrypted 1 2 0 3 1 1 1
3.12 Decryption 1 1 1 1 1 1 1
3.13 Security Nuggets 0 0 0 0 0 0 0
3.14 GUI-Kernel-Interaction,
choosable chiphers
1 2 1 1 1 1 1
3.15 Analog Communication,
0 3 2 0 0 0 0
3.16 Packet Communication,
e.g. AE, routing, turtle, F2F.
0 3 0 2 0 0 0
3.17 Wireless Interaction,
e.g. Bluetooth Server
0 2 0 0 0 0 0
3.18 Social Engineering:
SMP Process
0 2 2 0 0 0 0
3.19 Default Crypto Values,
0 3 0 1 0 0 0
3.20 Account-Pass-words,
e.g. length
1 2 1 2 1 1 1
TOTAL CryptoCat
15
GoldBug
45
OTR+XMPP
23
RetroShare
22
Signal
13
SureSpot
12
Tox
13

Considering that CryptoCat enables decentralized server in the user's hand and already has a corresponding development history, one can see CryptoCat ahead of the clients Signal, Surespot and Tox. The battle cry of cryptocat developer, to address with his intended desktop client development also OTR/XMPP aka e.g. Pidgin, is then - also from the review in this overview - for CryptoCat an important motivational target (with 15 compared to 23 points obtained).

Due to the central server (with identity checks via mobile phones) in Signal and the numerous code contributions of different individuals with the appropriate coordination and review effort in Tox, possibly Surespot with a dozen points can be seen in front at these three messengers, as this also as a mobile variant can be operated with a private, decentralized server, and dispense with an identity check: No friend receives unsolicited a chat-ID, as is the case with the client Signal. Regarding RetroShare and OTR / XMPP, which also play in a comparable points-league according to the methodology used audit fields, the conditions of serverlessness for RetroShare can gain points and the missing native encryption architecture at OTR / XMPP can deduct points, so we would in a world with only one Messenger out of these two decide for the decentralized and natively encrypted RetroShare . It is also considerably more extensive than CryptoCat, but not available for mobile devices such Surespot.

GoldBug we see next to RetroShare at the top of the BIG SEVEN open source Crypto-Messenger, because GoldBug reached at the end of our substantive audit analyzes in the individual fields and features more than twice as many points as RetroShare. As seen above in a small aspect, also the related crypto procedures (for example, in the keys, hash functions or password-lengths) in GoldBug are twice as safe as using OTR.

GoldBug is very trustworthy and compliant to international IT audit manuals and security standards, but also in comparison to the individual functions GoldBug scores in our evaluation in much greater detail than any other comparative open source Crypto-Messenger. GoldBug receives twice as many valuation points in an audit matrix of 20 evaluation criteria as RetroShare. Although the development of these projects not make a stop, depth analyzes may also see ratings in the individual fields arguably here and there, we have this content and analysis found, realized and evaluated as given at the present time. Adjustments and discussions are strongly encouraged, when they are described and referenced in a scientific paper - and are especially compared.

To compare the topics, functions and audit fields of other messengers at a future time as well with the implementation and good practice models in GoldBug, remains an interesting task for upcoming student generations.

Although if today the points would be distributed differently, it shows itself indicative, that GoldBug is very far forward because of its excellent perspectives, standards and elaborations in the individual functions and audit fields and can therefore be referred to as perspective-richest Crypto-Client, one should know and have tested.

And yet: No client can be seen far back. The analysis items have shown, that many comparable Messenger have their Achilles-verses, on the other hand also their specific potentials, which need to develop further.

The collection of all encrypting Messenger has taken place (compare chapter 2), so that it is now in further research and publications of portals in particular about the phase of qualitative and substantive comparisons of BIG SEVEN Messengers.

Figure 37: BIG SEVEN Open Source Crypto-Messenger Overview

Source: BIG SEVEN - Study (Adams / Maier 2016)

De facto the clients are anchored in different sized communities, that it is to be expected that the users will leave this comfort zone of networked friends only cumbersome to use a more excellent or technically better encountered quality-standard.

Here one can possibly briefly reflect on the name of GoldBug, going back to a short story by Edgar Allan Poe, in which three friends launch a joint adventure: This means not to trot a community behind, but instead to establish with an own team a new era, to seek a new part, is the goal of learning and life: so why not even prepare for the next party a GoldBug Bluetooth-Server for friends instead always connecting via the same cable?

Not only encryption is the subject of a next cryptoparty but especially the teaching of know-how to setup a decentral server for encrypted communication.

Recommendation here is to focus not only on a client & server or a single model, but try out and to test each of the BIG SEVEN yourself (as client and chat server) - Ideally with friends who have already gained some experience with at least two Crypto-Messengers in comparison. In the future there will be continuously attempts to break cryptology, to fit cryptology with backdoors or to prohibit encryption.

A total ban is unlikely because it paralyzes the economy, and restricts personal freedom and human rights to an unacceptable extent. A partial ban is as senseless, finally remains "ciphertext" a ciphertext: No one can read it primitively, which encryption values are given, or if multiple encryption is being used. In addition the field of open source cryptology is for end-users at an advanced stage and a restriction or ban makes little sense here, like a ban on the Math or XOR operations.

Backdoors will be possibly more to be expected under asymmetric encryption than in symmetric encryption: The existing standards are therefore to be continued to be explored and also we should evaluate the random number of a machine (compare Meyer et al. / BSI, 2015).

In symmetric encryption, a common shared secret password is given. If this can not be promptly cracked due to brute force attacks, so by trying out all possible combinations due to fast computers, remains the manual definition of an end-to-end encrypting password and its immediate renewal, as defined by Instant Perfect Forward Secrecy such as by the Gemini function of GoldBug, also a perspective rich solution. In many other clients this important requirement is missing: manually defined symmetry!

The perspective of GoldBug is also in its diversity: it is similar to a house, in which hangs a chandelier. Should now possibly in twenty years, if necessary, a light bulb be broken, however the house does not need to be rebuilt. If RSA should be considered broken, we find in GoldBug as well ElGamal or NTRU available or even a hybrid symmetric encryption, which can be renewed in the hidden between two users at any time.

Since February 2014, the time in which we finalize this study, RSA now is considered broken: the American Institute NIST sees RSA as "No longer secure: we must begin now to prepare our information security systems to be able to resist quantum computing" (NISTIR 8105 / Chen et al. 2016).

Thus, the comparison of Crypto Messenger is actually obsolete and it means a Hiob's message for all other Messenger, using RSA for key creation or key transport. Also DHE, so the ephemerale key exchange using the Diffie-Hellman protocol based on RSA has thus become in need of change and requires "New Directions" (compare slso the homonymous paper of Diffie/Helman from 1976). OTR requires also multi-encryption or NTRU and McEliece.

It remains (in the Qantum age) currently the Goldbug Messenger, since it is the only one, who has additionally implemented ElGamal and NTRU and nevertheless continues to make the decoding of multiple encrypted RSA-Chiphertext extremely difficult!

Hybrid multi-encryption and numerous customizable encryption options are so far the core competencies of merely GoldBug and this situation has been not only been prooved in the comparative audit analysis, but also from this strategic consideration above, that GoldBug clearly has the edge.

Although currently downloads or user acceptance differ for all clients, restrictive circumstances of future times can change this quickly - just as well as people who think ahead:

When file-sharing in France was considered with high fines, downloads of encrypting transfer tools have increased significantly.

Also in India encryption tools experienced a boom after it was announced that the online monitoring should be extended.

Would Bittorrent replaced by StarBeam-transfers and those linked to accounts of a GB-server (for example, via Bluetooth), an intervention in the free exchange of information is no longer that easy - not only in the residence of students, but also in the worldwide web.

Also the function of the URL exchange in GoldBug, which may include the whole website of the URL, is a safe alternative to proxy networks like Tor.

For the end user with the interest of protecting personal communications ultimately not only the test of client's with a friend, but also a visit of a Crypto-Party in the group may possibly be helpful to contribute to a privacy secured future.

It has to be assumed, that, for example, a high percentage of OTR-users do not know, whether the password, that they can manually enter, defines an authentication within the meaning of the Socialist-Millionaire-Process or a measure for a symmetrical end-to-end encryption. It is still a long educative way to go to make encryption available for the masses.

We therefore will be glad, when this audit text respectively this overview of the BIG-SEVEN-study is linked to participants of a Crypto-Party in advance as material-annex and thus are able to prepare efficiently for questions, functions and clients.

With that way participants learn also about the manuals, methods and principles of an IT audit, to self assess technology-offers, that are particularly open source.

When we recognized that other communication applications and their server architecture are

• not open source (or hide even the server source code)
• implementing encryption not natively (but work instead on risky plugin architectures in which things need to be installed) and
• not encrypting both, chat and email (but instead keep chat and email separate): It shows the trend towards applications that can encrypt both, chat and email, or, as the Goldbug Messenger, even send a chat message via an e-mail server,
• (for this collection of encrypted applications at the start of this study within Chapter 2 the applications for encrypted e-mail have been omitted, because firstly these take not in particular into account the (hybrid and inclusive) trend for presence chat on mobile platforms, and secondly because for email encryption merely PGP is prominent, which is considered both, complicated and seen from some experts as stillbirth. Therefore, the innovative strength of GoldBug to encrypt both, e-mail and chat, or the concept of the client in itself can be considered as forward-looking also related to e-mail applications. Encryption for email as a plugin and without chat and then still complicated and not suitable for mass production due to historical experience - makes no sense. GoldBug is very simple to operate for both, chat and email, and the configuration of chat servers and p2p email mailboxes.
• and bring users not in a position to create their own communication server with a few clicks (but mostly need a central server) and finally
• not allowing the user a wide range of secure ways to define manual end-to-end encryption passwords for themselfs (such as a password on an e-mail, also known in this function as "GoldBug"), (and: GoldBug has with Instant Perfect Forward Secrecy a unique selling point No other client allows to define the password for a symmetrical end-to-end encryption within this frequency with a friend manually)

we wanted to contribute with this audit of GoldBug, and encourage people to deepen analysis in further research areas.

• As a further trend is to realize that not only the transfer of communication is crucial, but also the storage of the messages on the hard drive should always be encrypted.
• The Socialist-Millionaire-Protocol (SMP) as a zero-knowledge process obtains an increasingly important feature for authentication.
• Multi-encryption, i.e. the conversion of ciphertext into ciphertext ... and other multiple transformations, are becoming increasingly important in the era of quantum computers, as well as
• the choice of different algorithms within an application: In addition to RSA are to implement especially NTRU and McEliece as well as ElGamal.
• Ephemeral (temporary) keys can no longer be bound only to the tranche of one online session, but should always be renewable by the user, that is, the paradigm has changed to an Instant Perfect Forward Secrecy (IPFS): Keys that often, almost every second can be changed within a session, whenever the user wants it.
• As another trend it can be seen that Crypto-Messaging shall allow, that users can define their own values for encryption. Here we speak, figuratively, of a kind of "Crypto-DNA", which have to be adjust by the user and then should bring the greatest diversity and variety to make it as difficult as possible for attackers.
• Similarly, it represents a new trend in Crypto-Messaging to ensure in a network through appropriate protocols, that meta-data - so for example, regarding who communicates with whom, who reads when which message - not apply as far as possible or at least to make is less accessible for analysts.

The in Goldbug Messenger utilized Echo protocol is thereto a new, pioneering direction with regard to the prevention of recordings of metadata in the network.

These findings out of this study are packaged as 10 Trends in Crypto-Messaging, as the following table and info-graphic on the next page is summarizing it.

Table 81: 10 Trends in Crypto-Messaging

# 10 Trends in Crypto-Messaging
01 Consolidation of E-Mail & Chat Encryption: Messaging for both in one application & Chat over E-Mail-Servers (POPTASTIC).
02 Storage of Data on the Hard Disk only encrypted.
03 Zero-Knowledge-Process: Socialist-Millionaire-Protocol (SMP) for Authentication.
04 Multi-Encryption is: Conversion of Ciphertext.. to Ciphertext.. to Ciphertext..
05 Easy & Decentral Server Setup: Listener-Creation for Friends & Online Key Sharing in symmetric channels (EPKS).
06 Instant Perfect Forward Secrecy: Immediate Renewal of ephemeral keys multiple times in a session.
07 Individual Choice of Crypto-DNA Values: Keysize, Salt, Hash, Cipher, Iteration Count.
08 Manual Definition of Passphrases for End-to-End Encryption (e.g. in Chat) & symmetric Passwords on E-Mails. Messenger with userdefined, manually provided end-to-end sym. encryption should be the opener at the start of any Crypto-Party!
09 Avoidance of Recording of Metadata: Multi-Graph-Theory / Echo-Theory & Network-Praxis.
10 Alternatives to RSA: McEliece, ElGamal & NTRU Algorithms also as choice in an App

Source: Own collection

The following infographic on 10 Trends in Crypto-Messaging identified in this study is also an one-pager, which can offer a first beginning and introduction to the various features and standards of encryption at a Crypto Party as a handout to each participant - even before it comes to encryption principles, libraries or applications and the deepening of the functionality of the individual applications.

Because the trends clearly show that security may involve numerous aspects that should not only relate to a code review or downloading of a somehow trusted or brought close application. In this sense, we wish a successful next Crypto-Party, a common testing with each other, good development posts and of course well written and detailed documentation of experieces, is this is not yet the case.

In particular, who is documenting their practical experience in the Internet or is undertaking with a friend an experiential journey, creates a difference for the better.

This therefore also applies to the field of encryption, many reviews, posts and meetings and debates remain to in the future to be expected.

LITERATURE

1. Albergotti, Reed / MacMillan, Douglas / Rusli, Evelyn M.: "Facebook's $18 Billion Deal Sets High Bar". The Wall Street Journal. pp. A1, A6, February 20, 2014, based on Press Release URL: http://newsroom.fb.com/news/2014/02/facebook-to-acquire-whatsapp/. 2. Amnesty International: Encryption - A Matter of Human Rights, URL: http://www.amnestyusa.org/sites/default/files/encryption_-_a_matter_of_human _rights_-_pol_40-3682-2016.pdf, Amnesty International March 2016 3. Arbeitskreis Vorratsdatenspeicherung (AKV), Bündnis gegen Überwachung et al.: List of Secure Instant Messengers, URL: http://wiki.vorratsdatenspeicherung.de/List_of_Secure_Instant_Messengers, Mai 2014. 4. Arcieri, Tony: What’s wrong with in-browser cryptography? URL: https://tonyarcieri.com/whats-wrong-with-webcrypto, December 30, 2013. 5. Backu, Frieder: Pflicht zur Verschlüsselung?, ITRB 2003, S. 251–253. 6. Bader, Christoph / Bergsma, Florian / Frosch, Tilman / Holz, Thorsten / Mainka, Christian / Schwenk, Jorg /: How Secure is TextSecure (now called: Signal)? URL: https://eprint.iacr.org/2014/904.pdf, Bochum 2014. 7. Balducci, Alex / Devlin, Sean / Ritter, Tom: Open Crypto Audit Project –TrueCrypt Cryptographic Review, URL: https://opencryptoaudit.org/ reports/TrueCrypt_Phase _II_NCC_OCAP_final.pdf, March 13, 2015. 8. Baluda, Mauro et. al: Sicherheitsanalyse TrueCrypt, Fraunhofer-Institut für Sichere Informationstechnologie (SIT) für das Bundesamt für Informationssicherheit (BSI), URL: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ Publikationen/ Studien/Truecrypt/Truecrypt.pdf?__blob=publicationFile&v=2, Darmstadt, 16. November 2015. 9. Bamford, James / Campbell, Duncan: Verbot von Verschlüsselung ist kindischer Mist, URL: http://www.heise.de/newsticker/meldung/Duncan-Campbell-Verbot-von-Verschluesselung-ist-kindischer-Mist-3010493.html, Heise 2015. 10. Banerjee, Sanchari: EFYTIMES News Network: 25 Best Open Source Projects Of 2014: EFYTIMES ranked GoldBug Messenger # 4 on the overall Top 25 Best Open Source Projects Of 2014, http://www.efytimes.com/e1/fullnews.asp?edid=148831. 11. Bäumler, Helmut: Das Recht auf Anonymität, in: Bäumler, Helmut / von Mutius, Albert (Hrsg.), Anonymität im Internet – Grundlagen, Methoden und Tools zur Realisierung eines Grundrechts, Braunschweig 2003:1–11. 12. Blahut, Richard E.: Cryptography and secure communication, Cambridge : Cambridge University Press, 2014. 13. Bleichenbacher, Daniel (1998): "Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1" (http://www.springerlink.com/index/j5758n240017h867.pdf). CRYPTO '98. pp. 1–12. 14. Bolluyt, Jess: Does WhatsApp’s Encryption Really Protect You?, URL: http://www.cheatsheet.com/gear-style/does-whatsapps-encryption-really-protect-you.html/?a=viewall, June 03, 2016 15. Borisov, Nikita / Goldberg Ian / Brewer, Eric: Off-the-record communication, or, why not to use PGP. In: WPES ’04: Proceedings of the 2004 ACM workshop on privacy in the electronic society, 77–84, New York, NY, USA, 2004. 16. Boudot, Fabrice / Schoenmakers, Berry / Traoré, Jacques: A Fair and Efficient Solution to the Socialist Millionaires’ Problem, in: Discrete Applied Mathematics, (Special issue on coding and cryptology) 111, URL: https://www.win.tue.nl/~berry/papers/dam.pdf, 2001:23–36. 17. BSI / Bundesamt für Sicherheit in der Informationstechnik: Empfehlungen zum Umgang mit Passwörtern, URL: https://www.bsi-fuer-buerger.de/BSIFB/DE/Empfehlungen/Passwoerter/passwoerter_node.html, o.J.. 18. BSI / Bundesamt für Sicherheit in der Informationstechnologie: IT-Grundschutz-Kataloge. Standardwerk zur Informationssicherheit. 12. Ergänzungslieferung, Bundesamt für Sicherheit in der Informationstechnik. Bundesanzeiger, URL: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/itgrundschutzkataloge_node.html, Köln 2005ff., Juli 2011. 19. BSI / Bundesamt für Sicherheit in der Informationstechnologie: Studie zur Durchführung von Penetrationstests URL, https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/Penetrationstest/penetrationstest_pdf.pdf?__blob=publicationFile. 20. Cabinet Office: ITIL Verfahrensbibliothek – Best Management Practice Portfolio. Cabinet Office, URL: http://www.cabinetoffice.gov.uk/resource-library/best-management-practice-portfolio, 10. Juni 2011. 21. Cakra, Deden: Review of GoldBug Instant Messenger, Blogspot, URL http://bengkelcakra.blogspot.de/2014/12/free-download-goldbug-instant-messenger.html, 13 December 2014. 22. CCITT: X.800 – Security Architecture for Open Systems Interconnection For CCIT Applications – Recommendation X.800, URL: http://www.itu.int/rec/T-REC-X.800-199103-I/en, Geneva 1991. 23. cnlab: cnlab-security AG - Security Review Threema: Security Statement, URL: https://threema.ch/press-files/2_documentation/external_audit_security_statement.pdf, Rapperswil, November 2, 2015. 24. Constantinos / OsArena: GOLDBUG: ??? S????? G?? CHATING ?? ???????? ??????G??F?S?, Latest Articles, URL: http://osarena.net/logismiko/applications /goldbug-mia-souita-gia-chating-me-pollapli-kriptografisi.html, 25 March 2014. 25. Cramer, Ronald / Shoup, Victor: Design and Analysis of Practical Public-Key Encryption Schemes Secure against Adaptive Chosen Ciphertext Attack, URL: http://www.shoup.net/papers/cca2.pdf). SIAM Journal on Computing 33 (1): 167–226. doi:10.1137/S0097539702403773, 2004. 26. Dai, Yuanxi / Lee, J. / Mennink, B. / Steinberger, J.: The security of multiple encryption in the ideal cipher model, Advances in Cryptology, Springer, 2014. 27. Dai, Yuanxi / Steinberger, John: Tight Security Bounds for Multiple Encryption, URL: https://eprint.iacr.org/2014/096.pdf, Institute for Interdisciplinary Information Sciences, Tsinghua University, Beijing, 2014. 28. Dalibor: Moving to a Plugin-Free Web: Oracle deprecates the Java browser plugin, URL: https://blogs.oracle.com/java-platform-group/entry/moving_to_a_plugin_free, Oracle Product Management blog on Jan 27, 2016. 29. Demir, Yigit Ekim: Güvenli ve Hizli Anlik Mesajlasma Programi: GoldBug Instant Messenger programi, bu sorunun üstesinden gelmek isteyen kullanicilar için en iyi çözümlerden birisi haline geliyor ve en güvenli sekilde anlik mesajlar gönderebilmenize imkan taniyor (Translated: “Goldbug Instant Messenger Application is the best solution for users, who want to use one of the most secure ways to send instant messages”), News Portal Tamindir, URL: http://www.tamindir.com/goldbug-instant-messenger/, 2014. 30. Diffie, Whitfield / Hellman, Martin E.: New Directions in Cryptography, URL: https://www-ee.stanford.edu/~hellman/publications/24.pdf, IEEE TRANSACTIONS ON INFORMATION THEORY, VOL. IT-22, NO. 6, NOVEMBER 1976. 31. Diquet, Alban / Thiel, David / Stender Scott: Open Technology Fund – CryptoCat iOS – Application Penetration Test, Prepared for: Open Technology Fund, URL: https://isecpartners.github.io/publications/iSEC_Cryptocat_iOS.pdf, March 16, 2014. 32. Dolev, D.: The Byzantine generals strike again. J. Algorithms 3, 1, Jan. 1982. 33. Dragomir, Mircea: GoldBug Instant Messenger - Softpedia Review: This is a secure P2P Instant Messenger that ensures private communication based on a multi encryption technology constituted of several security layers, URL: http://www.softpedia.com/get/Internet/Chat/Instant-Messaging/GoldBug-Instant-Messenger.shtml, Softpedia Review, January 31st, 2016 34. Eckersley, Peter: Which apps and tools actually keep your messages safe? & What Makes a Good Security Audit?, URL: https://www.eff.org/deeplinks/2014/11/ what-makes-good-security-audit & https://www.eff.org/de/node/82654, November 8, 2014. 35. Edwards, Scott (Ed.) et al.: GoldBug – Deutsches Benutzer-Handbuch des sicheren E-Mail-Klienten und Sofort-Nachrichten-Programms GoldBug mit Multi-Verschlüsselung, URL: https://de.wikibooks.org/wiki/Goldbug, Wikibooks 2014. 36. El-Hadidi, M.T. / Hegazi, N.H. / Aslan, H.K.: Logic-Based Analysis of a New Hybrid Encryption Protocol for Authentication and Key Distribution, in: Global IT security / ed. by György Papp .... - Vienna, 1998. - S. 173- 37. Even, S. / Goldreich, O.: On the power of cascade ciphers, ACM Transactions on Computer Systems, vol. 3, pp. 108–116, 1985. 38. ExContributor: Tox is a crypto 101 mistake, URL: https://news.ycombinator.com /item?id=9036890, 2014. 39. Fadilpašic, Sead: WhatsApp encryption pointless, researchers claim, URL: http://www.itproportal.com/2016/05/09/whatsapp-encryption-pointless-researchers-say/, May 2016 40. Floemer, Andreas: WhatsApp arbeitet an verifizierter Ende-zu-Ende-Verschlüsselung, URL: http://t3n.de/news/whatsapp-verifizierte-ende-zu-ende-verschluesselung-669008/, T3n 06.01.2016. 41. Fujisaki, Eiichiro / Okamoto, Tatsuaki / Pointcheval, David / Stern, Jacques: RSA-OAEP Is Secure under the RSA Assumption, URL: http://www.di.ens.fr/~pointche/Documents/Papers/2004_joc.pdf). Journal of Cryptology (Springer) 17 (2): 81–104. doi:10.1007/s00145-002-0204-y, 2004. 42. Gaži, Peter / Maurer Ueli: Cascade Encryption Revisited, Advances in Cryptology – ASIACRYPT, URL: http://eprint.iacr.org/2009/093.pdf, pp 37-51, 2009. 43. Gerhards, Julia: (Grund-)Recht auf Verschlüsselung? Baden-Baden 2010. 44. Goldberg, Ian / Stedman, Ryan / Yoshida. Kayo: A User Study of Off-the-Record Messaging, University of Waterloo, Symposium On Usable Privacy and Security (SOUPS) 2008, July 23–25, Pittsburgh, PA, USA, URL: http://www.cypherpunks.ca/~iang/pubs/otr_userstudy.pdf, 2008. 45. Green, Matthew: Noodling about IM protocols, URL: http://blog.cryptographyengineering.com/2014/07/noodling-about-im-protocols.html, July 2014. 46. Gultsch, Daniel: XEP-OMEMO Multi-End Message and Object Encryption, URL: https://conversations.im/xeps/omemo-filetransfer.html, September 2015 47. Gupta, H. / Sharma, V.K.: Multiphase Encryption: A New Concept in Modern Cryptography, International Journal of Computer, URL: http://www.ijcte.org/papers/765-Z271.pdf, 2013. 48. Hallberg, Sven Moritz: Individuelle Schlüsselverifikation via Socialist Millionaires’ Protocol, URL: https://wiki.attraktor.org/images/7/77/Smp.pdf, Juni 2008. 49. Harley, David: Re-Floating the Titanic: Dealing with Social Engineering Attacks EICAR Conference, URL: http://smallbluegreenblog.files.wordpress.com /2010/04/eicar98.pdf, 1998. 50. Hartshorn, Sarah: GoldBug Messenger among - 3 New Open Source Secure Communication Projects, URL: http://blog.vuze.com/2015/05/28/3-new-open-source-secure-communication-projects/, May 28, 2015. 51. Harvey, Cynthia: Datamation: 50 Noteworthy Open Source Projects – Chapter Secure Communication: GoldBug Messenger ranked on first # 1 position, URL: http://www.datamation.com/open-source/50-noteworthy-new-open-source-projects-3.html, posted September 19, 2014. 52. Hatch, Brian / Lee, James / Kurtz, George / McAfee / ISECOM (Hrsg.): Hacking Linux Exposed: Linux Security Secrets and Solutions. McGraw-Hill / Osborne, Emeryville, California 2003:7ff. 53. Henryk Piech, Piotr Borowik: Probability of retrieving information in a multi-encrypted enviroment, Scientific Research of the Institute of Mathematics and Computer Science, URL: http://amcm.pcz.pl/get.php?article=2012_2/art_12.pdf, 2012, Volume 11, Issue 2, pages 113-124. 54. Herzog, Pete: OSSTMM – Open Source Security Testing Methodology Manual. 3, ISECOM, New York, 1. August 2008. 55. Hoerl, Manual: Secure Communication Protocols, CreateSpace Independent Publishing Platform, 19. Oktober 2015. 56. Hofheinz, Dennis / Kiltz, Eike: Secure Hybrid Encryption from Weakened Key Encapsulation URL: http://www.iacr.org/archive/crypto2007/46220546/46220546.pdf, Advances in Cryptology -- CRYPTO 2007, Springer, pp. 553–571, 2007. 57. Information Technology Security Evaluation Criteria (ITSEC): Netherlands, National Comsec Agency, Hague, The Netherlands, May 1990. 58. INTERNATIONAL STANDARD ISO/IEC 27000: Information technology — Security techniques — Information security management systems — Overview and vocabulary, Third edition, 2014-01-15, Reference number ISO/IEC 27000:2014(E), Switzerland 2014. 59. Ioannidis, Ioannis / Grama, Ananth: “An Efficient Protocol for Yao’s Millionaires’ Problem”. Center for Education and Research in Information Assurance and Security (CERIAS). Purdue University. URL: https://www.cerias.purdue.edu/assets/ pdf/bibtex_archive/2003-39.pdf, 2003. 60. ISECOM: Open Source Security Testing Methodology Manual (OSSTMM), Institute for Security and Open Methodologies (ISECOM), URL: http://www.isecom.org/research/osstmm.html, 2010. 61. ISO/IEC 27001 / Bsigroup.com: The new version of ISO/IEC 27001:2013 is here, URL: http://www.bsigroup.com/en-GB/iso-27001-information-security/ISOIEC-27001-Revision/, September 25, 2013. 62. ISO/IEC 27002 / ISO.org: Information technology – Security techniques – Code of practice for information security management, URL: http://www.iso.org/iso/ iso_catalogue/ catalogue_tc/catalogue_detail.htm?csnumber=50297, 2005-06-15. 63. Jacobs, Frederic: On SMS logins: an example from Iran, URL: https://www.fredericjacobs.com/blog/2016/01/14/sms-login/, Jan 14, 2016. 64. Jakobsen, Jakob Bjerre / Olrandi Claudio: A practical cryptoanalysis of the Telegram messaging protocol, Aarhus University September 2015. 65. Jakobsson, Markus / Yung, Moti: “Proving without knowing: On oblivious, agnostic and blindfolded provers.”. Advances in Cryptology – CRYPTO ‘96, volume 1109 of Lecture Notes in Computer Science. URL: http://cseweb.ucsd.edu/users/markus/proving.ps, Berlin 1996:186–200. Doi:10.1007/3-540-68697-5_15. 66. Johnston, Erik: Matrix - An open standard for decentralised persistent communication, URL: http://matrix.org/ & https://github.com/matrix-org/synapse/commit/ 4f475c76977 22e946e39e 42f38f3dd03a95d8765, fist Commit on Aug 12, 2014 67. Joos, Thomas: Sicheres Messaging im Web, URL: http://www.pcwelt.de/ratgeber/ Tor__I2p__Gnunet__RetroShare__Freenet__GoldBug__Spurlos_im_Web-Anonymisierungsnetzwerke-8921663.html, PCWelt Magazin, 01. Oktober 2014. 68. Kannenberg, Axel: Facebooks Messenger hat jetzt 800 Millionen Nutzer - Whatsapp 900 Millionen, http://www.heise.de/newsticker/meldung/Facebooks-Messenger-hat-jetzt-800-Millionen-Nutzer-3065800.html URL: Heise 07.01.2016. 69. King Ho, Anthony: Hybrid cryptosystem using symmetric algorithms and public-key algorithms, Thesis/dissertation, Lamar University, 1999. 70. Knight Foundation: Knight News Challenge awards$3.4 million for ideas to strengthen the Internet, URL: http://www.knightfoundation.org/press-room/press-release/knight-news-challenge-awards-34-million-ideas-stre/Jun 23, 2014.
71. Koenig, Retro / Haenni, Rolf: How to Store some Secrets, IACR Cryptology ePrint Archive 2012: 375 (2012)
72. Könau, Steffen: Whatsapp Messenger ist nach geltendem Recht illegal, URL: http://www.naumburger-tageblatt.de/ratgeber/multimedia/whatsapp-messenger-ist-nach-geltendem-recht-illegal-24060664, 2016
73. Kumar, Arun: Why Centralized Internet won over the Decentralized Internet model?, URL: http://www.thewindowsclub.com/centralized-vs-decentralized-internet, 2016
74. Lamport, L. / Shostak, R. / Pease, M.: The Byzantine Generals Problem. In: ACM Trans. Programming Languages and Systems. 4, Nr. 3, Juli 1982:382–401.
75. Levine, Yasha: Almost Everyone Involved in Developing Tor was (or is) Funded by the US Government, URL: https://pando.com/2014/07/16/tor-spooks/, written on July 16, 2014.
76. Levine, Yasha: How leading Tor developers and advocates tried to smear me after I reported their US Government ties, URL: https://pando.com/2014/11/14/tor-smear/ , written on November 14, 2014.
77. Lindner, Mirko: Poptastic: Verschlüsselter Chat über POP3 mit dem GoldBug Messenger, Pro-Linux, URL: http://www.pro-linux.de/news/1/21822/poptastic-verschluesselter-chat-ueber-pop3.html, 9. Dezember 2014.
78. Marcus, David: "Wir haben keine Pläne, die beiden Dienste zusammenzuführen." - Facebook und WhatsApp sollen voneinander unabhängig bleiben, URL: http://www.heise.de/newsticker/meldung/Facebook-und-WhatsApp-sollen-voneinander-unabhaengig-bleiben-2550806.html, via Heise, Andrej Sokolow, dpa 17.02.2015.
79. Matejka, Petr: Master thesis on Turtle, URL: http://turtle-p2p.sourceforge.net/thesis2.pdf, Prague 2004.
80. Maurer, M / Massey, J.L.: Cascade ciphers - The importance of being first, Journal of Cryptology, vol. 6, no. 1, pp. 55–61, 1993.
81. Maurer, U.M. / Massey, J.L.: Cascade ciphers, Journal of Cryptology 6(1), 55–61, 1993.
82. McClure, Stuart / Scambray, Joel / Kurtz, George / McAfee (Hrsg.): Hacking Exposed: Network Security Secrets & Solutions, McGraw-Hill Professional, Emeryville, California 2005, ISBN 0-07-226081-5.
83. Menezes, Alfred J. / van Oorschot, Paul C. / Vanstone, Scott A.: Handbook of Applied Cryptography, URL: http://citeseer.ist.psu.edu/viewdoc/download? doi=10.1.1.99.2838&rep=rep1&type=pdf, Massachusetts Institute of Technology, June 1996.
84. Mennink, B. / Preneel, B.: Triple and Quadruple Encryption: Bridging the Gaps - IACR Cryptology ePrint Archive, eprint.iacr.org, URL: http://eprint.iacr.org/2014/016.pdf, 2014.
85. Messerer, Thomas / et alt. / Fraunhofer ESK: Einsatz von Skype im Unternehmen – Chancen und Risiken, Fraunhofer-Institut für Eingebettete Systeme und Kommunikationstechnik ESK, URLs: http://www.esk.fraunhofer.de/de/publikationen/studien/sykpe2.html & http://www.esk.fraunhofer.de/content/dam/esk/de/documents/SkypeImUnternehmen_final.pdf & http://www.heise.de/ix/meldung/Fraunhofer-ESK-Skype-ist-Sicherheitsrisiko-fuer-Firmen-3082090.html München 2016.
86. Meyer zu Bergsten, Wolfgang / Korthaus, René / Somorovsky, Juraj / Mainka, Christian / Schwenk, Jörg: Quellcode-basierte Untersuchung von kryptographisch relevanten Aspekten der OpenSSL-Bibliothek, Arbeitspaket 2: Random Number Generator, Eine Studie im Auftrag des Bundesamtes für Sicherheit in der Informationstechnik, URL: https://www.bsi.bund.de/DE/Publikationen/Studien/OpenSSL-Bibliothek/opensslbibliothek.html, Projekt 154, Version 1.2.1 / 2015-11-03,
87. Murdoch, Stephen (2016): Insecure by design: protocols for encrypted phone calls, URL: https://www.benthamsgaze.org/2016/01/19/insecure-by-design-protocols-for-encrypted-phone-calls/, & http://www.heise.de/newsticker/meldung/MIKEY-SAKKE-Unsichere-VoIP-Verschluesselung-a-la-GCHQ-3081912.html, Bentham's Gaze 2016-01-20.
88. Nakashima, Ellen / Peterson, Andrea: Not to force firms to decrypt data, Washington Post, October 8, 2015 .
89. NIST / Chen, Lily / Jordan, Stephen / Liu, Yi-Kai / Moody, Dustin / Peralta, Rene / Perlner, Ray / Smith-Tone, Daniel: NISTIR 8105, DRAFT, Report on Post-Quantum Cryptography, URL: http://csrc.nist.gov/publications/drafts/nistir-8105/nistir_8105_draft.pdf, National Institute of Standards and Technology. February 2016.
90. NZZ / Neue Zürcher Zeitung: Teenager will privates E-Mail-Konto von CIA-Chef geknackt haben, URL: http://www.nzz.ch/digital/teenager-will-privates-e-mail-konto-von-cia-chef-geknackt-haben-ld.2627, 20. Oktober 2015.
91. Öberg, Jonas: Is this the end of decentralisation? URL: http://blog.jonasoberg.net/is-this-the-end-of-decentralisation-2/, 2016
92. Oppliger, Rolf: Secure Messaging on the Internet, Boston 2014.
93. Perrin, Trevor: Axolotl ratchet, URL: https://github.com/trevp/axolotl/wiki, retrieved 2014-03-14.
94. Perrin, Trevor: noise specifications - First commit on 4 Aug 2014, URL: https://github.com/ noiseprotocol/noise_spec/commit/ c627f8056ffb9c7695d3bc7bafea8616749b073f, August 4, 2014 and Domain from January 4, 2016
95. Persiclietti, Edoardo: Secure and Anonymous Hybrid Encryption from Coding Theory, in: Gaborit, Philippe (Hrsg.): Post-quantum cryptography : 5th international workshop / PQCrypto 2013, Limoges, France, June 4 - 7, 2013:174ff
96. Popescu, Bogdan C. / Crispo, Bruno / Tanenbaum, Andrew S.: Safe and Private Data Sharing with Turtle: Friends Team-Up and Beat the System, URL: http://turtle-p2p.sourceforge.net/turtleinitial.pdf, 2004.
97. Positive Technologies: Whatsapp encryption rendered ineffective by SS7 Vulnerabilities, URL: https://www.ptsecurity.com/wwa/news/57894/, May 06 2016
98. Ptacek, Thomas: Javascript Cryptography Considered Harmful, URL: https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/, 29 August 2011.
99. Quarkslab SAS: ChatSecure security assessment, URL: http://blog.quarkslab.com/resources/ 2015-06-25_chatsecure/14-03-022_ChatSecure-sec-assessment.pdf, 2015.
100. Roberts, D.W.: Evaluation criteria for it security. Computer Security and Industrial Cryptography Bd. 741. Springer Berlin Heidelberg, 1993:149-161.
101. Rogers, Everett: Diffusion of Innovations, 5th Edition, Simon and Schuster, 2003.
102. Saint-Andre, Peter: A Public Statement Regarding Ubiquitous Encryption on the XMPP Network, Version: 0.5, URL: https://github.com/stpeter/manifesto/blob/master/manifesto.txt, Guthub 2014-03-21.
104. Scherschel, Fabian A.: Keeping Tabs on WhatsApp's Encryption, URL: http://www.heise.de/ct/artikel/Keeping-Tabs-on-WhatsApp-s-Encryption-2630361.html, Heise 30.04.2015.
105. Scherschel, Fabian: Enigmail verschickte manche Mails unverschlüsselt, URL: http://heise.de/-2389248, Heise 10.09.2014.
106. Scherschel, Fabian: Test: Hinter den Kulissen der WhatsApp-Verschlüsselung, URL: http://www.heise.de/security/artikel/Test-Hinter-den-Kulissen-der-WhatsApp-Verschluesselung-3165567.html, 08.04.2016
107. Schmaus, Florian: OX (OpenPGP for XMPP) - A new OpenPGP XEP, URL: http://mail.jabber.org/pipermail/standards/2016-January/030755.html, January 06, 2016.
108. Schmidt, Jürgen: Lasst PGP sterben, http://www.heise.de/ct/ausgabe/2015-6-Editorial-Lasst-PGP-sterben-2551008.html, Magazin Ct, 20.02.2015.
109. Schneier, Bruce / Seidel, Kathleen / Vijayakumar, Saranya: GOLDBUG Multi-Encrypting Messenger – in: A Worldwide Survey of Encryption Products, URL: https://www.schneier.com/cryptography/paperfiles/worldwide-survey-of-encryption-products.pdf, February 11, 2016 Version 1.0.
110. Security Blog: Secure chat communications suite GoldBug. Security Blog, URL: http://www.hacker10.com/other-computing/secure-chat-communications-suite-goldbug/, 25. März 2014.
111. Seddik, Hassene: Combined Multi-encryption Techniques for Text Securing Using Block Cipher and Stream Cipher Crypto-systems, URL: http://dx.doi.org/10.3991/ijes.v1i1.2901, University of Tunis, Tunis, Tunisia, iJES ? Volume 1, Issue 1, August 2013, p. 53ff
112. Setyaningsih, Emy / Iswahyudi, Catur / Widyastuti, Naniek: Image Encryption on Mobile Phone using Super Encryption Algorithm, URL: http://www.journal.uad.ac.id/index.php/TELKOMNIKA/article/view/871/673.
113. Shannon, C.E.: Communication Theory of Secrecy Systems. Bell System Technical Journal. 28:656-715, 1949.
114. Shirey, R.: RFC 4949, Internet Security Glossary, Version 2. URL: https://tools.ietf.org/html/rfc4949, IETF 1987.
115. Simonite, Tom: Verschlüsselung als Menschenrechtsthema, URL: http://www.heise.de/tr/artikel/Verschluesselung-als-Menschenrechtsthema-2909776.html, Technology Review, 09.22.2015
116. Spot-On (2014): Documentation of the Spot-On-Application, URL: https://github.com/textbrowser/spot-on/tree/master/branches/trunk/Documentation, Github 2014.
117. Spot-On (2011): Documentation of the Spot-On-Application, URL: https://sourceforge.net/p/spot-on/code/HEAD/tree/, under this URL since 06/2013, Sourceforge, including the Spot-On: Documentation of the project draft paper of the pre-research project since 2010, Project Ne.R.D.D., Registered 2010-06-27, URL: https://sourceforge.net/projects/nerdd/ has evolved into Spot-On. Please see http://spot-on.sf.net and URL: https://github.com/textbrowser/spot-on/blob/master/branches/Documentation/RELEASE-NOTES.archived, 08.08.2011.
118. Stahl, Leslie: 60 Minutes - Preview on encryption, URL: https://2paragraphs.com/2016/03/telegram-texting-app-used-by-isis-made-in-russia/, 03/2016.
119. Stiftung Zukunft: Antrag auf Förderung des Projektes "Spot-On: Web-Suche in einem Netzwerk dezentraler URL-Datenbanken" mit 30 zu fördernden Abschlussarbeiten an Hochschulen und Einbezug von 30 Auszubildenden aus Mitgliedsorganisationen durch die Stiftung Zukunft, Spot-On Source Documentation File at GitHub, 29.06.2015
120. Sun, Hung-Min / Wu, Mu-En / Ting, Wei-Chi / Hinek, M. J.: Dual RSA and Its Security Analysis, IEEE Transactions on Information Theory, v53 n8 (200708): 2922-2933.
121. Teicke Friedhelm: Mein Sohn bei Whatsapp, dem Messenger-Dienst, der als Super-Wanze galt, URL: http://www.zitty.de/mein-sohn-bei-whatsapp/, 2016
122. Thomas, Steve: “DecryptoCat”. URL: http://tobtu.com/decryptocat.php, Retrieved 2013-07-10.
123. Van den Hooff, Jelle / Lazar, David / Zaharia, Matei / Zeldovich, Nickolai: Vuvuzela - Scalable Private Messaging Resistant to Traffic Analysis, https://davidlazar.org/papers/ vuvuzela.pdf, MIT CSAIL / SOSP’15, Oct. 4–7, 2015
124. Vaughan-Nichols, Steven J.: How to recover from Heartbleed, ZDNet, URL: http://www.zdnet.com/how-to-recover-from-heartbleed-7000028253, April 9, 2014.
125. Vervier, Markus: X41-2016-001: Memory Corruption Vulnerability in "libotr", URL: https://www.x41-dsec.de/lab/advisories/x41-2016-001-libotr/, 01/2016
126. Völker, Jörg: BS 7799 – Von „Best Practice“ zum Standard, in: Datenschutz und Datensicherheit (DuD) (2004), URL: http://www.secorvo.de/publikationen/bs7799-voelker-2004.pdf, Nr. 28:102-108, 2004.
127. Wales, Jimmy: Encryption Ban Like Banning Maths - via: Morris, Gemma: Wiki Boss: Encryption Ban Like Banning Maths, URL: http://news.sky.com/story/1565811/wiki-boss-encryption-ban-like-banning-maths, Sky News' tech show Swipe at IP EXPO Europe, 08 October 2015.
128. Weller, Jan: Testbericht zu GoldBug für Freeware, Freeware-Blog, URL: https://www.freeware.de/download/goldbug/, 2013.
129. Weßelmann, Bettina: Maßnahmen gegen Social Engineering: Training muss Awareness-Maßnahmen ergänzen. In: Datenschutz und Datensicherheit. DuD. 9, 2008:601–604.
130. WhatsApp: Encryption Overview - Technical white paper, URL: https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf, April 4, 2016
131. Wikipedia: Meet-in-the-middle attack, URL: https://en.wikipedia.org/wiki/Meet-in-the-middle_attack, Wikipedia, 17 April 2016
132. Wilcox, Nathan et alt.: Report of Security Audit of Cryptocat, URL: https://leastauthority.com/static/publications/LeastAuthority-Cryptocat-audit-report.pdf, 2013-11-06.
133. Wired: Teen Who Hacked CIA Director’s Email Tells How He Did It, URL: http://www.wired.com/2015/10/hacker-who-broke-into-cia-director-john-brennan-email-tells-how-he-did-it/, 19. Oktober 2015 („Wie der Datendieb verlauten ließ, will er die Zugangsdaten zu Brennans E-Mail-Konto mittels Social Engineering erhalten haben: Er hat offenbar Mitarbeiter von Verizon dazu gebracht, Daten von Brennan herauszugeben“).
134. Yao, Andrew: How to generate and exchange secrets”. URL: http://www.csee.wvu.edu/~xinl/library/papers/comp/Yao1986.pdf, Proc. 27th IEEE Symposium on Foundations of Computer Science (FOCS ‘86). Pp. 162–167. Doi:10.1109/SFCS.1986.25, 1986.
135. Yao, Andrew: Protocols for secure communications”, Proc. 23rd IEEE Symposium on Foundations of Computer Science (FOCS ‘82), URL http://research.cs.wisc.edu/areas/ sec/yao1982-ocr.pdf, 1982:160–164, doi:10.1109/SFCS.1982.88.
136. You broke the internet (YBTI): Next generation secure communication, URL: http://youbroketheinternet.org/secure-email, June 2014, zurückgehend auf einen ersten Entwurf vom Feb 3, 2014 unter der URL: https://github.com/OpenTechFund/ secure-email/commits/master/README.md?page=2, 2014.
137. Zhong, Peng: Prism-Break (PB) Portal, URL: https://prism-break.org/, since 2013.

GLOSSARY: VOCABULARY, TERMS & DEFINITIONS

This glossary defines the most common words and terms used in this review/audit and as well vocabulary mostly used within these cryptography related contexts.

• Access Controls: means to ensure that access to assets is authorized and restricted based on business and security requirements. Related to authorization of users, and assessment of rights.
• AES: The Advanced Encryption Standard (AES), also known as Rijndael (its original name), is a specification for the encryption of electronic data established by the U.S. National Institute of Standards and Technology (NIST) in 2001. AES is based on the Rijndael cipher developed by two Belgian cryptographers, Joan Daemen and Vincent Rijmen, who submitted a proposal to NIST during the AES selection process.
• AE-Token: the AE-Roken is a cryptographic token used to deploy the adaptive echo (AE) modus. It is a kind of password or string, which is entered into the node, to avoid messages to be sent to nodes, without the AE-Token. AE-Tokens can help to create a self-learning, adaptive network. The token must contain at least mprov-six characters.
• Algorithm: In mathematics and computer science, an algorithm is a self-contained step-by-step set of operations to be performed. Algorithms exist that perform calculation, data processing, and automated reasoning.
• Attack: attempt to destroy, expose, alter, disable, steal or gain unauthorized access to or make unauthorized use of an asset
• Audit: systematic, independent and documented process for obtaining audit evidence and evaluating it objectively to determine the extent to which the audit criteria are fulfilled. An audit can be an internal audit (first party) or an external audit (second party or third party), and it can be a combined audit (combining two or more disciplines).
• Auditing and Logging: Related to auditing of actions, or logging of problems
• Authentication: provision of assurance that a claimed characteristic of an entity is correct
• Authentication: Related to the identification of users
• Availability: property of being accessible and usable upon demand by an authorized entity
• Bluetooth: Bluetooth is a wireless technology standard for exchanging data over short distances (using short-wavelength UHF radio waves in the ISM band from 2.4 to 2.485 GHz) from fixed and mobile devices, and building personal area networks (PANs).
• Buzz: Buzz is the name of the libspoton to provide echoed IRC (e*IRC). So Buzz is another word for IRC, respective e*IRC, used by the library.
• C/O (care of)-Funktion: “Care of”, used to address a letter when the letter must pass through an intermediary (also written c/o). Neighbors are often asked to care of your postal letters, in case you live with them in one house or have a relationship to them. As well parcel stations, letter boxes or just persons e.g. at you home or in the neighborhood provide a local delay of your envelopes and parcels, in case you are at work and want to receive the parcel or letter in the evening. The included Email Function of GoldBug provides such a feature.
• Calling: A “Call” transfers over a public/private key encrypted environment a symmetric key (e.g. AES). It is a password for the session talk, only the two participants know. With one click you can instantly renew the end-to-end encryption password for your talk. It is also possible to manually define the end-to-end encrypted password (manually defined Calling). There are five further different ways to call: Asymmetric Calling, Forward Secrecy Calling, Symmetric Calling, SMP-Calling and 2-Way-Calling. The term of a “Call” in Cryptograophy has been introduced by Spot-on, the integrated library and kernel of the GoldBug Applikation, and refers to sending a new end-to-end encryption password to the other participant.
• CBC: Cipher Block Chaining – Ehrsam, Meyer, Smith and Tuchman invented the Cipher Block Chaining (CBC) mode of operation in 1976. In CBC mode, each block of plaintext is XORed with the previous ciphertext block before being encrypted. This way, each ciphertext block depends on all plaintext blocks processed up to that point.
• Cipher: In cryptography, a cipher (or mprov) is an algorithm for performing encryption or decryption—a series of well-defined steps that can be followed as a procedure. An alternative, less common term is encipherment. To encipher or encode is to convert information into cipher or code. In common parlance, ‘cipher’ is synonymous with ‘code’. Codes generally substitute different length strings of characters in the output, while ciphers generally substitute the same number of characters as are input.
• Confidentiality: property that information is not made available or disclosed to unauthorized individuals, entities, or processes
• Configuration: Related to security configurations of servers, devices, or software
• Congestion Control: Congestion control concerns controlling traffic entry into a telecommunications network, so as to avoid congestive collapse by attempting to avoid oversubscription of any of the processing or link capabilities of the intermediate nodes and networks and taking resource reducing steps, such as reducing the rate of sending packets.
• Continuous improvement: recurring activity to enhance performance
• Corrective action: action to eliminate the cause of a nonconformity and to prevent recurrence
• Cryptogramm: Verbal arithmetic, also known as alphametics, cryptarithmetic, crypt-arithmetic, cryptarithm, mprovemen or word addition, is a type of mathematical game consisting of a mathematical equation among unknown numbers, whose digits are represented by letters. The goal is to identify the value of each letter. The name can be extended to puzzles that use non-alphabetic symbols instead of letters.
• Cryptography: Related to mathematical protections for data
• Data Exposure: Related to unintended exposure of sensitive information
• Data Validation: Related to improper reliance on the structure or values of data
• Decentralized computing: Decentralized computing is the allocation of resources, both hardware and software, to each individual workstation, or office location. Decentral means, there is no central server nor a webinterface, you can lof into a service. A client needs to be installed and adjusted locally on your device. Another term is: Distributed computing. Distributed computing is a field of computer science that studies distributed systems. A distributed system is a software system in which components located on networked computers communicate and coordinate their actions by passing messages. Based on a “grid model” a peer-to-peer system, or P2P system, is a collection of applications run on several local computers, which connect remotely to each other to complete a function or a task. There is no main operating system to which satellite systems are subordinate. This approach to software development (and distribution) affords developers great savings, as they don’t have to create a central control point. An example application is LAN messaging which allows users to communicate without a central server.
• Documented information: information required to be controlled and maintained by an organization and the medium on which it is contained. Note: Documented information can be in any format and media and from any source.
• Dooble: Dooble is a free and open source Web browser. Dooble was created to improve privacy. Currently, Dooble is available for FreeBSD, Linux, OS X, OS/2, and Windows. Dooble uses Qt for its user interface and abstraction from the operating system and processor architecture. As a result, Dooble should be portable to any system that supports OpenSSL, POSIX threads, Qt, SQLite, and other libraries.
• Echo Accounts: Echo Accounts define an authorization scheme for the access to neighbor nodes respective to the listener of a server. At the same time they can form a Web-of-Trust. One-Time-Accounts regulate the assignment of an access, which can be used on time.
• Echo, adaptive (AE): The Adaptive Echo does not send in terms of the normal Echo a message-packet to each connected node, instead, for the overgiving of a message a cryptographic token is needed. The Echo-Protocol is equipped for the Adaptive Echo Modus with a routing information. Only nodes, which have a certain cryptographic token available, get the message forwarded.
• Echo, half: If you use the modus “half echo”, then your message is not shared with other, third participants (Model: A -> B -> C) . Only direct connections are used (Model A -> B). It requires only one direct connection to one friend. With the modus “full echo” your message is forwarded from friend to friend and so on, until the recipient could decrypt the envelope and read the message.
• Echo Protocol: The echo protocol means from an operational view: you send only encrypted messages, but you send your to-be-send-message to all of your connected friends. They do the same. You maintain your own network, everyone has every message and you try to decrypt every message. In case you can read and unwrap it, it is a message for you. Otherwise you share the message with all your friends and the message remains encrypted. Echo is very simple and the principle is over 30 years old – nothing new. As echo uses HTTP as a protocol, there is no forwarding or routing of messages: no IPs are forwarded, e.g. like it is if you send your message e.g. from your home laptop to your webserver. The process starts at each destination new – as you define it. The echo protocol provided by spot-on has nothing to do with RFC 862. A new echo protocol RFC has to be written or re-newed and extended – with or without that RFC-Number it refers to a p2p network.
• ECHO-Grid: The Echo-Grid is a graphical representation of a template for the echo-protocol, do be able to illustrate different nodes and communicational relations in a graphic and within graph-theory. For that the letters for the word ECHO, respective the both characters AE are drawn and connected on a base-line. All angle corners of each letter further represent potential nodes in communicational networks, which can be per letter be consecutively numbered, example: E1 … E1 for the six nodes of the letter E. Then it is possible to talk about the communicational paths of drawn users from E to O.
• ElGamal: In cryptography, the ElGamal encryption system is an asymmetric key encryption algorithm for public-key cryptography which is based on the Diffie–Hellman key exchange. It was described by Taher Elgamal in 1985. ElGamal encryption is used in the free GNU Privacy Guard software, recent versions of PGP, and other cryptosystems.
• E-Mail Institution: An E-Mail-institution describes an E-Mail-Postbox within the p2p network of the Echo protocol. Per definition of an address-like Description for the institution, E-Mails of users within the p2p network can temporarily be stored within one other node. As well it is possible, to send E-Mail to friends, which are currently offline. Institutions describe a standard, how to configure an E-Mail-Postbox within a p2p network – like today POP3 and IMAP allow to provide a Mailbox. The Mailbox of the E-Mail-Institution is inserted by a Magnet-URI-Link within the client, which want to use the Postbox. At the E-Mail-Institution only the public E-Mail-Encryption-Key of the postbox-users has to be entered.
• Encryption, asymmetric: In cryptography, encryption is the process of encoding messages or information in such a way that only authorized parties can read it. In public-key encryption schemes, the encryption key is published for anyone to use and encrypt messages. However, only the receiving party has access to the decryption key that enables messages to be read. Public-key encryption was first described in a secret document in 1973; before then all encryption schemes were symmetric-key (also called private-key).
• Encryption, clientside: Client-side encryption is the cryptographic technique of encrypting data before it is transmitted to a server in a computer network. Usually, encryption is performed with a key that is not known to the server. Consequently, the service provider is unable to decrypt the hosted data. In order to access the data, it must always be decrypted by the client. Client-side encryption allows for the creation of zeroknowledge applications whose providers cannot access the data its users have stored, thus offering a high level of privacy.
• Encryption, Multi-/Hybrid: A hybrid cryptosystem is one which combines the convenience of a public-key cryptosystem with the efficiency of a symmetric-key cryptosystem. A hybrid cryptosystem can be constructed using any two separate cryptosystems: first, a key encapsulation scheme, which is a public-key cryptosystem, and second a data encapsulation scheme, which is a symmetric-key cryptosystem. Perhaps the most commonly used hybrid cryptosystems are the OpenPGP (RFC 4880) file format and the PKCS #7 (RFC 2315) file format, both used by many different systems. Multiple encryption is the process of encrypting an already encrypted message one or more times, either using the same or a different algorithm. Multiple encryption (Cascade Ciphers) reduces the consequences in the case that our favorite cipher is already broken and is continuously exposing our data without our knowledge. When a cipher is broken (something we will not know), the use of other ciphers may represent the only security in the system. Since we cannot scientifically prove that any particular cipher is strong, the question is not whether subsequent ciphers are strong, but instead, what would make us believe that any particular cipher is so strong as to need no added protection. Folk Theorem: A cascade of ciphers is at least as at least as difficult to break as any of its component ciphers. When a cipher is broken (something we will not know), the use of other ciphers may represent the only security in the system. Since we cannot scientifically prove that any particular cipher is strong, the question is not whether subsequent ciphers are strong, but instead, what would make us believe that any particular cipher is so strong as to need no added protection.
• Encryption, symmetric: Symmetric-key algorithms are algorithms for cryptography that use the same cryptographic keys for both encryption of plaintext and decryption of ciphertext. The keys may be identical or there may be a simple transformation to go between the two keys. The keys, in practice, represent a shared secret between two or more parties that can be used to maintain a private information link. This requirement that both parties have access to the secret key is one of the main drawbacks of symmetric key encryption, in comparison to public-key encryption (asymmetric encryption).
• Encrypt-then-MAC (ETM): The plaintext is first encrypted, then a MAC is produced based on the resulting ciphertext. The ciphertext and its MAC are sent together. Used in, e.g., Ipsec. The standard method according to ISO/IEC 19772:2009. This is the only method which can reach the highest definition of security in authenticated encryption, but this can only be achieved when the MAC used is “Strongly Unforgeable”. In November 2014, TLS and DTLS extension for EtM has been published as RFC 7366.
• End-to-end: The end-to-end principle is a classic design principle of computer networking,[nb 1] first explicitly articulated in a 1981 conference paper by Saltzer, Reed, and Clark. The end-to-end principle states that application-specific functions ought to reside in the end hosts of a network rather than in intermediary nodes – provided they can be implemented “completely and correctly” in the end hosts. In debates about network neutrality, a common interpretation of the end-to-end principle is that it implies a neutral or “dumb” network. End-to-end encryption (E2EE) is an uninterrupted protection of the confidentiality and integrity of transmitted data by encoding it at its starting point and decoding it at its destination. It involves encrypting clear (red) data at source with knowledge of the intended recipient, allowing the encrypted (black) data to travel safely through vulnerable channels (e.g. public networks) to its recipient where it can be decrypted (assuming the destination shares the necessary key-variables and algorithms). An end-to-end encryption is often reached by providing an encryption with the AES Passphrase.
• EPKS (Echo Public Key Share): Echo Public Key Share (EPKS) is a function implemented in GoldBug to share public encryption keys over the Echo network. This allows a group to share keys over secure channels so that a classical key server it not needed. It is a way of key exchange to a group or one individual user. The key exchange (also known as “key establishment”) is any method in cryptography by which cryptographic keys are exchanged between users, allowing use of a cryptographic algorithm. If sender and receiver wish to exchange encrypted messages, each must be equipped to encrypt messages to be sent and decrypt messages received. The nature of the equipping they require depends on the encryption technique they might use. If they use a code, both will require a copy of the same codebook. If they use a cipher, they will need appropriate keys. If the cipher is a symmetric key cipher, both will need a copy of the same key. If an asymmetric key cipher with the public/private key property, both will need the other’s public key. The key exchange problem is how to exchange whatever keys or other information are needed so that no one else can obtain a copy. Historically, this required trusted couriers, diplomatic bags, or some other secure channel. With the advent of public key / private key cipher algorithms, the encrypting key (aka public key) could be made public, since (at least for high quality algorithms) no one without the decrypting key (aka, the private key) could decrypt the message. Diffie–Hellman key exchange: In 1976, Whitfield Diffie and Martin Hellman published a cryptographic protocol, (Diffie–Hellman key exchange), which allows users to establish ‘secure channels’ on which to exchange keys, even if an Opponent is monitoring that communication channel. However, D–H key exchange did not address the problem of being sure of the actual identity of the person (or ‘entity’).
• File Encryption Tool: The File Encryption Tool of GoldBug has the function to encrypt and decrypt files on the hard disk. Here as well many values for the encryption details can be set individually. The tool is useful, in case files have to be sent - either over encrypted or unencrypted connections. As well for the storage of files, either on your local hard disc or as well remote in the cloud, this tool is very helpful, to secure own data.
• Forward Secrecy, Instant Perfect (IPFS): While Perfect Forward Secrecy, often also called only Forward Secrecy, describes within many applicationa and as well from a conceptional approach the transmission of ephemeral – this means temporary - keys, it is implicit connected, that this is proceeded one time per online session. With GoldBug and the underlying architecture of the Spot-On Kernel a new paradigm has been implemented. The end-to-end-encryption with temporary keys can be changed at any time, this means also per any second. This describes the term of Instant Perfect Forward Secrecy (IPFS). Via a so-called “Call” the end-to-end-encryption can be renewed. Instantly. Also the term of a “call” for the transmission of a to-be-created or to-be-renewed end-to-end-encryption has been introduced by Spot-on into cryptography.
• Forward Secrecy, Pure (PURE FS): Pure Forward Secrecy refers to a communication in the E-Mail function of GoldBug, within which the information is not sent over asymmetrical keys, but over temporary, ephemeral keys, which generate a symmetric encryption. The ephemeral keys for Pure Forward Secrecy are exchanged over asymmetric keys, but then the message is sent exclusively over the temporary symmetric key. Compare in a different approach of Instant Perfect Forward Secrecy, that the messages is encrypted and transferred with both, a symmetric key and also with a asymmetric key within the format of the Echo-protocol.
• Forward Secrecy: In cryptography, forward secrecy (FS; also known as perfect forward secrecy) is a property of secure communication protocols: a secure communication protocol is said to have forward secrecy if compromise of long-term keys does not compromise past session keys.[2] FS protects past sessions against future compromises of secret keys or passwords. If forward secrecy is utilized, encrypted communications recorded in the past cannot be retrieved and decrypted should long-term secret keys or passwords be compromised in the future.
• Friend-to-Friend (F2F): A friend-to-friend (or F2F) computer network is a type of peer-to-peer network in which users only make direct connections with people they know. Passwords or digital signatures can be used for authentication. Unlike other kinds of private P2P, users in a friend-to-friend network cannot find out who else is participating beyond their own circle of friends, so F2F networks can grow in size without compromising their users’ anonymity.
• Galois/Counter Mode (GCM)-Algorithm: Galois/Counter Mode (GCM) is a mode of operation for symmetric key cryptographic block ciphers that has been widely adopted because of its efficiency and performance. GCM throughput rates for state of the art, high speed communication channels can be achieved with reasonable hardware resources.
• Gemini: The Gemini is a feature in GoldBug Secure Instant Messenger to add another security layer to the chatroom with an AES Key for end-to-end encryption.
• GoldBug (Application): The GoldBug Messenger and E-Mail-Client is a user interface, which offers for the kernel and the application Spot-On an alternative to the originally offered user interface of Spot-on, which contains many options. The GoldBug Graphical User Interface (GUI) therefore has the approach, to have a more simplified user interface designed, which is useable not only on the desktop, but also can be deployed for mobile devices.
• GoldBug (E-Mail): The GoldBug-feature is used in the integrated email client to add here as well an end-to-end AESEncryption layer – the GoldBug, or: just a password, both users use to encrypt their emails once more. So with the GoldBug, you need a kind of password (e.g. AES-string) to open the email of a friend or to be able to chat with him.
• Graph-Theory: In mathematics, and more specifically in graph theory, a graph is a representation of a set of objects where some pairs of objects are connected by links. The interconnected objects are represented by mathematical abstractions called vertices (also called nodes or points), and the links that connect some pairs of vertices are called edges (also called arcs or lines). Typically, a graph is depicted in diagrammatic form as a set of dots for the vertices, joined by lines or curves for the edges. Graphs are one of the objects of study in discrete mathematics.
• GUI: In computer science, a graphical user interface or GUI is a type of interface that allows users to interact with electronic devices through graphical icons and visual indicators such as secondary notation, as opposed to text-based interfaces, typed command labels or text navigation.
• Hash: A hash function is any function that can be used to map data of arbitrary size to data of fixed size. The values returned by a hash function are called hash values, hash codes, hash sums, or simply hashes. A cryptographic hash function is a hash function which is considered practically impossible to invert, that is, to recreate the input data from its hash value alone. These one-way hash functions have been called “the workhorses of modern cryptography”. The input data is often called the message, and the hash value is often called the message digest or simply the digest.
• HTTPS: HTTPS (also called HTTP over TLS, HTTP over SSL, and HTTP Secure) is a protocol for secure communication over a computer network which is widely used on the Internet. HTTPS consists of communication over Hypertext Transfer Protocol (HTTP) within a connection encrypted by Transport Layer Security or its predecessor, Secure Sockets Layer. The main motivation for HTTPS is authentication of the visited website and protection of the privacy and integrity of the exchanged data.
• IMAP: In computing, the Internet Message Access Protocol (IMAP) is an Internet standard protocol used by e-mail clients to retrieve e-mail messages from a mail server over a TCP/IP connection. IMAP is defined by RFC 3501. IMAP was designed with the goal of permitting complete management of an email box by multiple email clients, Therefore, clients generally leave messages on the server.
• Impersonator: Impersonator is a function, which sends from the GoldBug Client a message from time to time into the network, which contains only random signs. With this method it is made more difficult for attackers to conduct time analysis of communications. Also real cipher text messages should be harder to recognize and harder to differ from such messages with random characters.
• Information security: information security preservation of confidentiality, integrity and availability of information
• Integer factorization: In number theory, integer factorization is the decomposition of a composite number into a product of smaller integers. If these integers are further restricted to prime numbers, the process is called prime factorization. When the numbers are very large, no efficient, non-quantum integer factorization algorithm is known; an effort by several researchers concluded in 2009, factoring a 232-digit number (RSA-768), utilizing hundreds of machines took two years and the researchers estimated that a 1024-bit RSA modulus would take about a thousand times as long.
• Integrity: property of accuracy and completeness.
• Iteration Function: In mathematics, an iterated function is a function X ? X (that is, a function from some set X to itself) which is obtained by composing another function f : X ? X with itself a certain number of times. The process of repeatedly applying the same function is called iteration. Iterated functions are objects of study in computer science, fractals, dynamical systems, mathematics and renormalization group physics.
• Kernel: In computing, the kernel is a computer program that manages input/output requests from software, and translates them into data processing instructions for the central processing unit and other electronic components of a computer. The kernel is a fundamental part of a modern computer’s operating system or of applications.
• Key, Private: Public-key cryptography refers to a set of cryptographic algorithms that are based on mathematical problems that currently admit no efficient solution. The strength lies in the “impossibility” (computational impracticality) for a properly generated private key to be determined from its corresponding public key. Thus the public key may be published without compromising security. Security depends only on keeping the private key private.
• Key, Public: Public-key cryptography refers to a set of cryptographic algorithms that are based on mathematical problems that currently admit no efficient solution – particularly those inherent in certain integer factorization, discrete logarithm, and elliptic curve relationships. It is computationally easy for a user to generate a public and private key-pair and to use it for encryption and decryption. The strength lies in the “impossibility” (computational impracticality) for a properly generated private key to be determined from its corresponding public key. Thus the public key may be published without compromising security. Security depends only on keeping the private key private.
• Key, Symmetric: These keys are used with symmetric key algorithms to apply confidentiality protection to information.
• Keyed-Hash Message Authentication Code (HMAC): In cryptography, a keyed-hash message authentication code (HMAC) is a specific construction for calculating a message authentication code (MAC) involving a cryptographic hash function in combination with a secret cryptographic key. As with any MAC, it may be used to simultaneously verify both the data integrity and the authentication of a message. Any cryptographic hash function, such as MD5 or SHA-1, may be used in the calculation of an HMAC; the resulting MAC algorithm is termed HMAC-MD5 or HMAC-SHA1 accordingly. The cryptographic strength of the HMAC depends upon the cryptographic strength of the underlying hash function, the size of its hash output, and on the size and quality of the key.
• Libcurl: cURL is a computer software project providing a library and command-line tool for transferring data using various protocols. The cURL project produces two products, libcurl and cURL. It was first released in 1997. The name originally stood for “see URL”.
• Listener: A listener is a software design pattern in which an object maintains a list of its dependents and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems. It is often used for creating or opening a port on which the service or chat-server then is “listening” for incommuig data connections.
• MAC (Message Authentication Code): In cryptography, a message authentication code (often MAC) is a short piece of information used to authenticate a message and to provide integrity and authenticity assurances on the message. Integrity assurances detect accidental and intentional message changes, while authenticity assurances affirm the message’s origin. A MAC algorithm, sometimes called a keyed (cryptographic) hash function (however, cryptographic hash function is only one of the possible ways to generate MACs), accepts as input a secret key and an arbitrary-length message to be authenticated, and outputs a MAC (sometimes known as a tag). The MAC value protects both a message’s data integrity as well as its authenticity, by allowing verifiers (who also possess the secret key) to detect any changes to the message content.
• Magnet-URI: The Magnet URI scheme, defines the format of magnet links, a de facto standard for identifying files by their content, via cryptographic hash value) rather than by their location.
• Management system: set of interrelated or interacting elements of an organization to establish policies and objectives and processes to achieve those objectives
• McEliece: In cryptography, the McEliece cryptosystem is an asymmetric encryption algorithm developed in 1978 by Robert McEliece. It was the first such scheme to use randomization in the encryption process. The algorithm has currently not gained much acceptance in the cryptographic community, but is a candidate for “post-quantum cryptography”, as it is immune to attacks using Shor’s algorithm and — more generally — measuring cost states using Fourier sampling. The recommended parameter sizes for the used Goppa code - which maximizes the adversary’s work factor - appears to be n = 1024, t = 38, and k = 644.
• Measurement: process to determine a value
• MELODICA: With the MELODICA feature in GoldBug Secure Messenger you call your friend and send him a new Gemini (AES-256-Key). The Key is sent over your asymmetric encryption of the RSA key. This is a secure way, as all other plaintext transfers like: email, spoken over phone or in other messengers, have to be regarded as unsafe and recorded. MELODICA stands for: Multi Encrypted Long Distance Calling. You call your friend even over a long distance of the echo protocol and exchange over secure asymmetric encryption a Gemini (AES-256 key) to establish an end-to-end encrypted channel.
• Monitoring: determining the status of a system, a process or an activity
• Multi-Encryption: Multiple encryption is the process of encrypting an already encrypted message one or more times, either using the same or a different algorithm. It is also known as cascade encryption, cascade ciphering, multiple encryption, and superencipherment. Superencryption refers to the outer-level encryption of a multiple encryption.
• Nova: Nova describes a password on the to-be-transferred file. It is a symmetric encryption of the file scheduled for the transfer. It can be compared with the term of a GoldBug-Password on an E-Mail. Both are technically created with an AES-256 (or a user-defined password).
• NTRU: NTRU is a patented and open source public-key cryptosystem that uses lattice-based cryptography to encrypt and decrypt data. It consists of two algorithms: NTRUEncrypt, which is used for encryption, and NTRUSign, which is used for digital signatures. Unlike other popular public-key cryptosystems, it is resistant to attacks using Shor’s algorithm (i.e. by “quantum computing”) and its performance has been shown to be significantly better.
• Objective: result to be achieved.
• Off-the-record (OTR): Off-the-Record Messaging (OTR) is a cryptographic protocol that provides encryption for instant messaging conversations. OTR uses a combination of AES symmetric-key algorithm with 128 bits key length, the Diffie–Hellman key exchange with 1536 bits group size, and the SHA-1 hash function. In addition to authentication and encryption, OTR provides forward secrecy and malleable encryption.
• One-Time-Magnet (OTM): A One-Time-Magnet (OTM) is a Magnet, which is deployed for the File-Transfer within the StarBeam-Funktion. After sending the File using the cryptographic values included in the Magnet-Link, the Magnet is deleted within the GoldBug application. Other Magnets for the StarBeam-Funktion can be used several times – this means, several and different files can be transferred to the receiver through the symmetric Channel (including all users, knowing the specific Magnet).
• One-Time-Pad (OTP): In cryptography, the one-time pad (OTP) is an encryption technique that cannot be cracked if used correctly. In this technique, a plaintext is paired with a random secret key (also referred to as a one-time pad). Then, each bit or character of the plaintext is encrypted by combining it with the corresponding bit or character from the pad using modular addition. If the key is truly random, is at least as long as the plaintext, is never reused in whole or in part, and is kept completely secret, then the resulting ciphertext will be impossible to decrypt or break.
• OpenPGP: The OpenPGP standard (also Pretty Good Privacy) is a data encryption and decryption computer program that provides cryptographic privacy and authentication for data communication. PGP is often used for signing, encrypting, and decrypting texts, e-mails, files, directories, and whole disk partitions and to increase the security of e-mail communications. It was created by Phil Zimmermann in 1991.PGP and similar software follow the OpenPGP standard (RFC 4880) for encrypting and decrypting data.
• OpenSSL: In computer networking, OpenSSL is a software library to be used in applications that need to secure communications against eavesdropping or need to ascertain the identity of the party at the other end. It has found wide use in internet web servers, serving a majority of all web sites. OpenSSL contains an open-source implementation of the SSL and TLS protocols. Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), both of which are frequently referred to as ‘SSL’, are cryptographic protocols designed to provide communications security over a computer network.
• Pandamonium: Pandamonium is a Web-Crawler, with which URLs of a Domain can be indexed for GoldBug. The Pandamonium Web Crawler can allocate for the URL-Search function within the GoldBug Messenger a bunch of URLs over the Import-function.
• Passphrase: A passphrase is a sequence of words or other text used to control access to a computer system, program or data. A passphrase is similar to a password in usage, but is generally longer for added security. Passphrases are often used to control both access to, and operation of, cryptographic programs and systems. Passphrases are particularly applicable to systems that use the passphrase as an encryption key. The origin of the term is by analogy with password. The passphrase in GoldBug must be at least 16 characters long, this is used to create a cryptographic hash, which is longer and stronger.
• Peer-to-Peer (P2P): Peer-to-peer (P2P) computing or networking is a distributed application architecture that partitions tasks or work loads between peers. Peers make a portion of their resources, such as processing power, disk storage or network bandwidth, directly available to other network participants, without the need for central coordination by servers or stable hosts. Peers are equally privileged, equipotent participants in the application. They are said to form a peer-to-peer network of nodes.
• Performance: measurable result. Note: Performance can relate either to quantitative or qualitative findings.
• Policy: intentions and direction of an formal entity as formally expressed by its management
• POP3: In computing, the Post Office Protocol (POP) is an application-layer Internet standard protocol used by local e-mail clients to retrieve e-mail from a remote server over a TCP/IP connection. POP has been developed through several versions, with version 3 (POP3) being the last standard in common use.
• POPTASTIC: POPTASTIC is a function, which enables encrypted chat and encrypted E-Mail over the regular POP3 and IMAP-Postboxes of a user. The GoldBug Messenger recognizes automatically, if the message has to be regarded as a Chat-Message or an E-Mail-Message. For that, the POPTASTIC encryption key is used. Once with a friend exchanged, this key is sending all E-mails between to E-Mail-Partner only as encrypted E-Mail. Third, POPTASTIC enables – respective the insertion of the POP3 / IMAP account information into the settings enables – also an old-fashioned and unencrypted E-Mail-Communication to @-E-Mail-Addresses. GoldBug extends the Instant Messaging with this function to a regular E-Mail-Client and also to an always encrypting E-Mail-Client over the POPTASTIC Key. The E-Mail-Addresses for encrypted E-Mails are indicated with a lock icon. Encrypted Chat is enabled over the free ports for E-Mail also behind more restrictive Hardware environments at any time.
• PostgreSQL: PostgreSQL, often simply Postgres, is an object-relational database management system (ORDBMS) with an emphasis on extensibility and standards-compliance. As a database server, its primary function is to store data securely, supporting best practices, and to allow for retrieval at the request of other software applications. It can handle workloads ranging from small single-machine applications to large Internet-facing applications with many concurrent users. PostgreSQL implements the majority of the SQL:2011 standard.
• Process: set of interrelated or interacting activities which transforms inputs into outputs
• Qt: Qt is a cross-platform application framework that is widely used for developing application software that can be run on various software and hardware platforms with little or no change in the underlying codebase, while still being a native application with the capabilities and speed thereof. Qt is currently being developed both by the Qt Company, a subsidiary of Digia, and the Qt Project under open-source governance, involving individual developers and firms working to advance Qt.
• Repleo: With a Repleo the own public key is encrypted with the already received public key of a friend, so that the own public key can be transferred to the friend in a protected way.
• Requirement: need or expectation that is stated, generally implied or obligatory; Note: “Generally implied” means that it is custom or common practice for the organization and interested parties that the need or expectation under consideration is implied. A specified requirement is one that is stated, for example in documented information.
• Review: activity undertaken to determine the suitability, adequacy and effectiveness of the subject matter to achieve established objectives
• Rewind: Rewind describes a function within the StarBeam-File-Transfer. With this the Send-out of a file is started for a second time. It is comparable with a new play from start of a music file. In case the file has not been completely transferred, the transmission can be started new or even scheduled for a later point of time. In case only some missing block of the file should be transferred again to the receiver, the further tool StarBeam-Analyzer is able to generate a Magnet-URI-Link, which the receiver can send to the sender, so that is will send out only the missing blocks again.
• Risk: effect of uncertainty on objectives. An effect is a deviation from the expected — positive or negative. Uncertainty is the state, even partial, of deficiency of information related to, understanding or knowledge of, an event, its consequence, or likelihood. Risk is often characterized by reference to potential events and consequences, or a combination of these. Risk is often expressed in terms of a combination of the consequences of an event (including changes in circumstances) and the associated likelihood of occurrence. In the context of information security management systems, information security risks can be expressed as effect of uncertainty on information security objectives. Information security risk is associated with the potential that threats will exploit vulnerabilities of an information asset or group of information assets and thereby cause harm to an organization.
• Rosetta CryptoPad: The Rosetta-CryptoPad uses an own Key for the encryption – as also an own key exists for E-Mail, Chat, URLs or POPTASTIC. With the Rosetta-CryptoPad a text can be converted into cipher text. It is used, to encrypt own texts before sending the text out to the internet or before you Post it somewhere into the Web. Similar to the File-Encryption-Tool for Files, Rosetta also converts plaintext into cipher text. Then the text can be transferred – either over one again secured and encrypted channel or even unencrypted as Chat or E-mail. Further messages can be posted to an Internet-Board or a Paste-Bin-Service as chipper text.
• RSA: RSA is one of the first practical public-key cryptosystems and is widely used for secure data transmission. In such a cryptosystem, the encryption key is public and differs from the decryption key which is kept secret. In RSA, this asymmetry is based on the practical difficulty of factoring the product of two large prime numbers, the factoring problem. RSA is made of the initial letters of the surnames of Ron Rivest, Adi Shamir, and Leonard Adleman, who first publicly described the algorithm in 1977.
• Salt, cryptographic: In cryptography, a salt is random data that is used as an additional input to a one-way function that hashes a password or passphrase. The primary function of salts is to defend against dictionary attacks versus a list of password hashes and against pre-computed rainbow table attacks.
• SCTP: In computer networking, the Stream Control Transmission Protocol (SCTP) is a transport-layer protocol (protocol number 132), serving in a similar role to the popular protocols Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It provides some of the same service features of both: it is message-oriented like UDP and ensures reliable, in-sequence transport of messages with congestion control like TCP.RFC 4960 defines the protocol. RFC 3286 provides an introduction.
• Session Management: Related to the identification of authenticated users
• Signature: A digital signature is a mathematical scheme for demonstrating the authenticity of a digital message or documents. A valid digital signature gives a recipient reason to believe that the message was created by a known sender, that the sender cannot deny having sent the message (authentication and non-repudiation), and that the message was not altered in transit (integrity).
• Simulacra: The Simulacra function is a similar function compared to the Impersonator function. While Impersonator is simulating a chat of two participants with messages, Simulacra is just sending out a Fake-Message from time to time. Simulacra-Messages contain only random characters and have not the style or goal, to imitate a process of a conversation.
• Small world phenomenon: Small world phenomenon refers to a a hypothesis, according to which every human being (social actor) is connected to the world with each other over a surprisingly short chain of acquaintance relationships. The phenomenon is often referred to as Six Degrees of Separation. Guglielmo Marconi’s conjectures based on his radio work in the early 20th century, which were articulated in his 1909 Nobel Prize address, may have inspired[citation needed] Hungarian author Frigyes Karinthy to write a challenge to find another person to whom he could not be connected through at most five people. This is perhaps the earliest reference to the concept of six degrees of separation, and the search for an answer to the small world problem. The small-world experiment comprised several experiments conducted by Stanley Milgram and other researchers examining the average path length for social networks of people in the United States. The research was groundbreaking in that it suggested that human society is a small-world-type network characterized by short path-lengths.
• SMTP: Simple Mail Transfer Protocol (SMTP) is an Internet standard for electronic mail (email) transmission. First defined by RFC 821 in 1982, it was last updated in 2008 with the Extended SMTP additions by RFC 5321—which is the protocol in widespread use today. SMTP by default uses TCP port 25. The protocol for mail submission is the same, but uses port 587. SMTP connections secured by SSL, known as SMTPS, default to port 465
• Socialist Millionaire Protocol (SMP): In cryptography, the socialist millionaire problem is one in which two millionaires want to determine if their wealth is equal without disclosing any information about their riches to each other. It is a variant of the Millionaire’s Problem whereby two millionaires wish to compare their riches to determine who has the most wealth without disclosing any information about their riches to each other. It is often used as a cryptographic protocol that allows two parties to verify the identity of the remote party through the use of a shared secret, avoiding a man-in-the-middle attack without the inconvenience of manually comparing public key fingerprints through an outside channel. In effect, a relatively weak password/passphrase in natural language can be used.
• SQLite: SQLite is a relational database management system contained in a C programming library. In contrast to many other database management systems, SQLite is not a client–server database engine. Rather, it is embedded into the end program.
• StarBeam-Analyser: The StarBeam-Analyzer is a tool, to analyze a transferred file over the StarBeam-function in that regard, if all partially blocks of the file have been received completely. The tool investigates – in case needed – the missing blocks of a file and creates a respective Magnet-URI-Link with this information. The receiver of the file can generate the Magnet and send it over to the sender of the file, who is then able to schedule a new send-out just of the missing blocks (also named as links or chunks). Over this procedure not the complete files has to be sent or replayed new to complete the original first transfer.
• Super-Echo: The echo protocol consists within these remembered characteristics (if we summarize it short), that each node tries to encrypt each message capsule – if this succeeds in terms of the hash-comparison, this message is for the own reading, and will be not again repacked and transferred further to all other connected online neighbors. As an online attacker could recognize this, when an incoming message is not send out again, and thus could assume, that that it is a message for the receiver at this node. With Super-Echo the message will be – even if it has been decrypted successfully for the own node – sent out again to the connected nodes and for traveling on further paths. Just in regard, as this message would not have been determined for the own readings.
• TCP: The Transmission Control Protocol (TCP) is a core protocol of the Internet protocol suite. It originated in the initial network implementation in which it complemented the Internet Protocol (IP). Applications that do not require reliable data stream service may use the User Datagram Protocol (UDP), which provides a connectionless datagram service that emphasizes reduced latency over reliability.
• Timing: Related to the race conditions, locking, or order of operations
• Turtle Hopping: Turtle was a free anonymous peer-to-peer network project being developed at the Vrije Universiteit in Amsterdam, involving professor Andrew Tanenbaum. Like other anonymous P2P software, it allows users to share files and otherwise communicate without fear of legal sanctions or censorship. Turtle’s claims of anonymity are backed by two research papers. Technically, Turtle is a friend-to-friend (F2F) network. The RetroShare File Sharing application is based on a F2f and implemented a “Turtle Hopping” feature which was inspired by Turtle.
• UDP: The User Datagram Protocol (UDP) is one of the core members of the Internet protocol suite. The protocol was designed by David P. Reed in 1980 and formally defined in RFC 768. UDP uses a simple connectionless transmission model with a minimum of protocol mechanism. It has no handshaking dialogues, and thus exposes the user’s program to any unreliability of the underlying network protocol. There is no guarantee of delivery, ordering, or duplicate protection. Time-sensitive applications often use UDP because dropping packets is preferable to waiting for delayed packets, which may not be an option in a real-time system.
• URL-Distiller: URL-Distillers are filter rules, with which the downloaded, uploaded or imported URLS will be filtered. For example one can configure his URL-Distillers in such a way, that all URLs are loaded into the own Database, but only specific URLS from one defined Domain, e.g. Wikipedia, are uploaded. Also e.g. a university can distribute only URLs out of the own database to its connected students, which refer to the own web-domain. URLs and URIs of Magnets, ED2K-Links and Torrent-URLs are currently not supported in the own URL-Database respective filter rules. The distillers refer to Web-URLs and also to FTP and Gopher.
• Virtuelle E-Mail Institution (“VEMI”): See E-Mail-Institution.
• Web of Trust: In cryptography, a web of trust is a concept used in PGP, GnuPG, and other OpenPGP-compatible systems to establish the authenticity of the binding between a public key and its owner. Its decentralized trust model is an alternative to the centralized trust model of a public key infrastructure (PKI), which relies exclusively on a certificate authority (or a hierarchy of such). As with computer networks, there are many independent webs of trust, and any user (through their identity certificate) can be a part of, and a link between, multiple webs.

ANNEX: INDEX OF DESCRIPTIONS

Table 82: Difficulty Level and Description

Difficulty Level Difficulty Description
Undetermined Commonly exploited, public tools exist or can be scripted that exploit this flaw
Low Commonly exploited, public tools exist or can be scripted that exploit this flaw
Medium Attackers must write an exploit, or need an in depth knowledge of a complex system
High The attacker must have privileged insider access to the system, may need to know extremely complex technical details or must discover other weaknesses in order to exploit this issue

Table 83: Severity Category and Description

Severity Category Severity Description
Informational The issue does not pose an (immediate) risk, but is relevant for theoretical analysis or to security best practices or Defense in Depth
Undetermined The extent of the risk was not determined during this engagement
Low The risk is relatively small, or is not a risk the customer has indicated as important
Medium Individual user’s information is at risk, exploitation would be bad for client’s reputation, of moderate financial impact, possible legal implications for client
High Large numbers of users, very bad for client’s reputation or serious legal implications.

Table 84: Innovation & Improvement Class and Descripton

Innovation &
Improvement Class
Innovation & Improvement Description
Informational Suggestion for improvement given by the auditor.
Habitual Improves the given status, process or function.
Medium Defines a new status, process or function for the application.
High Defines a new status, process or function compared for the market. Sets a new state of the art. Regarded as Innovation. Shows high innovation and improvement in one or more dimensions (e.g. in technical or processural regard).

Table 85: Strength Dimensions and Descripton

Strength Dimension Strength Description
Low Process, function or feature implementation is state of the art compared to just a few other comparable entities.
Medium Process, function or feature implementation is very deep and detailed and this leading within the standard compared to others.
High Process, function or feature implementation is very deep and detailed and a unique selling proposition (USP) compared to others. This strength sets new standards.

ANNEX: INDEX OF FIGURES

Table 86: Index of figures:

Please see the Index of figures in the PDF-Layout of the Study also under: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf

1. Figure 01: Eight Principles of a Crypto-IT-Audit
2. Figure 02: GoldBug – Encrypted Message Format within the Echo-Protocol
3. Figure 03: Source Code for the Hash Comparision memcmp in spot-on-crypt.cc
4. Figure 04: Usage of Digital Signatures for e.g. E-mail-Letters defined in Options
5. Figure 05: Neighbor connection to the project server
6. Figure 06: Encrypted Message of GoldBug shown in a web browser
7. Figure 07: Virtual keyboard of the GoldBug application
8. Figure 08: Database email.db with ciphertext
9. Figure 09: GoldBug – Account Firewall for Accounts and IP-Addresses
10. Figure 10: GoldBug – Handbook and User-Manual of GoldBug Messenger
11. Figure 11: POPTASTIC Settings
12. Figure 12: Diffusion of POPTASTIC Innovation as theoretical construct
13. Figure 13: GoldBug – File Transfer in the Chat Pop-up Window
14. Figure 14: Example of Magnet URI-Link for StarBeam-File-Transfer
15. Figure 15: Assessment of Codelines of spot-on-starbeamanalyzer.cc
16. Figure 16: Statistics Window of GoldBug
17. Figure 17: Console Statistic Function
18. Figure 18: EPKS – Echo Public Key Sharing
19. Figure 19: RSS-Function in the GoldBug Klient
20. Figure 20: Code for the URL-Database Distribution to other participants
21. Figure 21: GoldBug - Tooltip for the encryption of GUI to kernel
22. Figure 22: Code-Review for the encryption of the GUI Kernel connection
23. Figure 23: GoldBug - E-Mail-Client with Forward Secrecy for ephemeral E-Mail-Keys
24. Figure 24: Source-Code quotation of the GoldBug Password on E-Mails
25. Figure 25: Adaptive Echo - Hansel, Gretel and Wicked Witch example
26. Figure 26: Adaptive Echo Test-Network-Environment
27. Figure 27: Creating a Bluetooth Chat-Server / Listener
28. Figure 28: Graph-Example including Bloutooth-Chat Servers in a classroom
29. Figure 29: Socialist-Millionaire-Protocol in the graphical user interface of the GoldBug Messenger
30. Figure 30: Socialist Millionaire Protocol – State Machine Process
31. Figure 31: Currently available Algorithms in GoldBug Messenger & E-Mail Client
32. Figure 32: Individual adjustable crypto values within GoldBug
33. Figure 33: GoldBug – Account Names and Passwords with at least 32 characters
34. Figure 34: Code for the Account Authentification in file Spot-on-Neighbor.cc
35. Figure 35: Reason Core Security Scan of GoldBug
37. Figure 37: BIG SEVEN Open Source Crypto-Messenger Overview
38. Figure 38: Infographic: 10 Trends in Crypto-Messaging

ANNEX: INDEX OF TABLES

Table 87: Index of tables:

Please see the Index of tables in the PDF-Layout of the Study also under: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf

1. Table 01: Referring of methodical Audit-Dimensions to Funktions of the Programm GoldBug each with a question to research
2. Table 02: 38 open source Crypto-Applications & -tools out of 4 Blog-Portals
3. Table 03: Group of the „Big SEVEN“ to be compared secure Messengers (B7-List)
4. Table 04: Audit Key Steps
5. Table 05: Description of findings 3.01
6. Table 06: Indicative BIG SEVEN context references 3.01
7. Table 07: Good Practice Insight # 01
8. Table 08: GoldBug Authentification Matrix for Digital Signatures
9. Table 09: Description of findings 3.02
10. Table 10: Indicative BIG SEVEN context references 3.02
11. Table 11: Good Practice Insight # 02
12. Table 12: Description of findings 3.03
13. Table 13: Indicative BIG SEVEN context references 3.03
14. Table 14: Good Practice Insight # 03
15. Table 15: Description of findings 3.04
16. Table 16: Indicative BIG SEVEN context references 3.04
17. Table 17: Good Practice Insight # 04
18. Table 18: Description of findings 3.05
19. Table 19: Indicative BIG SEVEN context references 3.05
20. Table 20: Good Practice Insight # 05
21. Table 21: Description of findings 3.06
22. Table 22: Indicative BIG SEVEN context references 3.06
23. Table 23: Good Practice Insight # 06
24. Table 24: Description of findings 3.07
25. Table 25: Indicative BIG SEVEN context references 3.07
26. Table 26: Good Practice Insight # 07
27. Table 27: Allocation of function, number of pages & screenshots in the manual
28. Table 28: Description of findings 3.08
29. Table 29: Indicative BIG SEVEN context references 3.08
30. Table 30: Good Practice Insight # 08
31. Table 31: Open Source Crypto Messenger Applications and their Review Reports
32. Table 32: Description of findings 3.09
33. Table 33: Indicative BIG SEVEN context references 3.09
34. Table 34: Good Practice Insight # 09
35. Table 35: Description of findings 3.10
36. Table 36: Indicative BIG SEVEN context references 3.10
37. Table 37: Good Practice Insight # 10
38. Table 38: Overview of the Magnet-URI-Standards for cryptographic values
39. Table 39: Description of findings 3.11
40. Table 40: Indicative BIG SEVEN context references 3.11
41. Table 41: Good Practice Insight # 11
42. Table 42: Analysing and comparing the statistcs after a practical monitoring test
43. Table 43: Description of findings 3.12
44. Table 44: Indicative BIG SEVEN context references 3.12
45. Table 45: Good Practice Insight # 12
46. Table 46: Within Top 10 search results of main search engines for query: GoldBug Messenger
47. Table 47: Description of Findings 3.13
48. Table 48: Indicative BIG SEVEN context references 3.13
49. Table 49: Overview of other Messengers in the Portal Majorgeeks
50. Table 50: Good Practice Insight # 13
51. Table 51: Description of findings 3.14
52. Table 52: Indicative BIG SEVEN context references 3.14
53. Table 53: Good Practice Insight # 14
54. Table 54: Overview of the different Calling-ways with referring criteria
55. Table 55: Description of findings 3.15
56. Table 56: Indicative BIG SEVEN context references 3.15
57. Table 57: Good Practice Insight # 15
58. Table 58: Description of findings 3.16
59. Table 59: Indicative BIG SEVEN context references 3.16
60. Table 60: Good Practice Insight # 16
61. Table 61: Description of findings 3.17
62. Table 62: Indicative BIG SEVEN context references 3.17
63. Table 63: Good Practice Insight # 17
64. Table 64: Steps of the Socialist Millionaire Process
65. Table 65: Description of findings 3.18
66. Table 66: Indicative BIG SEVEN context references 3.18
67. Table 67: Encryption options for Jabber / XMPP
68. Table 68: Good Practice Insight # 18
69. Table 69: Description of findings 3.19
70. Table 70: Indicative BIG SEVEN context references 3.19
71. Table 71: Good Practice Insight # 19
72. Table 72: Description of findings 3.20
73. Table 73: Indicative BIG SEVEN context references 3.20
74. Table 74 :Good Practice Insight # 20
75. Table 75: List of the files from the GoldBug Installation ZIP
76. Table 76: Release History of GoldBug Messenger
77. Table 77: Description of findings 3.21
78. Table 78: Evaluation-Matrix of possible risks & continuous improvements suggestions
79. Table 79: BIG SEVEN Crypto-Messenger comparison scale
80. Table 80: Indicative Comparison of contextual assessments on BIG SEVEN Crypto Messengers
81. Table 81: 10 Trends in Crypto-Messaging
82. Table 82: Difficulty Level and Description
83. Table 83: Severity Category and Description
84. Table 84: Innovation & Improvement Class and Descripton
85. Table 85: Strength Dimensions and Descripton
86. Table 86: Index of figures
87. Table 87: Index of tables

PUBLIC SUMMARY

BIG SEVEN Study about 7 Crypto-Messenger:
E-Mail-Client GoldBug scores in the IT-Audit

Tokyo/Munich. Another contribution in the crypto discussion: Two security researchers from Tokyo and Munich examine in their BIG SEVEN study seven well-known encryption applications for e-mail and instant messaging out of the open source area and then performed a deeper IT-audit for the acquainted software solution GoldBug.sf.net. The evaluation took into account the essential criteria, study fields and methods of eight international IT-audit manuals and identifies Ten Trends in the Crypto-Messaging.

Another contribution in the crypto-discussion: The two security researchers David Adams (Tokyo) and Ann-Kathrin Maier (Munich), who examined in their BIG SEVEN study seven well-known encryption applications for e-mail and instant messaging out of the open source area, performed then a deeper IT-audit for the acquainted software solution GoldBug.sf.net. The audit took into account the essential criteria, study fields and methods on the basis of eight international IT-audit manuals and was carried out in 20 dimensions.

Security researcher David Adams from Tokyo about the published BIG SEVEN CRYPTO-study: "We looked at the seven major open source programs for encrypted online-communication and identified ten trends in the Crypto-Messaging area. One of the important trends is the feature, that the users should be able to define an so-called end-to-end encrypting password by themselfs manually".

The software "GoldBug - email client and instant messenger" here was ahead with excellent results and is not only very trustworthy and compliant to international IT-audit manuals and safety standards, GoldBug also scores in comparison and in the evaluation of the single functions in much greater detail than the other comparable open source crypto messenger.

Co-author of the study Ann-Kathrin Maier from Munich confirms: "We have then our Messenger study deepened with a detailed audit of the crypto-program GoldBug, which received excellent results for encrypted email and secure online chat. By our code-reviews we can confirm the trustworthiness of this open source encryption in GoldBug."

Numerous details have been analyzed by various methods, compared and also strategically evaluated by the two authors regarding the current encryption discussions.

The comparatively studied applications include CryptoCat, GoldBug, OTR-XMPP clients such as Pidgin with the OTR-plugin, RetroShare and Signal, Surespot and Tox.

In the study, detailed analysis and findings are described, such as

• that GoldBug has its strength especially in the hybrid multi-encryption, which is for the future strategically important: already encrypted text will be encrypted again,
• it incorporates many of the background and subject-specific information, such as mutual attacks of the Crypto-projects amoung each other, for example, when cryptocat developers want to outdo other developments with new releases, or it is questioned why some experts distract of options for decentralized chat servers prominent within the media. Also it is examined, why chat applications are considered open source, although the chat server is not,
• it is the thesis analyzed in the study, that it is today no longer (only) about the breaking of cryptology, but (especially also) about the recording of metadata: "Who communicates with whom" is more crucial, as the content of communication,
• that e.g. the key strength of GoldBug is twice as large and thus safer than in the OTR-plugin of XMPP-clients,
• that the development of TOX could be regarded as a promiscuous pool since over 147 developers contributed to the code development - and quality management of the code therefore could be regarded as critical,
• it is analyzed, why students prefer in their dormitory houses to exchange open source files encrypted using a Bluetooth server than a LAN network,
• the further development of traditional encryption tools is seen in relating encryption in an application to both, chat and e-mail, so that you can reach online and offline friends, as it is implemented in the GoldBug Messenger by the POPTASTIC function (Chat via IMAP / POP3),
• for all encrypting messengers the installation of manually defineable symmetrical end-to-end encryption is recommended, which have so far only a few messenger (also not Whatsapp),
• in particular the need for more comparative research in the field of functions and solutions for encryption and their referring applications is further regarded.

After the institute NIST (Chen et al.) has stated in February 2016 that the algorithm RSA in quantum computer age is broken respectively no longer sure, GoldBug is the remaining Messenger which has next to RSA also even ElGamal and NTRU implemented and therefore can be regarded as safe against Quantum computers! The in-depth audit was therefore carried out for this of seven Messengers.

Therefore, the comparative BIG SEVEN study about open source crypto-messaging respective the GoldBug audit-report is recommended not only as a resource for IT interested readers, students, mathematicians, cryptologists and auditors, but also can be regarded as a basis for discussion on further development in the field of research, programming and as preparatory reading material for questions at the next crypto party.

The study has been archived accordingly at the project and can be downloaded in the Version 1.1 in the PDF-Layout at the following URL: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf