CryptoSRAM: SRAM-Based Cryptographic Techniques

• CryptoSRAM is a family of SRAM-centric security techniques that harness inherent memory variations for unique key generation and authentication.
• It employs SRAM start-up values for both reconstructing secrets and executing cryptographic operations directly within the memory array.
• Demonstrated implementations achieve significant performance gains, with up to 74x throughput improvement for AES and effective mitigation of helper-data and side-channel risks.

Searching arXiv for recent and foundational papers on CryptoSRAM and related SRAM-PUF / in-SRAM cryptography. CryptoSRAM denotes a family of SRAM-centered cryptographic techniques in which SRAM is treated not merely as volatile storage but as a security primitive, a cryptographic compute substrate, or both. In the literature, the term encompasses SRAM physically unclonable functions (PUFs) for device-unique key generation and authentication, addressable SRAM start-up mechanisms for password or token reconstruction, and in-SRAM computing architectures that execute Boolean and cryptographic kernels directly inside the memory array. It also includes work on securing SRAM itself against data imprinting and remanence, as well as work showing that such protections are necessary because previously stored SRAM data can leave persistent aging-induced traces (Chen et al., 2017, Zhang et al., 26 Sep 2025, Hovanes et al., 2022).

1. Scope of the term and principal research lines

Within published work, CryptoSRAM has at least three distinct but related meanings. First, it refers to deriving cryptographic secrets from SRAM start-up behavior. Here, the power-up state of an SRAM array is interpreted as a PUF response: each cell spontaneously settles to $0$ or $1$, and process variation makes the resulting bitstring device-specific, reproducible enough for regeneration, and difficult to predict across devices. This line includes syndrome-based helper-data constructions, fuzzy extractors, and threshold-based authentication (Chen et al., 2017, Gao et al., 2019, Lehn et al., 17 Apr 2026).

Second, CryptoSRAM refers to on-demand secret reconstruction from addressable SRAM regions. In that formulation, a software-derived challenge, typically obtained from a hash, selects SRAM locations whose start-up values are concatenated into a password, token, or key. A representative implementation combines an Addressable PUF Generator with a ternary mask that excludes fuzzy cells, thereby avoiding explicit ECC and helper data in the reported design (Mohammadinodoushan, 2020).

Third, CryptoSRAM denotes in-SRAM cryptographic computing. In this usage, the SRAM array and its periphery are modified so that bitlines, wordlines, and sense amplifiers execute logic such as XOR, AND, NOR, shifts, and algorithm-specific dataflows for AES, SHA3, GHASH, or modular multiplication. Architectures in this category target microcontrollers, LLC-level memory encryption engines, and secure SRAM macros with erase or toggling support (Zhang et al., 26 Sep 2025, Zhang et al., 2022, Reis et al., 2021, Ku et al., 2024, Yin et al., 2023).

These meanings are technically different but share a common premise: SRAM’s circuit-level behavior can be elevated into a cryptographic resource. A plausible implication is that CryptoSRAM is best understood as an SRAM-centric security paradigm rather than a single mechanism.

2. SRAM-PUF secret generation and authentication foundations

The PUF-oriented branch of CryptoSRAM begins from the physics of the 6T SRAM cell. On cold boot, each cell’s cross-coupled inverters resolve to one of two stable states, and independent process variation makes the fraction of $1$s close to $0.5$. In the key-generation setting, an enrollment observation $X^N$ and a later authentication observation $Y^N$ are modeled as i.i.d. samples from a binary symmetric channel with crossover probability $p$, typically $15\%$ to $25\%$. One formulation uses

$$\Pr\{(X^N,Y^N)=(x^N,y^N)\}=\prod_{n=1}^N Q(x_n,y_n),$$

with $1$0 and $1$1 (Chen et al., 2017).

A canonical CryptoSRAM architecture separates enrollment and regeneration. During enrollment, the encoder computes $1$2, where $1$3 is the secret key and $1$4 is public helper data. During regeneration, the decoder receives $1$5 and $1$6, reconstructs $1$7, and verifies correctness by comparing $1$8 with the stored $1$9. In the polar-code syndrome construction, the helper data is the frozen-bit projection of the polar-domain codeword,

$1$0

where $1$1 with $1$2. Under uniformly distributed $1$3, the scheme proves zero leakage,

$1$4

because the columns of $1$5 indexed by $1$6 and $1$7 are disjoint and together span the full space (Chen et al., 2017).

In that same construction, polar codes are tailored to the BSC by freezing low-reliability bit-channels and allocating the key to reliable positions. With $1$8, $1$9, and rate $0.5$0, the reported implementation uses $0.5$1 SRAM-PUF bits and $0.5$2 helper bits. Successive cancellation alone reaches failure probability close to $0.5$3 at $0.5$4, whereas hash-aided successive cancellation list decoding with modest list size, including $0.5$5, achieves $0.5$6 at the same error rate. The decoder can be made adaptive: it starts with SC, checks the stored hash, and increases the list size only if the hash fails, thereby retaining average complexity near $0.5$7 while preserving worst-case $0.5$8 behavior (Chen et al., 2017).

A separate authentication line replaces full secret reconstruction with direct Hamming-distance thresholding. On ESP32-S3 MCUs, authenticated acceptance is defined by $0.5$9, with analytical impostor false-accept rate

$X^N$0

and genuine false-reject rate modeled from the post-stabilization genuine bit error $X^N$1 as

$X^N$2

That work defines the error-constrained security margin

$X^N$3

and reports that larger response lengths sharply widen the feasible operating window. Combined Hamming-code ECC and temporal majority voting reliably cap the post-authentication BER below $X^N$4 (Lehn et al., 17 Apr 2026).

3. Addressable CryptoSRAM and on-demand password reconstruction

A second interpretation of CryptoSRAM treats SRAM start-up values as an addressable secret source rather than as a monolithic PUF response. In the reported password-manager implementation, an Addressable PUF Generator reads selected SRAM cells from a Cypress CY7C1021CV26 $X^N$5 Mbit SRAM controlled by a Digilent chipKIT WiFire board based on a Microchip PIC32MZ, with the firmware implemented in the Arduino IDE. The APG uses an $X^N$6 kB region of SRAM as the PUF region (Mohammadinodoushan, 2020).

Enrollment in this system is a characterization step. The SRAM is cold-booted repeatedly, described as “hundreds” of cycles, and each candidate address is labeled $X^N$7, $X^N$8, or $X^N$9 according to whether the cell powers up stably as $Y^N$0, stably as $Y^N$1, or ever flips. This produces a ternary mask $Y^N$2. The system stores only the mask or stable-cell indexes, and optionally the logical-to-physical address mapping; it does not store raw PUF bits (Mohammadinodoushan, 2020).

During reconstruction, the password is hashed with SHA-256 to produce a $Y^N$3-byte digest $Y^N$4. An expander then rotates the two most significant bytes of $Y^N$5 through eight rotations, hashes each rotated variant with SHA-256, and concatenates the resulting $Y^N$6 into a $Y^N$7-byte “Long MD”. Splitting this value into $Y^N$8 $Y^N$9-bit words yields $p$0 SRAM addresses inside the designated PUF region. If an address maps to a fuzzy cell $p$1, the Ternary Addressable PUF Generator replaces it with the next non-fuzzy address. Reading the resulting $p$2 cells after cold boot produces a $p$3-bit response $p$4 (Mohammadinodoushan, 2020).

The central design choice is that reliability is achieved by masking rather than by helper-data-based ECC. The reported implementation states that T-APG reduces BER by removing fuzzy cells and substituting stable neighbors, though it does not numerically report BER reductions. This suggests a CryptoSRAM design point optimized for simple embedded deployment: the attack surface associated with helper data is avoided, but enrollment becomes more stringent because stability must be established up front (Mohammadinodoushan, 2020).

A closely related lightweight formulation appears in energy-harvesting beat sensors. There, the microcontroller’s normal operating mode already consists of repeated power-up and power-down cycles, which aligns naturally with SRAM-PUF evaluation. The reported system samples $p$5 SRAM bits from addresses $p$6 to $p$7, groups them into $p$8-bit blocks, classifies stable and unstable positions across $p$9 samples, and then applies a spatially weighted thresholding algorithm. With threshold $15\%$0, the procedure selects on average $15\%$1 positions per block and limits observed flips to at most $15\%$2 across the tested conditions, allowing a lightweight Hamming-code fuzzy extractor and subsequent SHA-256 derivation of a $15\%$3-bit key (Pham et al., 10 Aug 2025).

4. In-SRAM cryptographic computing architectures

The compute-oriented branch of CryptoSRAM moves cryptographic operations into SRAM arrays and their periphery. One reported microcontroller architecture modifies a fraction of standard MCU SRAM subarrays to be “ISC-enabled”. Each such subarray adds a second row decoder, a command decoder, and modified sense amplifiers that support bitline Boolean logic and $15\%$4-bit shifts via a small per-column MUX and a flip-flop. The control interface exposes six commands: $15\%$5, $15\%$6, $15\%$7, $15\%$8, $15\%$9, and $25\%$0. The reported hardware overhead is approximately $25\%$1 SRAM area (Zhang et al., 26 Sep 2025).

That architecture targets MCUs precisely because physical addressing and DMA make operand placement deterministic. AES is mapped by bit slicing, with AddRoundKey executed as in-SRAM XOR, SubBytes realized by a logic-only Boyar–Peralta-style circuit, ShiftRows implemented by repeated $25\%$2-bit shifts, and MixColumns realized through shift-plus-XOR formulations over $25\%$3. SHA3 is mapped lane-per-row, so that the Keccak steps

$25\%$4

become combinations of XOR, row remapping, NOT, AND, and shifts. On STM32L562, the reported throughput at $25\%$5 MHz reaches $25\%$6 MB/s for AES-128-CBC at $25\%$7 ISC-enabled SRAM, compared with $25\%$8 MB/s in software and $25\%$9 MB/s for the hardware AES engine. For SHA3-256, the reported throughput is $$\Pr\{(X^N,Y^N)=(x^N,y^N)\}=\prod_{n=1}^N Q(x_n,y_n),$$0 MB/s versus $$\Pr\{(X^N,Y^N)=(x^N,y^N)\}=\prod_{n=1}^N Q(x_n,y_n),$$1 MB/s in software. The paper summarizes this as up to $$\Pr\{(X^N,Y^N)=(x^N,y^N)\}=\prod_{n=1}^N Q(x_n,y_n),$$2 throughput improvement over software for AES, up to $$\Pr\{(X^N,Y^N)=(x^N,y^N)\}=\prod_{n=1}^N Q(x_n,y_n),$$3 for SHA3, and up to $$\Pr\{(X^N,Y^N)=(x^N,y^N)\}=\prod_{n=1}^N Q(x_n,y_n),$$4 over existing AES hardware accelerators (Zhang et al., 26 Sep 2025).

A related LLC-level design, “Sealer,” treats SRAM subarrays as a memory encryption engine. It uses $$\Pr\{(X^N,Y^N)=(x^N,y^N)\}=\prod_{n=1}^N Q(x_n,y_n),$$5 6T subarrays partitioned into six tiles, stores the AES S-box in the first eight columns, and fuses AddRoundKey, SubBytes, ShiftRows, and MixColumns through bitline compute and small sense-amplifier modifications. The reported peripheral overhead is less than $$\Pr\{(X^N,Y^N)=(x^N,y^N)\}=\prod_{n=1}^N Q(x_n,y_n),$$6, and the architecture achieves up to two orders of magnitude throughput-per-area improvement while consuming $$\Pr\{(X^N,Y^N)=(x^N,y^N)\}=\prod_{n=1}^N Q(x_n,y_n),$$7 less energy than prior solutions. Relative to AIM-SRAM, the reported gain is $$\Pr\{(X^N,Y^N)=(x^N,y^N)\}=\prod_{n=1}^N Q(x_n,y_n),$$8 in throughput-per-area; relative to AIM-NVM it is greater than $$\Pr\{(X^N,Y^N)=(x^N,y^N)\}=\prod_{n=1}^N Q(x_n,y_n),$$9 (Zhang et al., 2022).

The same broad idea extends beyond AES and SHA3. “IMCRYPTO” combines a compute-enabled SRAM with dual-mode RA/CAM arrays to execute AES encryption and decryption within a unified in-memory structure. Its reported throughput-per-area gains over prior ASICs and IMC architectures range from $1$00 to $1$01, and the reported area-delay-power-product gains range from $1$02 to $1$03 for CMOS-based IMCRYPTO (Reis et al., 2021). “ModSRAM” adapts the CryptoSRAM notion to public-key arithmetic: it uses an 8T SRAM PIM array with in-situ $1$04-input logic to realize carry-save modular multiplication through the R4CSA-LUT algorithm. For $1$05-bit modular multiplication, it reports $1$06 cycles at $1$07 MHz, corresponding to approximately $1$08, with $1$09 fewer cycles than prior in-/near-memory approaches and $1$10 area overhead relative to a regular SRAM macro (Ku et al., 2024).

At the circuit level, one important CryptoSRAM direction is secure in-memory XOR. A $1$11-transistor SRAM cell implemented and simulated in GlobalFoundries $1$12 nm adds two compute-gating devices and one isolation device to a conventional 6T cell. In XOR mode, operand $1$13 is the stored cell value, operand $1$14 is injected per column via a Data Line, and a dedicated compute bitline BLR drives a two-step conditional reset and conditional flip sequence. This enables single-cycle, massively parallel array-level XOR across more than two rows and also supports array-wide toggling and erase. The paper reports that with BLR at $1$15 V, the conditional reset completes within approximately $1$16 in the tested Monte Carlo case, while read, static, and write noise margins remain close to the 6T baseline (Yin et al., 2023).

A further extension is context co-location. A ROM-augmented 8T SRAM uses multi-$1$17 read-port devices so that the same bitcell can store RAM data and a ROM overlay simultaneously. In dual-context mode, the SRAM bit is read first and the ROM bit is then sensed by adjusting the shared source-line bias and reference threshold. The reported benefits are $1$18 storage density versus an 8T SRAM with a separate ROM bank and $1$19 versus a 6T SRAM baseline, with dual-context read delay/bit of $1$20 and read energy/bit of $1$21 relative to standard 8T SRAM (Kaiser et al., 2023).

5. Security properties, attack surfaces, and misconceptions

One recurrent CryptoSRAM misconception is that SRAM loses all security relevance once power is removed. A direct challenge to that assumption appears in work on aging-imprint recovery. Using six commercial Microchip $1$22 Kbit serial SRAM chips, accelerated aging at $1$23, and repeated measurements of initial power-up and final power-up states, the reported attack partially recovers previously stored SRAM content from a nominally volatile memory. Power-up states were captured $1$24 times at $1$25-hour intervals to classify stable and unstable cells, and a recognizable imprint was reported after only $1$26 hours of accelerated aging, with a clearer impression by $1$27 hours. Aggregating multiple chips aged with the same content improves recovery via majority voting (Hovanes et al., 2022).

The mechanism is transistor aging rather than residual charge. Long-term storage of a logical value biases device thresholds through NBTI, with possible contributions from PBTI and HCI, so that the final power-up state becomes statistically complementary to the aged data. The reported threat model assumes an adversary able to record initial power-up fingerprints at manufacturing time and to reacquire chips after retirement. This makes CryptoSRAM security dependent not only on present-time remanence but also on cumulative usage history. A plausible implication is that any design storing static secrets in fixed SRAM locations must treat zeroization, relocation, and retirement as first-class security problems rather than as operational details (Hovanes et al., 2022).

A second misconception is that helper data inevitably degrades secrecy. The literature is more nuanced. In the polar-code syndrome construction for SRAM-PUF key generation, the helper data is proven to satisfy $1$28 under uniformly distributed $1$29, so the public syndrome does not reduce the secrecy of the extracted key (Chen et al., 2017). By contrast, other works explicitly caution that ECC parity or secure-sketch data can leak structural information if misused, and that helper-data attacks and ML-assisted prediction must be considered when moving from authentication to key derivation (Lehn et al., 17 Apr 2026).

Conversely, avoiding helper data does not eliminate all leakage. The T-APG password-manager design stores no raw PUF bits and no ECC helper data, but it does rely on a ternary mask indicating which cells are stable; that mask itself reveals where stable cells are located and is therefore identified as something that should be protected, for example in secure flash or by a device-bound derivation process (Mohammadinodoushan, 2020).

In compute-oriented CryptoSRAM, side-channel exposure remains an open issue. In-SRAM execution reduces off-array data movement and can thereby reduce one class of bus-toggling leakage, but simultaneous row activations, sense-amplifier activity, and whole-column line swings create new power and EM signatures. Current works explicitly note that masking, constant-time scheduling, balanced activation, randomized row masks, or related countermeasures are not yet incorporated into the reported designs (Zhang et al., 26 Sep 2025, Zhang et al., 2022, Yin et al., 2023).

6. Design trade-offs and deployment patterns

CryptoSRAM design is fundamentally an optimization over response length, stabilization cost, helper-data footprint, latency, energy, and threat model. In constrained authentication systems, one reported conclusion is that larger response lengths make aggressive reliability optimization increasingly unnecessary. On ESP32-S3 devices, increasing the response length from $1$30 to $1$31 bits improves the error-constrained security margin by approximately $1$32 at $1$33, whereas moving from $1$34 to $1$35 votes or switching to the most redundant Hamming-code ECC each adds approximately $1$36 at $1$37 bits. Tightening $1$38 from $1$39 to $1$40 reduces the margin much less when $1$41, where $1$42 (Lehn et al., 17 Apr 2026).

For extremely constrained devices, the dominant architectural choice is whether decoding occurs on-device or off-device. A representative solution for batteryless CRFID devices uses a reverse fuzzy extractor so that the tag performs only encoding and hashing. The reported single-reference RFE uses $1$43 blocks of BCH$1$44, $1$45 helper bits, and $1$46 cycles on MSP430FR5969. A three-reference variant, MR$1$47FE, uses references enrolled at $1$48, $1$49, and $1$50, reduces the code to $1$51 blocks of BCH$1$52, reduces helper data to $1$53 bits, and lowers the reported cost to $1$54 cycles while still achieving $1$55. BLAKE2s-128 is reported as the fastest among the evaluated hashes, at $1$56 cycles per call in the given setup (Gao et al., 2019).

Energy-harvesting beat sensors illustrate a different deployment point. Their power-on/transmit/power-off rhythm naturally enforces the cold-boot condition needed by SRAM PUFs. There the reported strategy is not heavy ECC but aggressive preselection: $1$57 samples, spatial weighting of stable runs, threshold $1$58, and a Hamming-code fuzzy extractor sufficient because the selected $1$59-bit response exhibits at most one flip across the tested temperature and aging scenarios. The final secret is obtained by SHA-256 and split into two operational keys (Pham et al., 10 Aug 2025).

For in-SRAM computing, the primary trade-off is between memory capacity and cryptographic throughput. Compute-enabled subarrays occupy only a fraction of SRAM in some designs, with $1$60, $1$61, and $1$62 ISC-enabled fractions reported as explicit scaling points. This allows a system to balance general-purpose memory use against cryptographic bandwidth. A plausible implication is that CryptoSRAM is especially well matched to MCU-class systems whose physical addressing and DMA already make fine-grained SRAM placement controllable in software (Zhang et al., 26 Sep 2025).

Across all variants, CryptoSRAM replaces or supplements conventional secret storage with device physics, memory-array parallelism, or both. Its mature forms already support $1$63-bit key generation from SRAM-PUFs with $1$64, threshold-based authentication with post-authentication BER below $1$65, addressable password reconstruction without raw-secret storage, AES and SHA3 acceleration with throughput improvements reported up to $1$66 and $1$67 over software, and secure array-level toggling or erase primitives. At the same time, the literature shows that SRAM cannot be treated as automatically self-sanitizing, and that helper-data security, side-channel hardening, and retirement-time sanitization remain central to any comprehensive CryptoSRAM deployment (Chen et al., 2017, Lehn et al., 17 Apr 2026, Zhang et al., 26 Sep 2025, Hovanes et al., 2022).