Transparent Ciphertext

[hdk0102]

Hello,

I am aware there have been issues reported on transparent ciphertexts, including #179 and #137. I also get the error of libc++abi.dylib: terminating with uncaught exception of type std::logic_error: result ciphertext is transparent when I do,

double p = 0.0046;
ckks_encoder.encode(p, ptext);
evaluator.mod_switch_to_inplace(ptext, ctext.parms_id());
evaluator.multiply_plain_inplace(ctext, ptext);

To avoid, I included two ifs in SEAL/native/src/seal/evaluator.cpp file like following:

void Evaluator::multiply_plain_inplace(Ciphertext &encrypted, const Plaintext &plain, MemoryPoolHandle pool)
{
        (...)
        if (encrypted.is_transparent())
        {
            continue;
        }
        if (plain.is_transparent())
        {
            continue;
        }                                        
        // these two ifs are what I added      

        if (encrypted.is_ntt_form())
        {
            multiply_plain_ntt(encrypted, plain);
            // Could not understand what ntt is.
        }
        else
        {
            multiply_plain_normal(encrypted, plain, move(pool));
        }

// I've also tried disabling the below #ifdef part, but same error occurs.
#ifdef SEAL_THROW_ON_TRANSPARENT_CIPHERTEX 
        // Transparent ciphertext output is not allowed.
        if (encrypted.is_transparent())
        {
            throw logic_error("result ciphertext is transparent");
        }
#endif
}

However, the error is not reconciled.

FYI, my SEAL version is 3.5.6 (master), Apple clang version is 11.0.3, and cmake version is 3.13.4.

Does anyone know how to fix this problem?

Thank you!

hdk

[kimlaine]

There is a bug in your code: you are calling the incorrect overload of CKKSEncoder::encode for encoding a single integer. Your double is cast to 0 so the plaintext is identically zero. multiply_plain with an identically zero plaintext doesn't make sense and is not allowed, which is what the transparent ciphertext guard correctly catches.

I've made this mistake too. It would probably be a good idea to rename the CKKSEncoder::encode overload for a single integer to something else to avoid issues like this. The difference between the single floating-point and the single integer versions is that the single-integer version doesn't require a scale to be given (it uses scale 1.0).

[hdk0102]

Thanks Kim!! This is really helpful. All solved.

[MyrrhDev]

Hello! I was trying to solve the exact same problem, I checked if something had changed in the ckks.h since what you said about the "calling the incorrect overload" however I found that calling CKKSEncoder::encode was still in such an overload. I was wondering if there is a way to specify which type you're using or how exactly was this solved? Initially I thought it was missing a double scale variable... but then I tried that, ckks_encoder.encode(p, scale, ptext); to try to call the
inline void encode(
double value, double scale, Plaintext &destination, MemoryPoolHandle pool = MemoryManager::GetPool())
{
encode(value, context_.first_parms_id(), scale, destination, std::move(pool));
}
Is there something I'm missing?