Make initialization vector dependant on password or random seed in `ReversibleRenamer` instead of input data

[KvanTTT]

I suggest the following options:

1. Calculate IV (initialization vector) based on a password or hardcoded string. It's not secure safe but does not differs from the current scheme because ConfuserEx sources are open and encrypted IV into input data does not provide additional security and only consumes one byte.
2. Calculate IV based on seed if it's specified. If not then generate a random IV and dump it into the output file. This value or seed can be used later during stack trace decryption. This way looks much more secure safe since it can generate different identifiers every run despite the same encryption key. But it has drawback: IV value from value is required together with the encryption key (I don't think it's a big problem).

[mkaring]

I do not fully understand the major advantage of what you are proposing. We can easily change the way the IV is calculated, that isn't much of an issue. But it still needs to be part of the encoded name to ensure that decoding with only the password is possible.

The advantage of the current implementation is that the IV is different for every name, only deriving it from the seed would change that, but even if we create the IV from the name, the seed and the password used, it still wouldn't add much additional security I can see.

I'd like to avoid adding a secondary password that is used create the IV. Two keys aren't more secure than one.

[KvanTTT]

The advantage of the current implementation is that the IV is different for every name

This does not differ from the implementation with just hardcoded and constant IV because once you get the key you are able to decrypt all names despite the fact that IV is inlined into the encrypted name.

I'd like to avoid adding a secondary password that is used to create the IV. Two keys aren't more secure than one.

It's more secure if the seed is different for every obfuscation (random), but not the constant.

[KvanTTT]

The current deobfuscation scheme with reversible mode allows attackers to use the same map encrypted_id → id for the present and future versions of an application. The map can be built one time for valuable identifiers.

It is not possible if a random seed will be used on every obfuscation step.

Also, see the description on Wikipedia:

The IV is typically required to be random or pseudorandom, but sometimes an IV only needs to be unpredictable or unique. Randomization is crucial for some encryption schemes to achieve semantic security, a property whereby repeated usage of the scheme under the same key does not allow an attacker to infer relationships between (potentially similar) segments of the encrypted message. For block ciphers, the use of an IV is described by the modes of operation.

[mkaring]

I got it, I got it :wink: I'll change it to use the random value generator that is based on the seed.

[KvanTTT]

I also can implement it but later 😃

I suggest using the current scheme if seed is defined (for instance, seed="", seed="qwer"), but without inlined IV in encrypted data because it does not make sense. If a seed is not defined it will be generated every run and will be stored in Seed file alongside with Symbols.map.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.