Subscribe and Return Every Monday, Wednesday, and Saturday for a Dose of Privacy.

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.

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 to 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 entire differently, 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 publish the cryptographic scheme for in 1976 resulting in breakthrough foundational model for cryptographic based communications. (Diffie-Hellman Key Exchange)

Their solution to the problem is reliant on math, but for simplicity sake, I’ll do my best to explain the trick with the previously mentioned paint by color example.

Linked in: 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 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 off line 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 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.

What makes ODIN.Chat different than the products that claim to be free?

When ODIN Blockchain decided to build a free messenger, we put a lot of thought into what free means not just to us, but to the end-user too. 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. We might not be changing the world by ourselves, but we certainly hope to be apart of the group that does.

Thank you for reading! Stay tuned for parts two and three in the coming days!

About the author

Christopher Reeder is ODIN Blockchain’s Lead Content Strategist and Technical Writer. As an advocate and researcher, he is exploring technology’s impact on privacy.

Interested in Blockchain and Cryptocurrency Technologies? Join the ODIN community!

All community ongoings and official support take place on the ODIN Reddit. Free to join — get involved now!

Read more about how to get Ø(ODIN) here.