Abschlussarbeit. Zur Erlangung des akademischen Grades. Bachelor of Science. an der

Transcription

1 Kryptanalytische Software- und Sourcecodeanalyse eines Bitmessage Open-Source Clients zum vertraulichen Austausch von Nachrichten sowie Ausblick auf die Verwendbarkeit von Bitmessage im Alltag Abschlussarbeit Zur Erlangung des akademischen Grades Bachelor of Science an der HOCHSCHULE FÜR TECHNIK UND WIRTSCHAFT BERLIN FACHBEREICH V WIRTSCHAFTSWISSENSCHAFTEN II Internationale Medieninformatik 1. Prüferin: Prof. Dr. Debora Weber-Wulff 2. Prüfer: Herr Ulrich Eridy Lukau Matrikel-Nr July 21, 2014

2 C est lui qui cherche, trouve Danke Papa für deine stets sachliche und intellektuelle akademische Art sowie für dein Interesse und deine Geduld für all die Dinge die ich so tue. Dort wo dein Weg damals aufhörte, hat meiner begonnen. Alles was ich erreiche erreichst du mit mir. Ich widme dir diese Arbeit. Aber die nächste Arbeit kommt noch. Danke Mama! Merci beaucoup pour tout! Je t embrasse! Dieu te protege! C est pour toi aussi! Und danke Juju und Sabina! Danke Tosh! Danke Hasi und Max! Danke Strolchenbande! Danke Pfalz! Danke Maike! Danke Ingo! Danke Phil Wayne Wenneck, auf Murphys Law und die immer währenden Züge!!

3 Erklärung zur Sprache dieser Abschlussarbeit In Absprache mit meiner Betreuerin, habe ich mich dazu entschlossen diese Abschlussarbeit zwar in englischer Sprache, jedoch getreu der Aufgabenstellung durchzuführen. Daher ist die Aufgabenstellung auf dem der Titel zwar auf deutsch, der Inhalt jedoch auf englisch, man möge mir dies hoffentlich verzeihen. Vielen Dank 4

4 Contents 1 Introduction About Bitmessage About this Thesis Structure of this Thesis Bitmessage Cryptographic Blocks Symmetric-Key Cryptography Block-Ciphers and Stream-Ciphers Cipher-Block-Chaining Initialization-Vector Bitmessage Encryption AES-256-CBC Introduction of the AES Successful Attacks on AES Public-Key Cryptography Diffie-Hellman Key-Exchange Discrete Logarithm Problem (DLP) Koblitz Curve secp256k Message Authentification MAC / HMAC/ECDSA Cryptographic Hash Functions Secure Hash Algorithm RIPEMD The Bitmessage Protocol Bitmessage Integrated Encryption Elliptic Curve Integrated Encryption Scheme Ephemeral Diffie-Hellman Key-Exchange Bitmessage-Workflow Message Setup

5 Contents Contents Message-propagation and processing The Bitmessage Address Base58 encoding Assembling a Bitmessage-Address Decoding a Bitmessage-Address Bitcoin-Address vs Bitmessage-Address Source Code Analysis Important Classes Pyelliptic Cryptographical Backbone Secure Hash Interface hashlib.py Python Code Quality Cryptographic Code Quality CCS Checklist Further Issues Disclosure Prospects on Applicability

6 1 Introduction 7

7 1Introduction 1.1AboutBitmessage 1.1 About Bitmessage Bitmessage is an anonymous and encrypted message delivery and authentification system based on an internet peer-to-peer network. It is an Open Source project and was developed and published under MIT licence 1 by Jonathan Warren in November, The name Bitmessage is an alteration of the name Bitcoin 2, from which Warren openly adopted most of the implemented ideas and principles as a basis for his own message system. The source code analysis will show up some of the similarities and differences between the two. Bitmessage is based on an underlying cryptographic network communications protocol, which is responsible for the encryption-keys, the encryption itself and the anonymisation of every Bitmessage user. To communicate via Bitmessage a user needs to install the latest Bitmessage client called PyBitmessage 3, which is implemented in Python. As soon as a user installs and starts Bitmessage, the client connects to other Bitmessage clients around the world and represents a node (or in other words a peer ) that is connected to a worldwide peer-to-peer network. Every user has the possibility to use one or more Bitmessage addresses, that are comparable to addresses and can be used to communicate with other users. The messages are propagated through the whole network, meaning that every peer in the network gets every message. To send a message to another person, the message is passed from peer to peer until it reaches the recipient. This sort of propagating relies on the defined behavior of every peer. Each peer repeatedly downloads messages from a neighbor peer. Stored objects are again downloaded from other peers and so on, until the receiver downloads the message from another peer he is connected to. It is a trustless network, which means that the authentification is done without a central authority. Even though every peer gets every message, only the receiver will be able to read the message, since they are always encrypted. Furthermore, the encryption does not only cover the message body, but also the subject, which is a huge advantage over encrypted s, where it is not possible to encrypt the subject, nor the sender, 1 The MIT License (MIT) 2 More informations on Bitcoin: 3 In further analysis the client and protocol will be called Bitmessage even if the clients real name is PyBitmessage to keep things simple 8

8 1 Introduction 1.2 About this Thesis nor the receiver. The message does not have the address attached to it. It is rather bound by encryption. Wheneverapeergetsanewmessage,itautomaticallychecks whether the message is bound for him and tries to decrypt it with a decryption-key but only the targeted receiver has the correct key that enables him to decrypt the message. However, in order to keep anonymity, no peer alters or stops a message. Regardless whether a peer is successful decrypting or not, the message is still available for download for other peers. To notify the sender that the message has arrived, the recipient responds with a message, containing ackdata as acknowledgement to the sender. Data packages that float through the Bitmessage network are named objects. A sender or creator of an object is also anonymous in the network. By simply downloading objects from a connected neighbor peer the downloading peer cannot tell, whether the neighbor he downloaded the object from is the creator of object or not. Bitmessage can also be used to broadcast messages to several peers or to be setup as a mailinglist. It can also be installed on a server and act as an API About this Thesis This thesis will try to identify and explain every in Bitmessage applied cryptographic concept as well as its implementation in Python, by analysing and reviewing the source code. A reader of this thesis will gain a deep insight and knowledge of cryptographic primitives, functions, classes and schemes implemented in Bitmessage, along with the information how and why they are used. Some of them will be explained with examples, in a for cryptographic literature usual way. Additionally it will show parts of the source code as result of the analysis in order to build up coherences, if the particular source code implementation is ostensive and understandable enough. The reader will also be informed about eventually existing bugs and vulnerabilities of used cryptographic algorithms that could be dangerous for Bitmessage. However, finding bugs in an unknown code is hard, especially in the case of cryptographic opensource software. Hence, not mentioning or not finding any bugs does not mean that 4 For more informations on Bitmessage based use cases, services and other interesting Bitmessage projects see 9

9 1 Introduction 1.2 About this Thesis the software is secure. There could still be an exploit or an other vulnerability in the source code that could cause several hearts bleeding. Thus, Bitmessage needs more than this thesis to find them. At the moment of writing this document, it is the only detailed software analysis that contains more information about the implementation than the official Bitmessage wiki or the official GitHub. Subject to the thesis PyBitmessage PyBitmessage (beta) Latest Version: Main Developer: Jonathan Warren Date: January 25, 2014 Subject to this thesis is the PyBitmessage client version PyBitmessage is still beta. The source-code is available on GitHub 5. The compiled versions for Windows Mac and Linux can be found on the official Bitmessage Wiki Structure of this Thesis Seen the protocol as one big construct, it will be divided into several protocol building blocks so that each block can be analyzed alone. On a next step the whole scheme will be explained and analyzed using simple examples. The Analysis will end with the Source-Code analysis. This will be a structured process in order to sum up all possible vulnerabilities. The disclosure is the last chapter with a brief outlook on Bitmessages Applicability. 5 GitHub repository: 6 Bitmessage wiki: 10

10 2 Bitmessage Cryptographic Blocks 11

11 2 Bitmessage Cryptographic Blocks 2.1 Symmetric-Key Cryptography 2.1 Symmetric-Key Cryptography In order to encrypt and decrypt the written message along with the subject, Bitmessage usessymmetric-key Cryptography. These symmetric-key algorithms only need one identical key for encryption and decryption (see Figure 1.2). As explained by Bruce Schneier in the Book Applied Cryptography [35], the encryption key can be calculated from the decryption key and vice-versa. The symmetry relies on the reversible calculation of the key based on one single secret. This secret-key needs to remain hidden and is never communicated in plaintext. As soon as sender or receiver publishes the encryption or decryption key, the communication is no longer secure. Apossibleattackercouldrecreatethekeyandsabotagethecommunication. Example(Alice and Bob communicating on a symmetric cryptosystem ([35]) We asume that Alice and Bob agree on Bitmessage as encryption and communications system Alice and Bob agree on an identical key. Alice takes her plaintext message and encrypts it using the encryption algorithm and the key. This creates a ciphertext message. Alice sends the ciphertext message over Bitmessage to Bob. Bob decrypts the ciphertext message using the identical key and reads it. Symmetric-key algorithms are also known as: single-key algorithms, one-key algorithms, private-key algorithms or secret-key algorithms [35, 18]. Most symmetric cryptosystems choose one unique key for encryption and decryption which requires to be kept secret before and after communication, as long as the communication needs to be secret [35]. Sender and receiver have to agree on a key before the communication starts. The key-agreements must be secure, without giving an attacker the possibility to obtain any key-secrets. To overcome this challenge of Key Distribution ( Menezes et al. in Handbook of Applied Cryptography [18] ), Bitmessage draws successfully on Diffie- 12

12 2 Bitmessage Cryptographic Blocks 2.1 Symmetric-Key Cryptography key1 key1 Encryption Decryption Plaintext Cyphertext Original Plaintext Figure 2.1: Single-key Encryption/Decryption Hellman Key-Exchange. Sincesenderandreceivercannotmeetphysically,asecure method is mandatory. Due to the characteristics of Bitmessage as a serverless protocol, massive amounts of keys are managed by each and every peer and transported from point to point or, regarding the architecture of Bitmessage, from peer to peer. ReferringtoSchneier [35], since every pair of Bitmessage users communicating with each other requires a distinct key to exchange encrypted messages, the protocol needs to withstand the transportation of approximately n(n 1)/2 keys, where n is the number of users Block-Ciphers and Stream-Ciphers The symmetric encryption can be implemented in two different ways: Block-Ciphers and Stream-Ciphers [36, Ch. 9.3]. According to Schneier, stream-cipher algorithms operate on streams of single bits, seperately converting each plaintext bit into a ciphertext bit [36, Ch. 9.3]. Block-cipher algorithms do not map single plaintext bits to ciphertext bits unlike stream-ciphers. As described by Paul van Oorshot et al. in the Book: Handbook of Applied Cryptography [19, P.224], they rather combine single bits to fixed-sized n-bit plaintext blocks and transform them to n-bit ciphertext blocks [19, P. 224]. The size n is called the blocklength of one single block. Jonathan Warren identifies the encryption-scheme used by Bitmessage as encryption based on the Advanced Encryption Standard AES in cipher-block chaining mode [46]. The key used by Bitmessage for this symmetric encryption function is a k-bit key with k =256[46]. Therefore, plaintext-messages are subdivided into particular blocks in a first step and separately transformed into ciphertext-blocks using the 13

13 2 Bitmessage Cryptographic Blocks 2.1 Symmetric-Key Cryptography chosen cipher in following steps. The blocksize used by Bitmessage for block-cipher encryption is 16 byte. This is defined as macro in the OpenSSL-Highlevelclass openssl/aes.h 1 #aes. h 2 #define AES_BLOCK_SIZE 16 Listing 2.1: Blocksize definition used by PyBitmessage[caption The implemented symmetric encryption-scheme AES-256-CBC [46] identifies Bitmessage as a Block-Cipher. However, as elaborated by Menezes et al. [19, P.192], it could also be named a stream-cipher, usingamandatoryinitialization-vector[19, P.192] to operate on streams of large blocks. But when considering the specifications of AES-256-CBC as defined in the official Federal Information Processing Standard 81 (FIPS-81) [24], it must technically still be seen as Block Cipher Cipher-Block-Chaining Cipher-block-chaining was published as one of several recommended cipher block modes of operation by the National Institute of Standards and Technology (NIST) in 2001 on the Federal Information Processing Standard 81 FIPS-81. [21]. The recommended operation modes named by the FIPS-81 only covers FIPS-approved symmetric key block cipher algorithms... as underlying algorithm [21, p.7]. Since AES is FIPS-approved [24], Bitmessage strictly follows open standards of cryptography. Blocks are processed in a chain-sequence in such a way that each block depends on the preceding block. Each preceding block is the input vector for the next calculation of the following cyphertext-block [36, Ch 9]. Therefore, the CBC-algorithm needs to remember the preceding result by using the vector as small amount of memory in order to calculate the next following block [19, P.230]. (See Figure 1.3) Applying Cipher-Block-Chaining on a plaintext-message, the message M is subdivided into M = m 0,m 1,m 2,...,m n 1,m n blocks, with each block the size of b. The input v of the function on each block m is calculated with v = m n c n 1. This applies 14

14 2 Bitmessage Cryptographic Blocks 2.1 Symmetric-Key Cryptography to all blocks m with exception to the first block m 0, which uses the Initialization- Vector (IV) as input, and v = m 0 IV is the initial calculation for the first encryption round. The resulting cyphertext-blocks c 0...n are then concatenated to the cyphertextmessage C, sothatc = c 0,c 1,c 2,...,c n 1,c n. Each cyphertext-block has the same blocklength b as the original plaintext-block. m 0 m 1 m 2 m n-1 IV Key 1 AES Key 1 AES Key 1 AES Key 1 AES C 0 C 1 C 2 C n-1 C n Figure 2.2: Cipher Block Chaining Initialization-Vector The added Initialization-Vector or initial chaining value [36, Ch. 9.3] makes the encryption-scheme dependant on on the used key along with the used initializationvector. Plaintexts are only converted to the according ciphertext and vice-versa if the identical Initialization Vector as well as the same secret-key are used for encryption and decryption. Using a different initialization-vector results in a wrong ciphertext. Hence, it must be delivered together with the encrypted message. According to Bruce Schneier [36, Ch. 9] the Initialization-Vector can be a random dummy of data. Thus, securing the initial vector after encryption is not mandatory because it does not affect the security of the protocol as long as it is unpredictable as mentioned in several Crypto-Blogs like Defuse Computer Security [31]. Schneier explains that since the initial-vector is used once and the following vectors are results of a preceding block-ciphertext, every vector will be exposed during encryption even if the initial vector is still secret [36, Ch. 9]. However, there are still open discussions throughout the crypto-community about wether the IV should be secure even if it is 15

15 2 Bitmessage Cryptographic Blocks 2.1 Symmetric-Key Cryptography not required. Nevertheless, a new Initialization-Vector has to be created randomly for each messageencryption in order to ensure that encryption using the same secret key is always randomized. The randomization ensures that encrypted messages are unique [36, Ch. 9]. Furthermore, two identical plaintexts do not encrypt to the same ciphertext if the identical cypher is used [36, Ch. 9] several times. Reusing the same or non-random initialization-vector for each message makes the system vulnerable to dictionary attacks, as stated by the Common Weakness Enumeration CWE-329 [14]. Initialization Vectors on Bitmessage The IV used by Bitmessage for each message relies on 16 secure randomly generated bytes [46] which are not encrypted. Therefore each message sent via Bitmessage uses a new randomly generated initial vector with b = 16 bytes which are normally prefixed to the encrypted ciphertext. The function raw_encrypt() in pyelliptic/ecc.py contains the call OpenSSL.rand(). Itisusedeverytime when a message needs to be encrypted. 1 class ECC: 2 #... 3 def raw_encrypt(data,... ) 4 #... 5 iv = OpenSSL.rand(OpenSSL. get_cipher(ciphername). get_blocksize ()) 6 #... Thus, generating a random intitial value [46]. 1 bd db 7c b a2 f Listing 2.2: Generating the IV with the OpenSSL random function The previously used example of Alice and Bob communicating via Bitmessage now needs to be extended regarding AES-256-CBC as a main protocol building encryption block. Hence, both of them have to include the identical Initialization-Vector. Example(Alice and Bob communicating via Bitmessage AES-256-CBC) 16

16 2 Bitmessage Cryptographic Blocks 2.1 Symmetric-Key Cryptography Alice and Bob agree on Bitmessage as encryption and communications system. Alice and Bob agree on an identical key for encryption and decryption. Alice and Bob agree on an identical IV regarding AES-256-CBC for symmetric encryption and decryption. Alice takes her plaintext message and encrypts it using the encryption algorithm. This creates a ciphertext message. Alice sends the ciphertext message over Bitmessage to Bob. Bob decrypts the ciphertext message using the identical key and identical IV for AES-256-CBC and reads the message Bitmessage Encryption AES-256-CBC By implementing AES-256-CBC on Bitmessage, as stated in [46], Jonathan Warren strictly follows the guidelines for cryptography of the National Institute of Standards and Technology NIST (see Table below). This may be the reason why Rijndael is used for symmetric-encryption instead of other encryption algorithms like Twofish which was developed by Bruce Schneier. Bitmessage AES-256-CBC Client PyBitmessage Keylength 256 (bit) 32 (byte) Blocklength 128 (bit) 16 (byte) Note: AES-256-CBC identifies the used key as a 256 bit key Introduction of the AES The Advanced Encryption Standard is an international encryption standard initiated by the National Institute of Standards and Technology for symmetric-key encryption. 17

17 2 Bitmessage Cryptographic Blocks 2.1 Symmetric-Key Cryptography As documented in the official Report on the Development of the Advanced Encryption Standard published on 2 October 2000 [23], the symmetric-key algorithm Rijndael has been chosen as Advanced Encryption Standard out of five finalists. Rijndael s combination of security, performance, efficiency, implementability, and flexibility make it an appropriate selection for the AES for use in the technology of today and in the future. [23, p.7] The procedure of selection, started by NIST in 1997, was organized openly to the extent that cryptography had the possibility to take part in analyzing participating algorithms [23]. The expression AES is used for the proposed cryptography standard using Rjindael, which was slightly modified. The modifications have been maintained in the Note of Naming, which were added to the official Rjindael Proposal [8] in The former blocklength and the keylength needed to be a multiple of only 32 bit. Especially the blocklength had to be at least greater than 128 bits but not greater than 256 bits. This has been restricted by NIST to only support cryptographic keys of 128, 192 and 256 bit-size and a block-size of 128 bits [24]. The specifications for the cipher were published as the standard in November 2001 on the official Federal Information Processing Standard 197 FIPS-197. This document can be used as reference to AES, in order to get an insight in the algorithms functioning [24]. Quoting the FIPS publication, the encryption standard AES may be used by Federal departments and agencies when an agency determines that sensitive (unclassified) information... requires cryptographic protection. [24]. The direct reference to Rijndael together with its history, developers and more details can be found in a book written by the inventors of Rijndael: Jonathan Daemen and Vincent Rijmen [9]. As mentioned in the Rijndael-Proposal [8], the algorithm itself as well as any of its implementations are not subject to any patents. Referring to the FIPS Publication, the AES is capable of using cryptographic keys of 128, 192 and 256 bit-size, to encrypt and decrypt data in blocks of 128 bits [24]. Using AES-256-CBC, identifies the key used by Bitmessage as a 256 bit key. In addition, Bitmessage does not subdivide the plaintext into blocks applying a blocklength of 64 bit (as mentioned above), but rather a blocklength of 128 bit as prescribed by the standard. 18

18 2 Bitmessage Cryptographic Blocks 2.1 Symmetric-Key Cryptography Successful Attacks on AES Taking benefit from NIST s open call, AES/Rijndael has also been subject to cryptanalysis of the New European Schemes for Signatures, Integrity, and Encryption (NESSIES) research project, supported by a Commission of the European Communities. As elaborated in their Final report of European project number IST , published in 2004, NESSIES testifies as AES-128 as: No security flaws have been found, and the 128-bit block variant on which it is based was selected as the AES and has been well-studied. (by NIST). However, there are also proven attacks on the AES-128 variant according to the european report, applicable on Rijndael with a reduced round below 7-8 Rounds [27, 113]. Attacks like the Square Attack by Daemen et al. or Gilbert and Miniers Chosen-Plaintext-Attack have been stated to be the most successful attacks by NESSIES [27, p.112]. Especially the vulnerability to Square- Attacks due to its mathematical structure has been concerned by R. Schroeppel in an official comment in May 2000 [24, p.27]. However, since the operationrounds of Rijndael increase with Rijndaels keylength, those attacks might not be full applicable on AES-256, as used by Bitmessage. Possible Encryption Rounds Keylength Blocklength: Blocklength: Blocklength: 128-bit 192-bit 256-bit Keysize: 128-bit Keysize: 192-bit Keysize: 256-bit Due to Rijndaels strong algebraic nature, that has already been criticized during the selection process [24, p.28], there could still be theoretical attacks on AES-256 derived from the previously mentioned, as stated by the NESSIES report: (AES-256)...still warrants a separate analysis as the byte alignments of this variant are different from those of the 128-bit block variant [27, p.121]. Other successful and serious attacks on AES, so called side-channel attacks, have been reported on cryptanalysis by Dag Arne Osvik et al. on Cache Attacks and Countermeasures: the Case of AES in 2005 and Cache-timing attacks on AES [10], by Daniel J. Bernstein [3], demonstrating inter-process leakage and successful key-recovery. The used side-channel-attacks by Shamir et al. including the Synchronous-Known-Data Attacks [10, p.3], needed additional malware working on 19

19 2 Bitmessage Cryptographic Blocks 2.2 Public-Key Cryptography the same processor as the encryption algorithm. The attack observed the memory and cache management while interprocess communication on a processor. As e result, they have been able to break encryptions on OpenSSL and Linux dm-crypt partitions in 65 milliseconds[10, p.10; p.7]. Bernsteins successful timingattacks were also targeted to AES implemented on a sever for full key-recovery [3, Ch.3]. In order to prove the security of Bitmessage, a precise cryptanalysis regarding OpenSSLs cache-management for AES used for Python needs to be accomplished, since there is no official cryptanalysis on the Bitmessage implementation available at this point. As pointed out by Shamir et al. for vulnerable systems, analysing the cache state of those algorithms is necessary whenever a process gets separated [10, p. 24]. Hence, it remains to mention that security does not rely on the implementation of Bitmessage only, but also on the users own care for security on the own Computer. Note: The Rijndael implementation used by PyBitmessage, depends on the aes implementation of the OpenSSL installation on the users PC. PyBitmessage implementation gets acces to the OpenSSL classes via python OpenSSL wrapper called pyelliptic. A highlevel implemantation of rijndael can be found in the appendix. 2.2 Public-Key Cryptography Bitmessage uses Public-Key Cryptography to transmit the keys securely over the network. In contrary to Symmetric-Key Encryption, Public-Key algorithms use two distinct keys for encryption and decryption. The encryption key or public-key can be published, while the decryption or private-key stays hidden. As explained by Schneier [36], public-key algorithms are more suitable to key encryption, due to their poor efficience if applied on big plaintexts, in contrary to symmetric-algorithms. Hence, they are mostly used to secure general message traffic or to encrypt session keys [36]. Symmetric-Key Cryptography is much more efficient in encrypting or decrypting big plaintexts like messages. In the case of Bitmessage, Public-Key Cryptography secures the shared-secret transmission between Alice and Bob. The shared secret, is a secret piece of data which must be securely generated and then securely transmitted in order to be usable as symmetric-key for AES. Bitmessage implements successfully the Diffie Hellman Key- 20

20 2 Bitmessage Cryptographic Blocks 2.2 Public-Key Cryptography Exchange method of Public-Key Cryptography to accomplish this task. The process is comparable to a Trapdoor-function which is easy to use in calculating the public-key from a private-key in forward direction, but hard to calculate backwards in order to recover the private-key from given public-key. The difficulty relies in this case on Elliptic Curve Cryptography (ECC). This difficult mathematical problem is comparable to the discrete logarithm problem, mentioned above Diffie-Hellman Key-Exchange The Diffie-Hellman Key-Exchange is a public-key concept, which targets highest security goals, since it constitutes public-key-security. By using this method, Bitmessageclients can exchange public-keys and shared-secrets between each other over a network, without giving a man in the middle the possibility to obtain any secrets. Diffie Hellman Key-Exchange is most trivial explained, as done in this Videotutorial [4], using color generation between Alice and Bob, as well as Eve, tracking the communication between both continuously. 1 Step 1: Alice and Bob are communicating over a wire. They agree on a basic open color. Eve is in the middle of both and is able to obtain the open communicated color aggreement Yellow. Eve Alice Bob Figure 2.3: Diffie Hellman Key-Exchange Step 1 1 This example bases on a simplified example of the Diffie Hellman Key-Exchange on a Academic Videotutorial [4]. 21

21 2 Bitmessage Cryptographic Blocks 2.2 Public-Key Cryptography Step 2: After both have agreed on one color openly, Alice creates a new color, which she keeps in secret. Bob does the same, generating a new color secretly. None of them will ever send this color over wire. Neither Bob knows Alice private-color nor Alice knows Bobs private-color. Eve sitting in the middle will not be able to obtain one of them neither. Eve Alice Bob Figure 2.4: Diffie Hellman Key-Exchange Step 2 Step 3: Now Alice and Bob each, adds their own private-color to the openly communicated color. The Mixture generates a second color on each side and represents a public-color. The public-color can be used by both, to be sent over wire without exactly revealing the private color that has been added to the open color. Eve Alice Bob Figure 2.5: Diffie Hellman Key-Exchange Step 3 Step 4: Alice and Bob both exchange their public-colors. Eve, still listening to the communication, captures the two freshly communicated informations. Step 5: After exchangement Alice has two sets of colors, her own private-color 22

22 2 Bitmessage Cryptographic Blocks 2.2 Public-Key Cryptography Eve Alice Bob Figure 2.6: Diffie Hellman Key-Exchange Step 4 and Bobs public-color. Bob has also his own private-color and Alice public-color. Eve has the information of the first openly color and two public colors from Alice and Bob. Even though she has both key, she wont be able to obtain the exact recipe, which explains how exactly the public keys has been created. So she has information about the added color but not enough to recreate the secret-colors perfectly. Eve Alice Bob Figure 2.7: Diffie Hellman Key-Exchange Step 5 Step 6: This step is the most significant part of this procedure. Alice on her side now adds the her private color to Bobs public-color and generates a new color, which has never appeared openly before between both of them. Bob does the same on the other side and creates the very same color Brown. Both have now successfully communicated a shared-secret without revealing it. Even though Eve has collected every single information that has been communicated over the wire, she will not be able to recreate the shared-secret color, since she needs either Alice or Bobs never published private-color. 23

23 2 Bitmessage Cryptographic Blocks 2.2 Public-Key Cryptography Eve Alice Bob Figure 2.8: Diffie Hellman Key-Exchange Step 6 Considering the colors of the example as keys, both participants create a privatekey and a public-key. The process of mixing the colors is considerable as arithmetic operation in Bitmessage. The security of this calculations must be as secure as possible, so that Eve does not have the ability to either recover the private-key from the public-key or to obtain the secret, without knowledge of any hidden key. According to Bitmessage, she faces the Discrete Logarithm Problem. The key set up as well as the arithmetic operation in Bitmessage, are implemented by using Elliptic Curve Cryptography Discrete Logarithm Problem (DLP) The way how Alice and Bob creates their mixture of colors can be adopted on a numerical procedure which is easy to solve in one direction but fairly difficult in the other. The security of this procedure relies on the mathematical difficulty of solving a one-way function reversely. The one-way function Bitmessages public-key cryptography relies on is called the Discrete Logarithm Problem (DLP) found by Diffie and Hellman in 1998 [?]. Example: 1. Alice and Bob publicly agree on two numbers z and P with P is a Prime-number and z<p 2. Each of them creates a random number which is kept in private. Alice chooses a, Bobchoosesb 24

24 2 Bitmessage Cryptographic Blocks 2.2 Public-Key Cryptography 3. Alice takes her private number and calculates z a mod P Y and sends Y to Bob. Bob does the same, and calculates z b mod P = X and sends X to Alice. 4. Alice takes X and calculates X a mod P = S, while S is the shared secret. Bob on his side does the same with Y,calculating Y b mod P S and gets the same shared secret. Both did exactly the same calculation to get the secret on each side since: X a mod P Y b mod P This true because: Alice calculation: X a mod P S using Bobs X which was calculated by X z b mod P is the same as z ba mod P and thus X a mod P z ba mod S Bobs calculation: Y b mod P S using Alice Y which was calculated by Y z a mod P, is the same as z ab mod P and thus Y b mod P z ab mod P S Since both have the same result S, this can also be written as 25

25 2 Bitmessage Cryptographic Blocks 2.2 Public-Key Cryptography z ba mod P z ab mod P, Since flipping the exponents does not change the result: z ab mod P z ab mod P S shows that Alice and Bob are doing the same calculation on each side. The mathematical task for Eve is: How can she find S without knowing a or b? There is no mathematical trivial procedure for this calculation yet. It may be solved, using trial and error, but as soon as the Prime is chosen big enough, so that it consists of a large number of digits, this problem becomes computationally infeasible. It would cost a computer millions of years to solve the Discrete Logarithm Problem: X? mod P S subsectionelliptic Curve Cryptography (ECC) The DLP is the basis for Bitmessages security on public-key cryptography. However, DLP is not implemented based on modular arithmetic but rather applied on Elliptic Curve Cryptography (ECC). This is also known as Elliptic Curve Diffie Hellman (ECDH). Calculations on an elliptic curve over a finite field of primes also faces the DLP. While arithmetic operations like addition or multiplication can be defined for specific elliptic curves, division on these curves is a hard to solve problem. Addition is defined as adding a point to another. Multiplication can be done by repeatedly adding a point to it self. 26

26 2 Bitmessage Cryptographic Blocks 2.2 Public-Key Cryptography Example: 2 Given two points X and G (which is a prime) on an elliptic curve over a finite field of primes, it is easy to use Addition (warum addition groß?)to add and multiply points since addition of points is also used for multiplication. Hence, calculating x G = X, sothatx is also a point on the curve and a member of the finite field of primes is easy to proceed with knowledge of x as the factor. However, reversing the formular to find an unknown factor x like X = x, sothat G x G = X is also a hard problem to solve due to the required division. This is comparable to a trapdoor function, which is easy to proceed in one direction but not in the other. Therefore:! x G = X is easy x G = X is hard 3 In order to generate the shared secret in public-key cryptography, Bitmessage implements ECDH to complete the ECIES. Therefore, every Bitmessage client uses the same specific curve and the identical parameters to ensure that the elliptic curve arithmetic is proceeded correctly. This information can be shared openly, since the used curve and the parameters are not secret. Hence, the parameters are hardcoded in pyelliptic/arithmetic.py. 3 P= Gx = Gy = G= (Gx,Gy) Listing 2.3: Elliptic Curve Parameters of sec256k1 2 This example is a simplified explanation of Elliptic Curve Cryptography. Elliptic Curves are complex mathematical structures. However, the details go beyond the scope of this thesis. The example is used to explain the meanings of the variables and calculations used in PyBitmessages arithmetic.py. For a deeper understanding of this topic research () on () Elliptic Curves is mandatory. 3 The arrows here do not represent vectors, but rather the direction. 27

27 2 Bitmessage Cryptographic Blocks 2.2 Public-Key Cryptography While, P defines the size of the field, G is a point on that specific curve over the field meaning G must be a point between 0 and P. 4 Assuming that the required factor x is the private-key, Bitmessage calculates: x privkey G point = X pubkey to gain the public key. As mentioned above, Elliptic Curve Point Multiplication (ECPM) is solved through repeated addition. The function base10_multiply() recursively calles the functions base10_add() and base10_double(), toaccomplishadouble and add calculation, using point addition and point doubling. 9 def privtopub(privkey) : 10 return point_to_hex( base10_multiply (G, decode ( privkey,16) ) ) def base10_multiply(a,n) : 13 if n == 0: return G 14 if n == 1: return a 15 if (n%2) == 0: return base10_double(base10_multiply(a,n/2)) 16 if (n%2) == 1: return base10_add( base10_double ( base10_multiply (a,n 17 /2)),a) 18 def base10_add(a,b) : 19 if a == None: return b[0],b[1] 20 if b == None: return a[0],a[1] 21 if a[0] == b[0]: 22 if a[1] == b[1]: return base10_double(a [0], a [1]) 23 else : return None 24 m= ((b[1] a[1]) inv(b[0] a[0],p)) % P 25 x = (m m a[0] b[0]) % P 26 y = (m (a[0] x) a[1]) % P 27 return (x,y) def base10_double(a) : 30 if a == None: return None 31 m= ((3 a[0] a[0]+a) inv(2 a[1],p)) % P 32 x = (m m 2 a[0]) % P 4 The size of this field is pretty huge. This can be seen here: 28

28 2 Bitmessage Cryptographic Blocks 2.2 Public-Key Cryptography 33 y = (m (a[0] x) a[1]) % P 34 return (x,y) Listing 2.4: ECPM calculation for private to public key The calculation Bitmessage clients do to reveal the shared secret, is also based on ECPM, calculating: x privkey G pubkey = X sharedsecret. The function multiply(privkey,pubkey) is also written in the same class. 35 def multiply(privkey,pubkey) : 36 return point_to_hex( base10_multiply (hex_to_point(pubkey), decode ( privkey,16) )) Listing 2.5: ECPM calculation for private to public key Koblitz Curve secp256k1 The parameters used for the elliptic curve calculation are associated with the Koblitz curve secp256k1. They are defined as such by Certicom Research in the official Standards for Efficient Cryptography (SEC) as 256-bit Elliptic Curve Domain Parameters [32]. These constants are applied in Bitcoins Elliptic Curve Digital Signature Algorithm (ECDSA) [43],too. The National Institute of Standards and Technology also published official Standards for elliptic curves in digital signature algorithms in FIPS [26]. However, the parameters mentioned by the standard for a curve named P-256 [26] are identical to the parameters mentioned by SEC for a 256-bit pseudorandom curve secp256r1 [32]. When Satoshi Nakamoto, the official Bitcoin founder, developed Bitcoin in 2007 [47], he decided to use parameters for secp256k1 despite the fact that there already was a recommended NIST-Standard for secp256r1. Jonathan Warren adopted the same curve specifications for Bitmessage. It is a remarkable implementation of a specific cryptographic primitive, in Bitcoin and Bitmessage, that completely differs from NIST-Standards of Cryptography. Later in 2013, Dan Bernstein and Tanja Lange reported possible backdoors in NIST curves architecture, implemented by the 29

29 2 Bitmessage Cryptographic Blocks 2.3 Message Authentification NSA[2]. Their assumption started discussions in the Bitcoin-community and amongst several cryptography-experts. Bruce Schneier mentioned in a comment on his Blog that he does not trust the parameters which are proposed by NIST, because he believes they may have been manipulated by the NSA [38].The question why Satoshi Nakamoto had chosen secp256k1 instead of NISTs secp256r1 has also been discussed in several (Bitcoin)forums [11, 12] and other cryptography or Bitcoin related blogs and magazines [5, 28] amongst others. In conclusion, one must say that it is still uncertain whether Satoshi Nakamoto had more information regarding the recommended curves or a close relationship with the NSA or if he was perhaps just clever. Since his identity is also discussed on the internet [47, 17], this issue, along with the question of whether or not the chosen parameters are truly free of backdoors, remains open. 2.3 Message Authentification Like the explained encryption schemes, messages sent via Bitmessage need to be signed. The signature proves the ownership of the message in the network, so an attacker cannot impersonate a participant of the communication (i.e. by doing a Man in the Middle attack). This is solved by a digital signature scheme which is included in Bitmessage s public-key algorithm. Bitmessage does not use any central server as an Arbitrator, as described by Schneier in [36, Ch. 2.6]. An arbitrator could be a server that is trusted by the whole network. The task of an Arbitrator is to know the signatures and prove the authenticity of each participant. Since no trusted server is implemented by the protocol, Bitmessage is, as mentioned by Jonathan Warren in [46], a so called trustless protocol MAC / HMAC/ECDSA The authentification is implemented in, by using a Message Authentification Code (MAC) [36] for integrity, in order to sign each message by the author. The appended signature is also known as Message Authentification Code (MAC). [36]. The MAC can be used by Alice and Bob, when sharing a secret. Both of them are then able to validate their messages. According to the used public key scheme, message integrity can also be used by both with a private and a public key, based on the ideas of 30

30 2 Bitmessage Cryptographic Blocks 2.3 Message Authentification Diffie-Hellman. Both keys are not used for encryption, but rather for signing and authentification. This is applied in Bitmessage aselliptic Curve Digital Signature Algorithm (ECDSA) Example: Alice creates two public and private key-pairs and names them signing keypair and encryption key-pair Alice propagates her public signing-key and her public encryption-key through the network Alice writes a Message and signs it with her private signing-key She then encrypts it using her private encryption-key and sends the signed and encrypted Message to Bob Bob encrypts the Message using the shared-secret and proves the included signature with Alice public signing-key The included MAC needs to be a specific code that indicates the integrity of a message, which means that, as soon as a message gets corrupted during transmission, Bob is be notified by the code. It also needs to be infeasible for an attacker to recreate the exact code that has been created by Alice. To accomplish this, Bitmessage uses Cryptographic Hash Functions to generate the authentification code. As input value for the hash function, Bitmessage uses a key in order to generate a Keyed Hash-value according to HMAC as described in RFC2104. [?]. The MAC-Scheme implemented in Bitmessage is, according to [46], a Keyed Hashing -Scheme for Message Authentification (HMAC) Cryptographic Hash Functions Hash functions are basically central to public key cryptography [37]. These cryptographic functions are mathematical one-way functions, converting variable-length inputs or pre-images, asdescribedbyschneier[37],intofixedsizehash-valuesor hash-digests. Asalreadymentionedabove,one-wayfunctionsortrap-door functions are easy to calculate in one direction but difficult to reverse. 31

31 2 Bitmessage Cryptographic Blocks 2.3 Message Authentification Example: Using x as pre-image, it is simple to calculate f(x) as hash-value. But calculating a missing x from given f(x) is not trivial and would take a computer,according to Schneier, millions of years [37]. Schneier also compares hashing to smashing a plate into millions of pieces, which is obviously easy but putting the plate back together is rather difficult [37]. The security relies thus on this difficulty. This one-wayness [37] is fundamental for hash-security. Furthermore, hash-functions needs to be, as stated by Schneier: collision-free [37], which means that it must be computationally infeasible, as elaborated by Menezes et al.[20] to find two pre-images with an equal hash-value. In other words: It has to be extremely difficult or at least not trivial for an interceptive attacker to alter the file in a manner that results in an equal hash value (kein komma) that reveals the file as corrupted. The integrity therefore comes from the capability of hash function to create a completely different digest, shown in the source-code snippet below, as soon a bit or byte of the pre-image has been changed while transmission. The integrity is therefore given by the property of hash function, to create a completely different digest, shown in the source-code snippet below, as soon a bit or byte of the pre-image has been changed while transmission. 37 sha512("the jumping rabbit jumps very high" ) 38 8 a01c eb3997c603400e6983ce4ceef13fce149d8523a22508d589b5268c de7acea6ccf3e8564bbd1bf2621af9ef5cf52b7bfd69b5de b2ec # Adding an exclamation mark results in a completely different hash with the same size 42 sha512("the jumping rabbit jumps very high! " ) 43 ea9d3c60e12f6db034e141a43590f9b1a327a264a31ae2ffd513a05d729d85f2ecf e38e0b9331c3b3871c429ff fd976d660eb407e1dea Listing 2.6: Python example: sha512 Hash-digests Cryptographic hash functions are, due to their integrity, also known as fingerprints, cryptographic checksums or message integrity checks (MIC), as elaborated by Schneier in [37] or modification detection codes (MDCs) by Menezes et al. [20]. A Sender can use the hash of a file he wants to share with others and provide it. To prove the files s integrity a downloader examines the hash-value of the downloaded file and compares it to the promoted hash. 32

32 2 Bitmessage Cryptographic Blocks 2.3 Message Authentification Example(Simple check wether the Message has been altered) Alice writes a message and hashes the message Alice encrypts the plaintext and the hash-value with Bob s public key and sends the package to Bob Bob decrypts the package with his private key. Then he hashes the decrypted message and checks its hash-value Bob then compares his created hash-value with the hash-value sent by Alice. If they match, the message is unmodified. Furthermore, the size of a hash-digest is always the same, according to the defined hash function, regardless of the pre-images size. 45 sha512("the jumping rabbit jumps very high" ) 46 8 a01c eb3997c603400e6983ce4ceef13fce149d8523a22508d589b5268c de7acea6ccf3e8564bbd1bf2621af9ef5cf52b7bfd69b5de b2ec # A smaller input results in the same hash length 50 sha512("the jumping rabbit" ) 51 1 e888386e7d728a029901f8b5ef5ffd c377e01a497d1ece71b215ec3a1 52 fbe680bbbde629fa40d5f0e14cb5f9e3a7aef7c7a4b15201fe22cc4336bd4a Listing 2.7: Python example: sha512 Hash-digests Finally it has to be stated, that hashing is not in any way comparable to encryption. Encryption transforms plaintext into ciphertext and (given a key-secret) back to the corresponding plaintext. Hash functions,on the other hand, are not designed to be reversible Secure Hash Algorithm 512 Algorithm Message Size (bits) Block Size (bits) Word Size (bits) Message Digest Size (bits) SHA-512 <

33 2 Bitmessage Cryptographic Blocks 2.3 Message Authentification Bitmessage implements SHA-512 and SHA-256 for hashing, which are cryptographic hash functions invented and patented by the National Security Agency (NSA) with the Patent-ID: US [29]. Both belong to the secure hash algorithm group SHA-2 that has been released by the United States under royalty-free license [30]. SHA-2 algorithms were first published by the Institute of Standards and Technology (NIST) in Specifications and details of SHA-512 can therefore be found and reviewed in the latest FIPS document FIPS [25]. While SHA-256 is barely used by Bitmessage and only in order to convert privatekeys to Bitcoins Wallet Import Format (WIF) (see example taken from source-code below), SHA-512 is included all over the code for most of the signing processes and key setups. It is especially used within the Bitmessage address generation (next to RIPEMD) and therefore one of the most important cryptographic elements in Bitmessage. 53 # An excellent way for us to store our keys is in Wallet Import Format 54 # https ://en. bitcoin. it/ wiki/ Wallet_import_format 55 # privencryptionkey = \x80 + potentialprivencryptionkey 57 checksum = hashlib. sha256 ( hashlib. sha256 ( privencryptionkey ). digest () ).digest()[0:4] 58 privencryptionkeywif = arithmetic. changebase ( privencryptionkey + checksum, 256, 58) 59 print privencryptionkeywif,privencryptionkeywif Listing 2.8: PyBitmessage source-code: utilization of sha256() 60 # sha = hashlib.new( sha512 ) 62 sha. update(senderspubsigningkey + senderspubencryptionkey) 63 #... Listing 2.9: PyBitmessage source-code: utilization of sha512() RIPEMD-160 The RACE Integrity Primitives Evaluation Message Digest (RIPEMD) is also a cryptographic hash-function used by Bitmessage. It is mainly used for address generation (will be explained later). The utilization of RIPEMD-160 hash isremarkable since it is, unlike other hash-functions, not an official cryptographic standard as proposed by 34

34 2 Bitmessage Cryptographic Blocks 2.3 Message Authentification Figure 2.9: One iteration in a SHA-2 family compression function. Wikipedia, Picture: Kockmeyer (Source NIST. However, it is still recommended as a collision-resistent underlying compression function for TTMAC by NESSIE in the Portfolio of recommended cryptographic primitives [6]. As elaborated by Menezes et al., RIPEMD-160 is an extended version of RIPEMD. RIPEMD is based on principles of the MD4 [33] algorithm by R.Rivest [19, p. 349] with some alterations. These are, for example, the number of rounds, chaining variables and number of rotations amongst other things [19]. The security requirements of the algorithms regarding hash-value integrity, collision-resistance and applicability as checksum have to be similar to SHA-2 algorithms in order to be used for digital signature algorithms. The RIPEMD-160 test vectors to showing algorithms conduction, taken from [22], are as follows: message="" (empty string) 66 hash=9c1185a5c5e9fc ee8f548b2258d message="a" 69 hash=0bdc9d2d256b3ee9daae347be6f4dc835a467ffe message="abc" 72 hash=8eb208f7e05d987a9b044a8e98c6b087f15a0bfc message=" message digest" 75 hash=5d0689ef49d2fae572b881b123a85ffa21595f36 Listing 2.10: RIPEMD-160 Testvectors [22] 35

35 2 Bitmessage Cryptographic Blocks 2.3 Message Authentification RIPEMD Security The security of RIPEMD-160 is, as indicated in [19], comparable to SHA-1, and provides an increased security against brute-force attacks. However, SHA-1 and MD4 have known security issues, that has been found by cryptographers all over the world. Hans Gobbertin stated MD4 as not collision free in his cryptanalysis in[15]. Hence, using MD4 in any cryptographic protocol is not recommended. He [Gobbertin] also found RIPEMD to be not collision-resistent because its design is similar to MD4, and therefore requested for it to be replaced by stronger algorithms[16] like RIPEMD-160 or SHA-1 in However SHA-1 was later also scrutinized as elaborated in Bruce Schneiers Blog [34] and was therefore replaced by SHA-2. SHA-1 went through dozens of cryptanalyses before being proposed as a official Standard in contrary to RIPEMD-160. This may be the reason why SHA-1 has been more popular and consequently also attacked more often as RIPEMD Hence, there may still be unknown security issues in collision-resistence or several other attacks. However, at this point, no vulnerability has been found. But regardless of known or unknown vulnerabilities, RIPEMD-160 is of particular importance to the address generation scheme used in Bitmessage as well as in Bitcoin. 36

36 3 The Bitmessage Protocol 37

37 3 The Bitmessage Protocol 3.1 Bitmessage Integrated Encryption 3.1 Bitmessage Integrated Encryption Bitmessage implements a Hybrid Encryption Scheme close to the hybrid encryption scheme explained by Schneier in [36]. It combines the concepts of symmetric-key cryptography and public-key cryptography. As applied by Bitmessage, the symmetric encryption is encapsulated in an asymmetric encryption. Schneier also mentions, that due to performance issues public-key algorithms usually perform worse than symmetric-key algorithms if applied i.e. on a huge plaintext [36]. Therefore, they are used to secure the communication by being responsible for message-authentification (i.e. ECDSA) and key-management (i.e. Diffie Hellman Key-Exchange). Both schemes provide two distinct but combined security layers. While the security of symmetric-key cryptography relies on the strength of the used secret key as well as the chosen encryption algorithm, public-key cryptography relies on strong principles such as ECC or DHP Elliptic Curve Integrated Encryption Scheme Nevertheless, the hybrid encryption scheme applied by Bitmessage needs to be specified as Elliptic Curve Integrated Encryption Scheme (ECIES), since the security of the used public-key scheme relies on elliptic curves. Hence, if ECIES is applied on the previously shown examples of Diffie Hellman Key-Exchange, a shortened comparable example finally shows how the keys are generated in an ECIES. Eve Alice Bob Figure 3.1: ECIES/DH Generating a key pair. The lock symbolizes a public-key 38

38 3 The Bitmessage Protocol 3.1 Bitmessage Integrated Encryption Eve Alice Bob Figure 3.2: ECIES/DH Public-Key Exchange Eve Alice Bob Figure 3.3: ECIES/DH Shared Secret-Key generation Ephemeral Diffie-Hellman Key-Exchange The Diffie-Hellman Key-Exchange concept can be designed for durable static keys, meaning that the key-pairs are generated once between a sender and a receiver and as such reused unmodified for all further communications. Certainly, Diffie-Hellman can also be designed for non-durable or ephemeral- keys as recommended by NIST in [13]. The latter has been chosen for Bitmessage and is also known as Ephemeral Diffie-Hellman (EDH). In contrary to the normal DH, EDH does not rely on static long-live but rather on short-live ephemeral keys. They are changed every time a communication or session starts, and are therefore only used once. This improves security, as mentioned by Paul Bakker on a cryptography forum [1], explaining that changing 39

39 3 The Bitmessage Protocol 3.1 Bitmessage Integrated Encryption the keys for each connection improves the security regarding Perfect Forwards Secrecy. Hence, along with Bakker, one can say that even if a private-key gets stolen, not only past communications are still secure (if encrypted) but also all following communication will be secure, thanks to different keys. Example: Alice and Bob agree on ECIES with ephemeral keys and an identical ellipticcurve as encryption and communications system. Alice generates a private/public-key pair using ECC and sends her public-key to Bob. Bob generates a private/public-key pair using ECC and sends his public-key to Alice. Alice receives Bobs public-key and wants to send him an encrypted message. Instead of using her firstly created key pair, she creates a new ephemeral private/public-key pair using ECC on the previously agreed curve. She then uses the ephemeral private-key together with Bobs public-key in order to perform an ECPM and generates an ephemeral shared-secret. She uses this secret as symmetric-key to encrypt the message and sends it along with her newly created ephemeral public-key to Bob. Bob receives the message and Alice ephemeral public-key. He performs an ECPM using his private-key and Alice ephemeral public-key and gets the same ephemeral shared-secret. Heusesthesecret-keytodecryptthecyphertext and reads it. Bob wants to respond to Alice and also generates a new ephemeral key-pair. He uses the ephemeral private-key and Alice original public key, creates a new ephemeral shared-secret uses it as symmetric-key to encrypt the message and sends it to Alice along with the new ephemeral public-key. Alice encrypts the message using her original private-key and Bobs ephemeral public-key. 40

40 3 The Bitmessage Protocol 3.1 Bitmessage Integrated Encryption NOTE: The shared secret-key alters every time before a new message is encrypted due to the always changing ephemeral private-key. One could also say that ephemeral keys only last one encryption and one decryption session. However, encryption always needs the original public-key of the recipient as well as decryption always needs the decryptors original private-key. The original private/public-key pairs are therefore, unlike ephemeral keys, never dropped. Bitmessage takes advantage of the in OpenSSL implemented ECC functions that perform mathematical tasks for new ephemeral key-pairs to calculate Elliptic Curve arithmetic. Assuming the always changing IV which is also sent with the Message, in the case of AES-256-CBC, together with an always changing symmetric-key, this scheme seems to be a pretty good approach for high security goals. Even if Eve is able to obtain one single secret out of the communication, she will neither be able to read messages from the past nor upcomming messages Bitmessage-Workflow The Bitmessage Encryption Scheme can be explained by putting the protocol building blocks together on a workflow Message Setup We Asume, that Alice already has Bobs BM-Address and wants to send him a message. 2 Step 1: Getting Bobs Public-Key In order to generate the shared secret, Alice needs Bobs public-key and her own private-key. Since the BM-Address is a hash of the pub-keys, she sends a getpubkey request to the network. This request contains the ripe hash, she extracted from Bobs BM-Address. The request is passed to every user in the network via peer to 1 This presented workflow can also be seen on the bitmessage.org/wiki/encryption. However this wikipage is not public. Dummy data representing states of data are taken from there. 2 This example is used to show how which cryptographic primitives are involved. The code has been simplifiey. To set up and packing is implemented in in the method sendmsg in src/single- Worker.py 41

41 3 The Bitmessage Protocol 3.1 Bitmessage Integrated Encryption peer. When a peer gets the request, it takes the ripe-hash and compares it to a list of ripe-hashs in its own local database. Bitmessage peers automatically save every public-key together with its ripe which is send over the wire in an own database. If the peer does not have a fitting key on in the database, he does not answer to Alice, but still passes the request to the next peer and so on. As soon as it reaches Bobs peer, the ripe-hash will fit to the own ripe-hash. He then sends a pubkey message back to the network which is also passed from peer to peer until it reaches Alice. Bobs pubkey message contains his public signing-key and his public encryption-key in plaintext. Step 2: Setup a data package Alice assembles a data package containing her public keys and the written message to Bob. 1 payload += pubsigningkey 2 payload += pubencryptionkey 3 messagetotransmit = Subject : + \subject + \n + Body : + message 4 payload += messagetotransmit Step 7: Signing the package: After she assembled all necessary data, she signs the data-package with her private signing-key using ECDSA. Signing will generate a 64byte value which is her signature. 1 signature = highlevelcrypto. sign(payload, privsigningkeyhex) 1 def sign( self, inputb) : 2 """ 3 Sign the input with ECDSA method and returns the signature 4 """ 5 try : 6 size = len(inputb) 7 buff = OpenSSL. malloc(inputb, size ) 8 digest = OpenSSL.malloc(0, 64) 9 md_ctx = OpenSSL.EVP_MD_CTX_create( ) 10 dgst_len = OpenSSL. pointer (OpenSSL. c_int(0) ) 11 siglen = OpenSSL. pointer(openssl.c_int(0)) 12 sig = OpenSSL.malloc(0, 151) 13 key = OpenSSL.EC_KEY_new_by_curve_name( self. curve ) 14 priv_key = OpenSSL.BN_bin2bn( self. privkey, len ( self. privkey), 0) 42

42 3 The Bitmessage Protocol 3.1 Bitmessage Integrated Encryption 15 pub_key_x = OpenSSL. BN_bin2bn( s e l f. pubkey_x, len ( s e l f. pubkey_x), 0) 16 pub_key_y = OpenSSL. BN_bin2bn( s e l f. pubkey_y, len ( s e l f. pubkey_y), 0) 17 OpenSSL. EC_KEY_set_private_key( key, priv_key ) 18 group = OpenSSL.EC_KEY_get0_group(key) 19 pub_key = OpenSSL.EC_POINT_new( group ) 20 OpenSSL. EC_POINT_set_affine_coordinates_GFp ( group, pub_key,pub_key_x,pub_key_y,0) 21 OpenSSL. EC_KEY_set_public_key( key, pub_key) ) == 0: 22 OpenSSL. EC_KEY_check_key( key ) ) == 0: 23 OpenSSL. ECDSA_sign(0, digest, dgst_len. contents, sig, siglen, key) 24 OpenSSL. ECDSA_verify (0, digest, dgst_len. contents, sig, siglen.contents, key) 25 return sig.raw[: siglen. contents.value] Step 8: Encrypt the pre-payload: After she assembled and signed the data-package, she adds the package and her signature into a pre-payload. 1 payload += signature Step 9: Encryption: In order to prepare the encryption she takes Bobs public encryption-key and a new ephemeral private encryption-key and calculates a symmetric value using ECPM. This symmetric value is than hashed with sha512 resulting in a 64byte secret hashvalue. This hash-value is then divided into two parts, each with 32byte size. The first part is called key_e and the second part is called key_m. Alice then, uses key_e as symmetric key together with a randomly created initialization vector to encrypt the pre-payload using AES-256-CBC. After encryption, she uses key_m (as salt) together with the encrypted pre-payload as input for the HMACSHA256 in order to create the MAC 1 encrypted = highlevelcrypto. encrypt(payload," pubencryptionkeybase256. encode ( hex )) 1 def raw_encrypt(data, pubkey_x, pubkey_y, curve= sect283r1, 2 ephemcurve=none, ciphername= aes 256 cbc ): 3 if ephemcurve is None : 4 ephemcurve = curve 43

43 3 The Bitmessage Protocol 3.1 Bitmessage Integrated Encryption 5 ephem = ECC( curve=ephemcurve ) 6 key = sha512(ephem. raw_get_ecdh_key(pubkey_x, pubkey_y) ). digest () 7 key_e, key_m = key [ : 3 2 ], key [ 3 2 : ] 8 pubkey = ephem. get_pubkey () 9 iv = OpenSSL.rand(OpenSSL. get_cipher(ciphername). get_blocksize ()) 10 ctx = Cipher(key_e, iv, 1, ciphername) 11 ciphertext = ctx. ciphering(data) 12 mac = hmac_sha256 (key_m, c i p h e r t e x t ) 13 return iv + pubkey + ciphertext + mac 1 def hmac_sha256(k, m) : 2 """ 3 Compute the key and the message with HMAC SHA """ 5 key = OpenSSL. malloc (k, len (k) ) 6 d = OpenSSL. malloc(m, len(m)) 7 md = OpenSSL. m a l l o c ( 0, 3 2 ) 8 i = OpenSSL. pointer(openssl. c_int(0)) 9 OpenSSL.HMAC(OpenSSL. EVP_sha256 (), key, len (k ), d, len (m), md, i ) 10 return md. raw Step 10: Sending After the encryption Alice collects all the components and adds them to a finalpayload, which is then sent as msg-object to Bob, containing: The initialization vector (plaintext) The ephemeral public encryption-key The encrypted payload ( including: her public-keys, the message, her signature, afullackpayload) The 32 Message Authentification Code The object is send to the network. 44

44 3 The Bitmessage Protocol 3.1 Bitmessage Integrated Encryption Message-propagation and processing Step 1: Getting a msg object A peer can be connected to 20 other peers. It repeatedly downloads new objects from every peer it is connected to. Step 2: Check if a message is bound for me In the case of a downloaded object beeing a msg-object, the peer uses every private encryption key it possesses to decrypt the message. If the decryption fails for all tried keys, the message will be ignored. Regardless whether the decryption was successful or not, the object will still be downloadable for other connected peers. 1 #See if it is a message 2 # bound for me by trying to decrypt it with my private keys. 3 for key, cryptorobject in shared.myeccryptorobjects. items () : 4 try : 5 decrypteddata = cryptorobject. decrypt( 6 data [ readposition :]) 7 toripe = key 8 initialdecryptionsuccessful = True 9 break 10 except Exception as err : 11 pass 12 if not initialdecryptionsuccessful : 13 return 1 def decrypt( self, data, ciphername= aes 256 cbc ): 2 """ 3 Decrypt data with ECIES method using the local private key 4 """ 5 blocksize = OpenSSL.get_cipher(ciphername). get_blocksize() 6 iv = data [: blocksize ] 7 i = blocksize 8 curve, pubkey_x, pubkey_y, i2 = ECC._decode_pubkey(data [ i :]) 9 i += i2 10 ciphertext = data[ i : len(data) 32] 11 i += len(ciphertext) 12 mac = data [ i : ] 13 key = sha512( self. raw_get_ecdh_key(pubkey_x, pubkey_y) ). digest () 14 key_e, key_m = key [ : 3 2 ], key [ 3 2 : ] 45

45 3 The Bitmessage Protocol 3.1 Bitmessage Integrated Encryption 15 if hmac_sha256(key_m, ciphertext )!= mac: 16 raise RuntimeError(" Fail to verify data" ) 17 ctx = Cipher(key_e, iv, 0, ciphername) 18 return ctx. ciphering ( ciphertext ) If Bob is the peer, the decryption will succeed, since his private encryption-key multiplied with Alice ephemeral public encryption key will create the shared symmetric key. Step 3: Check if a message is correctly signed In the case of a successful decryption, the MAC signature included in the object is then verified. Regardless wether verification was successful or not, the object will again still be downloadable for other connected peers. verification, the message will be accepted def verify(self, sig, inputb): 2 bsig = OpenSSL. malloc(sig, len( sig )) 3 binputb = OpenSSL. malloc(inputb, len (inputb)) 4 digest = OpenSSL.malloc(0, 64) 5 dgst_len = OpenSSL. pointer (OpenSSL. c_int(0) ) 6 md_ctx = OpenSSL.EVP_MD_CTX_create( ) 7 If the message passed the 8 key = OpenSSL.EC_KEY_new_by_curve_name( self. curve ) 9 pub_key_x = OpenSSL. BN_bin2bn( s e l f. pubkey_x, len ( s e l f. pubkey_x), 0) 10 pub_key_y = OpenSSL. BN_bin2bn( s e l f. pubkey_y, len ( s e l f. pubkey_y), 0) 11 group = OpenSSL.EC_KEY_get0_group(key) 12 pub_key = OpenSSL.EC_POINT_new( group ) OpenSSL. EC_POINT_set_affine_coordinates_GFp ( group, pub_key, 15 pub_key_x, 16 pub_key_y, 17 0)) == 0: 18 OpenSSL. EC_KEY_set_public_key( key, pub_key) 19 OpenSSL. EC_KEY_check_key( key ) 20 OpenSSL.EVP_MD_CTX_init(md_ctx) 21 OpenSSL. EVP_DigestInit (md_ctx, OpenSSL. EVP_ecdsa () ) 3 There are several more checks for Address and Versionnumber as well as the calculated POW which is a condition for the message to be accepted. They are not included in this simplified example 46

46 3 The Bitmessage Protocol 3.1 Bitmessage Integrated Encryption 22 OpenSSL. EVP_DigestUpdate (md_ctx, binputb, len ( inputb ) ) 23 OpenSSL. EVP_DigestFinal (md_ctx, digest, dgst_len ) 24 ret = OpenSSL.ECDSA_verify(0, digest, dgst_len. contents, bsig, len( sig ), key) 25 if ret == 1: 26 return False # Fail to Check 27 else : 28 if ret == 0: 29 return False # Bad signature! 30 else : 31 return True # Good 32 return False 47

47 3 The Bitmessage Protocol 3.2 The Bitmessage Address 3.2 The Bitmessage Address The Bitmessage address is a core primitive of the implemented integrated encryption scheme. It incorporates the public signing-key as well as the public encryption-key into a base58 encoded, 33 character hash-string, prepended with BM-. 1 BM onkvu1kkl2uauss5upg9vxmqd3estmv79 The prefix has no cryptographic intension. Furthermore, the address includes the client s version number as well as the user s required stream number. Bitmessage enables users to generate as many distinct addresses as they want, either from randomly generated data or deterministically from a certain user s passphrase Base58 encoding The base58 encoding of the address does not have the intension to secure the contents of the adress but rather to ensure that it is properly transmitted and legible by human eyes. Base58 encoding excludes letters 0 (zero), O (uppercase o), l (lowercase L) and I (uppercase i), to prevent mistakes. This principle is also used by Bitcoin. The official Bitcoin Wiki states that problems with equal looking characters or non-alphanumeric characters can be problematic [44]. They also state a fact that makes handling Bitmessage Adresses less difficult: Doubleclicking selects the whole number as one word if it s all alphanumeric, [44]. This applies to Bitmessage Addresses, since they have to be shared electronically via or in a forum or a webpage. Thus, in general an area where users handle with Mouse and Mousepointers abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ The encoding and decoding is implemented in the class arithmetic.py as follows: 1 def get_code_string(base) : 2 #... 3 elif base == 58: return " ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz" 4 #... 5 else : raise ValueError("Invalid base!") 6 7 def encode(val,base, minlen=0): 48

48 3 The Bitmessage Protocol 3.2 The Bitmessage Address 8 code_string = get_code_string(base) 9 result = "" 10 while val > 0: 11 result = code_string[val % base] + result 12 val /= base 13 if len(result) < minlen: 14 result = code_string [0] (minlen len( result ))+result 15 return result def decode(string, base) : 18 code_string = get_code_string(base) 19 result = 0 20 if base == 16: string = string.lower() 21 while len( string ) > 0: 22 result = base 23 result += code_string. find(string [0]) 24 string = string [1:] 25 return result Assembling a Bitmessage-Address In order to generate an address, Bitmessage generates four different keys for asymetric signing and encryption. Key Private Signing-Key Public Signing-Key Private Encryption-Key Public Encryption-Key Size 256 (bit) 128 (bit) 128 (bit) 128 (bit) Note: The symmetric key for AES is not implemented here since it is not literally apartoftheaddress. Step 1: At first, two 32 byte values are generated, using the OpenSSL rand() function, implemented as follows: 76 def rand( self, size ) : 77 while self.rand_bytes(buffer, size)!= 1: 78 return buffer.raw 49

49 3 The Bitmessage Protocol 3.2 The Bitmessage Address Listing 3.1: Python OpenSSL random function The two random 32 byte values, represented in hexadecimal format 4,aresecretkey material, representing the private encryption and signing-keys. Both needs to be kept secret. 1 privatesigningkey : 2 93d0b61371a54b53df143b954035d612f8efa8a3ed1cf842c2186bfd8f privateencryptionkey : 4b0b73a54e19b059dc274ab69df095fe699f43b17397bca26fdf40f4d7400a3a Step 2: The two private keys are converted to public keys, using Elliptic Curve Point Multiplication. To enable mathematical operations, the private keys are previously converted into the Integer format and afterwards back into the hexadecimal format. 1 publicsigningkey : 2 044a367f049ec16cb6b6118eb734a9962d10b8db59c890cd08f210c43ff08bdf 3 09d16f502ca26cd0713f38988a1237f1fc8fa07b15653c996dc4013af6d15505ce 1 publicencryptionkey : d59177fc1d89555d38915f581b5ff2286b39d022ca0283d2bdd5c36be5 3 d3ce7b9b a562752e4b79475d1f51f5a b241227f45ed36a9 The derivation of private key to public key in Step 2, using ECPM is the cryptographic base of the key-pair. An attacker needs to solve the mathematical problem based on ECC to obtain the private-key from the public key. After Step 2, the key-setup is finished. Both keys are stored on a user s hard drive in a file named keys.dat. Unfortunately, the private keys are not saved encrypted by Bitmessage, with the consequence that as soon as an attacker gets access to a user s computer, the attacker gets also access to the user s private keys. Since hackers have several ways to capture a computer, this approach might be easiest way to obtain the secrets, rather than trying to solve the ECC problem. 4 To simplify the process, the results and different states are mostly shown in hex format eventhough the data is passed on digest level. 50

50 3 The Bitmessage Protocol 3.2 The Bitmessage Address Step 3: The public signing-key and the public encryption-key represents the public key-pair. Both are now converted into binaries. 5 They are used as input for the first round of hashing, in order to get the CombinedKeyBinaryHash (CKBH). In this case, SHA512 is used as hash function. The resulting hash-digest can not be used to recreate the public key-pair, due to SHA512s one-wayness. 1 sha512( publicencryptionkeybinary+publicsigningkeybinary) 2 16a31a932ebb910736ec3c84e816a14938dd6086fdf3a5737a587cdde1f114b1 3 b30a068b6942a20c1869e7cd0525b e5c63cc2174b2b a9be62 Step 4: This stage represents the second round of hashing, using the SHA512 Combined Key Binary Hash, created in Step 3 as input in order to create a ripehash using RIPEMD-160 as hash-function. 6 1 ripe160(combinedkeybinaryhash) : 2 3cd097eb7f35c87b5dc8b4538c22cb55312a9f Step 5: To create the final address the Address-versionnumber and the Streamnumber are now prepended to the ripe-hash. These numbers are previously converted to variable int format. Both prepended to the ripe, creates the important intermediateresult. This sets the basis information, the checksum (will be generated later) relies on, covering the unique ripe hash, which has been build with the public key-pair. 1 varint(versionnumber =2) = 02 2 varint(streamnumber =1) = 01 3 intermediateresult = 02013cd097eb7f35c87b5dc8b4538c22cb55312a9f Step 6: The intermediateresult is now used as input for third round of hashing, using SHA512. This will produce the hash-value of the intermediateresult named intermediatehashresult. 1 sha512( intermediateresult ) : e5aca86e cc bc13c62d41b8e381c66f280e05d5ad4b d8b274cd645807e5aec3b6fbbc6671aa66e9a50a4edcd8020c9f5592f924edc Step 7: The fourth round is the last round of sha512, providing a hash of a hashvalue created in Step 6. This step produces the important checksum-hash 5 Both keys starts with 044 which specifies the encoding type (04x). This prefix is removed. 6 a possible x00 prefix of the resulting ripe-hash will be cut off by Bitmessage for packing issues 51

51 3 The Bitmessage Protocol 3.2 The Bitmessage Address 1 sha512(sha512( intermediateresult )) : 2 3bcb4d54dcef8a18f8e62d8be5f36259ecbed620e1acd282600d1f700e637a f28bd50c22da70e82fd3ffc2aefcc35dcb2fb86d4f473ecc7cb71c967448ab Step 8: In this step, the first 4 bytes are obtained and used as the checksum. The fact that only a few bytes of the checksum-hash are sufficient to represent the checksum, relies on the charactaristics of the hashing-function. An attacker would have to create a pre-image [37], that creates a 512bit hash, containing the identical bytes on the first four positions (collision). This is rather difficult if SHA512 is collision-resistent. 1 3b: cb :4d:54 Step 9: The obtained checksum is now appended to the intermediateresult (Step 5) containting Versionnumber, Streamnumber and ripe-hash. This will be transformed into an Integer. Note: The appended checksum bytes are two rounds of hashing ahead of the rest. 1 Versionnumber Streamnumber ripe checksum cd097eb7f35c87b5dc8b4538c22cb55312a9f 3bcb4d54 The data transformed into an integer is represented as follows: 1 int : Step 10: The Integer created in Step 9: will now be encoded using base58 format. This reveals the typical Bitmessage-Address format for the first time. 1 onkvu1kkl2uauss5upg9vxmqd3estmv79 Step 11: Finally adding the BM- String creates the completed Bitmessage-Address. 1 BM onkvu1kkl2uauss5upg9vxmqd3estmv79 Data Version Stream ripe checksum Hex cd097eb7f35c87b5dc8b4538c22cb55312a9f 3bcb4d54 Bytes

52 3 The Bitmessage Protocol 3.2 The Bitmessage Address Decoding a Bitmessage-Address Every address used by Bitmessage needs to be decoded in order to obtain the needed information (Versionnumber, Streamnumber, ripe-data). The address of a recipient needs to be typed into a textfield by the sender. The address is then subject to examination that proves the checksum. The address is not accepted if the checksum-verification fails. Addresses are not exchanged over the Bitmessage-Network. If Alice wants to communicate with Bob, she needs to ask Bob for his Bitmessage address before she can send him a message. Bitmessage does not allow her to get his address through the network. He has to give her his address via another internet-based communication(forum, Webpage,Mail,Messenger), QR-Code, Phone or on a simple piece of paper. However, even if she gets Bobs address she is not able to recover his public key-pair from the address (since they are hashed) in order to send him a message. The public-keys are instead only sent through the network. Hence, she has to send a so-called getpubkey request, which contains the ripe-data from Bob s address, to the Bitmessage-Network. This request is propagated from peer to peer until it reaches Bob. He then responds to the network with his public key-pair. The response is then sent from peer to peer until it reaches Alice. Note: Alice will only get his public key-pair if Bob is online, or if somebody else has already saved his public-key pair. This will work, since every peer saves public-keys which are propagated through the network. As soon as she has the Bitmessage address, her client starts decoding. Step 1: Bitmessage accepts an address with following format: 1 BM onkvu1kkl2uauss5upg9vxmqd3estmv79 Step2: The prepending BM-String needs to be cut off. The remaining part is then base58 decoded and afterwards converted into an integer

53 3 The Bitmessage Protocol 3.2 The Bitmessage Address Step 3: The Integer gets converted into the hexadecimal format 7. The obtained value reveals the internal parts of the address, which has previously been included. In order to accept the address, the checksum needs to be verified 1 Versionnumber Streamnumber ripe checksum cd097eb7f35c87b5dc8b4538c22cb55312a9f 3bcb4d54 Step 4: In order to accept the address integrity the delivered checksum is cut off but will be remembered for the following integrity verification. 1 3b: cb :4d:54 Step 5: The remaining part, including Version- and Streamnumber along with the ripe-hash, is used as input for two consecutive rounds of SHA512 hashing. The purpose of this procedure is to add two missing rounds of hashing, so that the data has the equal number of hash-rounds like the obtained checksum. If the data is not corrupted, the resulting hash-digest will be identical to the checksumhash, that has previously been generated by the address owner. 1 #First round : 2 sha512(02013cd097eb7f35c87b5dc8b4538c22cb55312a9f) 3 4 = 3672e5aca86e cc bc13c62d41b8e381 5 c66f280e05d5ad4b86128d8b274cd645807e5aec3b6fb 6 bc6671aa66e9a50a4edcd8020c9f5592f924edc 1 #Second round : 2 3bcb4d54 dcef8a18f8e62d8be5f36259ecbed620e1acd d1f700e637a3843f28bd50c22da70e82fd3ffc2aefcc 4 35dcb2fb86d4f473ecc7cb71c967448ab Step 6: The first four bytes of the alleged checksum-hash are supposed to be equal to the address-owners (internally created) checksum obtained in Step 4. The integrity-check will fail, if the checksums does not match. In a case of missmatch the address is invalid. 1 3b: cb :4d:54 = 3b: cb :4d:54 7 in the case of the length of the hex being uneven, a 0x00 byte will be added. This is not the case here 54

54 3 The Bitmessage Protocol 3.2 The Bitmessage Address Step 7: As soon as the check has been passed, assurance that the data has not been corrupted is given. The address is now ready to work with cd097eb7f35c87b5dc8b4538c22cb55312a9f 2 3 Ripe data 4 5 Streamnumber = Addressversionnumber = Bitcoin-Address vs Bitmessage-Address It is noteworthy that Bitcoin-Addresses are pretty similar to Bitmessage-Addresses, due to the nearly equal address-generation scheme. (See pictures) Both scheme includes Elliptic Curve generated Public keys and procedes them to final addresses. This Scheme is a core-concept that has been adopted by Bitcoin. However, Jonathan Warren extended the scheme by replacing SHA256 with SHA512 and adding two extra bytes for Version and Streamnumber to the final address along with the BMstring. Furthermore, the manner of creating the checksum shares the same basic. 1 Bitcoinaddress : 2 16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM The reason why he chose a different hash-function may be due to the higher security level provided by SHA512 compared to SHA256. However, it can be excluded, that the size of the hash-digest influenced his decision, since the hash-digest is either used to generate the checksum, or as input for the RIPEMD-160 hash-function that always has a 20byte hash output regardless of the input size. 55

55 3 The Bitmessage Protocol 3.2 The Bitmessage Address Figure 3.4: Conversion from public key to Bitcoin address[45] 56