fix(integer): rotations/shifts < 2 blocks

[tmontaigu]

This commit fixes a few bugs

• The shift/rotate functions used when blocks encrypt a number of bits that is a power of 2 was causing a panic when working on one block.

  • Also, when the number of blocks was low (e.g 2 blocks with 2_2 params) a noise cleaning step was wrongly skipped

• The function used when blocks encrypt non power of 2 number of bits also had a problem

The test have been updated to test with different block sizes and check the noise level

Overall these bugs only affected low block counts (e.g FheUint2, FheUint4) ciphertexts

---

This change is 

[IceTDrinker]

Looks good a typo and a question on the amount when len == 1

Reviewed 1 of 3 files at r1, all commit messages.
Reviewable status: 1 of 3 files reviewed, 2 unresolved discussions

---

tfhe/src/integer/server_key/radix_parallel/shift.rs line 416 at r1 (raw file):

            let block = self.key.unchecked_apply_lookup_table_bivariate(
                &ct.blocks()[0],
                &amount.blocks[0],

here amount could be of length 0 (?)

Also is it certain this behaves properly if amounts is e.g. == 16 meaning the lower block == 0 (so no shift) but in practice the shift by 16 on a block of 2 bits is going to yield a 0 block or some wrapped around stuff depending on how the shift behaves ?

If it wraps around are we sure we keep enough bits in the amount block vs the number of bits in the ct block ?

---

tfhe/src/integer/server_key/radix_parallel/shift.rs line 448 at r1 (raw file):

        // When doing right shift of a signed ciphertext, we do an arithmetic shift
        // Thus, we need some special luts to be used on the last block
        // (which has the sign big)

sign big -> sign bits

[tmontaigu]

Reviewable status: 1 of 3 files reviewed, 1 unresolved discussion (waiting on @IceTDrinker)

---

tfhe/src/integer/server_key/radix_parallel/shift.rs line 416 at r1 (raw file):

Previously, IceTDrinker (Arthur Meyre) wrote…

here amount could be of length 0 (?)

Also is it certain this behaves properly if amounts is e.g. == 16 meaning the lower block == 0 (so no shift) but in practice the shift by 16 on a block of 2 bits is going to yield a 0 block or some wrapped around stuff depending on how the shift behaves ?

If it wraps around are we sure we keep enough bits in the amount block vs the number of bits in the ct block ?

As this is meant for params where blocks encrypts a number of bits that is a power of 2, that means since the shift applies a modulus to the amount, only looking at the first block of the amount is fine.

The tests have a case where amount > nb bits

I added a guard for empty amounts

[IceTDrinker]

Thanks !

Reviewed 1 of 1 files at r3, all commit messages.
Reviewable status: 2 of 3 files reviewed, all discussions resolved

[IceTDrinker]

Reviewed 1 of 1 files at r4, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @tmontaigu)