A number of encryption functions include their tuning parameters in the output. For example, SCrypt, which I've been considering for an app I'm building, outputs in the following format:
It seems to me that if an attacker didn't know these values, it'd make life harder for them... but if my app doesn't know the values, then it makes things tricky for me and my users. I understand that many implementations then go on to hash this output to obscure the parameters; I presume that there is therefore a way of doing this that doesn't weaken the overall scheme or increase the chance of collisions. However, by my understanding, if this second hashing pass is reversible, then it's of limited use because an attacker can reverse it as easily as we can and get the parameters we were trying to hide from them - and if it's not reversible, then we still have the problem of the parameters being inaccessible to us as well, so I don't see how it's that different from just cutting the parameters off. I could always have the parameters as constants in the app's code, of course, but that then relies on the quality of my code obfuscation, which is something I've never been too confident about (call it healthy paranoia). It also means I couldn't migrate users from old versions without losing their passwords and anything else I have encrypted, and setting up logic to use the old and new methods in parallel seems to me like having two doors instead of one, which feels less secure.
Do these parameters really need protecting from attackers, and if so, what's the safest way to do so?