1) salt must be generate randomly so it must be put not encrypted into the output file, isn't it? (IV-CIPHERTEXT-SALT-MAC)
Correct, although the more logical form would be SALT-IV-CIPHERTEXT-MAC in some kind of container format. This would be the order in which the other party would need the components to
- calculate the keys
- verify the data
- decrypt the data
2) saltlen has a correct "crypto" value or can i choose whatever i prefer? Like 10,20,30...
The bare minimum (for a highly secure system) would be 64 bits or 8 bytes, but since you are using high end crypto primitives, why not go for 256 bits secure random, to match your key size.
3) keysize (in this case) must be 512, right?
That is correct, the key size in bits must be 512. The API expects the KEYSIZE argument to be in octets so that would be 64 octets. It seems you want to perform MAC signing/verification. This requires a separate key from the one used for encryption/decryption. So you need two 256 bit keys, which fortunately matches the output of the SHA-512 algorithm. I said "fortunately" because you really don't want PBKDF2 to calculate another block - it would go through all the iterations once again.
The IV value is best calculated separately, and put in front of the ciphertext. You should include the IV value in the MAC calculation (otherwise the first block of plain text won't be verified). The IV should be a random block of data, so that would be 128 bits or 16 bytes of secure random data for AES.