AES 256 CBC - Storing local data, how to save IV vector? I want to use AES256 CBC for protecting small data (&lt;100kb) against misusage for my application in the local store folder. I'm not an expert at data encrypting so I'm to try to understand it step by step. 

I want to just make sure myself that I understand it well. I have a key for decrypting/encrypting and then IV which I generate for every new encrypting. And because IV is not a secret I can append it at the end of data something like that: encrypted data + IV and then during decrypting I just read the last 16 bytes and use the IV for decrypting. I'm right? Or is there any error I don't see?

My main intention is to hide data from the user and not allow them to change the data. So maybe, it would be better to use Authenticated Encryption (GCM?). What do you think? There are a lot of types of encryptions and I can't decide for any.

I'm using the OpenSSL library.
If you are using AES-CBC, You can store the IV however you like.  It is not important to keep the IV secret; you just need to make sure that an adversary cannot predict the IV in advance.

However, you have the right intuition that you should generally always use an authenticated cipher like AES-GCM.  AES-CBC is bad for other reasons too having to do with padding—AES-GCM provides a much better security contract all around than AES-CBC.  For AES-GCM, the only requirement of the nonce—sometimes also called an IV—is that it must be distinct for every message: you cannot reuse a nonce between two messages under a single key, and the consequences are fatal if you do.

That said…


  My main intention is to hide data from user and not allow them to change the data.


…it sounds like you are treating the user of your software as an enemy on their own computer.  If you're trying to do some kind of digital restrictions management (DRM) scheme, forget about it.  Not only is this hopeless—if it's happening on the user's own computer, the user can get the key anyway—but it is morally wrong to try to commandeer your users' own computers to work against their interests, and then penalize the ones who lack technical competence to work around your abuse of authority to run code on them.