I don't know what "the digest of pickle data with some salt padding" means (when you say "salt", you trip the "talking about crypto using words only lay programmers use" sensor), but it sure doesn't sound crypto-safe. There are a number of easy-to-make errors with digest schemes that allow attackers to make constrained modifications to documents without breaking the digest.
Long story short, don't do this; instead, PGP/GPG encrypt and sign the pickled file. GPG is strictly better across all axes than hand-hacking your own protection scheme.
Or just hash it and keep a whitelist if you don't need to get too heavy-duty. Though I would personally just go for signing the file -- don't necessarily need to encrypt it unless you have sensitive data in there -- then you just have to keep track of the key instead of maintain a whiltelist of good hash values.
For what I've read salt is a commonly used term in cryptology, and refers to certain schemes for key derivation for hashing/encrypting. Salt can either be public (to make brute-force attacks infeasible) or private (for better security).
Almost always when pickling we're only interested in one aspect of security that is integrity: what we put in is what we get out. Encryption isn't needed and signing doesn't really offer much more with regard to this case. Instead, cross-checking against a message digest to make it hard to modify pickles (or any runtime data offloaded to disk) seems to be almost idiomatic. YMMV.
Not that I wouldn't want to write a fancy GPG based persistent storage but generally it would be an overkill. And overkills, in my experience, are good at blinding the developers from other threats. YMMV.
There are many good, proven message digest algorithms that are useful for implementing a simple salted hashing scheme. In practice, an application developer must eventually take algorithms for granted. We consider MD5 demonstrably weak but SHA, especially variations with longer digests, we consider strong enough for most purposes. So given the assumption that we can trust SHA, I'm sure you're familiar with something like the following:
- take the pickle output from pickle.dumps()
- create some random data and use it as salt
- run the pickle output + salt through hashlib.sha512() or whichever you prefer to obtain the message digest
- store the pickle output somewhere, even in public
- store the message digest somewhere, even in public
- store the salt some place safe
- recompute and verify before calling pickle.loads()
You still have to have trust in some storage that you consider safe. Computing the salt dynamically from a set of fixed and/or runtime values could be done by anyone, and is merely security by obscurity. However, exactly the same applies to GPG: you would have to store the private and public keys somewhere safe, and go from there.
And finally, as for me, I'd probably create more security holes in implementing the GPG integration than just sticking with the standard Python hashlib.
There are a number of easy-to-make errors with digest schemes that allow attackers to make constrained modifications to documents without breaking the digest.
Long story short, don't do this; instead, PGP/GPG encrypt and sign the pickled file. GPG is strictly better across all axes than hand-hacking your own protection scheme.