Skip to content
Tech News
← Back to articles

A Copy-Paste Bug That Broke PSpice AES-256 Encryption

read original more articles
Why This Matters

A critical bug in PSpice's AES-256 encryption mode 4 significantly reduces the effective keyspace, allowing attackers to brute-force the decryption of proprietary SPICE model files. This vulnerability compromises the security of vendor IP, highlighting the importance of robust encryption practices in protecting intellectual property within the semiconductor industry.

Key Takeaways

Security research

A Copy-Paste Bug That Broke PSpice® AES-256 Encryption

PSpice is a SPICE circuit simulator from Cadence Design Systems that encrypts proprietary semiconductor model files to protect vendor IP and prevent reuse in third-party SPICE simulators. The encryption scheme is proprietary and undocumented.

Many third-party component vendors distribute SPICE models exclusively as PSpice-encrypted files, locking them to a single simulator and preventing their use in open-source and alternative tools such as NGSpice, Xyce, and PySpice. As part of research into these encryption schemes, I’ve released SpiceCrypt — a Python library and CLI tool that decrypts encrypted SPICE model files, restoring interoperability so engineers can use lawfully obtained models in any simulator.

PSpice supports six encryption modes (0–5). Modes 0–3 and 5 derive all key material from constants hardcoded in the binary; once those constants are extracted, files in these modes can be decrypted directly. Mode 4 is the only mode that incorporates user-supplied key material: vendors provide a key string via a CSV file referenced by the CDN_PSPICE_ENCKEYS environment variable. This key is XOR’d with the hardcoded base keys during derivation, so decryption requires the same key file. A bug in key derivation reduces the effective keyspace to 2^32, making the user key recoverable by brute force in seconds.

The Bug

Mode 4 uses AES-256 in ECB mode. Key derivation starts from two base strings:

g_desKey : a 4-byte “short” base key ( "8gM2" )

: a 4-byte “short” base key ( ) g_aesKey : a 27-byte “extended” base key ( "H41Mlwqaspj1nxasyhq8530nh1r" )

When a user provides a key via the CDN_PSPICE_ENCKEYS CSV file, user key bytes 0–3 are XOR’d into the short base, and bytes 4–30 are XOR’d into the extended base. A version suffix (e.g., "1002" ) is then appended to each base key.

... continue reading