spice-crypt

It's even worse than the key derivation. from the poster's Github repo, https://github.com/jtsylve/spice-crypt/blob/v2.0.1/SPECIFICA...: Modes 0–2 use a custom DES variant that retains the standard 16-round Feistel network structure but differs from FIPS 46-3 in its permutation tables, S-boxes, and key rotation direction. Why would you need a custom DES variant? Did Cadence have a cryptographer on staff? Or did they license this DES-variant? Or was a three-letter US government agency involved? Looks like the DES-related modes were developed back before crypto code export restrictions were relaxed.

v2 Adds support for PSpice, which should hopefully cover the TI models. Let me know if not. https://github.com/jtsylve/spice-crypt

I posted SpiceCrypt (https://github.com/jtsylve/spice-crypt) a few days ago for decrypting LTspice models. It now supports all six PSpice encryption modes as well. PSpice is Cadence's SPICE simulator. Vendors encrypt component models with it, which locks them to PSpice and prevents use in NGSpice, Xyce, etc. Modes 0-3 and 5 derive keys entirely from constants in the binary, so those are straightforward once you extract them. Mode 4 is the interesting one. It's the only mode with user-supplied key material and uses AES-256 in ECB mode. The key derivation has two base keys: a 4-byte short key (originally for DES) and a 27-byte extended key (intended for AES). The code passes only the short key to the AES engine -- it looks like a copy-paste from the DES path that was never corrected. The short key gets null-terminated and zero-padded to 32