I'm writing a little program to encrypt and decrypt a file. I'm using AES encryption in CTR mode that takes a key generated by a KDF (script). I have read some articles about cryptography but I have some doubts. To encrypt the file I divide it in chunks and I encrypt them with AES generating a random nonce for every chunk. For key derivation I generate a random salt for every file. Do I need a different salt for every chunk or for every file it's enough? Do I need a padding with CTR mode? Should I follow other guidelines for a correct encryption? Thank you!!
I'm using AES encryption in CTR mode that takes a key generated by a KDF (script).
You should use authenticated encryption unless you have a strong reason not to. For example, AES-GCM, or AES-CTR with HMAC-SHA256 in encrypt-then-MAC composition like the scrypt(1) utility uses. If you're not sure, use authenticated encryption.
If you are sure you have a strong reason not to use authenticated encryption, you should have a design document articulating (a) what you're trying to accomplish with what resources, (b) what powers the adversary has to subvert those resources, and (c) what security properties you want to provide to the legitimate users in spite of that—and a clear justification that the adversary's powers enumerated in (b) exclude the ability to modify ciphertext.
Actually, you should write that design document anyway! But the use of unauthenticated encryption will definitely raise a lot of eyebrows if you don't have a clear justification for it.
For key derivation I generate a random salt for every file. Do I need a different salt for every chunk or for every file it's enough?
As long as you generate each key independently for each file (which you do already, if you derive it from a password using a random salt generated independently for each file) and never reuse it outside the file, you can safely reuse the key for all the chunks in the file as long as you use a distinct nonce for each chunk.
To encrypt the file I divide it in chunks and I encrypt them with AES generating a random nonce for every chunk.
Random nonces with AES-CTR (or AES-GCM) are generally unsafe because for plausibly large volumes of data the collision probabilities are uncomfortably high, and nonce reuse is catastrophic.
In this case it may be that you won't ever have a file with more than a few million chunks, which is safe for 64-bit nonces, but I don't know that and I wouldn't rely on it. Even if you choose 96-bit nonces, which you can safely use if your chunks are never more than a gigabyte, a few billion chunks may be a plausibly large volume of data.
- If you used NaCl crypto_secretbox_xsalsa20poly1305, random nonces have negligible collision probability because they're 192 bits long, longer than AES can support directly or efficiently.
Even with authenticated encryption, an adversary may be able to cut and paste chunks to put them out of order or delete them or duplicate them.
- You can kill two birds with one stone by using sequential nonces: use the chunk's sequence number in the file as a nonce. Even with 64-bit nonces, you won't ever get a collision sequentially (you'll hit birthday bounds on the 128-bit block cipher first, and it will take centuries unless you parallelize the computation), and if you demand that the nonce match the chunk's sequence number in the file then even an adversary who can modify the file can't put the chunks out of order.
Do I need a padding with CTR mode?
CTR mode does not require padding. CTR mode is just a way to use a block cipher with a key and a per-message nonce to generate a one-time pad in any bit length you want.
All that said: Consider using an existing construction for many-chunk files?