1
$\begingroup$

I want to use AES256 CBC for protecting small data (<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.

$\endgroup$
  • 1
    $\begingroup$ Yes. I fixed it. Thanks :) $\endgroup$ – Filip Procházka Nov 7 at 18:25
3
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Certainly a better reply then mine... But I never really understood why the IV must be different with each message IF you reuse the same key, because, the message is different every time so the ciphertext is different every time..right? $\endgroup$ – Ömer Enes Özmen Nov 7 at 17:40
  • 1
    $\begingroup$ @ÖmerEnesÖzmen The nonce must be different in each message under AES-GCM for the same reason that a one-time pad loses all security when you use the same pad twice as a two-time pad. $\endgroup$ – Squeamish Ossifrage Nov 7 at 17:41
  • $\begingroup$ Thank you for your reply. There are information about product version (trial etc.). I know that if a user wants it, they gets the key from the application no matter what I do but it can't be so easy for them than just to change the readable file. $\endgroup$ – Filip Procházka Nov 7 at 17:46
  • $\begingroup$ @FilipProcházka Right, so you're commandeering users' own computers to work against them, and penalizing the ones who lack technical skills. That is not cool. Don't do it. $\endgroup$ – Squeamish Ossifrage Nov 7 at 17:47
  • 1
    $\begingroup$ @FilipProcházka In that case, just use AES-GCM like you were going to after reading my answer! (And maybe quietly polish your resume so you can find an employer whose business model does not involve commandeering people's devices to abuse them for profit extraction. Of course, capitalism makes the morality of the whole thing a bit sticky, but there's plenty of opportunities for subversion and harm reduction within the system!) $\endgroup$ – Squeamish Ossifrage Nov 7 at 18:54
0
$\begingroup$

I am not familiar with openSSL, but adding the IV to the end of the message is fine, because with the IV alone, you can't do anything useful, UNLESS you have the key.

$\endgroup$
  • $\begingroup$ In practice, it is common that the IV is prepended and the authentication tag is appended. IV||encrypted_text||tag $\endgroup$ – kelalaka Nov 8 at 11:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.