Use hash of raw message in identity verification

[Kailai-Wang]

Problem:

the web2 verification message needs to be encrypted with TEE's shielding key before being posted on the platform. Currently TEE uses 3072 bit RSA key pair which means the resulting ciphertext would be 384 bytes long => 768 chars in hex.

It will exceed the length limit of a tweet: 280 chars.

Suggested solution:

use blake2_256 hash of the composed message as the raw payload.

It means now the raw "cleartext" would be a fixed length (32) byte array => this will be what the user posts on twitter/discord It also means for some web3 verification scenarios (substrate-ecdsa and evm signature) we will have to hash twice: we are performing another blake2_256 and keccak_256 hashing to the hashed message, respectively => but we don't see a problem there

What about the hash collision

It's considered safe because:

• we have a challenge code which changes in every verification, so the hash can't be precalculated
• we have an expiration setting between link_identity and verify_identity
• most importantly, the length of the raw message is small. A typical raw message would be 60-80 bytes, there's enough space even though you consider a very long twitter/discord handle.

Please feel free to leave a comment if you have concerns or better ideas

[jingleizhang]

It looks good.

1. It's good for UX. Reducing message length can make the user send it just in one tweet. Meanwhile, the user can't know and even doesn't care about the original contents of the verification message.

2. The total storage size for those hashed messages is under our control, because there is an expiration time for each message. Expired messages can be deleted at some step in the codes.

[jonalvarezz]

I actually like this hashing approach better than using the shielding key. It ensures the message can safely remain public as the risk of guessing the message is quite low.