Unified Program Generation and Verification: A Case Study on Number-Theoretic Transform

Abstract

Giving correctness assurance to the generated code in the context of generative programming is a poorly explored problem. Such assurance is particularly desired for applications where correctness of the optimized code is far from obvious, such as cryptography.

This work presents a unified approach to program generation and verification, and applies it to an implementation of Number-Theoretic Transform, a key building block in lattice-based cryptography. Our strategy for verification is based on problem decomposition: While we found that an attempt to prove functional correctness of the whole program all at once is intractable, low-level components in the optimized program and its high-level algorithm structure can be separately verified using procedures of appropriate levels of abstraction.

We demonstrate that such a decomposition and subsequent verification of each component are naturally realized in a program-generation approach based on the tagless-final style, leading to an end-to-end functional correctness verification of a highly optimized program.

Appendix A Programs to be Verified and their Semantics

The verification procedure in Sect. 5 is a series of step-by-step simplifications of programs and their correctness proofs. The following table lists the programs and the domain interpretations in the procedure.

	Program	Domain	Arithmetic operation
$P_0$	DFT formula (1)	$Z_q$	Arithmetic operations in $Z_q$
$P_1$	DSL program in Sect. 2.2	$Z_q$	Arithmetic operations in $Z_q$
$P_2$	The same as $P_1$	Unsigned int	Arithmetic with modulo-q
$P_3$	The same as $P_1$	Unsigned int	Low-level operations
$P_4$	$P_1$ + lazy reduction	Unsigned int	Low-level operations
$P_5$	Generated C code	Unsigned int in C	Arithmetic operations in C

$P_0$ is the DFT formula (1) in Sect. 2.1. $P_1$, $P_2$, and $P_3$ are the DSL program whose inner-most loop was given in Sect. 2.2 with different domain interpretations. For the interpretation of DSL, we take the natural ‘interpreter’ semantics, which is essentially the same as the module R in Sect. 2.2.

$P_1$, $P_2$, and $P_3$ differ in the domain interpretations. For $P_1$, the domain is interpreted as $Z_q$. For $P_2$, the domain is interpreted as the set of 16 bit unsigned integers, and the arithmetic operations are those for unsigned integers followed by the modulo-q operation. To treat multiplication within 16 bits, we use mullo and mulhi in Sect. 3. For $P_3$, the domain remains the same as $P_2$, while the arithmetic operations are replaced by low-level operations such as Barrett reduction. The semantics of unsigned integers and their operations is specified by the bit-vector theory [16]. $P_4$ is the same as $P_3$ except that it employs lazy reduction in Sect. 3.

$P_5$ is the C code generated by interpreting the DSL constructs as generators for strings that represent the corresponding C code. This process (called offshoring in the literature) is conceptually a trivial injection, however, formalizing it involves the semantics of the C language and is beyond the scope of this paper, and we put the equivalence of $P_4$ and $P_5$ into our trusted base.

Besides it, our trusted base includes correctness of our interval analysis, symbolic execution, and the implementations of helper functions such as mullo and mulhi. With this trusted base as well as the language and domain interpretations explained above, this paper has verified that, for $0 \le k \le 3$, $P_k$ is extensionally equal (modulo q) to $P_{k+1}$ (written $P_k =_{ext} P_{k+1}$): $P_3 =_{ext} P_4$ and $P_1 =_{ext} P_2$ in Sect. 4, $P_2 =_{ext} P_3$ in Sect. 5.3, and $P_0 =_{ext} P_1$ in Sect. 5.4.