What information should goes into the hash?

Community
1

What is the best practice for choosing what goes into the hash?

Some ideas are:

  1. First name and last name of recipient
  2. First name, last name, year of issuing, name of the certificate
  3. First name, last name, year of issuing, name of the certificate, first 3 letters of passport of some id
  4. First name, last name, year of issuing, name of the certificate, the entire passport ID

Which of the above 4 or if any is good for a school certificate system?

Here’s my understanding and please let me know if it’s right:
The more information that goes into the hash, it should be more convincing to proof that the information on the certificate has not been changed. On the other hand, people would feel that it is less secure since some people would think that there’s a super slight chance to brute force and find out what’s in the hash (although I personally think it’s close to impossible). I am not sure if I understand this right. Please let me know what you think.

It would be nice if someone can share some insights. Thanks.

2

Hi @sevzen,

I’m not sure which hash you are referring to, but how blockcerts work is by hashing the whole document that is being presented, that is all the data that’s part of the certificate you are issuing. If multiple documents are issued at the same time (batch issuance), then each document becomes a merkle leaf, and all of the hashes are being computed to generate the merkle root.
The proof (path to the merkle root and target hash of the document) then gets appended to your initial document.

At this point there should be quite a lot of data, so I am not convinced you could brute force the document, and even if you did, it would still be saved on the blockchain where you would have to revert the hash and the merkle path/root to tamper with the document and change it to your own desire.

1 Like
3

Thanks for your reply. I have a better understanding now.

My current understanding is: whatever information that usually appears on a normal, physical certificate are hashed and put into the blockchain. Private data of the recipients like date of birth and passport ID don’t go to the blockchain because they are not supposed to appear on a physical certificate anyway.

So I think I can treat the blockcert like a blockchain version of the physical blockcert, in terms of what data goes to the blockchain.

4

It is worth noting that the blockchain will not host any personal data per se, as it will be hashed (we are using sha 256).
But yes, it is up to the issuer to decide if they want to add such private information into a blockcert definition. My personal inclination is to restrict the amount of “private” data (where is the limit of privacy on a date of birth and a passport id), but I know that for EDCI tend to add that data in.

In the longer run we would like to add more support for DIDs for both the issuer and the recipient, but at this time, you might still want to provide enough information for a verifying entity to ensure that the recipient is who they claim they are. Again, there is no strong guideline there.

1 Like