From 0bd91cbca8c0ae39a28948c337a96c983933cb79 Mon Sep 17 00:00:00 2001 From: "Kim Laine (HE/HIM)" Date: Mon, 10 Apr 2023 19:58:33 -0700 Subject: [PATCH] Updated README --- README.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/README.md b/README.md index 3c738d79..92fa93ab 100644 --- a/README.md +++ b/README.md @@ -183,8 +183,7 @@ The shortest item length we support (after truncation) is 80 bits, which is stil The second trick is to break up each item into multiple parts and encode them separately into consecutive batching slots. Namely, if `plain_modulus` is a `B`-bit prime, then we write only `B - 1` bits of an item into a batching slot and the next `B - 1` bits into the next slot. One downside is that a batched plaintext/ciphertext now only holds a fraction of `poly_modulus_degree` items. -Typically we would use either 4 or 8 slots per item. -For example, if `plain_modulus` is a 20-bit prime, then 4 slots could encode an item of length 80, and the query ciphertext `Q` (and its powers) can encrypt up to `poly_modulus_degree / 4` of the receiver's items. +For example, if `plain_modulus` is a 21-bit prime, then 4 slots could encode an item of length 80, and the query ciphertext `Q` (and its powers) can encrypt up to `poly_modulus_degree / 4` of the receiver's items. The receiver now queries substantially fewer items than before. The solution is to decouple the cuckoo hash table size from the `poly_modulus_degree` and simply use two or more ciphertexts to encrypt `{X_i}` (and their powers).