I noticed there's no set_server_key on the engine on unary operators, so I wanted to test the unary precompiles to see if they fail on different security zones, so I expanded the tests to test once for security zone 0 and once for 1.
The tests did not seem to care if the server_key is set or not, which is pretty weird... same as with cast. But they did expose another bug we have: namely, the casting from euint to ebool will fail for non-default security zones, because internally it uses the ne fhe comparison with a constant (0 encrypted) that belongs to security zone 0, meaning it will fail because ne is done with two operands that are different security zones. This is why the CI will not pass here.
We could fix it in the following ways:
leaving the asEbool cast as is and documenting the caveats with working with non-default security zones. namely, the developer will have to manually trivially encrypt the constant 0 for the security zone in question, and then do ne.
supporting the native cast of the TfheBool type in the engine. (currently there's a comment that says it apparently isn't supported and that we have to dig deeper to understand completely?)
implementing the ne hack on the precompile level, which is aware of security zones. Specifically, the Cast precompile should check if the toType is bool, and then if it is, trivially encrypt the zero for that security zone, and passing it to Ne as opposed to cast.
I noticed there's no
set_server_keyon the engine on unary operators, so I wanted to test the unary precompiles to see if they fail on different security zones, so I expanded the tests to test once for security zone 0 and once for 1. The tests did not seem to care if the server_key is set or not, which is pretty weird... same as with cast. But they did expose another bug we have: namely, the casting from euint to ebool will fail for non-default security zones, because internally it uses thenefhe comparison with a constant (0 encrypted) that belongs to security zone 0, meaning it will fail because ne is done with two operands that are different security zones. This is why the CI will not pass here. We could fix it in the following ways:ne.TfheBooltype in the engine. (currently there's a comment that says it apparently isn't supported and that we have to dig deeper to understand completely?)nehack on the precompile level, which is aware of security zones. Specifically, the Cast precompile should check if the toType is bool, and then if it is, trivially encrypt the zero for that security zone, and passing it to Ne as opposed to cast.added a monday task for this: https://fhenix.monday.com/boards/1216577959/views/4451803/pulses/1563307282