You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 20, 2022. It is now read-only.
Based on the proposed ticketbooth-solutions/Ticketbooth/issues/24, it would be useful to implement a wrapper for a password hashing algorithm which is best suited for smart contracts. Possibilities include Argon2di, PBKDF2, scrypt or bCrypt.
The most important factors I would consider for choosing an implementation are hash size and security. The smaller the hash size, the less gas which is required to log it in a contract, though a hash that is too short will have many more collisions. Splitting the hash from the salt would be benefitial for gas saving, as the salt does not have to be stored in a smart contract to verify a hash.
The text was updated successfully, but these errors were encountered:
Based on the proposed ticketbooth-solutions/Ticketbooth/issues/24, it would be useful to implement a wrapper for a password hashing algorithm which is best suited for smart contracts. Possibilities include Argon2di, PBKDF2, scrypt or bCrypt.
The most important factors I would consider for choosing an implementation are hash size and security. The smaller the hash size, the less gas which is required to log it in a contract, though a hash that is too short will have many more collisions. Splitting the hash from the salt would be benefitial for gas saving, as the salt does not have to be stored in a smart contract to verify a hash.
The text was updated successfully, but these errors were encountered: