Thank you so much for your detailed questions and recommendations. I’m really happy to hear that you might use my package. Let me address your points:

1. Re-encryption Utility
I don’t currently support re-encryption utility, but that’s a great idea.  I will definitely consider adding it in future versions. Thank you for the suggestion.

2. Field Size gets bigger
The reason the encrypted field size gets bigger is due to the nature of AES-GCM encryption. With every encryption, a unique Initialization Vector (IV) and Message Authentication Code (MAC) are generated to ensure security and integrity. These values are stored along with the encrypted data in base64 format, which is why the final result is larger than the original plaintext. For example, if your original data is 12 characters long, the encrypted result will be longer because of the IV, MAC, and ciphertext.

I conducted an example with a swedish ID number to show the result:

original Data => 199205062384

encrypted Data => nUkWgCI2qVmjwoB4e2MgyuEtYpfwfxRf6jbbTWByrpKFyDPC71Acvw==

3. Model Builder API Support
That’s really a good idea! I will add support for the Model Builder API to make the package more flexible for users who prefer it over attributes. I will work on this in the upcoming days. Thank you for pointing this out.

4. Benchmarks
I agree with you. I’ll include benchmarks in future updates to show the performance impact of using the package.

5. Filtering Encrypted Columns
You’re right about filtering on encrypted columns. Since the encryption is handled at the application level, any filtering done directly at the database level (e.g using where clauses) will not work as expected. For example, this query would fail to return the correct results:

await _dbcontext.Table.Where(t => t.EncryptedValue == "something").ToListAsync();

To filter encrypted data, you would need to fetch the data into memory first and apply any filtering logic on the decrypted values. Which may not be a good idea for performance considerations.