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
We would like to NOT expose the trivial encryption feature anymore to devs using TFHE.sol library.
We need to be very careful not missing cases of handling uninitialized encrypted variables, for eg today we are missing this in TFHE.select at least (and maybe other ops?).
The text was updated successfully, but these errors were encountered:
there is a closely related question to this issue btw from all the contracts I reviewed from fhevm-contracts : we tried to limit as much as possible the use of trivial encrypt, but I noticed that sometimes when a user request a reencrypt or a dapp tries to read a handle from a view function to use it in computation, from a handle which is supposed to belong to him/it - for instance balances[msg.sender] but if it is still uninitialized - we should take extra-care when we will remove completely the trivialEncrypt from TFHE.sol. At least this would mean that both dApp contracts calling other contract as well as front-end devs handling reencrypt request, should put extra-logic for handling uninitialized variables. Something important to keep in mind.
We would like to NOT expose the trivial encryption feature anymore to devs using
TFHE.sol
library.We need to be very careful not missing cases of handling uninitialized encrypted variables, for eg today we are missing this in
TFHE.select
at least (and maybe other ops?).The text was updated successfully, but these errors were encountered: