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.
Encryption
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.
The above is one of the hotties in the current applied cryptography. AEAD schemes may employ a variety of encryption methods and functions used to generate the āauth-bytesā. Here, ChaCha20 is a very efficient stream cipher, which works in software almost as fast as hardware accelerated AES. We didnāt go with AES as we wanted full interoperability across mobile devices and web-browser and the latter are assumed at least for now not to provide hardware accelerated crypto-schemes to JavaScript.
-
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.
What exactly?
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š§āāļøš§