Depends on the encryption-decryption system.
I've personally tended to use AES, for encrypting data with a default hash key for that program; then on each decryption generate a new hash that is stored securely.
If you make sure that the security system is actually something built-in to Windows (like Windows Encryption System) then you'll find that it makes it extremely difficult for people to trace, especially in Vista where the information is held within a protected area of the hard disk that there is no access to without going through an TCPA compliant CPU (basically anything AthlonXP/Pentium4 era and after) otherwise it destroys the data.
A main aspect that prevents tampering this way is it is a 2048bit protection system; so even if someone strong-armed it, you're looking at someone with a top-end (8 processor (cores) at 6GHz equivilant) pc a good 2 weeks just to hack it. That's running at full capacity, and no computer will remain stable at 100% usage for 2weeks straight; there has to be a dip in power else they burn out.
So unless they get lucky, it'll be too much trouble to break; especially given they'll also have to be running your app.
WES can be circumvented with a bootloader hack, but that hack has to be specific to your app. So unless you make the best thing since sliced bread the sheer fact of not having much space (512K) to play with in the boot-loader will prevent this. Sure they could change it each time they want to use something different, but they also would have to reboot each time. So it's not likely they'll bother.
Protection on the whole doesn't need to be solid, just solid enough to piss off anyone attempting to crack it so they give up.
A previous protection system I worked on a couple of years back basically ping-ponged with several key layers; which sure took about 25sec in all to get any data in/out, but that data would be commited straight to memory. The layers ment it couldn't be strong-armed (512-bit 8-Layer AES Protection) would just take far to bloody long for most.
It could've been hacked, but point is that realistically it made life hell for anyone trying. Just as soon as they think they had got one encryption the last one might invalidate. Meaning they'd have to start again.
Keeping encryption cycling is a very good way, it's how WiFi adapters do it with WEP iirc; where you first have a base key to lock a WiFi adapter that is set prior to starting. Then you store several other keys (upto 16 on mine) that every few minutes it'll cycle to the next. It then handshakes with part of the code that those adapters also have stored from when they initialise the connection. They recieve part of the hash, which then then check the hashs of the current keys they have to find a match and send back another part.
Due to the time limitation, means no forced entry is possible so a different approach has to be taken to break in to such networks; which again is possible but no system is fool proof.
That said with such systems it doesn't matter if the public know what is going on; atleast at the user level. Knowing what is going on in the background however gives hackers a starting point, but remember more processing power and built-in hardware encryption systems mean you can really make their life such a pain even if they knew exactly what was going on they would be left with only one choice .. strong-arm hacking, which requires far more power to keep up in real-time.
