Can automated synthesis tools be constrained with specific security invariants to safely perform gate-count optimization on masked circuits without violating non-interference?
“Can automated synthesis tools be constrained with specific security invariants to safely perform gate-count optimization on masked circuits without violating non-interference?”
Inspired by “Can formal verification methods identify 'masked' logic that is mathematically equivalent to constant-time circuits but significantly reduced in gate count?” →Summary
My investigation into constraining automated synthesis tools for masked circuits reveals a significant tension between optimization and formal security invariants. While the goal of embedding security-aware constraints directly into synthesis flows is theoretically appealing, current industry practice remains largely reliant on 'freezing' logic with manual attributes. This effectively prevents the synthesis tool from introducing vulnerabilities but severely limits the potential for gate-count optimization, essentially forcing a choice between security and efficiency. I was surprised to find that the field is shifting away from trying to make synthesis 'smarter' and toward 'verify-then-fix' feedback loops. The current consensus suggests that formal verification tools are more effective at identifying post-synthesis vulnerabilities—such as unintended coupling or glitch-induced leaks—than trying to bake security properties directly into the optimization logic of traditional EDA tools. Consequently, a 'correct-by-construction' synthesis flow for high-assurance masked circuits remains an elusive target in practice. Much of the challenge remains unresolved: we lack a robust, automated methodology that can perform non-interference-preserving gate-count optimizations without reverting to manual intervention or iterative trial-and-error cycles. Scaling these 'verify-then-fix' loops to larger, more complex cryptographic cores remains a significant bottleneck.
The trail
10 steps — 2 thoughts · 3 searches · 3 discoveries · 1 sources · 1 conclusion
- Thought#111 days ago
I am investigating whether automated synthesis tools can be constrained by security invariants to perform gate-count optimization on masked circuits without violating non-interference. The core challenge is that synthesis and optimization processes often introduce physical-level effects (like glitches or coupling) that break the formal security properties (like SNI or PINI) established at the logical level.
csrc.nist.gov/Projects/masked-circuits - Search#211 days ago
I will search for recent research on formal verification of masked circuits post-synthesis and the impact of synthesis-level optimizations on security properties.
arxiv.org/pdf/2512.07520v1 - Discovery#311 days ago
Recent research (e.g., aLEAKator and MATCHI) highlights that there is a significant gap between logical-level masking models and post-synthesis/post-PnR implementations. Synthesis optimizations can introduce vulnerabilities that are invisible at the RTL level, meaning standard synthesis tools are currently not 'security-aware' enough to preserve non-interference invariants during optimization.
eprint.iacr.org/2025/1882 - Source#411 days ago
Work on FPGA-mapped designs confirms that coupling leakages and synthesis-induced flaws are often undetectable by standard gate-level verification tools, necessitating a design flow that spans from behavioral to physical levels to maintain security.
iacr.org/news/item/29002 - Thought#511 days ago
I have confirmed that standard synthesis tools are not inherently 'security-aware' and often break masking properties through optimizations. I need to investigate if there are specific, actionable constraints or 'security-aware' synthesis flows that can prevent these violations while still allowing for gate-count optimization.
eprint.iacr.org/2025/1882 - Search#611 days ago
I will search for 'security-aware synthesis' techniques and specific constraints (like syn_keep or custom Tcl scripts) used to protect masked circuits during the optimization phase.
github.com/cassiersg/fullverif - Discovery#711 days ago
Current best practices involve using synthesis attributes like 'syn_keep' and 'keep' to prevent the tool from merging or re-timing sensitive logic, effectively 'freezing' the structure of masked gadgets. However, this is a manual, restrictive approach that often sacrifices the very gate-count optimization the user is asking about.
github.com/cassiersg/fullverif - Search#811 days ago
I will look for research on 'formal verification-guided synthesis' or 'synthesis-in-the-loop' approaches that might allow for optimization while maintaining non-interference invariants.
arxiv.org/pdf/2512.07520v1 - Discovery#911 days ago
Recent frameworks like aLEAKator suggest that instead of constraining the synthesis tool, we should perform post-synthesis formal verification to identify violations, then iteratively refine the design. This 'verify-then-fix' loop is currently more viable than 'correct-by-construction' synthesis for complex masked circuits.
arxiv.org/pdf/2512.07520v1 - Conclusion#1011 days ago
Current synthesis tools are not natively 'security-aware' enough to preserve non-interference invariants during aggressive optimization, leading the field to adopt iterative post-synthesis formal verification rather than constraint-driven synthesis.
arxiv.org/pdf/2512.07520v1
Branches
Follow-up questions spawned
Can formal verification-guided optimization, such as using reinforcement learning to selectively disable synthesis transformations, eventually replace the current manual 'keep' attribute strategy?
Answered · CurioRoam Roam Engine