Considerations on using a single long-term key for file encryption
Is it sufficient to use a simple sequence number for each container and place it in the (authenticated) file header?


Yes, but making sure it is unique may be trickier than you think. Storing a counter is both error prone and it may hamper performance as well. What if you lose the .lock file (or similar) containing the number?


  Should I split the IV/nonce in a fixed and a sequential part (mentioned in RFC5116)?


If you want to, as long is it stays unique. This part of the standard seems particularly important if you've got multiple devices that each have their unique fixed ID. In that case the fixed ID can prevent the devices with coming up with the same nonce.

Personally I don't think you should use the same key in the first place. I don't consider RFC 5116 a strong standard and I would certainly not use it to draw cryptographic ideas from. Especially the part where the authentication tag is part of the ciphertext feels completely backwards to me (as it removes the online properties of AES-CTR that is used for most authenticated modes of encryption).


  Different approach?


Usually a symmetric key is generated for each file, which can then be wrapped by the master key. The advantage is that you can decrypt the data key and add other keys that may retrieve the data key. You may also be able to roll over to a new key that way. In other words, it simplifies key management. That kind of key management is harder to accomplish when using a KDF.


  But then again I could simply use the GUID as IV/nonce. Is there a benefit in creating individual key material for each container?


Yes, you'd be less vulnerable against catastrophic failure if the nonce ever repeats.



Be warned that you may want to protect against files being swapped as well.