lwe: add ciphertext size and clarify modulus types on new lwe types #1083

copybara-service · 2024-11-11T19:42:27Z

lwe: add ciphertext size and clarify modulus types on new lwe types

This PR:

Removes key identifier until we have the need for >1 "keyholder"
Adds a ciphertext size descriping the "vectorspace" dimension of the ciphertexts (number of polynomials)
Adds a description of how rings with RNS types look

This PR: * Removes key identifier until we have the need for >1 "keyholder" * Adds a ciphertext size descriping the "vectorspace" dimension of the ciphertexts (number of polynomials) * Adds a description of how rings with RNS types look PiperOrigin-RevId: 695422841

asraa · 2024-11-11T22:21:32Z

@ZenithalHourlyRate @j2kun @AlexanderViand-Intel I made this PR to draft out the (1) addition of the size parameter and (2) to draft out our intentions about how RNS types fit into the modulus parameter in the ciphertext ring attribute and (3) the key attribute changes (removal of ID and size and clarification on basis)

Note that the description is hopeful for the polynomial dialect's ring change.

Do any of you have better nomenclature for the rotation basis / power of x basis in the key attribute? I didn't include a powers-of-s since it's not strictly necessary if we always perform rotations on canonical size 2 ciphertexts, but I borrowed the idea from @ZenithalHourlyRate PR #1067

lib/Dialect/LWE/IR/NewLWEAttributes.td

j2kun · 2024-11-11T22:26:35Z

lib/Dialect/LWE/IR/NewLWEAttributes.td

+
+    ```
+    !ideal = !polynomial.int_polynomial<1 + x**1024>
+    !cmod = !modarith<storage=i64, modulus=298374>


Maybe slap a TODO here to double-check this syntax against the syntax that we ultimately use for the new modarith and rns types. At least, it will need a dialect prefix before the type name.

Nice point I'll synthesize the poly changes into a tracking issue.

j2kun · 2024-11-11T22:27:52Z

lib/Dialect/LWE/IR/NewLWEAttributes.td

+    comprising the ciphertext. This is typically $2$ for RLWE ciphertexts that
+    are made up of an $(a, b)$ pair and greater than $2$ for LWE instances. For
+    example, after an RLWE multiplication of two size $2$ ciphertexts,
+    the ciphertext's size will be $3$.


Suggested change

comprising the ciphertext. This is typically $2$ for RLWE ciphertexts that

are made up of an $(a, b)$ pair and greater than $2$ for LWE instances. For

example, after an RLWE multiplication of two size $2$ ciphertexts,

the ciphertext's size will be $3$.

comprising the ciphertext. This is typically 2 for RLWE ciphertexts that

are made up of an $(a, b)$ pair and greater than 2 for LWE instances. For

example, after an RLWE multiplication of two size 2 ciphertexts,

the ciphertext's size will be 3.

Not worth plaintext readability of putting bare numbers in mathmode.

j2kun · 2024-11-11T22:28:37Z

lib/Dialect/LWE/IR/NewLWEAttributes.td

  }];

  let parameters = (ins
    "::mlir::polynomial::RingAttr":$ring,
-    "::mlir::heir::lwe::LweEncryptionType":$encryption_type
+    "::mlir::heir::lwe::LweEncryptionType":$encryption_type,
+    DefaultValuedParameter<"unsigned", "1">:$size


Suggested change

DefaultValuedParameter<"unsigned", "1">:$size

DefaultValuedParameter<"unsigned", "2">:$size

j2kun · 2024-11-11T22:29:35Z

lib/Dialect/LWE/IR/NewLWEAttributes.td

-    "::mlir::StringAttr":$id,
-    DefaultValuedParameter<"unsigned", "1">:$size,
-    OptionalArrayRefParameter<"unsigned int">:$basis
+    OptionalArrayRefParameter<"unsigned int">:$rotation_basis


The description above makes it sound like it should be called "decryption_basis", but I am in favor of just calling it "basis" for brevity.

ZenithalHourlyRate · 2024-11-12T16:03:59Z

lib/Dialect/LWE/IR/NewLWEAttributes.td

+    The `rotation_basis` describes the powers of `x` at each position of the
+    array, so $(1, s(x))$ becomes $[0, 1]$. After a Galois rotation mapping $x
+    -> x^i$, the key will have a new basis $(1, s(x^i))$, which will be
+    represented by $[0, i]$.


I was thinking that should we record the x^i or x^5^i, namely the automorphism index or the slot rotation index. The former would be hard to read. For OpenFHE, to map rotation index (like 1, 2, -1) to automorphism index, a FindAutomorphismIndex method is used (seems that they have different impl e.g. FindAutomorphismIndex2nComplex
for CKKS), which is quite some computing, and we need a inverse function for it when we analyse the rotation index in some optimization.

Also, for rotation index like -1, the automorphism index could be large.

Oh, that also makes me wonder what a key basis would look like for a more complex automorphism (hypercube view of a ctxt rather than array view)...

If this works for what we need right now, I think it would be safe to merge and revisit a more complex version later.

For one, it would be reasonable to implement a custom parser/printer for the basis, so that we can have a better readability/storage tradeoff.

In particular, could we extend/re-use the polynomial parser/printer for this (in a future PR)? It already supports parsing an expression like 1+s+s^2, but it does not currently support something like 1 + s(x^5) or 1 + s^2(x^5). I suppose really we'd prefer to represent the pretty-printed version as (1, s(x), s^2(x^5)) or similar, which means at least we could reuse the polynomial parser/printer for the stuff inside the s( - )

AlexanderViand-Intel

Thanks for putting this together! I'd still love to have a "packet header breakdown" style diagram for the various attributes & types in the documentation ;) I'm happy to draw one up, though I'm not sure where it should live and if it should be an image (e.g., excalidraw) or ASCII so it can live directly in the tablegen docs?

AlexanderViand-Intel · 2024-11-12T19:53:12Z

lib/Dialect/LWE/IR/NewLWEAttributes.td

-    constructed by listing the powers of `s` at each position of the array. For
-    example, `(1, s, s^2)` corresponds to `[0, 1, 2]`, while `(1, s^2)`
-    corresponds to `[0, 2]`.
+    An attribute describing the key used for decrypting the ciphertext.


I think it might be better to say "the key under which the message is currently encrypted" or something like that, as there'll be plenty of intermediate ciphertexts that are expressed relative to a key basis we don't actually ever intend to use for decryption.

AlexanderViand-Intel · 2024-11-12T19:55:09Z

lib/Dialect/LWE/IR/NewLWEAttributes.td

+    The `rotation_basis` describes the powers of `x` at each position of the
+    array, so $(1, s(x))$ becomes $[0, 1]$. After a Galois rotation mapping $x
+    -> x^i$, the key will have a new basis $(1, s(x^i))$, which will be
+    represented by $[0, i]$.


Oh, that also makes me wonder what a key basis would look like for a more complex automorphism (hypercube view of a ctxt rather than array view)...

copybara-service bot force-pushed the test_695422841 branch 2 times, most recently from 01f91bc to af7f4ef Compare November 11, 2024 21:16

copybara-service bot force-pushed the test_695422841 branch from af7f4ef to 8e94c45 Compare November 11, 2024 21:29

asraa requested review from j2kun and AlexanderViand-Intel November 11, 2024 22:18

j2kun requested changes Nov 11, 2024

View reviewed changes

asraa mentioned this pull request Nov 11, 2024

[modarith] Add a modarith type to describe storage type & modulus #1084

Open

ZenithalHourlyRate reviewed Nov 12, 2024

View reviewed changes

AlexanderViand-Intel approved these changes Nov 12, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

lwe: add ciphertext size and clarify modulus types on new lwe types #1083

lwe: add ciphertext size and clarify modulus types on new lwe types #1083

copybara-service bot commented Nov 11, 2024

asraa commented Nov 11, 2024

j2kun Nov 11, 2024

asraa Nov 11, 2024

j2kun Nov 11, 2024

j2kun Nov 11, 2024

j2kun Nov 11, 2024

ZenithalHourlyRate Nov 12, 2024

AlexanderViand-Intel Nov 12, 2024

j2kun Nov 12, 2024 •

edited

Loading

AlexanderViand-Intel left a comment

AlexanderViand-Intel Nov 12, 2024

AlexanderViand-Intel Nov 12, 2024

	DefaultValuedParameter<"unsigned", "1">:$size
	DefaultValuedParameter<"unsigned", "2">:$size

lwe: add ciphertext size and clarify modulus types on new lwe types #1083

Are you sure you want to change the base?

lwe: add ciphertext size and clarify modulus types on new lwe types #1083

Conversation

copybara-service bot commented Nov 11, 2024

asraa commented Nov 11, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

j2kun Nov 12, 2024 • edited Loading

Choose a reason for hiding this comment

AlexanderViand-Intel left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

j2kun Nov 12, 2024 •

edited

Loading