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