Identical encryption keys generated for Ren'Py saves with the same password

Question

Ren'Py allows developers to encrypt save files with a user‑supplied password to deter casual tampering. The encryption routine derives the key via PBKDF2 using a hard‑coded salt value, so every save that uses the same password produces an identical key.
This design means that if a password is reused across projects or shared between users, an attacker who obtains one encrypted save can derive the key and decrypt any other save protected with that password, weakening resistance to rainbow‑table attacks. The current implementation does not expose an option to supply a custom salt or to select an alternative key‑derivation function, leaving the community to weigh security gains against compatibility risks.
What options exist to introduce a per‑save salt without breaking already‑encrypted saves?Is there a roadmap for exposing a configurable salt or KDF choice in a future Ren'Py release?How can developers assess the impact of changing the salt on existing save‑file compatibility?

Tasadduq Burney · Answer

Implementing Per-Save Salts in Ren'Py
To introduce a per-save salt without breaking existing save files, you must implement a versioned encryption wrapper. Because Ren'Py's built-in password system uses a static salt, you cannot change the global salt without invalidating all current saves. Instead, you must shift the salt from a hard-coded constant to a value stored within the save file metadata itself.

Implementation Strategy
The most viable path is to wrap the existing save data in a custom structure that includes a salt header. Follow these steps:

Generate a Unique Salt: For every new save operation, generate a random salt (e.g., 16 bytes using os.urandom()).
  Derive the Key: Use PBKDF2 with the user's password and this unique salt to generate the encryption key.
  Store the Salt: Prepend the raw salt to the beginning of the encrypted save file.
  Implement a Fallback Reader: When loading a save, check for a specific "magic byte" or header that indicates the new salted format. If the header is missing, fall back to the legacy static-salt decryption method.

Compatibility and Roadmap
There is currently no official roadmap for exposing a configurable salt or alternative KDF choices in the core Ren'Py engine. The current design prioritizes simplicity and cross-platform consistency over high-security cryptographic standards.

Assessing Compatibility Impact
Changing the salt is a destructive action for any file encrypted with the previous salt. To assess the impact, you can use the following verification process:

Binary Comparison: Encrypt two different save states with the same password. If the resulting ciphertexts are identical for identical data, the system is deterministic.
  Header Validation: Attempt to decrypt a legacy save using the new salted logic; it should fail immediately, triggering your fallback mechanism.

Diagnostic Requirement: Are you using a custom Python wrapper for save handling, or are you relying exclusively on the config.save_encryption_password variable? If you are using the built-in variable, you will need to override the save/load hooks in renpy.save and renpy.load to implement the salt header described above.

Identical encryption keys generated for Ren'Py saves with the same password

1 answer

Implementing Per-Save Salts in Ren'Py

Implementation Strategy

Compatibility and Roadmap

Assessing Compatibility Impact

Your perspective belongs here.

0 question comments