Add a mechanism to distinguish between trivial encryptions and nontrivial encryptions at the secret level

[j2kun]

Maybe secret.conceal should have a trivial attribute that denotes this, otherwise server-side uses of secret.conceal on static plaintexts (say, for resolving type mismatches) would cause the noise analysis to think it's a fresh encryption rather than a zero-noise encryption.

[AlexanderViand]

:+1:

Maybe we should also consider more fine-grained differentation for the noise of encryptions (e.g., public vs private key)? Btw, where do we currently use secret.conceal for trivial encryptions?

[asraa]

Btw, where do we currently use secret.conceal for trivial encryptions?

This will only happen if there's some reason to reconcile types - rarely happens, but see https://github.com/google/heir/blob/da734afdeaf5e4a1e4f4fb594d0e036bec7ae260/lib/Dialect/Secret/Transforms/DistributeGeneric.cpp#L262 for the iter_args of a loop

[j2kun]

Yeah this is not relevant for most cases since most back ends have ct-pt ops that can be matched at secret-to-scheme, after which point the type system includes sk/pk differentiation as well.

[github-actions[bot]]

This issue has 3 outstanding TODOs:

• lib/Analysis/NoiseAnalysis/BFV/NoiseAnalysis.cpp:107: support trivial encryptions which have zero noise.
• lib/Analysis/NoiseAnalysis/BGV/NoiseAnalysis.cpp:108: support trivial encryptions which have zero noise.
• lib/Dialect/Secret/Conversions/Patterns.h:25: support trivial encryptions

This comment was autogenerated by todo-backlinks