Why String Encryption Wants Per-Call-Site Keys

One key for everything, or one per call site

If every string in a jar is decrypted with the same key, an analyst who recovers that key, or the decryptor that holds it, reads all of them at once. A contextual key narrows the damage: each call site gets its own, so recovering one does not hand over the rest.

HashGuard exposes this as the optional contextual key of the string transformer. The contextualStringKey option also derives the string crypto IVs from the owning class, so the class a string lives in is part of what protects it.

The question is not only how strong the cipher is, but what one recovered key is worth.

• Pool-sharded: the string pool is split into shards.
• Each shard is encrypted with AES-CTR and compressed with zlib.
• multiAlgoStrings varies the AES modes across classes to break signatures.
• cryptoKeyBits sets the AES key size, 128 in the example configuration.
• stringEncryptMode sets the strength and the runtime decryptor mode, Balanced in the example.

Lighter decryptors

When AES is more than you need, two XOR-based options exist. polyString is a per-class XOR-chain polymorphic string decryptor. jntPolyString is a per-call-site XOR plus key polymorphic decryptor in the jnt style. Both are false in the example configuration.

A decryptor has to reach its own class. On Java 9 and later HashGuard uses privateLookupIn, and a Java 8-safe invokedynamic fallback covers Java 8.

• comparisonObfuscation replaces String.equals() with a hashCode plus Integer.equals() proxy, with a collision fallback.
• staticFieldInit moves static String and Integer ConstantValue fields into <clinit> as PUTSTATIC.