# ADR-028 Address algorithm Problem discussion: https://github.com/cosmos/cosmos-sdk/issues/8041 - Aaron gives a context and describes current approach of current address construction algorithm - we only have two key schemas (secp256k1 and ed25519) ## Alan general thoughts - we don't need 2-preimage resistance - we need 32bytes address space for collision resistance - there is an issue with smart-contracts for hashing - this things can overlap - birthday attack ## Diving in Problems - when an attacker can control an input for object with an address then we have a problem with birthday attack Note: - sha2 mining can be use to breaking address pre-image Hashing algorithm - Any attack breaking blake3 will break blake2 - Alan is pretty confident about the current security analysis of the blake hash algorithm. It was a finalist, and the author is well known in security analysis. - Algorithm: + Alan suggest to hash the prefix: `hash(hash(prefix) | pub_key)`[:32] + discussion about personalization + -> about adding prefix post hash Aaron is asking about post hash prefixes and differencies + key_type | hash(pub_key) - this has longer address space, so it's harder. Alan: By separating out address spaces we are separating Alan reccomendation is to do pre-hash prefixing because it solves: + we are free to user arbitrary long prefix names + we still don't risk collisions + switch tables ### Complex addresses + multisig example + + mention about bitcoin schnorr scheme (bip340), PS: we have also an issue for that: [\#7315](https://github.com/cosmos/cosmos-sdk/issues/7315). + merging tree like addresses with same algorithm are fine ### should we separate / have different algorithm for module accounts? Requirement: + can't colide with any other address in the system Should module addresses have different size to differentiate it? + we will need to set a pre-image prefix for module addresse to keept them in 32-byte space: `hash(hash('module') | module_key)` Aaron: we already need to deal with variable length (to not break secp256k1 keys). ### Ideas for complex object addreses + hash the hash of object bytes + cache the object byte hash whenever we will use it for the first time. ### Discssion about arithmetic hash function Posseidon / Rescue Problem: much bigger risk because we don't know much techniques and history of crypto-analysis of arithmetic constructions. It's still a new ground and area of active research. ### Post quantum signature size Falcon: speed / size ration - very good. Aaron - should we think about it? based on early extrapolation this thing will get able to break EC cryptography in 2050 . But that's a lot of uncertinity. but there is magic happening with recurions / linking / simulation and that can speedup the progress. ### Other ideas + Let's say we use same key and two different address algorithms for 2 different use cases. Is it still safe to use it? + if we want to hide the public key (which is not our use case), then it's less secure but there are fixes.