The password hashing business is about turning a password (which is weak, by definition) into a sequence of bits suitable for storage (password verification token) or use as an encryption key (in which case we are doing password-based key derivation). In order to tolerate the use of passwords, we have to follow some strict rules:

• Use slow hashing with a lot of iterations (that's easier said than done, so don't get creative and use a well-studied standard like bcrypt or PBKDF2).
• Never ever reuse a salt value for another password instance. Indeed, if two passwords are hashed with the same salt, then attacking one will allow attacking the other "for free".

However, once you have turned the password into a key, you can use it as any key. If your encryption system is not laughably frail, there should be no problem with using the same key to encrypt many files. In the case of something AES-based, this implies, indeed, a new IV for each file. The properties of that IV depend on the actual encryption mechanism; AES-CBC requires a random, uniform, unpredictable IV, while some newer modes like GCM only need a non-repeating IV and thus work well with a simple counter.

Note that many password-based encryption scheme use a salt-and-iterations system to hash the password into a sequence of bits containing both the key and the IV. Such systems cannot be used for more than one file; otherwise, you will reuse the IV, and that's a deadly sin (usually worse than reusing a salt, which is already quite bad). If you want to reuse the key resulting from the password hashing, then you MUST generate a new IV for each encryption run.

Also, note that if two files are encrypted with the same password-derived key, chances are that their headers will include the salt (you have to put it somewhere, so that it is available for decryption), so you will leak the information that both files are protected with the same password, and thus have the same source. Depending on your context, this may or may not be a problem for you.

Other people have found it convenient to use the simple expedient of storing their ten files into a single Zip archive and encrypting that as one file. Depending on your context, this may be applicable (or not), and is much simpler to implement without botching the crypto layer. In general, designing your own encryption format and assembly of algorithms is a path fraught with perils, and you cannot know whether you did it right or not (security is not functionality: it cannot be tested).

The password hashing business is about turning a password (which is weak, by definition) into a sequence of bits suitable for storage (password verification token) or use as an encryption key (in which case we are doing password-based key derivation). In order to tolerate the use of passwords, we have to follow some strict rules:

• Use slow hashing with a lot of iterations (that's easier said than done, so don't get creative and use a well-studied standard like bcrypt or PBKDF2).
• Never ever reuse a salt value for another password instance. Indeed, if two passwords are hashed with the same salt, then attacking one will allow attacking the other "for free".

However, once you have turned the password into a key, you can use it as any key. If your encryption system is not laughably frail, there should be no problem with using the same key to encrypt many files. In the case of something AES-based, this implies, indeed, a new IV for each file. The properties of that IV depend on the actual encryption mechanism; AES-CBC requires a random, uniform, unpredictable IV, while some newer modes like GCM only need a non-repeating IV and thus work well with a simple counter.

Note that many password-based encryption scheme use a salt-and-iterations system to hash the password into a sequence of bits containing both the key and the IV. Such systems cannot be used for more than one file; otherwise, you will reuse the IV, and that's a deadly sin (usually worse than reusing a salt, which is already quite bad). If you want to reuse the key resulting from the password hashing, then you MUST generate a new IV for each encryption run.

Also, note that if two files are encrypted with the same password-derived key, chances are that their headers will include the salt (you have to put it somewhere, so that it is available for decryption), so you will leak the information that both files are protected with the same password, and thus have the same source. Depending on your context, this may or may not be a problem for you.

Other people have found it convenient to use the simple expedient of storing their ten files into a single Zip archive and encrypting that as one file. Depending on your context, this may be applicable (or not), and is much simpler to implement without botching the crypto layer. In general, designing your own encryption format and assembly of algorithms is a path fraught with perils, and you cannot know whether you did it right or not (security is not functionality: it cannot be tested).