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

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

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

Source: Own Case.

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

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

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

Table 11: Good Practice Insight #02

Source: Own Case.

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

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

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

Source: Own Case.

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

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

Table 17: Good Practice Insights #04

Source: Own Case.

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

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

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

Source: Own Case.

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

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

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

Source: Own Case.

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

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

Table 26: Good Practice Insights #07

Source: Own Case.

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

Source: https://de.wikibooks.org/wiki/Goldbug

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

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

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

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

Source: Own Case.

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

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

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

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:
https://twitter.com/GoldBugIM/ status/694263996044689408, https://twitter.com/ GoldBugIM/ 
status/693440868271939584, https://twitter.com/GoldBugIM/ status/ 689540775416369153).
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
https://twitter.com/tqbf/status/678065993587945472
Thomas H. Ptacek ?@tqbf  Dec 19 Austin, Chicago
By default Telegram stores the PLAINTEXT of EVERY MESSAGE every user has ever sent or 
received on THEIR SERVER.


https://twitter.com/Snowden/status/678271881242374144
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. 

Edward Snowden added,
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
Reply   Retweet  1.1K   
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
Nadim Kobeïssi ?@kaepora
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

Source: Own Case.

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

Source: https://de.wikibooks.org/wiki/Goldbug#POP3

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

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

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

Source: Own Case.

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

Source: https://de.wikibooks.org/wiki/Goldbug#FileSharing:_mit_StarBeam

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

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.

Optional: A Nova-Password for the additional encryption of the file

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

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

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

Source: Own Case.

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

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

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

Table 45: Good Practice Insights #12

Source: Own Case.

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

Source: Screenshot of RSS-/Atom-Reader in GoldBug.

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

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

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

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

Source: Own Case.

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

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

Table 53: Good Practice Insights #14

Source: Own Case.

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:

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

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

Table 57: Good Practice Insights #15

Source: Own Case.

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.

Figure 23: Adaptive Echo Test-Network-Environment

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

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

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

Source: Own Case.

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

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

Table 63: Good Practice Insights #17

Source: Own Case.

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

Source: https://en.wikipedia.org/wiki/Socialist_millionaire .

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:  Yes, please, enter that password. 

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

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, 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

Source: Own Case.

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

• Cipher Type
• Hash Type
• Iteration Count
• Salt length

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

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

Table 71: Good Practice Insights #19

Source: Own Case.

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

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

Table 74: Good Practice Insights #20

Source: Own Case.

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

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:

http://www.download3k.com/Antivirus-Report-GoldBug.html

There, the security is indicated even over five different scanner-suppliers as follows:

Figure 36: GoldBug-Antivirus Report of the Portal Download3k.com

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

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

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.