GoldBug-manual

Manual of the GoldBug Crypto Messenger

https://compendio.github.io/goldbug-manual/

& https://compendio.github.io/goldbug-manual-de/

Edited by Scott Edwards (2018, Review at Github).

(A first drafted translation into English by a translation machine).

Content 1 What is GoldBug? 1.1 Why is it important for Internet users to encrypt communication? 1.2 Where does the name "GoldBug" come from? 2 Encryption: GoldBug has alternatives to RSA – - The first NTRU & McEliece Messenger 2.1 Asymmetric encryption with PKI: RSA, Elgamal and especially NTRU and McEliece in comparison 2.2 Application of Block Cipher Modes & Encrypt-then-MAC 2.3 Hybrid encryption system 2.4 Symmetric encryption with AES 3 What is the Echo Protocol? 3.1 Full echo 3.2 Half echo 3.3 Echo Accounts 3.4 The echo grid 3.4.1 Examples of key exchanges by Alice, Bob, Ed & Maria 3.5 Adaptive Echo (AE) and its AE tokens 3.5.1 Hansel and Gretel - An example of Adaptive Echo mode 3.6 Some examples of how the echo protocol works 4 Cryptographisches Discovery 5 Set up a first installation - eg with the wizard 5.1 Two login methods 5.2 Generation of 10 Keys for Encryption 5.3 Activation of the kernel 5.4 Connect a neighbor with the IP address 6 The chat function 6.1 Add a friend by swapping and inserting the keys 6.1.1 Special feature: Repleo 6.2 Start a first secure chat 6.3 Additional security feature: MELODICA: Calling with a Gemini 6.3.1 Asymmetric Calling 6.3.2 Instant Perfect Forward Secrecy (IPFS) 6.3.3 Symmetric Calling 6.3.4 Two-Way-Calling 6.4 Additional security feature: Socialist Millionaire Protocol 6.4.1 SMP-Calling 6.5 Additional security feature: Forward Secrecy (asymmetric) 6.5.1 Forward Secrecy Calling 6.6 Overview of the different Calling types 6.7 Emoticons 6.8 File transfer in the chat pop-up window 7 Group chat in IRC style 8 Smoke Mobile Chat Client 8.1. Smoke Android Client 8.2. Fire to Buzz Chat 9 The e-mail function 9.1 POP3 9.2 IMAP 9.3 P2P E-Mail: without data retention 9.4 Setting up C/O & e-mail institutions 9.4.1 Care-Of-Method (c/o) 9.4.2 Virtual E-Mail Institution ("VEMI") - Method 9.5 Additional Encryption: Put a "GoldBug" on an e-mail 9.6 Forward Secrecy 9.7 Secret Streams 10 POPTASTIC - Encrypted chat and email via POP3 & IMAP 10.1 Chat over POPTASTIC 10.2 E-Mail over POPTASTIC 10.3 Setting up POPTASTIC 10.4 Further development of POPTASTIC 11 FileSharing: with StarBeam (SB) 11.1 Creating StarBeam magnets with encryption values 11.1.1 Option "Nova": Encrypt file before file transfer? 11.1.2 Using a one-time magnet 11.1.3 Overview of Magnet URIs with Cryptographic Values 11.1.4 Rewind function 11.1.5 Comparison with turtle hopping 11.2 StarBeam-Upload: transfer a file 11.3 StarBeam-Downloads 11.3.1 Tool: StarBeam-Analyzer 11.3.2 Outlook for Crypto Torrents 12 Web search engine with URL database 12.1 Database setup 12.1.1 SQLite 12.1.2 PostgreSQL 12.2 URL-Filter 12.3 URL-Community 12.4 Pandamonium Webcrawler 12.5 RSS-Reader and URL-Import 13 Set up chat / email server 13.1 Set up the chat / email server via a listener 13.1.1. Server Broadcast 13.1.2. Security options 13.1.3. Proxy- & Firewall-Annotations 13.1.4. GoldBug as Lan Messenger 13.2 Server / Listener Creation Home behind a router / Nat 13.3 Use of GoldBug in the TOR network 13.4 Spot-On Server 13.5 Spot-On Lite Server as Deamon 13.6 SmokeStack Server under Android 13.7 Bluetooth Server 13.8 UDP Server 13.9 SCTP Server 13.10 NCat Connection 14 Tools 14.1 Tool: Encryption of files (FileEncryptor) 14.2 Tool: The Rosetta CryptoPad 14.3 Tool: Echo Public Key Share (EPKS) 14.4 Pass-Through-Functionality 14.5 Display analyzes and statistics 15 BIG SEVEN STUDY: Crypto-Messenger-Audit 16 The Digital Encryption of Private Communication in the Context of ... 16.1 Principles of the protection of private speech, communication and life: Universal Declaration of Human Rights, 1948 (Art. 12) 16.2 International Covenant on Civil and Political Rights, 1966 (Art. 17) 16.3 European Convention on Human Rights, 1950 (Art. 8) 16.4 Charter of Fundamental Rights of the European Union, 2000 (Art. 7, 8) 16.5 Basic Law e.g. Federal Republic of Germany, 1949 (Art.2 Abs.1 & Art.1 Abs.1) 16.6 Art. 10 - Privacy of correspondence, posts and telecommunications 16.7 § 206 - Verletzung des Post- oder Fernmeldegeheimnisses 16.8 U.S. Constitution: Search and Seizure (Expectation of Privacy, US Supreme Court) 17 History of program releases 18 Website 19 Open source code 19.1 Compile Information 20 List of publications

Manual-Files: https://github.com/compendio/goldbug-manual

Manual Deutsch/German: https://github.com/compendio/goldbug-manual-de

PDF: https://sf.net/projects/GoldBug/files/goldbug-manual-de.pdf

Website: http://goldbug.sourceforge.net/

Download: https://sourceforge.net/projects/goldbug/files/

Source: https://github.com/textbrowser/spot-on

1 What is GoldBug?

GoldBug is a secure instant chat messenger and encrypting email client that also include additional features such as group chat, file transfer, and a URL search based on an implemented URL database.

Thus, the three basic functions frequently used by a regular Internet user in the Internet - communication (chat / e-mail), web search and file transfer - are represented in an encrypted environment safely and comprehensively.

In addition, GoldBug has also implemented a number of useful tools, such as encrypted chat server functionality, proxy-enabled passthroughs, text / ciphertext conversion pads and vice versa, a feedreader and web crawler, or dashboards for the friends of statistics and analysis, and much more.

With the use of GoldBug - GB for short - the user can therefore be relatively sure because of the encryption that no unwanted third party can eavesdrop on the conversations or open emails or file transfers. The URL search also happens on the local machine, so that search queries are protected and secured.

The user-to-user communication should remain with this application via the Internet in private, protected space.

GoldBug uses for this strong and multiple encryption, also called hybrid encryption, with different levels of modern encryption technology based on established encryption libraries - such as libgcrypt (known from OpenPGP or GnuPG and OpenSSL).

For example, it creates separate and different public / private keys for encryption and signatures for each function - based on the encryption algorithms RSA, or alternatively Elgamal and NTRU. In addition to NTRU, the encryption algorithm McEliece is open source implemented.

These latter two algorithms are considered to be particularly secure against attacks that are known from quantum computing and are becoming increasingly relevant in the future due to fast quantum computers. GoldBug is thus one of the first messengers worldwide to implement these two algorithms, thus initiating the renunciation of - or alternatives to - the RSA algorithm - that has been officially considered as broken since 2016 (see NIST cited in Adams / Maier 2016).

Furthermore, the application also offers decentralized and encrypted e-mail as well as decentralized public group chat in IRC style. Finally, there is also the function to implement a URL web search in a decentralized database repository: Users can store URLS and content of the website - as so far Bookmarks in the browser and its cache - in a comfortable searchable database to their thematic RSS feeds or import them, which is based either on SQL or PostGres and is also p2p networkable.

The email can be IMAP, POP3 and thirdly, P2P e-mail - GoldBug is thus a fully functional e-mail client. As soon as encrypted emails are sent, it is necessary that the friend also uses this (or any other echo) client. This has the advantage that the encryption key is only to be exchanged once, but then no longer has to be applied to every single e-mail. This function of transferring the key encrypted back in a direct way is called “Repleo” in GoldBug and later on this was also taken over in other projects under the name Autocrypt or KeySync (within an automatic process).

As in any messaging program, files can be shared and sent. The transfer is always encrypted per se. With the tools “Rosetta CryptoPad” and the “File-Encryptor” the user can additionally encrypt text and/or files additionally safely or convert them back. These encryption tools can therefore also be used for other transmission paths (such as an unencrypted path outside of GoldBug).

With all its equipment, GoldBug is therefore a so-called “Communication Suite” - a program with numerous functions for secure communication, which realizes the transmission of the encrypted packets with the so-called echo protocol. This is particularly secure, as it will be explained below.

Figure: Explanation of the tabs in GoldBug Crypto Messenger

1.1 Why is it important for Internet users to encrypt communications

Today almost all wireless Wifi Internet accesses are password protected (So called “Freifunk”-activities are currently trying to reverse this over-regulation through password-free and account-free wireless Internet access). In a few years plain text messages or e-mails to friends (in the following all terms always apply to all genders) via the internet should be encrypted as well. In order to consolidate this change, sometimes C-Mail (for crypto-mail) rather than e-mail is used as a new term.

Encryption is not a question of having something to hide or not, it is the question of whether we ourselves control our communication - or whether it is controlled by others, third parties.

It is ultimately also a question of attacking free thinking and a question of deleting the presumption of innocence (“In doubt for the accused” - if every citizen ever belongs to a dock!).

Democracy requires thinking and discussing alternatives in private as well as in public.

The communication and data transmission over the Internet should be protected as parents would also protect their loved ones or a mother bird their young against the unknown: Everyone should protect his privacy and human rights with modern encryption functions.

Strong multi-encryption (so-called “hybrid encryption”) thus ultimately secures the declarations of human rights in their broadly constituted consensus and is a digital self-defense that everyone should learn and use - to ultimately contribute to democracy and support them.

The GoldBug Messenger tries to be an easy-to-use tool for this claim. Similar to the development of safety in automobiles, the e-mail & chat encryption will also develop: if you initially drove without a seatbelt in the car, today we drive with obligatory safety belts (e.g. since 1968 in the U.S.) and additional airbags or thirdly additional electronic security information systems.

GoldBug is an easy-to-use, but to some extent also learnable program; it requires - as with the car driver’s license - the knowledge of the various controls and options. GoldBug is thus an already simplified user interface compared to the original user interface, which is also called Spot-on coming from the “Spot-on” project. Similar to a cockpit of an aircraft, there are even more control buttons available in this original user interface. In GoldBug these are already reduced and also another minimal view is offered for beginners in software for cryptographic processes. In this respect: Learn what is still unknown and note that it is already a reduced scope. This manual can help you to understand the individual functions. And users who first read and then try out are, as always, clearly in the advantage. :-)

The unencrypted Plain Text email or chat message should therefore have actually become obsolete after the 2013 Snowden Papers found that private emails are widely intercepted and systematically collected and evaluated by many interested parties worldwide.

Incidentally: The logo of the GoldBug logo is written in the font “Neuland” (which means translated: new territory) - a font that was developed in 1923 by the typographer Rudolf Koch. Interestingly enough, the logo has been an allusion to the German ‘‘sentence of the year’’ 2013, when German Chancellor Angela Merkel - in connection with the surveillance and espionage affair in 2013 and the Listening to her personal mobile phone - in a conversation with American President Barack Obama coined the phrase: “The Internet is a new territory for us all.” ..

.. - How long encryption for the subsequent student generations will remain a new territory (or ‘’ Neuland ‘’) or literally ‘secret science’ - or a kind of “seat belt”, which will also convert e-mails to c-mail, decide the learners, teachers and the media and technicians - but in any case everyone (e.g. the reader of this manual) with the own friends with whom this or other encryption software is used.

Figure: GoldBug logo (smiley face)

1.2 Where does the name “GoldBug” come from?

The Gold Bug is a short story by Edgar Allan Poe: The plot is about William LeGrand, who recently encountered a gold-colored ladybug.

His buddy, Jupiter, now expects LeGrand to evolve in his quest for insight, wealth, and wisdom after being in contact with the Golden Bug - and thus goes on to another friend of LeGrand, a narrator not further mentioned by name, who thinks it would be a good idea to visit his old friend again. After LeGrand then encountered a secret message and was able to decrypt it successfully, the three start an adventure as a team.

The Gold Bug - as one of the few pieces in the literature - integrates cipher text as an element of the short story. Poe was thus far ahead of the popularity of cipher texts of his time when he wrote “The Gold Bug” in 1843, in which the success of history turned to such a cryptogram and metaphorically to the search for the knowledge of the philosopher’s stone.

The Gold Bug was a much-read story, extremely popular and by the literati the most studied work by Poe during his lifetime. His ideas also helped to promote the writing of encrypted texts and so-called cryptograms (see also Wikipedia).

Over 170 years later, encryption in the Internet age has more weight than ever. Encryption should be a standard when we send communications over the insecure internet - reason enough to use this name for the application to remember the origins of the encrypted writing.

GoldBug is thus a historical tribute, which possibly requires an adaptation to the term, because “bug” is often understood in the IT language as an error correction. Depending on the person, the idea of valuing a golden ladybug as much as another cuddly toy may require a strong cognitive reorganization of a so far dominated worldview or the routinized expansion of the appreciation of bug-finds as interesting research finds.

Those who like exploring new things, openly approaching what is found, will be able to learn and deepen many things in cryptographic processes with the GoldBug application, if so far no access to this “new territory” has been made possible. For teachers, the software is therefore an interesting teaching tool that can introduce and test cryptography in practical implementation and exercises with playful testing, reminiscent of the beginnings of popular cryptography at the time.

2 Encryption: GoldBug has alternatives to RSA - The first NTRU & McEliece Messenger

Encryption is only as good as the mathematical calculations cannot be calculated by the automation of computers at lightning speed. Therefore mathematically speaking, the prime factorization is used because it requires years of computational effort.

There are basically two methods of encryption. First, the symmetric encryption: Both users use the same password, e.g. a so-called AES with 32 characters, which will be explained in more detail below, or on the other hand, there is the a-symmetric encryption. In a-symmetric encryption, each user has two keys, a private and a public key. The users each exchange the public key and can then encrypt data using the private key in combination with the public key. After transmission, the other party is also able to decipher the message with their own private key. The asymmetric method is also called PKI: Pubic Key Infrastructure called, which can build on different algorithms for key generation.

However, encryption - be it via AES or PKI - is not unbreakable, and the procedures and libraries must also be well-used to be secure. RSA is considered “today as an essential, widely studied and not yet breakable encryption standard - although the further development of fast computers might bring a different future”, - it was still 2014 in this manual noted. In 2016, the official NIST Institute announced that RSA is considered broken in the age of quantum computing (see NIST cited in Adams / Maier 2016).

The media has barely picked it up, as everyone will probably agree that you cannot buy a quantum computer in the nearest supermarket, so the problem might be not relevant. It has the charm of children who hold their hand in front of their eyes and thus do not let the problem or risk endanger their perception of reality. Nevertheless, it is officially confirmed that RSA can be broken - with special means. The security is gone. This also has an impact on our Internet economy and online banking, because so far, the secure connections are relying on RSA and a TLS to secure the connection to online banking or shopping based on McEliece or NTRU is not yet developed.

2.1 Asymmetric encryption with PKI: RSA, Elgamal and especially NTRU and McEliece in comparison

Therefore, GoldBug Messenger has already introduced additional alternatives to RSA at an early stage - if this encryption algorithm standard would ever be insecure: RSA with a correspondingly large size of the key (at least 3072 bytes) can still be regarded as a time hurdle by non-specialized technical administrative staff, especially as GoldBug holds more extensive security even with multiple encryptions.

In addition to RSA GoldBug has yet implemented the encryption algorithms Elgamal and also NTRU and McEliece. The latter two are also considered to be particularly resistant to the attacks known from quantum computing.

Figure: McEliece’s algorithm for advanced protection against attacks from quantum computing

GoldBug uses the libgcrypt, libntru, and McEliece libraries to create persistent private and public key pairs. Currently, the application generates key pairs for each of the ten functions during initialization. Key generation is optional. As a result, GoldBug does not require public key infrastructure. Of course, the desired algorithms can be selected and keys can be generated.

There is also a comprehensive choice of encryption methods available with encryption: DSA, ECDSA, EdDSA, Elgamal, and RSA. Signature means that the generated encryption key is re-signed with a key to prove that a message is coming from a particular subscriber and nobody else. The OAEP and PSS schemes are used with the RSA encryption and RSA signature respectively.

Figure: RSA and its alternatives in GoldBug

McEliece-Kryptosystem The McEliece cryptosystem is an asymmetric encryption algorithm. It was presented in 1978 by cryptographer and founder Robert J. McEliece. Even with the use of quantum computers, there is no known efficient method by which the McEliece cryptosystem can be broken. This makes it a promising algorithm for post-quantum cryptography.

NTRU NTRU is an asymmetric encryption technique developed in 1996 by mathematicians Jeffrey Hoffstein, Jill Pipher and Joseph Silverman. It is loosely based on lattice problems that are considered unbreakable even with quantum computers. However, NTRUEncrypt has not been extensively studied so far as more common methods (e.g. RSA). Ntruencrypt is by IEEE P1363.1 standardized (see Ntruencrypt)

Elgamal The Elgamal encryption method or Elgamal cryptosystem is a public-key encryption method developed in 1985 by the cryptographer Taher Elgamal, based on the idea of Diffie-Hellman key exchange. The Elgamal encryption method, like the Diffie-Hellman protocol, relies on operations in a finite-order cyclic group. The Elgamal encryption method is provably IND-CPA-safe, assuming that the Decisional-Diffie-Hellman problem is not trivial in the underlying group. Related to the encryption method described here (but not identical with it) is the Elgamal signature method (the Elgamal signature method is not yet implemented in GoldBug). Elgamal is not subject to a patent (cf. Elgamal encryption method).

RSA RSA (after the people Rivest, Shamir and Adleman) is an asymmetric cryptographic procedure that can be used for both encryption and digital signature. It uses a key pair consisting of a private key used to decrypt or sign data and a public key to encrypt or verify signatures. The private key is kept secret and can only be calculated from the public key with extremely high expenditure (see RSA Cryptosystem).

GoldBug encryption is designed so that any user can communicate with any user, no matter what encryption algorithm a user has chosen. Communication between users with different key types is thus well defined when the nodes share common versions of the libgcrypt and libntru libraries: anyone who has chosen an RSA key can also chat and email encrypted with an user who has chosen an Elgamal key. This is because everyone supports each algorithm and the library supports it. If you want to test the program with a friend, it is best to use the latest version of GoldBug.

Figure: Customizable crypto

Of course every user in GoldBug can set his

individual key size,

the “cipher”,

the “hashtype”,

furthermore “iteration count”,

and the cryptographic salt length .. which are often typical parameters for key creation and encryption.

The advantage is that every user can define this individually for himself. Other applications - even open-source applications - hardly create for the user this choice, to determine these key values for the encryption process itself.

2.2 Application of Block Cipher Modes & Encrypt-then-MAC

GoldBug has not only standardized forward-looking algorithms or numerous details such as the switch from AES-128 to AES-256 or the use of very high, because necessary key sizes, but also implemented the professional integration of established and new encryption processes.

GoldBug uses CBC with CTS to provide confidentiality. The file encryption mechanism supports the Galois / Counter Mode (GCM) algorithm without the authenticity property provided by the algorithm. To provide authenticity, the application uses the methodical approach of “Encrypt-then-MAC” (ETM). MAC stands for Message Authentication Code - and means that the order is determined: first encrypt, then authenticate the message with a code. The documentation for the source code for the section of encrypted and authenticated containers contains further technical details.

Another example of this innovation is the implementation of the ThreeFish hash, which was available as an alternative to SHA-3 when it was realized that SHA-1 was no longer able to cope with future requirements.

Threefish is a block encryption developed as part of the design of the cryptographic hash function Skein, which participated in the NIST selection process for SHA-3. Threefish does not use S-boxes or other lookup tables to complicate time-side attacks (computing time attacks).

Figure: Theefish implementation

Many more examples - especially compared to other messengers - can be found, which prove that the encryption processes in GoldBug are very state-of-the-art.

2.3 Hybrid encryption system

GoldBug implements a hybrid encryption system, including authenticity and confidentiality. Hybrid means first of all: “both variants are available” and can be combined with each other. Thus, a message can first be a-symmetrically encrypted with PKI shown above and then symmetrically with an AES again. Or the other way round, there is also another variant conceivable. The PKI transmission path transmits with permanent keys again only temporarily used keys, with which then the further communication takes place over this temporary channel. The temporary channel can then again transmit a symmetric encryption with an AES.

Thus, not only in the method change from PKI to AES respective from asymmetric encryption to symmetric encryption exists one option to build a hybrid system, but also in the switch from permanent PKI keys to temporarily keys.

Encrypting often and switching between these methods or time-limited keys is a strong competence of GoldBug in this multiple and hybrid encryption. With these possibilities you can now play and apply them in various ways. Is the permanent or the temporary key applied first, or once again the symmetric and then the asymmetrical as the second level of encryption? or vice versa?

Part of the system in GoldBug generates the key for authentication and encryption per message. These two keys are used to authenticate and encapsulate data (that is, the message). The two keys (for authentication and encryption) are then encapsulated across the public-key part of the system. The application also provides a mechanism for distributing session keys for this data encapsulation (or encryption of the message) as described above, the temporary key. Again, the keys are encapsulated and transmitted via the public key system: an additional mechanism allows the distribution of the session keys over the predetermined keys.

As an example, this format may serve the following message encryption:

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

For those who are dealing with encryption for the first time, the above example of encapsulation is a first example to further study and understand the methods; - In any case, you can see how the encryption key is supplemented by the hash key (see MAC) and also the data is embedded in different encryption levels.

Non-NTRU private keys are evaluated for correctness by the gcry_pk_testkey () function. The public key must also meet some basic criteria, such as the inclusion of the public key identifier.

The authentication of the private key and the encryption mechanism is identical to the method as further discussed in the documentation of the source code in the section on the encrypted and authenticated container.

However, let’s take a simpler case and go into more detail about symmetric encryption with an AES password, which can complement PKI encryption as follows:

2.4 Symmetric encryption with AES

Symmetric encryption uses AES - a 32-character password generated by random processes. Since all characters and special characters are used in the generation, the set of options is also sufficiently large that even fast machines can not try out all variants within a short time. While asymmetric encryption uses a public and private key pair, in symmetric encryption it is a secret passphrase that both subscribers need to know (hence called symmetric) (- or for GoldBug: in the later discussed Gemini function it is called “Gemini” (from the Greek term for “twin” derived): Both sides have to exchange and know the secret passphrase).

GoldBug thus uses both standards as described above: asymmetric keys and/or symmetrically encrypted messages are sent by SSL/TLS (i.e. asymmetric) encrypted connections, and the asymmetrically encrypted message can possibly also be secured with symmetric encryption (AES), Then GoldBug even uses three levels of encryption like this example of encapsulation (simplified, as shown without HASH / MAC or signature):

RSA-SSL/TLS (AES (Elgamal (Message)))

Translation of this formula: First, the text message is encrypted with the public (asymmetric) key of the friend via the Elgamal algorithm, then the encrypted text is encrypted again with an AES algorithm (symmetric password) (a second time) (and secured) and this capsule is then sent to the friend through the existing SSL/TLS (using RSA) encrypted (asymmetric) connection.

If an HTTP listener is set up and the encrypted message capsule is not sent via HTTPS - over the third encryption layer, via an SSL/TLS connection - the cipher text of the message capsule can also be viewed in the browser. It turns out that even with two encryption layers only cipher test is sent (see illustration from the practice demo of Adams / Maier 2016).

Figure: ciphertext

It is also possible to exchange the symmetric passphrase (the AES) with the remote station using established asymmetric (SSL/TLS) encryption. The passphrase can be automatically generated or manually defined, as we will see later in the Gemini/Call-function (“Cryptographic Calling”, which was introduced with GoldBug (and the Spot-on Kernel Project)), There are hardly any other - also open source - applications that include an end-to-end (e2e) encryption from one participant to the other participant, in which the user can manually and individually define the passphrase (e.g. an AES string).

A (symmetric) end-to-end encryption is thus to differentiate from the point-to-point encryption. Therefore, the word “continuous” end-to-end encryption is also added (better still: continuous symmetric end-to-end encryption) - because it’s about that only the participant Alice and the participant Bob the secret passphrase know. Point-to-point encryption would be when Alice connects to the server and then the server connects to Bob. This may mean that the server can read the message, so it unpacks and repackages the message, especially if there is an asymmetric key between the participants and the server located in the middle.

Instead, GoldBug offers continuous symmetric end-to-end encryption that can not only be manually defined, but can also be instantaneously renewed with automation (this is called cryptographic calling, see below).

This special way of mixing PKI and AES as well as having a transfer via a SSL/TLS connection in place is referred to as echo protocol, which is to be deepened in the following section, because it still contains one further characteristics when sending to the network: a special feature when unpacking the encrypted capsule. So what exactly is the specific Echo protocol?

3 What is the Echo Protocol?

With the Echo-Protocol is meant - simply put - that

Firstly, every message transmission is encrypted…

Example: SSL (AES (RSA * (message)))

*) instead of RSA you can also use Elgamal or NTRU or McEliece,

… and second, in the echo network, each connection node sends each message to each connected neighbor. Point. That’s how easy the world is. Underlying is the so-called “small-world phenomenon”: Anyone can somehow reach anyone over seven corners in a peer-to-peer or friend-to-friend network - or simply distribute the message over a shared echo-chat server in the circle of friends.

A third criterion for the echo protocol can be added, that is a special feature when unpacking the encrypted capsule: The capsules have neither a receiver nor sender information included - and here they are different from TCP packets. The message is identified by the hash of the unencrypted message as to whether the message should be displayed and readable to the recipient in the UI or not. But for this so-called “echo match” see even more detailed below.

Figure: Format of the used echo protocol

The figure (according to Adams / Maier 2016) shows from inside to outside the process of how the encrypted capsule is formed in the context of the Echo protocol:

First level of encryption: The message is encrypted and the ciphertext of the message is hashed and then the asymmetric key (e.g. the RSA algorithm) can also be used to encrypt the symmetric keys. In an intermediate step, the encrypted text and the hash digest of the message are bundled into a capsule and packed together. It follows the paradigm: Encrypt-then-MAC. To prove to the recipient that the ciphertext has not been corrupted, the hash digest is first formed before the ciphertext is decrypted.

Third level of encryption: Then this capsule can be transmitted via a secure SSL/TLS connection to the communication partner.

Second level of encryption: Optionally, there is also the option of symmetrically encrypting the first-level capsule with an AES-256, which is comparable to a shared, 32-character password. Hybrid encryption is then added to multiple encryption (see Adams / Maier 2016:46).

The “half echo” mode sends a message only one hop, i.e. from Bob to Alice. Alice then stops sending the message (as is the default with the full echo).

Thirdly, in addition to Full Echo and Half Echo, there is the Adaptive Echo (AE). Here, the message is only sent to neighbors or friends, if they know an encryption token, they have previously stored. So if the user does not know the token, the message will not be forwarded to this user.

After all, the echo still knows echo accounts. A kind of firewall. This ensures that only friends who know the account access can connect. So a web-of-trust can be created, which is a network exclusively among friends. It is not based on the encryption key but is independent of it. This means that the user does not have to associate his public key with his IP address or even announce it in the network.

Basically, in the echo, each node sends a message to each connected node: If a user should then receive a message a second time, it is compared in a temporary cache (based on the hash value for that message) and, if applicable, when the hash is known again, the message is discarded and thus not forwarded. This approach is called “congestion control” and balances the number of messages in the network from multiple nodes or servers.

A small analogy: The cryptography of the Echo Protocol can be compared with the giving and taking of so called “surprise eggs”, a capsule with a to assemble mini-toy in the famous chocolate egg. Bob gives Alice a surprise egg, Alice opens it and consumes the chocolate and bumps inside into the plastic capsule of the surprise egg, trying to open it and assemble the pieces into a toy, a smurf. However, she does not succeed in the assembly, the Smurf cannot be formed and therefore she packs the items back into the plastic capsule, pours new chocolate around and passes the egg to the neighbor, who also tries to assemble some of the pieces. Alice does not know who can assemble the surprise egg or the smurf successfully, so she continues to copy it (- what a miracle, Alice has an surprise-egg copying machine -) and gives each of her friends a copy. (Unpacking, crafting, evaluating, packing, giving away and unpacking, crafting, evaluating, wrapping, giving away, and so on ..

From the point of view of the entities represented in the network (kernels), the network would have become an surprise-egg paradise in this analogy, if the crafting processes were not reduced again with Congestion Control. Once known assembling parts are not built a second time together. Alice tinkers many packets until she recognizes a smurf with a red cap, she has received the figure of the Papa Smurf intended for her (or as her message).

In order to exclude time and frequency analyzes in the Internet or echo network, there are other functions in GoldBug which increase encryption or make crypto analysis more difficult:

For example: with the GoldBug application you can also send a kind of “fake” messages (from the simulacra function) and simulated communication messages (“impersonated messages”). On the one hand, encryption is not encryption, but it is pure random characters that are emitted from time to time, and the other is simulated human conversation, which is also based only on scrambled random characters:

Simulacra: This feature sends a “simulated” chat message to the echo network when the checkbox is activated. This “fake” message consists of pure random numbers, making it harder for analysts to distinguish encrypted messages with real and random messages. Simulacrum is a term that is not unknown from both the movie “[Matrix]” (https://en.wikipedia.org/wiki/Matrix_(Film)) and Baudrillard’s philosophy (Neo uses this name for the repository for software in his home and the book ‘‘Simulacres et Simulation’’ by the French media philosopher Jean Baudrillard explores the relationship between reality, symbols and society). Several years after the publication of the Echo Protocol, similar donors to the Tor network have developed software called Matrix Dot Org, which sends encrypted capsules to the network similar to the Echo protocol and also addresses a messaging function; an analysis is pending where the echo over the plagiarism-like architecture offers differences and benefits or offered further open source suggestions.

Impersonator: In addition to random fake messages, the GoldBug program can also simulate a chat as if a real person chats from time to time and sends out replies. Also these messages are filled with pure random data, but they vary - simulated in a real chat conversation. Thus, analysis of messages can be made more difficult if third-party recorders should temporarily store and record all user communication, which may be assumed. But even more: even the absence of meta-data (see data retention) gives no reason to suspect that a message was for the user. Anyone who has been able to successfully unpack a message normally does not send it back to the echo network. A record of metadata could have increased interest in the un-re-submitted messages, assuming that this message could then have been successfully decoded by the user. For this case there is also the option of the SuperEcho:

SuperEcho: This feature also redirects successfully decoded and readable messages back to all friends. Failure to retransmit the message may then no longer indicate to the SuperEcho that the message may have been successfully decoded.

SuperEcho, Simulacra and Impersonation are three options of the GoldBug program, which should make it harder for attackers to understand the messages that are of interest to the user (and apparently others) in the multitude of messages.

Now let’s take a closer look at the individual echo modes:

3.1 Full echo

The “full echo” modus underlies an assumption, as it is also in the so-called “small world phenomenon” given: hopping over a few friends everyone can send a message to each of them. Somehow, everyone knows everyone about a maximum of seven corners. This is also applicable in a peer-to-peer or friend-to-friend network. Therefore, a user can reach anyone if each node sends each message to all other known nodes (see figure).

Alternatively, a user can support this decentralized claim or abbreviate the message paths by installing an own chat server based on the Echo kernel for his friends, so that all encrypted messages can be sent to the participants and the server can serve as an e-mail-postbox or intermediate chat server.

The mapping simulates sending the message from a starting point to all network nodes across all connected network nodes.

Figure: Echo Simulation: Each node sends to each connected node

So basically, in the echo, each node sends each message to each node. This sounds simple: The echo protocol is a very simple protocol, but also has wider implications, that is: There are no routing information within the echo given and even metadata can hardly be recorded from the individual node or even network. The nodes also do not forward the message, the term “forwarding” is incorrect, because each node actively resends the message to the (its) connected friends.

This may result in receiving a message (from multiple connected nodes) multiple times - however, in order to avoid this happening and being efficient, the message hash is cached and the message may be rejected for retransmission if it is identified as a doublet. This is called as already indicated above: “Congestion Control”.

The message is in a capsule, so to speak, similar to a ZIP file. This capsule is created by asymmetric encryption with the public key. Added is the hash of the plaintext message. When a node tries to decode the ciphertext, a new text comes out - which can either be decoded correctly or incorrectly, that is to say, it is human-readable or, if the decoding key was incorrect, random characters became only random characters. This resulting text after the decoding attempt is thus again hashed.

Now, if the hash of the decoded message is identical to the hash of the original message that the sender already attached to the capsule, it is clear that the deciphering node has used the correct key and this message in plain text is for him: hence, the message is readable and displayed in the user interface. This can be called an “echo match”. Unsuccessful decoding attempts, in which the hash value between the original message and the message text of the decoding attempt do not match, are not displayed in the user interface, but remain in the kernel of the program for further transmission to the connected neighbors.

The node must therefore try with all the keys of his friends to unpack the message and compare the hash values. If the hash value is not identical, the node packs the ingredients back together in one capsule and sends it to each of the connected friends, who then try the same.

The hash value of a message is not invertible, therefore the encryption cannot be broken with the (enclosed) hash of the original message, it still requires the correct key.

A message that has been successfully unpacked will no longer be sent, unless the user uses the “Super Echo” option, which also retransmits the successfully unpacked messages. Thus, no one who records the Internet packets can identify messages that are not sent again.

Finally, as described above, it is also possible from time to time to send out false messages (“simulacra fake messages”) and also simulated impersonated messages, so that it is difficult for network traffic collectors to find out the message capsule, which has been of interest for the users own readability. Because it is to be noted that it may be assumed today that all communication data of an Internet user is somewhere stored and recorded on the Internet and in the case of interest also automated and manually evaluated.

Then: This encrypted capsule is again sent over an encrypted SSL/TLS channel that is established between the nodes. This is a decentralized, self-signed p2p connection, a “two-pass mutual authentication protocol”. The implementation is precisely defined according to SSL/TLS, but it can also be switched off: The network nodes thus communicate via HTTPS or even HTTP.

However, of course, the transfer becomes more susceptible if one does not use the multiple encryption. Therefore, one should always establish an HTTPS connection to his friends and send over this encrypted channel his encrypted capsules in which the message waits, to be kissed awake from the right key (using the “echo match” method based on the hash comparison) and to be converted in readable plaintext.

|** Process description of the echo match:**| |—| |Sender A hashed his original text to a hash 123456789, encrypts the text and packs the crypto-text and hash of the original message into the capsule (before he adds an AES and sends it out via a TLS/SSL connection). Recipient 1 converts the received encoded text of the capsule to a (supposed) plain text, but this has the hash 987654321 and is therefore not identical to the supplied original text hash of 123456789. This is repeated with all available keys of all friends of the recipient 1, since all Hash comparisons, however, were unsuccessful, he re-packs the message again and sends it on. The message is obviously not for him or one of his friends. Recipient 2 now also converts the received, encrypted text to a (supposed) plaintext, this has the hash 123456789 and is thus identical to the supplied original text hash of 123456789, the decoding was apparently successful with one of the existing keys of his friends and therefore the message is displayed on the screen of this receiver (and if Super-Echo is selected, also re-packed again and sent-out again).|

No one on the net can see what message a user successfully unpacked, because everything happens on the user’s local machine.

3.2 Half echo

The half echo mode sends the user’s message only one hop to the next node, e.g. from Bob to Alice. Alice then does not send the message down the path of her connected friends (as it is customary for the Full Echo). This Echo mode is technically defined by the connection to another listener: Bob’s Node, when connecting to the node of Alice, notifies that Alice should stop sending the message to her friends. Thus, two friends or nodes can exclude via a direct connection that the message is carried into the wider network via the other, further connections that each node has.

In addition to the Full and Half Echo, there is the third: Adaptive Echo (AE). Here, as it will be described below, the message is sent to connected neighbors or friends only if the node knows a particular cryptographic token - similar to a secret passphrase. Of course, this passphrase must first be defined, shared and stored in the respective nodes. Thus, defined ways of a message in a network configuration can be used. For example, if all nodes in a country use a common Adaptive Echo passphrase, the message will never appear in other nations’ nodes if they do not know the passphrase. Thus, a routing can be defined that is not located within the message, but in the nodes. If you do not know the passphrase, one does not get the message forwarded respective further sent out! Adaptive Echo turns messages that cannot be opened into messages that are not known or even exist.

The section below on the Adaptive Echo (AE) will therefore cover this option in more detail.

3.3 Echo Accounts

And in addition: the echo also knows Echo Accounts. An account is a kind of firewall. It can be used to ensure that only friends connect who know the credentials to the account. Thus, a so-called Web of Trust, a network based on trust, is formed. It is not based on the encryption key like in other applications, it is independent of it. This has the advantage that the encryption public key does not need to be associated with the IP address (as it is the case with RetroShare, for example); or that the user must announce his IP address in the network of friends, for example in a DHT where users can search for it. The echo accounts provide a peer-to-peer-(P2P)-connection to a Friend-to-Friend-(F2F)-network or allow both types of connection. This makes GoldBug suitable for both paradigms.

Figure: Figure: Account Firewall

The echo accounts work as follows:

Binding endpoints are responsible for defining the account information. During the creation process for an account, this can be defined for one-time use (one-time account or one-time use). Account name and also the passphrase for the account require at least 32 bytes of characters. So a long password is required.

After a network connection has been established, the binding endpoint informs the requesting node with a request for authentication. The binding endpoint will drop the connection if the peer has not identified within a fifteen second time window.

After the request for authentication has been received, the peer responds to the binding endpoint. The peer then transmits the following information: HHash Key (Salt / Time) // Salt, where the hash key is a concise summary of the account name and also the account password.

Currently, the SHA-512 hash algorithm is used to generate this hash result. The time variable has a resolution of a few minutes. The peer retains the value for the cryptographic salt.

The binding endpoint receives the information of the peer. Consequently, this then processes HHash Key (Salt // Time) for all accounts he has set up. If the endpoint cannot identify an account, it will wait one minute and perform another search. If an account matching this hash key was found, the binding endpoint creates a message similar to the one the peer created in the previous step and sends the information to the peer. The authenticated information is stored. After a period of about 120 seconds, the information is deleted again.

The peer receives the information of the binding endpoint and performs a similar validation process, this time including the analysis of the cryptographic salt value of the binding endpoint. The two salt values must then be clearly consistent. The peer will drop the connection if the endpoint has not identified itself within a fifteen-second time window.

It should be noted, by the way, that the account system can be further developed by including a key for encryption. The additional key then allows even more precise time windows to be defined.

If SSL/TLS is not available during this negotiation, the protocol may become vulnerable as follows: An intermediate station may record the values from the third step and consequently send to the binding endpoint.

Then, the binding endpoint could also grant access to the account to an unknown connection. The recording device could then grab the response of the binding endpoint, that is, the values of the fourth step, and forward the information to the peer. If the account information or password is then accurately maintained, the peer would then accept the response from this new binding endpoint. That’s why, as always, it’s about protecting passwords.

In GoldBug, therefore, a server account - if it is specified to be dedicated - therefore requires a password equal to the length of an AES-256: this is a passphrase of 32 characters.

Figure: Account Passwords

3.4 The echo grid

When students talk or students be taught or taught themselves about the Echo Protocol, they can simply draw an echo grid with the letters E_C_H_O. The nodes from E1 to O4 are numbered and connect the letters with a connecting line on the ground (see figure).

Figure: The Echo Grid Template

For example, then the connection E1-E2 denotes an IP connection to a neighbor.

If the individual nodes now exchange keys, connections are created that arise as a new level at the level of the IP connections of the P2P / F2F network.

With the architecture underlying in GoldBug not only the cryptographic routing in a kernel program was elaborated, also - as stated above - the term “cryptographic routing” was paradoxically removed from the routing with the echo protocol. It is therefore necessary to speak in more detail of the “cryptographic echo” instead of “cryptographic routing”. One more of them to differentiate the protocols, is the protocol of the “Cryptographic Discovery” which will be discussed below in an extra section.

Echo is thus “beyond” routing: Firstly, the message packets do not contain routing information (addressees) and the nodes also do not use “forwarding” in the original sense, because they simply send everything to all connections. And secondly: Even the cryptographic key that tries to decode the message is not an address (which would even be attached to the message package), but only a polarizing glass: it lets us see texts differently and possibly understand. The echo protocol therefore also uses the term “traveling” rather than the term “routing”. Or just in short: “cryptographic echo”.

From a legal point of view, a different evaluation is then also to be made here, since a node does not forward in the name of an addressee as a middleman, but informs the neighbors independently (see, for example, the forwarding in other routing models such as AntsP2P with its ant algorithm, Mute, AllianceP2P, RetroShare, Onion-Routing or I2P.

As well as spreading a good reputation in the neighborhood, the message also spreads in the echo - otherwise the echoing protocol allows any cryptographic “stuff” to “float” away (by not being decoded or being unreadable).

It is reminiscent of the Star Trek Borg collective paradigm: everyone has access to all the neighbors’ messages (unless half or adaptive echo is used and if the message text can be understood (decoded) at all).

In the echo, the node is more of a “sovereign” or “giving and receiving (non-directional) information”; in other networks, a node could be more referred to as a “postman”, “dealer”, “forwarder” or “intermediary”.

The echo grid as a simple network representation is not only used for the analysis of “routing” (or “travel”-ways) to represent echo modes and encryption stations, but ultimately can also be found in graph theory application: which path takes a message, depending on the structure of the network, and also can be evaluated the use of echo accounts, half or full echo and the Adaptive Echo, as the following examples of the graphs between Alice, Bob, Ed and Maria illustrate.

3.4.1 Examples of key exchanges by Alice, Bob, Ed & Maria

Figure: Alice, Bob, Ed and Mary in the Echo Grid - An example of the echo

The following examples of the figure can be further discussed - they use a few vocabulary and processes of functions of the GoldBug client, so that in the program inexperienced readers can also skip this section and refer back once the basic functions (installation, chat, e-mail, File transfer or URL search) have been explained – so that these technical examples are understood at a later date):

Alice (IP = E1) and Bob (IP = C3) have exchanged their public key and are connected via the following IP neighbors: E1-E3-E5-E6-C3.

Bob (C3) and Maria (O4) are also friends, they’ve also swapped their public keys for encryption: and use their neighbors’ IP connections: C3-C4-H5-H3-H4-H6-O3-O4.

Finally: Maria (O4) is a friend of Ed (H1). They either communicate via the path: O4-O3-H6-H4-H3-H1 or they use the path of: O4-O2-O1-O3-H6-H4-H3-H1. Since, in the echo protocol, every IP neighbor sends every message to every connected IP neighbor, the path that delivers the message fastest will succeed. (The second incoming message is then filtered out by Congestion Control).

Direct IP connections from neighbors such as E1-E3 can be further secured by the creation of a so-called “echo account”: No other IP address than E1 can then connect to the so-called “listener” of the neighbor E3. This method can be used to create a web-of-trust - without relying on keys for encryption - nor does it require a friend as a neighbor to exchange their chat or e-mail key.

So-called “turtle hopping “ becomes much more efficient in the echo network: when Ed and Alice start a file transfer (via the StarBeam function and using a magnetic URI link), the echo protocol transports the packets via the path H1-H3- H5-C4-C3-E6-E5-E3-E1. Maria is not in the route, but she will also receive the packets over the full echo if she knows the StarBeam magnet. The advantage is that the hopping is not done over the keys, but over the IP connections (e.g. the Web of Trust). Basically, everything is always encrypted, so why not take the shortest route on the net?

A so-called “Buzz” or “echo’ed IRC Channel” (therefore also short: e’IRC) space can be created or “hosted” by the nodes O2, for example. Since only the user Ed knows the buzz room name, all other neighbors and friends are left out. Advantage: The user can talk to unknown friends in a room without having exchanged a public e.g. RSA key with them. Instead, a one-time magnet is simply used for this “buzz” / “e’IRC” room.

Maria is a mutual friend of Ed and Bob and she activates the C/O (care of) feature for emails: this allows Ed to send emails to Bob, even though he’s offline, because: Maria saves the e-mails in her instance, until Bob comes online.

Furthermore: Alice created a so-called virtual “e-mail institution”. This is not comparable to a POP3 or IMAP server because the emails are only cached: Ed sends his public email key to Alice - and Ed adds the magnet of Alice’s “E-mail Institution” to the program. Now, emails from Bob and Ed are also cached within Alice (at the email institution), even though Maria should be offline.

It is helpful to follow the examples on the above graphic or to come back to this at the end of the manual after further explanations of the functions.

3.5 Adaptive Echo (AE) and its AE tokens

For the explanation of the “adaptive echo” another echo-grid with the connected letters A and E can be drawn (see following figure).

Figure: Adaptive Echo (AE): The “Hansel and Gretel” Example of the Adaptive Echo

If a user, his or her chat friend, and a configured third node as a chat server insert the same AE token (“Adaptive Echo Token”) into the program, then the chat server will only send the user’s message to his friend, and not to all other connected neighbors (or users), as it would normally be the case in the Full Echo mode.

The AE token consists, like a passphrase, of at least 96 characters. In the case of Adaptive Echo, the information from the sending node of the encrypted capsule is attached - and all other nodes learn that you are only forwarding (sending) the message to nodes or connection partners, who also know this AE token.

With an AE token, no other node that does not know the passphrase will be able to receive or view the user’s message. Thus, potential “recorders” can be excluded, these are possible neighbors, which presumptive record all the message traffic and then try to break the multiple encryption to get to the message core of the capsule.

In order to be able to determine the graph, the travel route, for the adaptive echo, several nodes must agree with each other and note the passphrase on the way path without any gaps. In the case of the adaptive echo it can be spoken of a routing.

3.5.1 Hansel and Gretel - An example of the Adaptive Echo mode

To illustrate the adaptive echo, a classic example is the tale of Hansel and Gretel.

In the AE grid explained above, the characters Hansel, Gretel and the evil witch are drawn as nodes. Now Hansel and Gretel think about how they can communicate with each other without the evil witch noticing this. According to the fairy tale, they are in the woods with the witch and want to find out again of this forest and mark the way with bread crumbs and white pebbles.

These fairy tale contents can now also illustrate the Adaptive Echo in the above grid pattern and show at which points of the grid or the communication graph a cryptographic token called “white pebbles” can be used:

If nodes A2, E5 and E2 use the same AE token, then node E6 will not receive a message that node A2 (Hansel) and node E2 (Gretel) will exchange. Because the node E5 learns about the known token “white pebbles”, it does not send the messages to the node E6, the “Wicked Witch”. It is a learning, adaptive network.

An “adaptive echo” network reveals no target information (compare again above: “Ants Routing”). Because - as a reminder: The mode of “half echo” sends only one hop to the connected neighbor and the “full echo” sends the encrypted message to all connected nodes over an unspecified hop number. While “echo accounts” encourage or hinder other users as a kind of firewall or authorization concept when connecting, “AE tokens” provides graph or path exclusivity - for messages that are sent via connected nodes that know the AE token,

Chat Server Administrators can exchange their tokens with other server administrators if they trust each other (so-called “Ultra-Peering for Trust”) and define a Web of Trust. In network labs or at home with three or four computers, the Adaptive Echo is easy to test and to document the results:

For an adaptive echo test, simply use a network with three or more computers (or “SPOTON_HOME” as the (endless) file in the binary directory to launch and connect multiple program instances on a single machine) and then implement this example flow:

Create a node as a chat server.

Create two nodes as a client.

Connect the two clients to the chat server.

Exchange keys between the clients.

Test the normal communication skills of both clients.

Put an AE token on the server.

Test the normal communication skills of both clients.

Now set the same AE token in a client as well.

Note the result: The server node no longer sends the message to other nodes that do not have or know the AE token.

This example should be easy to replicate.

3.6 Some examples of how the echo protocol works

Taking the various methods and options together, the figure “How the echo log works” will provide a more complex overview.

Illustration: How the echo PROTOCOL works

Shown in the graphics are the different usage examples of “Full Echo”, “Half Echo”, “Adaptive Echo” and “Echo Accounts”.

A distinction is made between physical IP connections and virtual connections to keys. Keys are therefore not necessarily assigned to an IP connection.

Users can exchange asymmetric public keys as well as magnet URIs with symmetric encryption details as well as tokens and account credentials.

Connected nodes can allow and deny connections - as well as send messages addressed (or sent addressed).

Accordingly, different communication scenarios arise.

Examples:

a. User H4 has an AE token. It does not send messages (via connection node H6) to the O-quadrant if HG does not know the token.

b. If H3 sends a message to H4, then H4 will not send this message because it is a “half echo” connection.

c. The user E1 does not let the user connect E2 because he does not know the login for the echo account.

d. User O1 and O4 chat with each other and only know their public key for encryption.

e. User H3 and C5 chat via a URI magnet in the same group chat room (also called buzz or e’IRC).

It turns out that the echo protocol can map a very complex network, although it has a simple structure. With the individual options and terms, users can tap into a lot of network and crypto theory in practice and try it out in practice. An ideal teaching tool, introduction to cryptographic processes, graph theory, and a hands-on user experience in the group. For example, for a team of three, as in the GoldBug story by Edgar Alan Poe.

4 Cryptographic Discovery

Cryptographic Discovery describes the method of an echoing protocol to find nodes in an echo network. The echoing protocol is supplemented with another useful method, if not even more important, than the echo itself. Cryptographic Discovery is available in existing clients such as GoldBug, Spot-on or the chat server for the Android operating system, SmokeStack, implemented within the code base. The source code and its documentation define the method accordingly. For example, Cryptographic Discovery can replace a Distributed Hash Table (DHT) to find a friend on the network. A further publication especially on this topic as an attachment to the source code of the development is in preparation.

If a user sends a message to a regular echo server, it does not know where to send it to andso it sends it to everyone. One of those everyones is the correct one. The correct one will then send the message to the other user. The alternative is to have the peer knowing my peer in a virtual cryptographic software structure. These peers are separate processes. Then the peer of the user could send the message to peer A and peer Z instead of peers: A through Z. Peers would be aware of other peers based on on a cryptographic discovery with cryptographic identities. Complex stuff - but already coded in into the mobile client of GoldBug: Smoke Messenger.

5 Set up a first installation – e.g. with the wizard

The first initial setup of the software is very simple in a few steps,

The user unpacks the program from the Zip and starts (under Windows) the GoldBug.exe from the path to which the program was unpacked, e.g. C: /GoldBug/GoldBug.exe or C: /Programs/GoldBug/GoldBug.exe.

The user interface and a wizard appear, with which settings can be implemented step by step. Alternatively, the user can close the wizard and make the settings manually in the tab for the settings or for kernel activation. It is recommended to use the wizard.

In the wizard, the necessary cryptographic keys are then generated with the user name and a passphrase to be entered twice.

Figure: Initial Wizard

After completing the wizard, the kernel must still be activated. So the GoldBug Messenger has a user interface (also called Interface or Graphical User Interface (GUI)) and a kernel. Both are given as a binary file (in Windows called GoldBug.exe and Spot-On-Kernel.exe). Spot-On is the original project for the Echo application and GoldBug merely provides a simplified user interface.

If the kernel is running, the user connects to a neighbor or server with the appropriate IP in the Neighbors tab.

Then the user exchanges the key with a friend and the encrypted communication via chat or e-mail can begin…

Otherwise, the user must activate the kernel via the “Activate” button in this tab for settings or for kernel activation after each start of GoldBug.exe, which then coordinates the connections to friends or to a chat server. So the kernel file Spot-on-Kernel.exe will be turned on or off from GoldBug’s program.

5.1 Two login methods

If the user starts GoldBug for the first time, the user enters a nickname in the corresponding box and defines a passphrase for the login into the application (see figure, blue widget box).

Figure: Set password

There are two methods to do this: the passphrase method or the question-and-answer method.

The password must be at least 16 characters long. If this is too long, you can repeat a shorter password three times, such as “password_password_password”, but then the password is not as secure as one with a random string.

The two methods can be differentiated as follows:

Passphrase method: When the password is created, it is not stored locally, just the hash of the input. The hash is supplemented by a supplementary string, the so-called cryptological salt. This complements the hash and makes it safer. The “Salted Hash” is thus defined as follows: hash (passphrase + salt). To achieve that the password is also trained for the user and typing errors are excluded, it must be entered a second time.

Question / Answer Method: This method does not enter a password twice but defines a string as a question and a string as the answer. Both strings will not be checked a second time. Technically, this login method is implemented via an HMAC: Hash (Question, Answer), indicates that an “HMAC” (Keyed-Hash Message Authentication Code) is used. And: neither the question nor the answer is stored on the user’s machine and no cryptographic salt is randomly generated by the machine. Instead of the question, the user can of course also enter two passwords without a question mark. It should be noted that here the question and the answer must be entered in subsequent logins exactly as they were defined and here at the first definition no second input check (“confirmation”) regarding typing errors is given as in the password method.

Figure: Login to the application with a password

Since the hash generated from the login passphrase unlocks the encrypted containers that also store the private key for encryption, it is especially important to protect the login process and login password. Therefore, the above two methods have been taken into account to make it more difficult for attackers: they do not know a) which method a user has chosen and b) the question-answer method is safer, as described above, because neither the question, nor the answer can be stored somewhere and a HMAC may be more complex than a password as a “just” salted hash. Only the user knows question and additionally the answer and only the match of both can open the container.

In order not to reveal information to keypad loggers, there is the possibility to use a virtual keyboard when logging in (see image). The user starts this by double-clicking on the input line for the password. At best, only mouse clicks can be recorded here, but no keystrokes.

Figure: Virtual Keyboard

In principle, it is important that the private key is kept encrypted in a sufficiently secured container. It is reasonable to suppose that, in particular, access by providers to mobile operating systems would otherwise make it easy to fetch the private key.

This is especially critical for web mail offers to provide the encryption in the browser or with keys that are deposited at and with the mail provider online. Encryption should always take place on the user’s machine and for this purpose, an open-source client and no online web application in the browser should be used, in which the user should - if necessary - also generate self-generated keys online.

The risk of seizing the possibly insufficiently encrypted private key is far too great. Program audits should also pay attention to capturing passwords for the encrypted container in which the private key is located, as well as to remote accessing the private key.

Even the few open-source messengers with encryption that can be counted on one hand for the desktop as well as for mobile devices that have undergone a security audit are hardly sufficient with regard to the security of the encrypted storage of - and secured access processes to - analyzed private keys.

5.2 Generation of 10 Keys for Encryption

When the user launches the GoldBug Messenger for the first time, the wizard asks if the user wants to generate the encryption keys. For key creation the user should choose a key of at least 3072 bits (default) or larger. The user can also choose other options such as algorithm, hashtype, cipher, salt-length or iteration count, for example, if he re-generates the key. The first setup has a presetting based on RSA ready: So if you want to test out NTUR or McEliece as an algorithm, then after the first setup again generate new keys with one of the then selectable algorithms.

The generated keys are stored in the sub-path “/.spot-on”. If the user wants to set up a new login with new keys and all user data should be deleted, then this path can simply be deleted and the GoldBug.exe has to be restarted. For Linux and the other operating systems their adequate path specifications apply accordingly. The same can be done in the main menu with “!!! Total_Database Erase !!! “.

Asymmetric keys are generated for the following functions (a key for the encryption as well as a key for the (optional) signature):

Chat: This is about the 1: 1 chat

E-Mail: this is about email to other users of GoldBug or Spot-on

POPTASTIC: This is about the chat via e-mail server

URLs: This involves searching for URLs in the URL database (web search)

Rosetta: With the Rosetta encryption pad, text with asymmetric keys can be converted back and forth from plaintext to ciphertext and vice versa before the texts are sent. This is recommended when other insecure messengers or e-mail are used or the ciphertext should be posted anywhere on the web - or the plain text, before it is sent in GoldBug, should again receive an additional encryption level.

That each function uses its own key pair is again a security feature. If the chat key were compromised, the email encryption will not be affected. Furthermore, the user can only pass friends his chat key and not the e-mail key. Thus, the user can decide whom he allows to chat with or just to e-mail or possibly also to exchange URLs for the function of p2p web search in the integrated URL database.

So far the minimal view on the user interface is described: Via the main menu one can choose between “full view” or “minimal view”. If you are not familiar with computers, you should choose the minimal view because it fades out the unnecessary variety of options. Keep it simple! Qt developers, and those who are looking for an exercise project for their own Qt development project, may even minimize the user interface (and are invited to “fork” the GoldBug project).

During the first setup, the option of the maximum view is not available, it will only be shown and set in the other logins. The possibility of looking at even more details in the user interface should therefore be addressed briefly here, since many details also refer to the last-mentioned point of the cryptographic values, which is also contained in the tabulator of the kernel activation and encryption key: Key-Generation is there to be found (just in the setting of the maximum view).

The values can be set individually for a new key generation (without wizard) from the extended user view. However, if you are using the client for the first time, the typical setting values are automatically available, i.e. the key has a (predefined) size of 3072 bits of the RSA algorithm.

In case of a non-minimal view, for example, the tab “Activate Kernel” shows the following elements in the user interface:

Path to kernel: Here the user can enter the path to the kernel. If the kernel with the “spot-on-kernel.exe” in the path specified correctly, then the path is highlighted in green. Otherwise, you have to look at the executable file of the kernel or copy it to the executable file of the GUI (GoldBug.exe) or adjust the path accordingly.

PID: The PID number identifies the process ID that identifies the executable file in Windows. The user also finds the process IDs in the Windows Task Manager.

“Key regeneration” function: With the “re-generation” function, the user can also generate individual keys - with new values and options. For this the check box has to be activated, the values have to be set and the respective keys have to be re-generated. This is the way to get e.g. keys of the McEliece or NTRU algorithm. Then the user has to put his new key back to his friends, because the key is the communication ID.

Another variety of options can also be found under the main menu / options in a pop-up window, which will be explained later. This is the actual options window, which can be neglected for a first start, however.

Figure: Options e.g. for digital signatures

Figure: Options e.g. for the view in the client

It is more important to start now the kernel after the first key generation via the wizard.

5.3 Activation of the kernel

When the user launches the GoldBug Messenger for the first time, a pop-up window at the end of the wizard asks if the kernel should be activated. Otherwise, the red “Activate Kernel” button should be pressed on all subsequent starts after the login in the settings tab, then the user can start: If the button is green, the kernel is running.

When the user closes the program interface, a pop-up window also asks if the kernel should continue running. So it’s a good idea to first deactivate the kernel and then close the GUI of GoldBug if you want to completely close the program.

Otherwise, the user runs the kernel without a GUI, which is sometimes desired on a web server, so that nobody can manipulate within the open user interface. (In addition to the Spot-on kernel, there is also the Spot-on-Lite kernel for this daemon web server purpose, which can be found in the repository of the source code as a standalone repository.)

Figure: Lock of the user interface in the status bar

If the user wants to leave the GUI in place, but no one should be able to enter or change anything during the absence, it is also possible to click the “Lock” button on the left in the lower status line, the user interface will close and return to the login tab for the input of the password back, so that the running processes and inputs of other tabs are not visible. To unlock the interface, press the lock button again in the status bar and the user then enters the passphrase(s) in a pop-up window.

Figure: Activation of the kernel

The user can also enable/disable the kernel by pressing the first LED in the status line at the bottom left. If it is green, the kernel is active; if it is red, the kernel is off. The middle LED indicates whether the user has set up a listener / chat server and the third LED indicates whether the user has an active and successful connection to a neighbor / server.

Figure: Encryption between kernel and GUI / UI

The connection of the user interface (goldbug.exe) to the kernel (spot-on-kernel.exe) is also encrypted, although both run on the same machine. A tooltip on the mouse over the first LED indicates the encryption.

5.4 Connect a neighbor with the IP address

Upon initial activation, the IP address of the Project Chat Server is automatically added as a neighbor. This serves as a temporary chat server through which the user can chat with his friends test-wise until a separate connection node has been created on a web server or at home (or two users connect directly to each other). The test server will not last forever, so far, users will need to first set up a server themselves before they can connect two clients.

Up to now, the user has been connected to a chat server directly after activation of the kernel by the previous test server. If the user would like to add another, the tab “Connect neighbor” must be used. Here is an input field for the IP address of the neighbor respective the web server, on which a Spot-On Kernel is running or a friend also uses a GoldBug Messenger.

Figure: Add a neighbor / server

Figure: Connection to a neighbor server

Figure: Connecting neighbor server

In the field, enter the IP address of the neighbor node. The points are each separated by three digits of the IP address (according to IP-V4). If a block only contains two digits, e.g. 37.100.100.100, then the 37 can be placed arbitrarily in the first block or entered as 37 in the first two positions. Then press the “Connect” or “Add” button. The IP address is then stored on the default port 4710 and appears as a link in the neighbors table.

If an error message appears, then this IP address has already been entered. In order to delete all neighbors, the button “Delete all neighbors” can be pressed (via the context menu button or via the right mouse button in the table in which the neighbor appears) and the IP address can be entered again. Optionally, you can also delete the file “neighbors.db” in the installation path “./spot-on” on the hard disk. It reforms immediately and is then empty.

When the kernel is activated (left, first LED in the status bar is green) and the neighbor or server is connected (middle LED is green) everything is successfully installed and online. Entering an IP address and pressing the connect button should be quite easy.

If the user wants to connect directly to another user without a server, one of them must create a so-called listener in the tab chat server (and release the firewall for the port and, if necessary, forward the port in the router to his machine, see below in more detail).

Or: if both users are on the same Windows network, the existing neighbor “239 ..” can be activated, then the GoldBug Messenger is converted into a Lan messenger and finds all other GoldBug participants in the local LAN automatically and connects them as a neighbor. If the users then exchange the keys, the communication can start.

If you want to see more details, the minimal view can also change to the full view: In this view, it becomes clear that in addition to the IP address, the port of the IP address can also be individually configured. By default, GoldBug uses the port 4710. Furthermore, the program can also be operated via IPv6 as well as to a listener/server, which is linked via the dynamic DNS. Then DNS is no number sequence for the IP, but a domain name to be added in a textfield. Further security options can be defined in the box below or the connection server can also be addressed via a proxy (e.g. if the user wants to use GoldBug via the TOR network).

Figure: Add a neighbor with IP address (detailed view)

6 The chat function

Figure: Chat Tab

Now if login password is defined, key generated, kernel enabled and a neighbor-server connected, so in the status bar two LED lights are green, then the user can exchange his key with a friend and the communication can start in the chat tab (see figure) or in the pop-up windows for a defined participant.

The key exchange can be described as follows:

6.1 Add a friend by swapping and inserting the keys

GoldBug uses a public/private key infrastructure, as it is well-known in the case of encryption: The public key can be exchanged with friends and the private key remains on the user’s hard disk in a re-encrypted container that is opened (mounted) by the login password – and used for the application runtime.

The user and his partner, both friends, must first exchange their public key, i.e. copy it out, and then insert the friend’s key in their own tab: Add Friend/Key and confirm (see figure). The friend can send his key via e-mail or another messenger. The user then copies the key into this tab and presses the “Add” button at the bottom.

Figure: Add Friend/Key

The user also finds his own public key in the tab “Add Friend/Key”. The large button (“Copy Key”) above allows the user to copy all his (or selected feature) keys to the clipboard. The user copies the full text here and sends it to his friend. Likewise, the friend does the same and the user inserts the friend’s key in the text box.

’’ ‘Optionally only as a note:’ ‘’ It may be necessary to confirm a new friend as friend with the right mouse button in the context menu (make-friend function). This is used when a friend sends his key online to the user in a direct IP connection. This feature is provided in the Spot-on interface, but in the GoldBug interface, this is not available so ideally both will always simply copy, email and paste the key for each other. But if a friend uses e.g. the spot-on client with the local user interface and builds a direct IP connection to a user of the GoldBug client, then it is also possible to transfer the key via a direct IP connection instead of copy/paste. Then, the friend appears with his nick name in the tab chat or e-mail (with a different icon) and can be confirmed as a friend with the right mouse button from the context menu.

This is a further development of the Repleo, i.e. the function of encrypting your own key with the friend’s public key (upon receipt) before the return transmission starts. The key exchange is thus automated: a synchronization process follows. The user must agree that the key will be displayed after synchronization via the neighbor connection in their own client respective their own friend list.

’’ ‘Other option - only as a note:’ ‘’ In addition to sending the key online via the direct IP-connection to a friend, the echo public key sharing (EPKS) tool described below can also be used. This is used if the friend is not connected to a direct connection (e.g. both partners use a shared chat server or a node is in the middle). Both partners then enter a common password secret in EPKS and send their public keys to the echo network via this password. See the more detailed information in the section of this tool, which may be a good alternative to the often uncomfortable and insecure usual key servers. This innovation by Repleo and the synchronization of the keys via the so-called Echo Public Key Share function (EPKS) or via a existing IP-connection has later also been taken up (copied) by other projects under the name AutoCrypt or KeySync. These functions are therefore based on the Repleo, EPKS and the key exchange via IP-connection of echo nodes.

6.1.1 Special feature: Repleo

If the user has already received a key from his friend (e.g. the chat key) and inserted it into his client, but now does not want to disclose his own public (chat) key to the public, does not want to transfer and store it in an e-mail program (although the public key may actually be public), then the user can also encrypt his own public key with the received key of his friend. This is called REPLEO. Hence, the key is transmitted encrypted, as soon as a user has already received a public key of the other party.

This process then has to be carried out for each function or key, i.e. the user can in each case send back the chat repleo, the email repleo and the URL repleo. The friend can also insert a Repleo in the box of the “Add Friend/Key” tab. Above the Insert box, just define the Radio Select button, whether it’s a Key, a Repleo, or an email address you’d like to add. Meanwhile, the K and R radio buttons in GoldBug have disappeared because the client automatically detects if it’s a Key or a Repleo.

The text of a key always starts with a letter “K” or “k” and a Repleo starts with an “R” or “r”. You can still recognize it.

6.2 Start a first secure chat

The user finds his chat friend in the tab “Chat” after a successful key exchange. For the chat to work, both parties should ideally use the same and most up-to-date version of the program, generate and exchange their keys, and connect to a network node or chat server (neighbor) on the web. When the first two LEDs in the status line below light green and the friend’s name appears in the chat tab, it looks good.

If the friend’s online status turns blue (absent), red (busy), or green (ready to talk), the chat can start. Either the user marks the friend in the table and chats out of the tab, or he double-clicks on the friend and a pop-up chat window opens for that friend.

The advantage of chatting in the chat tab is that you can mark multiple friends so that the message reaches all friends. If the user uses the pop-up chat (see picture), then the user no longer needs to look at the marker to select their friend from the friends list in the chat tab.

Figure: 1:1 chat in the pop-up window

And: In pop-up chat, the user has the options button “Share StarBeam”, with which he can select a file from the hard drive, so that it is then encrypted and securely transferred to the friend (see also the section below about StarBeam-FileSharing). This feature, which allows a chat friend to simply send a file by mouse-click and is fully encrypted for end-to-end transport, is not included in many applications. Encrypted transmission e.g. of a ZIP with vacation pictures to own siblings becomes thus quite simple and is possible without the use of a hosting platform in the Web.

In the status line at the top of the pop-up window, the user can see the nickname and online status and, for example, launch the Socialist Millionaire Protocol (SMP) to authenticate a friend and test whether he knows a common secret and enters it correctly, as it will be described below. Both users will be authentic if they enter the same password with SMP.

Figure: Chat in the pop-up window

6.3 Additional security feature: MELODICA: Calling with a Gemini

MELODICA stands for “Multi-Encrypted LOng DIstance Calling” – that means: “Multiple-Encrypted Calls over a Long Distance”

The MELODICA symbol is therefore also a keyboard of a musical instrument.

Picture: MELODICA symbol

The MELODICA button performs the calling function. The Cryptographic Calling has been developed by the Spot-On kernel project and secures the connection via an immediately renewed end-to-end encryption by transmitting the password via the symmetrical connection of the echo protocol. Cryptographic Calling with the MELODICA button means calling a friend like with a phone - only that it creates a secure end-to-end encryption.

The end-to-end passphrase - also known as Gemini - is mapped through an AES string and should be kept secret between both parties. Therefore, it is important to secure the electronic transmission always very secure with further encryption levels (as here in the echo protocol with the asymmetric chat key and the TLS/SSL connection), if the transmission can potentially be eavesdropped.

6.3.1 Asymmetric Calling

GoldBug has solved this end-to-end password transfer question by encrypting the Gemini (to be formed string for symmetric encryption) asymmetrically (using the key for chat) and then encrypting again (asymmetric) the SSL/TLS channel, over which it is transmitted.

Gemini is the Greek term for Twin, meaning it refers to both participants who should then know the passphrase.

This function thus generates a “call”, a call in which the password is transmitted, which then later forms the end-to-end encryption. Strictly speaking, the Gemini consists of two keys or components, because the Gemini is authenticated by another process: This further component is also called MAC-Hash, as explained above.

The “Cryptographic Calling” as an executable protocol with the MELODICA button thus extends the previous paradigm of Forward Secrecy as follows:

6.3.2 Instant Perfect Forward Secrecy (IPFS)

The user can thus renew the (symmetric) encryption or the Gemini at any time. This means that the paradigm of “perfect forward secrecy” has been extended by two components: on the one hand, one can manually or automatically define the end-to-end passphrase (the Gemini) and, on the other hand, renew it immediately, i.e. “instant” at any time. Therefore, we speak of “Instant Perfect Forward Secrecy” (IPFS).

By comparison, many other applications offer only one key per online session and you cannot manually and individually edit the symmetric end-to-end encryption phrase.

The Instant Perfect Forward Secrecy (IPFS) discussed here uses asymmetric encryption (of the chat key), whereby the temporary key is a symmetric key (just the Gemini, an AES string).

6.3.3 Symmetric Calling

Another option is GoldBug’s innovative ability to send a new Gemini through the channel of an existing Gemini. Here, the end-to-end key (that is, the symmetrically-encrypting Gemini) is sent through another end-to-end Gemini connection (i.e., the new symmetric key is communicated through a channel of an existing symmetric key). The symmetric encryption phrase (the Gemini or the AES password) is therefore not encrypted with asymmetric encryption (the chat key) (e.g. with RSA, Elgamal, McEliece or NTRU) and then sent over a secure channel (SSL/TLS) from point-to-point, but it is itself encrypted with the existing (symmetric) Gemini and then sent by the described method (again via SSL/TLS).

The double-rachet method, in which the key of the following message is in the encrypted content of the previous packet, may have been ajar or derived from symmetric calling.

Thus, asymmetrical calls and symmetric calls can be fundamentally differentiated. Symmetric calls use an existing Gemini. Asymmetric calls send the Gemini over the asymmetrically encrypted connection (namely the permanent chat key) to the friend. Even when calling over an existing Gemini, the sent Gemini can be instantaneously renewed at any time.

In sum: Secure end-to-end multi-encryption arises when a messenger encodes a manually-defined symmetric key with an existing symmetric key and then encrypts it with an asymmetric key. And then this package is sent through a secure connection.

6.3.4 Two Way Calling

Finally, in the context menu (right mouse click on a friend in the friend list), a third method for a so-called “Cryptographic Call” is added: Two-way calling. Here, the user sends an AES-256 as a passphrase for the future end-to-end encryption to the friend, and the friend also sends an AES-256 to the first user in response. Now the first half of the AES of the first user and the second half of the AES of the second user are taken, respectively, and assembled into a common AES-256. This names the method of 2-way safety. This ensures that no third party - if someone succeeds in compromising his friend’s machine - sends a Gemini (or an old Gemini) in his name from a third, foreign machine (which is not really possible, since it would mean the unnoticed acquisition of a machine or breaking the existing TLS and RSA (or NTRU or Elgamal) encryption). The two participant’s ping-pong game in two-way calling ensures that both participants are currently doing their part to agree on a secure end-to-end password - Fifty-Fifty.

Figure: 2-Way Calling in the context menu from the friends list

The possibility of the password

first, to be edited manually,

secondly, to be able to renew every second - or within each call

third, to send the password through an existing end-to-end encryption,

and finally, being able to generate the end-to-end password in a two-way process makes it very difficult for attackers to break the end-to-end encryption of the GoldBug Calling feature.

“Perfect Forward Secrecy” (PFS) has become not only “Instant Perfect Forward Secrey” (IPFS), but (in this feature) even a “2-Way Instant Perfect Forward Secrecy”: 2WIPFS. This feature has significantly advanced FS and PFS and the important element of end-to-end encryption with this process implementation. The encryption itself is not new, but only the process is sophisticated implemented to provide more security.

End-to-end encryption in the GoldBug is as simple as making a phone call simply by pressing a button: just pick up or hang up the phone. At any time, the communication remains asymmetrically encrypted and the symmetric end-to-end encryption can be easily added - and also renewed by asymmetric or symmetric encryption (within an SSL channel). This is a new architectural implementation standard established by this method of Crypto-Calling.

6.4 Additional security feature: Socialist Millionaire Protocol

While GoldBug encrypts the messages three times -

on the one hand the message is indeed sent in a secure TLS/SSL channel,

secondly, every message is encrypted asymmetrically (e.g. with RSA, NTRU, McEliece or Elgamal, i.e. with the chat key),

and third, yes, it is possible to use the “Call” function to send a Gemini to set a symmetric end-to-end encryption passphrase (as seen with different methods to perform the “calling”). E.g. within an existing symmetric encryption or via the two-way call function, where each defines half of the end-to-end password),

Fourth, there is an additional security enhancement mechanism: it is the “SMP” protocol: Socialist Millionaire Protocol (a method also described here for off-the-record messaging (OTR): https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html).

The idea behind this is to ask a friend a question like: “What is the name of the city we visited together last year?”, Or to ask a question like: “What is the name of the restaurant, in which we met for the first time?” etc. (see figure).

Figure: SMP protocol

Both participants usually sign the messages with a RSA (or other) algorithm to verify that the key used is from the original sender. But for the (possibly unlikely) case that a machine would be hacked, or if the encryption algorithm were broken, the Socialist Millionaire Protocol (SMP) process can simply identify a friend by entering the same password on both sides. It is important to ensure that the password is not to be sent through the chat, instead you should describe a situation that leads to the same password. If the SMP process is tested for the first time, you can also enter the password “test” on both sides (in lower case).

It is practically applied as follows: The user opens a personal pop-up chat window to use SMP and clicks the question mark icon next to the user name of the chat friend. Then a password is defined with the menu. Then the chat friend is asked to enter the same password. Third, the first user then finally clicks on the Verify button.

If both participants have set the same password - or the same hash value has been generated by the same password - then the question mark icon changes to a “lock” symbol. The chat friend has now been authenticated and the chat remains safe.

SMP is thus another ideal way to authenticate the chat friend with a shared secret in the live process, so it is not additional encryption!

An example illustrates the calculation process of this protocol as follows. Let’s assume in an example that Alice begins the exchange:

’’ ‘Alice’ ‘’ Records the random exponents a2 and a3 Send Bob g2a = g1a2 and g3a = g1a3

’'’Bob:’’’ Takes the random exponents b2 and b3 Calculates g2b = g1b2 and g3b = g1b3 Calculates g2 = g2ab2 and g3 = g3ab3 Records the random exponent r Calculates Pb = g3r and Qb = g1r g2y Sends Alice g2b, g3b, Pb and Qb

’’ ‘Alice’ ‘’ Calculates g2 = g2ba2 and g3 = g3ba3 Records the random exponent s Calculates Pa = g3s and Qa = g1s g2x Calculates Ra = (Qa / Qb) a3 Send Bob Pa, Qa and Ra

’'’Bob:’’’ Calculates Rb = (Qa / Qb) b3 Calculates Rab = Rab3 Checks if Rab == (Pa / Pb) Send Alice Rb

’’ ‘Alice’ ‘’ Calculates Rab = Rba3 Checks if Rab == (Pa / Pb)

If everything is done correctly, then Rab should get the value of (Pa / Pb) times (g2a3b3) (x - y), which means that the test at the end of the log will succeed only if x == y. Further, no further information is revealed than that g2a3b3 is a random number that is not known to any page if x is not equal to y! (See also the formulas in the documentation of the source code).

GoldBug describes a so-called “zero-knowledge proofs” during SMP’s various data exchange processes. GoldBug also uses the SHA-512 of the entered secret passphrase as the x and y components.

Figure: Socialist Millionaire Protocol (SMP) in chat window to authenticate the chat partner

SMP therefore requires sharing a common secret with its communication partner. If the SMP password is present, it can also be used as a basis for other functions. The secret streams function relevant for forward secrecy (see also explained at the e-mail function below) can be derived from this.

Figure: Implementation of secret streams in the extended SMP protocol

The Secret Streams are further explained in the section under E-Mail, we are here in the chat section first in the function of crypto calling, which can also build on the successfully verified SMP password. This is described by SMP-Crypto-Calling.

6.4.1 SMP-Calling

Above, we explained the call function of how to generate and transfer a Gemini. A User can not only define the Gemini manually or through the AES function, but it can also be derived from the password stored in the SMP process as outlined above. Thus, the password input from the SMP process is used (not the SMP process itself). It is another way of “crypto calling” and thus securely transmits to its counterpart an end-to-end password that does not originate from an AES generator this time! - if someone doubts the randomness of a machine number generator. Once the basic functions of encryption in GoldBug are clear, you can see, for example, the interconnectedness of the individual processes in the architecture.

6.5 Additional security feature: Forward Secrecy (asymmetric)

Since version 2.7, GoldBug Messenger has also been supporting Perfect Forward Secrecy for its role as an e-mail client, making it the first e-mail client to offer Forward Secrecy for e-mail, with both symmetrically and asymmetrically Forward Secrecy (see also further down).

While crypto calling with a Gemini for the chat function has the “instant perfect forward secrecy” and refers to a symmetric key (just the Gemini or the AES string), the perfect forward secrecy is in the email with temporary, a-symmetric keys defined.

This variant of the use of temporary asymmetric keys can of course also be transferred to the chat function. And this has just been done since the release 2.7.

While chat with the permanent chat key is always (asymmetrically) encrypted, a temporary asymmetric key is now used with this new layer of end-to-end encryption. This temporary asymmetric key is called an ephemeral key. This key is created by the forward secrecy function in the chat, which is displayed via the context menu (right mouse click) or via the menu button.

A tooltip on the screen (in the systray) indicates when the chat partner in chat has created a forward secrecy with temporary (ep