Hash to Ethereum

Toni Wahrstätter
6 min readMar 21, 2020

--

Prove ownership, verify integrity, check authenticity while not compromising the data itself. “HashToEthereum”, available under hashtoeth.toniwahrstaetter.com, is a prototype of an interface to hash, sign, timestamp, write, read and verify data to/from the Ethereum Blockchain.

The following article is split into several parts beginning with a general introduction into (the use-cases of) “Blockchain” when it comes to verifying the integrity and authenticity of data in decentralized environments. Next, the signing and verifying process are explained and finally an overview of the used technologies is provided.

Intro

In the last years and especially during the crypto-currency hype in 2017 a lot of possible use cases for “Blockchain” emerged. From decentralized payment solutions, to voting systems, to document verification, the possible applications are numerous. The strength of distributed ledger technology (Blockchain) lies in its decentralized architecture, which allows consensus building without a central authority. Additionally, cryptography ensures immutability which means that it’s impossible to manipulate data that was already included into an older block. And exactly this functionalities provide the perfect foundation to tackle the business model of notary services, and even improve it.

Problem definition

As I’m currently doing my Master’s in Innsbruck, i chose the university of Innsbruck as an example for defining the problem:

Normally, when applying for a job, the company must contact the university to ensure the authenticity and integrity of the diploma that the applicant presents. This would force the university to ask the diploma’s owner for permissions to process his/her personal data and share it with a third party. The transfer of data is legit, only if the owner of the data confirms. The following graphic (left side) illustrates this process:

Using Blockchain, this whole process becomes much smoother:

  • First, the issuer (University of Innsbruck) has to provide students their diplomas in analogue and digital format.
  • And second, the issuer has to digitally sign every diploma and write the signature onto the Blockchain.

As a consequence, an entity that wants to verify certain information, doesn’t need to ask the issuer for verification. Instead, it’s possible to call the Blockchain in order to verify certain data.

The same principles can be applied to every task that would normally need notary service or another way of verification by a third party.
The usage of Blockchain in verification-services allows anyone, anywhere and at any time to verify digital documents for no costs, just by providing the document and a signature.

Components of this project

In general the whole project can be split into 3 parts:

  • The Smart Contract (Solidity)
  • Back-end (Python — Flask, Web3)
  • Front-end (HTML, CSS, JavaScript)

How it works

The Smart Contract

The Smart Contract represents the core of this project. The code was deployed to the Ethereum Virtual Machine (EVM), therefore operates fully decentralized. It’s written in Solidity, Ethereum’s internal language for building smart contracts and was deployed to both, the Ethereum Mainnet and the Ropsten Testnet.

The contract’s main functionality is mapping addresses to signatures. This was achieved by using Solidity’s “Mapping” Type which can be described “as hash tables, which are virtually initialized such that every possible key exists and is mapped to a value whose byte-representation is all zeros, a type’s default value. The similarity (with hash tables) ends there, the key data is not stored in a mapping, only its Keccak256 hash is used to look up the value.
Because of this, mappings do not have a length or a concept of a key or value being set.”¹
Mappings are used to link the address that initialized the transaction to the hashed 320-bits signature which is passed to the the Contract for further processing. This ensures a collusion-free linking process and that the data is stored immutable in a decentralized environment.

Signing a file and write it to the chain

The Signing Process works like the following graphic illustrates:

Let’s assume the University of Innsbruck would like to sign a document and write it to the smart contract:

  • Therefore the university would need to enter its private key and upload the file that should be signed (of course: You should never input your raw-formatted private key on any website out of security reasons — this is a prototype).
  • After the file was hashed with solidity’s Keccak implementation, the private key is used to sign the hashed data which creates a unique signature.
  • The hashed signature is then used as “key”-value in the contract’s mapping. The address which initiated the transaction represent the corresponding “value”.

The signing process costs fractions of a cent as a transaction to the smart contract is needed. The gas prices is dynamically adjusted to the networks capabilities and at maximum 10k gas is used.

Verification process

To only verify a signature, at least a signature is needed.

If a user would like to verify a file’s integrity and authenticity, the the file and the corresponding signature are needed. The process then looks like the following:

File Verification (“Verify” tab)

The file verification process takes the file’s binary data and forwards it to the sever, while in parallel the signature is passed to both, the contract and the back-end.

  • First, the server takes the binary data and the signature and calculates the address that produced the given signature.
  • Second, the contract takes the signature and returns the corresponding value, which is the address that initiated the transaction (see Signing Process).

If both, the calculated address and the looked-up value match, then the verification will be successful. This means the file’s integrity and authenticity were maintained, or in other words: Since the file was issued by a trusted entity, it’s content has not changed.

Signature Verification (“Who signed…?” tab)

  • In a first step the user enters the signature, which is forwarded to the contract.
  • The Contract then looks up the value in his mapping-table and returns the corresponding value, which is the address that initiated the transaction (see Signing Process).

As a result, the user then knows the creation time and the address that created the provided signature.

The back-end

The back-end of this project is purely written in Python. The “Flask“ web framework was used to build the basic web application.
The “web3” library ensures the connection to Ethereum: Using JSON RPC, requests are sent to an “Infura” node, which then propagates the requests to all other nodes of the Ethereum network. This process can be illustrated as follows:

Image credit: iotbl.

Additionally every interaction with the site gets logged and is stored in an AWS bucket. This was achieved using the “botocore” library and it was mainly implemented to help debugging, but also to provide an overview of every interaction with the contract.(“History” tab)

Note: “HashToEthereum” is a project I’ve been developing over the past few months for educational purpose and no commercial intents are associated with this project.

Enjoy!

--

--