Very interesting - note that crypto is hard. This isn't nearly as practical, nor as wise, nor as safe as using gpg* to do the encryption for you, but it is interesting. Any particular reason you're doing this in C# rather than using SQL Server T-SQL functions and/or using an external program like gpg?
Critical: The IV should be randomly generated with a cryptographic random number generator like RNGCryptoServiceProvider, not static or, in your case, derived from the key. This will allow the code to generate different ciphertext when it uses the same key to encrypt the same file contents, and any adversary can no longer trivially gain that information (though they can, of course, see that the two files are within 15 bytes in size).
This implementation is not FIPS compliant; for that, you would need to use AesCryptoServiceProvider instead.
You should set the CipherMode deliberately. And if you choose ECB, the ghosts of encryption past will force you to use Windows ME forever... unpatched.
You should strongly consider using a much higher number of PBKDF2-HMAC-SHA1 rounds in Rfc2898DeriveBytes.
*If you use gpg:
Get the latest GPG4Win or GnuPG
If you use public keys rather than symmetric cryptography:
Generate your key with at least
gpg --gen-key --cert-digest-algo SHA256
to ensure you're using a modern hash algorithm (SHA384 or SHA512 are also good)
Use at least a 2048 bit RSA key, higher if you want possible security greater than 10-30 years
Immediately after key generation, use gpg --edit-key <key> and consider updating cipher preferences:
setpref SHA512 SHA384 SHA256 SHA224 AES256 CAMELLIA256 AES192 CAMELLIA192 AES CAMELLIA128 3DES BZIP2 ZLIB ZIP Uncompressed
If you're in the US and subject to FIPS, remove Camellia. If you're in Japan or the EU and subject to those regulations, consider putting Camellia ahead of AES (or remove AES).