I was looking at the APIs provided by Intel HEXL (which is also compatible with OpenFHE) and Intel HEXL-FPGA and I noticed that in the case of the Intel HEXL-FPGA in the host side for the NTT one of the arguments is const uint64_t* precon_root_of_unity_powers which is the same used in Intel HEXL and in OpenFHE. However, in the device side of the Intel HEXL-FPGA the corresponding parameter is named as barrettTwiddleFactors and I am not sure of the meaning of this. It’s apparently the same thing, but why is it named like this? Is it only because these powers are ciphertext modulo q and the modulo q is performed using Barrett Reduction for the case of Intel HEXL-FPGA? Is there something else that I am missing?

I am not sure if this is the right place to ask for this question, so I would appreciate if you could point out where I should place my question, if that’s the case.

Appreciate your help

I recommend that you ask this question on the GitHub repository for the library in question. The team behind the library is more likely to be able to answer your question there.

1 Like

@geoago I’ve asked one of the core developers of Intel HEXL and Intel HEXL-FPGA to answer your question in this topic.

1 Like

Thank you @Caesar and @ypolyakov for your answers.

While waiting for the reply, I came up with another question regarding OpenFHE and Intel HEXL (I have also posted it in the Intel HEXL’s GitHub repository Q&A but I am not sure whether the developers are notified). In Intel HEXL the maximum supported polynomial degree is N=2^{17} and the modulo q is up to q~62 bits.

- Does OpenFHE bounds polynomials to degree <= 2^{17} and

- does OpenFHE use NTT
**only** with modulo q<64 bits, taking advantage of the RNS representation to factor a large modulo q to q = q1*q2*q3*… and then deploy multiple NTTs with q that fit in 64bits.

- Would an accelerator supporting an NTT/INTT for polynomial degree N>2^{17} be useful for OpenFHE?

Thank you again,

George

I suggest starting another topic for new questions. Very brief answers to your questions (please create a new topic if you need more information):

- No, OpenFHE supports ring dimensions higher than 2^{17}.
- Yes, all OpenFHE schemes use either native words (for FHEW/TFHE) or RNS representation composed of native words (BGV, BFV, CKKS). The small moduli cannot exceed 2^{60}.
- Typically the maximum ring dimension we work with in practice is 2^{17} (in CKKS bootstrapping). It is secure for ciphertext moduli up to around 3,700 bits. In the case of 256 of security, supporting 2^{18} can be useful. But I’ve never seen a practical need for higher ring dimensions.