Fixes #879
Fixes #879
Conversation
tmontaigu
force-pushed
the
fixes
branch
2 times, most recently
from
cb42636 to
fee1ac3
Compare
|
erm, was a bit fast, maybe a test to check the bit not degree ? |
|
what kind of test ? |
|
checking the bit not degree is correct where it was not before for the boolean block ? |
|
Ok so quick update the degree problem is actually present for all operations |
Hmm, ok then tests for all boolean blocks |
|
And maybe use the % 2 in all look up tables for boolean blocks LUTs |
|
Its not as easy I think because in shortint, boolean ops use a |
|
ah yes |
|
but wouldn't we see that in the output of bit ops in integer as well then ? |
|
I don't think we really check for the degree, and here we are in a special case where the block only has 1 bit take (Degree(1)) whereas in integer, the degree is always 3 for each block at least (unless its a trivial, but again, we don't really check degree) I will try to fix after_bitand/bitor/bitxor in this pr add add part of the test hlapo from #850 with added degree checks |
We used `after_bitand/or/xor` on the ct_left **after** the lut had changed its degree. So the `after_bit` function computed the resulting using a wrong degree for the left ct.
tmontaigu
force-pushed
the
fixes
branch
2 times, most recently
from
f0e8860 to
dcc2662
Compare
| let a = cttrue.expand(); | ||
| let b = cffalse.expand(); |
There was a problem hiding this comment.
can we check the degree here as well in the various compressed/compact etc. encryptions ? I believe you have the helper function to do that
I'm guessing PK as well ?
This is getting annoying, sorry :/
encrypt_one_block does not leak information on the message. BooleanBlocks are meant for when we want to be explicit that the value is a boolean and are ok for this to be public. Thus it needs to correctly set the degree to 1 for other operations to properly take advantage of that
No description provided.