A High-Level Technical Analysis of the World’s First Blockchain-Driven Private Messenger
ODIN.Chat a Secure, Blockchain-Powered, Decentralized-Messenger.
ODIN wants you to own your conversation. Having realized the impending doomsday scenario where massive leaks of personal data lead to real-world consequences, ODIN Blockchain decided to do something about it and built ODIN.Chat, a blockchain-powered, secure messenger with the end user’s privacy in mind.
Section 1: Breaking Down the Diffie–Hellman Key Exchange
Why so many keys? Let’s define some of them.
Public key — A public key is created in public-key encryption cryptography that uses asymmetric-key encryption algorithms. Public keys are used to convert a message into an unreadable format. Decryption is carried out using a different, but matching, private key. Public and private keys are paired to enable secure communication. (Techopedia.com)
Private key — A private key is a tiny bit of code that is paired with a public key to set off algorithms for text encryption and decryption. It is created as part of public-key cryptography during asymmetric-key encryption and used to decrypt and transform a message into a readable format. Public and private keys are paired for secure communication, such as email. (Techopedia.com)
A private key is also known as a secret key.
The list goes on. Some honorable mentions that I’ll address later in future articles include private ephemeral keys, pre key bundles, one time use private keys, key derivation function, symmetric keys, and secret key exchanges.
Alice and Bob want to keep a secret from Eve.
Throughout this article, we’ll be discussing a hypothetical conversation between Alice and Bob who want to keep their conversation private from Eve.
One Way Functions
Think back to your days in elementary school and imagine a series of primary color paints like these:
You’ve got your blue, red, and yellow paint. Very easy to replicate — you could buy another tube of the same color code after all. Let’s take a bit of the blue and yellow, mix it, and we’ve got something entirely different, one of innumerable shades of green.
This is how locks work. Very easy in one direction (the mixing of the primary colored paints) Very difficult in the other (you can’t un-mix mixed colors after all).
Why does this matter? It matters because only the mixer could know the precise amount of the respective yellow and blue paint mixed to create this one-off green.
This brings us to:
Ralph Merkle, Whitfield Diffie, and Martin Hellman.
Diffie–Hellman key exchange (DH) is a method of securely exchanging cryptographic keys over a public channel and was one of the first public-key protocols as originally conceptualized by Ralph Merkle and named after Whitfield Diffie and Martin Hellman.
Ralph Merkle conceptualized a public key protocol that Whitfield Diffie and Martin Hellman [Diffie-Hellman] would go on publishing the cryptographic scheme for in 1976 resulting in a breakthrough foundational model for cryptographic based communications. (Diffie-Hellman Key Exchange)
Their solution to the problem is reliant on math, but for simplicity's sake, I’ll do my best to explain the trick with the previously mentioned paint by color example.
Bob and Alice want to have a private conversation that can only be decoded with the use of a mutually shared unique color. To complicate the matter, Bob is in London while Alice is in Los Angeles so sharing the color offline and in private isn’t an option. How do they go about attaining this color without subjecting it to the prying eyes of Eve?
First, Bob and Alice decide on a publicly available starting color. For this example, let’s say it’s yellow. Bob knows it’s yellow. Alice knows it’s yellow. Eve knows it’s yellow.
Next Alice and Bob both randomly select private colors. Bob chooses blue, and Alice chooses red. They then mix this randomly selected private color and mix it with the publicly known yellow color, thus disguising their private color choice. Eve is not privy to this information.
Now Alice keeps her private color private, and sends her mixed color to Bob, revealing only the mixed color to Eve in the transaction. Bob does the same. His private color remains private and the mixed color public, even to Eve.
This leaves:
Alice with the public color(yellow), her private color(red), her mixed color (some variant of red and yellow), and Bob’s mixed color (some variant of blue and yellow).
Eve with public color(yellow), Alice’s mixed color(some variant of red and yellow), and Bob’s mixed color (some variant of blue and yellow). She still is not privy to Alice’s nor Bob’s private color.
Bob with the public color(yellow), his private color(blue), his mixed color(some variant of blue and yellow, and Alice’s mixed color (some variant of red and yellow)
Here’s where the trick happens that allows for both Bob and Alice to have the mutually shared private color that allows for the decryption of their private conversation while leaving Eve utterly dark to the conversation.
Re-read Alice’s and Bob’s respective holdings. They both now hold the exact same information — just mixed in a different order, this is solved when Bob mixes his private color of blue with Alice’s mixed colors of red and yellow, resulting in [blue-red-yellow] and Alice mixes her private color red with Bob’s mixed colors of blue and yellow, resulting in [red-blue-yellow] and a shared private color mixture between Bob and Alice. Eve is left scrambling, grabbing random colors and mixing them with what’s publicly available hoping and praying she’ll come across the right one.
Let’s reexamine this with numbers instead of colors.
Bob and Alice want to have a private conversation that can only be decoded with the use of a mutually shared unique number. To complicate the matter, Bob is in London while Alice is in Los Angeles so sharing the number offline and in private isn’t an option. How do they go about attaining this number without subjecting it to the prying eyes of Eve?
First, Bob and Alice decide on a publicly available starting number. For this example, let’s say it’s 7. Bob knows it’s 7. Alice knows it’s 7. Eve knows it’s 7.
Next Alice and Bob both randomly select private numbers. Bob chooses 4, and Alice chooses 3. They then multiply this randomly selected private number with the publicly known number 7, thus disguising their private number choice. Eve is not privy to this information.
Now Alice keeps her private number private, and sends her multiplied number to Bob, revealing only the multiplied number to Eve in the transaction. Bob does the same. His private number remains private and the multiplied number public, even to Eve.
This leaves:
Alice with the public number(7), her private number(3), her multiplied number(21), and Bob’s multiplied number (28).
Eve with the public number(7), Alice’s multiplied number(21), and Bob’s multiplied number (28). She still is not privy Alice’s nor Bob’s private number.
Bob with the public number (7), his private number(4), his multiplied number (28), and Alice’s multiplied number (21)
Here’s where the trick happens that allows for both Bob and Alice to have the mutually shared private number that allows for the decryption of their private conversation while leaving Eve utterly dark to the conversation.
Re-read Alice’s and Bob’s respective holdings. They both now hold the exact same information — just mixed in a different order, this is solved when Bob multiplies his private number of 4 with Alice’s multiplied number of 21 and the public number of 7, resulting in [4x21x7=588] and Alice multiplies her private number 3 with Bob’s multiplied number of 28 and the public number of 7, resulting in [3x28x7=588]. Eve is left scrambling, plugging in random numbers and multiplying them with what’s publicly available hoping and praying she’ll come across the shared private number of 588.
Of course, this example uses smaller numbers resulting in a relatively limited potential answer set and thus a more accessible way by which Eve could guess at the shared private number. However, ODIN.Chat’s core cryptography uses numbers vastly larger, resulting in an effectively unhackable system as even brute force attacks would take an impractically long time.
Section 2: Double Ratchet Messaging Encryption
More Keys and Their Definitions
Key Derivation Function Ratchet (KDF Ratchet) — We define a KDF as a cryptographic function that takes a secret and random KDF key and some input data and returns output data. The output data is indistinguishable from random provided the key isn’t known. (Signal.org)
Layer One: Diffie-Hellman Ratchet
Alice’s initial messages advertise her ratchet public key. Once Bob receives one of these messages, Bob performs a DH ratchet step: He calculates the DH output between Alice’s ratchet public key and his ratchet private key, which equals Alice’s initial DH output. Bob then replaces his ratchet key pair and calculates a new DH output: (Signal.Org)
That looks really secure. Wouldn’t a single ratchet message encryption be enough?
In short, maybe, but let’s discuss the benefits this second layer adds.
When online shopping, for instance, you generate an initial key via the Diffie-Hellman key exchange and in most situations, use that key in all transactions going forward. This single key model isn’t the greatest of ideas when it comes to messaging. Imagine a nefarious party has been tracking your messages for a year in their encrypted state. These stored encrypted messages are piling up while the attacker systematically tries key after key after key. Eventually, whether it be tomorrow or five years from now, they will happen across the correct key, leaving all past, present, and future messages exposed. In the event that your conversation was of high importance — i.e. private discussion with large government figureheads, or the exchange of highly valuable financial information, then the attacker may be incentivized enough to spend the resources necessary to establish the correct key and decrypt all of your conversation.
Layer Two: Adding the Symmetric Key Ratchet
Combining the symmetric-key and DH ratchets give the Double Ratchet
The recipient applies a DH ratchet step to derive new receiving and sending chain keys. Then she applies a symmetric-key ratchet step to the receiving chain to get the message key for the received message: (Signal.Org)
As previously mentioned, the second layer of security fixes inherent flaws with a single ratchet model. Implementation of a second layer via a double ratchet system allows for the following:
Forward and Backward Secrecy
In the event that a future key is compromised, the current and key are safe thus negating the ability to read present messages. If a past key is compromised, current and future keys are secret. This forward and backward secrecy is often called a self-healing property in cryptography.
Why does this matter?
Let’s consider our earlier example of a private conversation between two parties.
It is incredibly costly to wage war against cryptographic protocols. The malicious parties are incredibly smart and highly motivated to expose vulnerabilities allowing for decryption of conversations. It is therefore advantageous to make the decryption of these messages as hard as possible — negating any incentive to reveal the hidden information.
For instance, suppose I tell you that should you find a way to decrypt this hypothetical conversation, the information will be worth some 1,000,000.00 dollars, and the proposition of doing so will cost 500,000.00 dollars. You have 500,000.00 reasons why you should act this out. Let’s then consider that adding a second layer of encryption makes the proposition of attaining the information no longer 500,000.00 dollars, but 20,000,000.00 dollars. The incentive has been negated it no longer makes sense to go about attacking this. Now in this scenario, you’ve been guaranteed that the information is worth 1,000,000.00 dollars, and the incentive has been built in for you. In nearly all cases, the information in any given message could be useless. You may spend a fortune of time and money on the decryption of a message that says, “Great. Sounds good.” or “Hello.” — not particularly juicy right? That’s the point. We want to make the opportunity cost so high that nefarious parties don’t waste their time.
Section 3: How Variables Like Random Human Entropy Generate Your ODIN I.D.
Definitions
Entropy — a measure of the number of possible arrangements the atoms in a system can have. In this sense, entropy is a measure of uncertainty or randomness. (eoht.info)
Human Entropy can be used as an extension of this. E.g. the randomness of human movement.
Bitcoin Improvement Proposal [BIP] — is a design document for introducing features or information to Bitcoin. The BIP should provide a concise technical specification of the attribute and a rationale for the feature. This is the standard way of communicating ideas since Bitcoin has no formal structure.
There are three types of BIPs
1. Standards Track BIPs — Changes to the network protocol, block or transaction validation, or anything affecting interoperability.
2. Informational BIPs — Design issues, general guidelines. This type of BIP is NOT for proposing new features and do not represent community consensus
3. Process BIPs — Describes or proposes a change in the process. Similar to Standards BIPs but apply outside the Bitcoin protocol. (Bitcoin.it.wiki)
Hierarchical Deterministic Wallets [HD Wallets] — wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins. (GitHub.com)
While BIPs, particularly that of BIP 32, was created by the Bitcoin community, many chains, including ODIN’s Blockchain, make use of them because the structure is sound and often cross-compatible.
A High-Level Overview of How HD Wallets Can Be Used Outside the Use of Coin Spends
If you’re anything like me, you see the word wallet and immediately think, “the storing of a currency to be exchanged or spent.” While that may be true, for the duration of this article, suspend that notion in favor of this: Heirachecial Deterministic Wallets can and in fact are often used for the function of Child Key Derivations (both public and private) — which can in turn act as a method of generating a unique identifier ala your ODIN.CHAT unique user ID.
BIP 32 Infographic Showing from Root (Master Node) to Varying Branch Structures
BIP 32 Changes
- Added private derivation for i ≥ 0x80000000 (less risk of parent private key leakage)
- Switched from multiplication by IL to addition of IL (faster, easier implementation)
- Added test vectors
- Rename keys with index ≥ 0x80000000 to hardened keys, and add explicit conversion functions.
- Added test vectors for hardened derivation with leading zeros
Additional Variables Ensuring Anonymity via both Controlled and Random Variables
Upon completion of the installation, via a combination of both controlled and random variables, you will be granted an eight-character alphanumeric ODIN ID. (e.g. 8Y2NKZ3D@ODIN) let’s discuss how this ID comes to be.
Before we get started, here’s a list of things we don’t ask for when you use our product: your name, your date of birth, your address, we don’t even ask for your email address, all of which other companies see as revenue when you sign up. We don’t even ask you to create a username and risk being linked to other accounts that might share certain features of that name. It truly is private.
So how do we do it?
I discussed previously the use of BIP32 and its ability to create Child Key Derivations (both public and private) and how those can be used to generate a unique identifier. We didn’t see this as being enough, so we’ve added a few more variables which I’ll list off now:
Environmental Properties
-Device Make / Model
-Time / Date of Generation
-Device Screen Size
Random Human Input Properties
-Random User Finger Movement Across the Screen
The final step in generating your unique eight-character alphanumeric ODIN ID calls for you (the user) to add human-driven entropy (random finger movements across the screen) as a final input. This movement, while *potentially* theoretically able to be replicated (*I’d argue heavily against this as human dexterity and timing doesn’t allow for mirrored replication of motion to the millisecond), matters not when combined with the environmental properties of the device make and model, time and date of generation, and the like. All variables are then compiled and hashed using an algorithm which uses the address itself as the *salt.
- In password protection, salt is a random string of data used to modify a password hash. Salt can be added to the hash to prevent a collision by uniquely identifying a user’s password, even if another user in the system has selected the same password. Salt can also be added to make it more difficult for an attacker to break into a system by using password hash-matching strategies because adding salt to a password hash prevents an attacker from testing known dictionary words across the entire system. (TechTarget.com)
Where do I find out more about ODIN?
Discord Reddit Telegram ODIN Blockchain M.A.S.H. Odin.Chat
Read more about how to get Ø(ODIN) here.
Come on by our discord and @ [nondescript | ODIN] to have a discussion around the topics in this article.
