Encrypting FIO Data
/new_funds_request and /record_obt_data require that certain sensitive data in those messages be encrypted using the Diffie-Hellman key exchnage scheme. This ensures that only the sender and receiver of the data can decrypt it.
The data is further serialized to reduce size. Currently there is no abi for that data, but you can find the relevant data elements inside the /new_funds_request and /record_obt_data API method specs.
Encryption inside wallet
Because the encryption of the data requires the private key of the sender and decryption requires the private key of the receiver, it can only be done inside the wallet. This is an important component of the FIO Protocol integration.
For those unfamiliar with Diffie-Hellman encryption, methods in fiojs SDK make this easy.
The FIO Chain does not see the unencrypted data, so no validation is performed on the data in the content field. It is up to the wallet to ensure the data received is properly formatted and handle any exceptions.
As an example, it is recommended chain_code and token_code be converted to upper case to mitigate the risk that the sending entity used lower case.
Size limitations on encrypted data
Since the FIO Chain cannot see the encrypted content, it cannot enforce size limitations on the individual field. Size limitation is therefore enforced on the content field containing the encrypted string.
|Method||Minimum characters||Maximum characters|
Once you factor encryption overhead the available characters for all parameters are:
Assuming typical FIO Request contains the following required parameters:
This would allow for a memo field to be as long as 81 characters. However, some blockchains can have public addresses of over 100 characters, which can severely limit the characters available for memo.
It is recommended that the memo restrictions are computed dynamically based on public address and amount entered.