Feirm Weekly — 24/08 to 30/08. Feirm Website
Tags: Feirm, Cryptocurrency, Update, Marketplace, Blockchain

Feirm Website

Over this week, the Feirm website has been updated to make use of a more content-friendly layout with support for multiple languages out of the box. Over time, we will be providing translations for the website in multiple languages, which ultimately should increase our audience reach to the Feirm project. We hope you like the new design if you decide to go and take a visit! :)

Blog

Next up, a blog section has been added to the new website. This enables us to keep our content all in one place, and hopefully gain greater visibility to the project. However, this idea was also inspired by a recent change to the Medium Privacy Policy which has made us want to reconsider where we publish our articles in the future. Fortunately, Medium is pretty open about how they gather and use data; it is no surprise though that they are making use of third-party analytics tools. Whilst this is expected from the majority of popular websites in 2020, it seems a bit excessive to require all this in order to read an article, right?

Just by looking at the weekly update article published last week, my web browser has blocked 11 cross-site trackers and/or ads at the time of writing this. Here is a quick breakdown of what was detected.

Optimizely — a software company that provides testing tools, website personalisation and other features for websites.

Google Analytics — a web analytics service offered by Google that tracks and reports website traffic.

Branch.io — a platform that provides referral services and personalised welcome messages. It is designed to engage the user and span across all devices, channels or platforms.

Medium’s own performance utility.

All of the above might come across as us having a dig at Medium but quite frankly, the platform has served us well and is great for content creators who are after a platform to share and express their views. We have never been interested in tracking our users through analytics software to gather information about how our services are being used.

Over time, we will migrate our existing posts that currently reside on Medium over to the new blog section of our website.

If you wish to take a quick glance of the new website whilst it is still in the process of having content added, feel free to visit https://new.feirm.com. Once we are satisfied, it will then be migrated to the official https://feirm.com domain.

Feirm Marketplace

Encrypted Messages

Throughout the past week, we have been working on improving the implementation of E2EE messages on the Marketplace.

End-to-End Encrypted messages are vital for a platform such as the Feirm Marketplace due to users potentially exchanging sensitive or compromising information between each other. In such events, Feirm as a project does not want to be held accountable for the sensitive data or any messages which go through our platforms — we try and limit the knowledge about our users who make use of the services we provide.

Additionally, E2EE is important in the event of a server breach for two reasons:

If the Marketplace server is compromised, then any data which could be intercepted is unreadable to the attacker.

If the data-centre where the Marketplace server is hosted is broken into, contents of the data stored on the disks are also unreadable.

Also, E2EE is vital because it ensures that you retain control over who can read or gain access to data. The Marketplace Moderation team can only step in if either party surrenders the private keys of the chat to us in order to decrypt the conversation.

How are messages encrypted on the Feirm Marketplace?

End-to-End Encryption takes place on the Marketplace through the use of pre-keys. These are a certain type of key that is generated when the user creates their account, and the amount of keys are topped up as needed.

Here is a summary — a pre-key is a cryptographic key-pair that is generated separately from a user account, yet can be associated to a user through its signature. When engaging in conversation between two users, a pre-key is used from both of their accounts.

Structure of a pre-key on the Marketplace server.

Lets say that we have two users called Alice and Bob — they wish to communicate with each other through the Marketplace. Each of them have a pre-key that is going to be used for message encryption.

Alice and Bob have a pre-key.

As we know from a previous diagram, a pre-key contains the encrypted version of the private key, which only the rightful owner can decrypt. There is also a public key that can be used by anyone.

As it stands though, Alice and Bob have no practical way of encrypting messages between each other. Fortunately though, by using a key-exchange protocol, they can generate a shared secret key just by knowing each others public key and subsequently encrypt messages using it. This works through the use of ECDH (Elliptic-Curve Diffie-Hellman), which is a cryptographic function that produces the same output given reversed public or private keys. This is the cryptographic function that is currently implemented on the Marketplace.

For an example, I will show each Alice and Bob’s public & private key-pair for their pre-key.

Alice

=============================

Private Key: 45fa0a3ec999835f9a39a6913297823af60ba064412653d63df8dfd9e89445aa Public Key:

04525a4462fafd7f081b93b560e4ac2f3670952d3a81136c28bcb111362180b4f90bf000c71a04bd2874f5196c7bd81d468cfbbcf10cd9e895b74d06aab599b08b Bob

=============================

Private Key: 12dfdbb27aa0eb2b14e8e6daa29b359b02e9e376bd7064ea8f6765e331e63cfd Public Key:

0458f41cfe6cbf9d9cbea548debfec39d5c4a16e6728bc8b251560cc7fbc36b92c79627fd0147444d7bf5f421755f5d3e2b15b3982a735ab86edb40840065cbb1d

When you look at each of their key-pairs, they are totally different from each other. However, when we run them through the ECDH key-exchange function, we can derive the shared secret that will be used for message encryption.

This diagram showcases the entire process it takes to derive the shared secret.

Alice and Bob share their public keys with each other. Alice and Bob NEVER exchange their private keys. They are solely kept to themselves. Alice and Bob can now use the ECDH cryptographic function to generate the same shared secret — using their own private key and the opposite parties public key.

Alice Shared Secret: 810d0d9d0b6006c1a56b3ec8eb566e97bc948fa7fce16f1d54e222362431f65a

Bob Shared Secret: 810d0d9d0b6006c1a56b3ec8eb566e97bc948fa7fce16f1d54e222362431f65a

4. As a result, both parties now have the same shared secret that can be used for message encryption!

Extra: Generating the shared secret with JavaScript.

As the Feirm Marketplace’s client-side cryptography implementation is written in JavaScript, it seems fitting to include a snippet of the shared-key derivation process using our friends Bob and Alice.

Closing Statement

That is all for last week! Thank you for reading, and please remember that you can check us out on our social medias below: