LIPPEN: A Lightweight In-Place Pointer Encryption Architecture for Pointer Integrity

Referee: §5 (Evaluation) and FPGA prototype description: The reported runtime, area, and power results support the performance claims relative to PAC baselines, but the evaluation does not include measurements of decryption latency variance, pipeline stall behavior, or handling of non-canonical addresses after decryption. These omissions directly affect the assertions of transparent decryption with negligible overhead and no new correctness or timing vulnerabilities.

Authors: We acknowledge the value of these additional metrics. In the revised §5 we have incorporated cycle-accurate measurements of decryption latency variance across repeated runs on both Rocket and BOOM FPGA prototypes, demonstrating low and consistent latency with no observable stalls beyond standard memory pipeline behavior. We have also added an explicit description of non-canonical address handling: post-decryption addresses that violate canonical form trigger the existing RISC-V fault mechanism without introducing new exception paths or timing side effects. These additions directly support the claims of transparent, low-overhead decryption. revision: yes

Referee: Abstract and §3 (Design): The manuscript asserts that full-pointer encryption with context binding resists brute-force, reuse, and implementation side-channel attacks, yet supplies no concrete attack evaluations, formal security arguments, or threat-model analysis. This is load-bearing for the central claim of strong integrity and confidentiality; the RISC-V and M1 comparisons address performance but not these security properties.

Authors: We agree that an explicit threat model improves clarity. The revised §3 now contains a dedicated threat-model subsection that defines the attacker (arbitrary memory read/write but no access to per-process encryption keys or context state) and explains how full 64-bit encryption plus context binding (process ID, thread ID, and stack pointer) raises the bar for brute-force (full 64-bit entropy) and reuse attacks (context mismatch causes decryption to invalid addresses). We supply informal security arguments grounded in the properties of the underlying block cipher and constant-time implementation; we do not add new empirical attack campaigns, as these lie outside the scope of a hardware-architecture paper, but the performance results remain focused on overhead while the security claims are now explicitly justified. revision: partial

Referee: §4 (Implementation): The design assumes the decryption primitive is constant-time and integrates into the pipeline without stalls or new fault behaviors. No timing analysis, gate-level details, or canonical-address fault handling is provided beyond the high-level FPGA prototype, leaving open whether real-silicon behavior undermines the negligible-overhead claim.

Authors: The FPGA synthesis reports already contain gate-level timing data; we have expanded §4 to present these numbers explicitly, confirming fixed-latency decryption with no data-dependent variation under the evaluated clock constraints. Pipeline integration is documented via cycle-accurate simulation showing zero additional stalls. Canonical-address faults after decryption are routed through the existing RISC-V memory fault path, preserving original exception semantics. Because the prototype is FPGA-based, we cannot supply fabricated-silicon measurements; the FPGA results nevertheless provide concrete evidence that the negligible-overhead claim holds under realistic hardware conditions. revision: partial