Asymmetric cryptography in the Universa Blockchain

In the previous article you could read about the basic principles of the hash functions which are used in the Universa Blockchain Protocol. The combination of three hash functions, called HashID, protects data so it can be stored securely without the need of a trusted third party in a network of distributed nodes. Another important aspect of storing data securely, is that it can’t be altered by entities who do not have the rights for it.

In this article we will dive a little bit further into the world of cryptography. Especially in the world of ‘asymmetric cryptography’ with encryption/decryption, public/private keys and signing/verifying.

Hashing and encryption

First of all, it’s important to notice and understand the difference between hashing and encryption. Encryption is when you convert an ‘original message’ to an ‘encrypted message’ (using an encryption key). After that, you can decrypt the encrypted message (using the decryption key) right back to the original message.

With the encryption/decryption algorithm, the encrypted message size varies depending on the original message size. It is usually at least the same size.

If you encrypt 10 million symbols of text, you’ll likely get 10 million symbols of encrypted text, because encryption is lossless. You can always restore the original message from the encrypted message, using the key.

With hashing, everything is different. The whole point of hashing is to be lossy in a controlled manner. Every message possible, no matter of its size, will get the same size of hash.

In Universa blockchain, only these hashes are stored. There is actually no data stored in the DAG that is encrypted. The contracts, by themselves, are never encrypted/decrypted, as they need to be processed by the nodes in their direct way. You could have read about HashID in the previous article, as a 128 characters string. No matter what kind of smart contract you are operating, the state of the contract will always be checked by the corresponding HashID from 128 characters.

Do not worry though: the communication between the clients and the nodes is encrypted and decrypted on the fly, so third parties cannot meddle in.

Asymmetric cryptography

The principle of a distributed and decentralized network is to ensure reliable and trustless data storage, which obviously cannot happen without being able to transmit data on secure way. In such a cryptosystem-secured transfer, the particular data may only be available for those who are allowed to see it and it should be hidden for those who should not be able to read it. 

So in short, to get access to this data you need to have a digital key. What is needed, is a key to encrypt data and a key to decrypt data. And remember: the length of input, is non-lossy encrypted to an output of the same length.

Asymmetric cryptography is also called “public-key cryptography”. It is a cryptographic system that uses pairs of keys: public keys which may be shared openly, and private keys which are only known by the owner.

In an asymmetric key encryption scheme, anyone can encrypt messages using the public key, but only the holder of the paired private key can decrypt. This is what makes it not a symmetric (and reversible) way of cryprography, hence it’s called asymmetric. The security of the data depends on the secrecy of the private key.

And this asymmetric encryption is used during the secure channel between the nodes, or between the node and the client.

So to make it easier: asymmetric cryptography is like a one-way process which is not possible to trace back. With symmetric cryptography, the secret key is used to both encrypt and decrypt data (having just one single key).

Here we’re talking about the RSA cryptosystem, called by the initial letters of the surnames of the creators (Rivest–Shamir–Adleman). The encryption key is public and it is different from the decryption key which is kept secret (private).

Encryption and Decryption

So let’s start with an easy example. Imagine you are the sender of some data. This may be a payment/transaction or something else. To do this, you have to sign the smart contract with your key. 

The public key may be stored in the smart contract, or you can just share it with whom you want. If you have the private key, you can sign any operation to utilize the smart contract.

The private key and the public key (together also called the “key pair”) are mathematically correlated.

Private and public key

When you create your private key (in fact you create the whole key pair) in the web client, you usually automatically download the file with the .unikey extension.

You don’t have to ‘open’ this file in notepad or another editor. This file is your key, that’s it. Nothing more, nothing less.

You should never, ever give it out, or provide any access to it to any third parties, nor attempt to open it with any type of program or text editor. You would risk irreparably compromising it, losing access to your data forever.

This is the most important thing of using the Universa Blockchain: with the key pair you can sign and verify contracts. As you might remember, the Universa Blockchain Protocol only stores the hashes of a revision of the smart contract. 

So to change it, you must prove that you have the corresponding private key to the smart contract.On the Knowledge Base website you can read more about the key pairs in Universa.

Signing and verifying

If you want to do a transaction in the Universa Blockchain, you have to sign it with your keys. Think of the private key as your unique personal stamp or signature that nobody besides you can use, and which allows you to sign any document for any other parties.

The public key is available to various parties you communicate with.

To register a smart contract, you have to sign it. You can also edit it, but when you want to do it, you must have the key to sign it. The system will check if you have the permissions to do this.

By the way, the step from public key to your corresponding addresses is done by hashing (but not by HashID function, which is rather complex and therefore only used to hash the whole contract).

Encrypting a message with someone’s public key, does automatically verify that the sender is the one who it says, since the public key might be public for everyone. In order to verify the origin of a message, RSA can also be used to sign a message.

Suppose you want to send a signed message to Alexander. You can decrypt it and attach a hash value to it as a « signature » to the message

When Alexander receives the signed message, he uses the same hash algorithm in conjunction with your public key. It encrypts the message, and compares the resulting hash value with the message’s actual hash value. 

If the two agree, the network also knows that the author of the message was in possession of your private key and that the message has not been tampered with since.

Long and short addresses

The address is a short alternative representation of your public key, convenient to be used when you need to enter it in some forms. You can alternatively use a short address (51 symbols long) or a long address (72 symbols long). 

They both refer to the same public key. The long address provides the ultimate level of security and the short address provides still sufficient security for most usage scenarios. The long address uses SHA3-384 and the short version SHA3-256.

You can read more about the binary and text representation of the addresses at our Knowledge Based website.

In Universa, the single key pair can be used to derive multiple addresses. Each of them can be used independently but still refer to the same public key. Do you have any questions? Feel free to contact @starnold on Telegram.

Help translating this post to Anglais Allemand Néerlandais Italien Espagnol Croate Russe. Contact @starnold to participate!

Related posts

Inside a Universa Smart Contract


Alexander meets Amsterdam 2020


Identity of Universa (and Ricardian) Smart Contracts


Leave a Comment