Dear Fellas! What a joyous time we have got! So many changes! At such a fast pace! Wonderful! 😍
The question everyone keeps asking themselves is whether The Old Wizard🧙 himself got hacked. The short answer is: Not at all.
By reading on you’ll get to know about:
- the difference between authentication and encryption
- what was the surprise we have been preparing about
- what exactly were the issues the surprise functionality attempted to address
- How did the OldWizard’s hack-joke😆 come to be! 🕵️♂️
If you are not interested in some of the medium-level introduction to cryptography related constructs, feel free to skip these through.
If you are reading this, chances are, you have most probably at least got a feeling what encryption is about. It is used to ‘hide’ information from the ones who are not supposed to see. That would be quite accurate. Not quite so. Got you! That’s what Steganography is all about – concealing a message within another message. With encryption we’re doing reversible transformation on the input data itself. GRIDNET OS employs multiple types of encryption. That depends on the current task at hand and especially upon the Threat Model which had been a priori designed to handle it. In short, threat models involve describing what security/anonymity assumptions are we willing to handle under all the possible conditions and actions agents involved in the system may undertake. Describing all the methods here would require academic-class article, which is not what this one aims to be. Do not however that very soon we’ll be releasing here a discussion and rationalization about our Elliptic Curve X25519 signature construct that is heavily used throughout GRIDNET-OS and that in itself requires explanation as Curve25519 is usually not being used for cryptographic signatures but rather for Elliptic Curve Diffie Hellman handshakes.
When it comes to encryption, we have usually got two choices:
- symmetric encryption – here the very same key is used both for encryption and decryption
- public-key encryption – one key (the secret/private key) is used for encryption and the other corresponding (public key) is used for decryption
Let us now take a short glimpse of some of the constructs that are used throughout the system. Hint: Do not get overly scared, it is meant to be short😆.
- Elliptic Curve Integrated Encryption Scheme (ECIES)
The infographics above depict what used quite often within GRIDNET OS for encryption – the ECIES encryption scheme. When exactly? When we are to encrypt data to a peer who is known by a public key. Nothing more is needed. Pretty cool, huh? You might know recipient solely by his public key and still deliver him securely encrypted information. We use it a lot. Lots of details come into play here and it’s very easy difficult not to make a mistake (like encryption to same public key twice without a proper IV vector),the reason why you have probably heard multiple times never to implement cryptographic constructs on your own. Certainly Wizards know what they are doing so we are all safe 😇
The system employs various variances of the above, including some exotic scenarios where an ephemeral session key is derived as a side effect of performing the Elliptic Curve Diffie Hellman handshake in ECIES and treated as a session key. These topics are worthy of separate lengthy articles.
Let us take a short glimpse at yet another interesting construct.
Authenticated Encryption with Associated Data (AEAD).
The point of AEAD is to provide authentication of the ciphertext. Without it, the ciphertext could be mangled with during data transit and the recipient would have no way of knowing. In cryptography we never want the recipient to even attempt decryption should it contain data prepared by an attacker. Allowing for this may open the system up to a variety of Side-Channel attacks. The latter might allow an attacker to infer some information in regard to the encryption key by doing timing analysis while the recipient attempts decryption. Usually constant-time algorithms are used to mitigate these, but these decrease performance and we should always be using the most proper tool at hand which in this case undeniably is – authenticated encryption. The resulting ciphertext assures the recipient that the data wasn’t mangled with and in case of our protocols, quite often that the data indeed originated from the presumed source.
In short: AEAD = encryption + authentication.
You encrypt your plaintext after also including a couple of bytes which assure integrity of the plaintext. Of course it is better use use an AEAD scheme like the one below which can authenticate the ciphertext itself, thus allowing mitigation of decryption at all should the prior be modified by attacker.
Authentication With a Cryptographic Signature
The infographics above illustrate how a special, secret value called the Private Key, together with a secure one way function, are used together to produce what we call a signature. It is assumed that only the person who came into possession of a private key could produce a signature verifiable by a corresponding public key.
Cryptographic signatures are used in decentralized systems like a lot. That is the main tool used to prove that you were the one issuing a transaction. Were it not for authentication and thus cryptographic signatures anyone could be spending assets from the account that you own. Remember when you generated the GRIDNET OS wallet in the mobile app? In that very moment, the private and public keys got generated. The private key is stored securely on your mobile device. The public key may be given away. Others may be using it to encrypt data to you etc. Most often what you use, however, is your wallet’s address. What is it? Well, the public key is a pretty long value as may see by switching the Settings View of your GRIDNET Token. The address is generated based on a truncated portion of the public key and also encoded in a way which makes it less prone to mistakes when typed by human and also includes a checksum. What is a checksum? A couple of bytes that allow for automatic detection of typos.
GRIDNET OS employs Wizards’ implementation of X25510 Elliptic-Curve crypto-signatures that became part of the Botan crypto-library.
The Old Wizard got hacked (not😉!)
From time to time we like to surprise you with new functionalities. We also love listening to your input and opinions so that we may improve the system as it’s in the best interest for all of us. All meaning who? The entire humanity. We are after creating the very first 100% decentralized operating system that can accomplish anything imaginable, just in a decentralized fashion. Decentralized YouTube, games, communicators, EVERYTHING.
Anyway, as you may know, GRIDNET OS even through the Decentralized Command-Line interface boards some cool functionalities. One of these certainly is the Global Chat. To access it, simply press CTRL+Q when connected over SSH. So, recently we were having the Wizards’ party within it, many of you have joined. While reading the transcript we’ve noticed a couple of things. Let us now walk through these one by one.
- some of you had trouble with setting a custom nickname
When connecting to GRIDNET OS over SSH you are automatically assigned a random nickname which usually goes as something like ‘anon123’. To set a custom identifier, one needs to execute the ‘nick’ command from the Commands View (CTRL+E) ex. ‘nick Old wizard’. It is all it took to feel like TheOldWizard🧙 at least for a moment! 🙃
- as it obviously quickly turned out, it’s easy to spoof somebody else’s identity
Indeed. That’s the thing we decided to address ASAP, the Wizards’ way. The Wizards style. There are a couple of things to note. First off, there’s no way to achieve full end-to-end encryption in case of an SSH connection IF the recipient i.e. human is to read the data directly from the screen as ASCII codes. When the data is scanned as an QR Code there’s no problem as the mobile app can interpret the resulting binary data with ease even if encrypted. But we would need some decryption chips in our brains 🧠. or be scanning each message with the mobile app. It would be crazy and useless. So. To sum up. EVERYTHING you type within the Terminal Interface is encrypted. It’s just the full-node which is serving you the Terminal Interface can see everything. If a government agency spies on your connection, they cannot see a thing. In a moment you will see how we solved the problem of spoofing one’s identity.
By the way. The above screenshot did not happen during the party. We have noticed the problem ourselves and announced a competition, guiding you several times to the problem that we aimed to solve. One of our followers hit it right on the spot. Congratulations! Reward has been issued💰.
- some of you asked how to utilize the Friendly ID which you have already established on the chain.
Previously identities registered on the chain were not used in chat. Random ephemeral nicknames were generated upon connection and that was about it. With the possibility of setting a custom one with ‘nick’ command. Surely reusing the on-chain registered identities within the Global Chat began to be tempting enough. The thing was, how to achieve ease of use and (solve the 1st problem and 2nd one.. the wishful thinking in the 3rd case). We wanted to kill three birds with one stone 🦃🐔🐓.. well Wizards. You know how they are.
Let us now look the final result in action:
As you may see now, you may employ your on the chain registered Identity Token. If you login into the system (🤯) the shell would automatically retrieve ID from ID Token if you’ve got one registered on-the-chain. The ID would be used within the Global Chat as well.
So how to ‘log-in’?
That is right simply type ‘logmein’ within the Terminal and see the magic happen😁
Now, once you pull out GRIDNET Token from your pocket.. you may see the real magic happen.
The mobile app would show a screen looking like the one below. Hats down folks. Some state-of-the-art technology, actually some of the most advanced technology known to humankind, is about to be triggered.
Indeed. What is about to happen once you’ve used the Virtual Fingerprint Scanner?
- The scanned QR intent contains an ephemeral public key generated by the GRIDNT OS VM which was spawned for you specifically, the one which you’ve been accessing over SSH
- The mobile app would retrieve the private key from its local storage and also the ephemeral public key from QR Intent
- It would use the private key to sign some of the pseudo-random data which was delivered within the QR Intent
- It would Onion Route (end-to-end encrypted! The response besides being network-layer encrypted while Onion Routing is also end-to-end encrypted to the very Terminal Session you are accessing from the full-node through ECIES encryption done to the ephemeral public key contained within the QR Code) that very signature to the full-node which has spawned the Remote Decentralized Terminal (SSH) session for you.
- The full-node upon receiving the signature would attempt to verify it and notify you both within the Terminal Session AND also by delivering an Onion Routed response directly to your mobile device.
In a few seconds – you are logged in. Felt the Magic?
The above article was written by Major🙏
One of the Wizards🧙♀️🧙