Label is truncated when using fast update

[Katherine-101]

Hi!

I have loaded SenderDB from disk to memory, and doing insert operation for a new data (item-label pair) by SenderDB::insert_or_assign. label_byte_count_ in the loaded SenderDB is 7, but the label bytes of new data is 32. I found the new label is truncated to 7 bytes when the receiver get the query result.

Is this an unresolved issue, or something wrong with my operation?
I want to use fast update in this case (new label larger than old label in DB). My basic idea is to extend the label_bins_ to put the extra label part, pad the other position with zero in new bins, and then generate the polynomials. But it will raise a problem about label decryption. The effective_label_byte_count becomes variable, so it is hard to decrypt the label correctly.

Could you please give me some advice?

[kimlaine]

Extending the labels is not supported. Why not just create a new SenderDB with longer labels? Label polynomial interpolation is the costliest operation anyway and it would have to be repeated since the newly extended labels need to be (re-)encrypted.

[Katherine-101]

Thank you for your reply! When I extend labels, all the labels need to be re-encrypted to get the same encrypted length. Is that right?

I have another question about cuckoo filter. I found sometimes error occurs like this when I set felts_per_item = 8:

Seems like the repeated felt item wasn't recognized in

APSI/sender/apsi/bin_bundle.cpp

Line 565 in 146070d

if (is_present(curr_bin, curr_filter, curr_item)) {

Is it the reason that some repeated felt item was kicked out of the cuckoo filter? Which parameters affect the probability of repeated points inserted in the same bin, felts_per_item?

[kimlaine]

Yes, when you extend labels, all labels will end up having to have the same extended length. Otherwise I'm not sure what the point of encryption would be. They need to have the same length.

As for your second question: this is very strange and perhaps there is some bug. Would you be able to share some code that reproduces this so I can look into what might be causing it?

[kimlaine]

It really might be that the cuckoo filter has some bug that causes false negatives, which should never happen no matter the parameters. The kick-out process in the cuckoo filter is just supposed to move stuff around so it's not like it should remove anything. It would be very good to know if you can reproduce this.