Encoding vs Hashing vs Encryption

In blockchain

In blockchain, at least as a developer, you will eventually be forced to become familiar with these three topics. Recently, while going through a client projects to break up 721 NFT's into a bunch of 1155's, we faced a lot of challenges implementing Georgios Konstantopoulos' implementation of this for the NFT Loot project. First, and foremost, our NFT metadata was not mapped 1:1 in sets like in Loot; but second, our familiarity with hashing, encryption, and encoding was at an implementation layer of abstraction. Meaning we used the functions to encode/decode, encrypt/decrypt, and hash, but rarely dove under the hood.


Encoding is basically a mapping between two characters. Like, if this character is 'a' on this set, map it to '12' on this set, and every time the program comes across an 'a,' it will change that value. Encoding is also not used for security, but a way for different interfaces to communicate.

Decoding is just the reverse of the encoding process. So, let's say another interface receives the '12', but wants to use the formatting set from the first source (the one with letters, like 'a'). It will reference a table, convert the '12' to an 'a', and be able to present the information in that lettered format. This link has a more detailed example down to the bits, but serves the same purpose.


Hashing is just a process of changing all the data to prevent that data from ever being changed by someone else. Let's say we pass 'hello' into a hash function, and it returns '3kd03a.' Now, we have no idea what that means, but it is a representation of the data when passed into a specific hash function- a 'one-way encryption.'

The data, when passed into a hash function like RSA or SHA, are broken down into blocks. The output of the first block is passed into the second hashing, along with the second block of data. So the hash is always building on top of itself, where the number of hashes is relative to the number of blocks that are passed in. This article does a great job of elaborating on this compounding effect.

What do the numbers represent in RSA128 and SHA256?

It represents the length of bits a hash is returned as from a function. So, for RSA128, the hash returned will be 128 bits, and for SHA256, the hash will be 256 bits. The higher the number, the harder it is to decrypt (like, a LOT harder).


Like hashing, encryption is fundamental to blockchain's usability. Basically, there is a public key (a hash) that encrypts the data, when passed through an encryption function. This public key is known to everyone on the internet. The other key (also a hash) is a private key, and this sits on your own computer. This key is used for decrypting the data (also using a function), and needs to be stored in a safe place.

How does this actually work?

  1. Your device (or you, if you're an engineer creating server software or SSH pair) creates a public/private key pair from a function (RSA or SHA256- see, it's a hash)
  2. Give your public key to the other data sender (remember, everyone on the internet knows your public key)
  3. They scramble/encrypt the data with your public key
  4. They send you the scrambled/encrypted text
  5. Your computer uses your private key to decrypt the data

How long does this process take? And can someone guess the private key if they have the public key?

The semi-accurate answer is milliseconds, but depends on a few variables like file size, interfaces, network size, etc- this link does a great job.

As for reverse engineering the private key from the public key, it is technically possible (using brute force and testing every hash possible), but it would be one of 2^256 possible answers. It would be computationally infeasible. Which sheds a lot of light on security- you basically don't make something unbreakable, you make it so hard to guess that no amount of available computation can crack it in a lifetime.

Tired of doing the same activities over and over again?

Get Started