AES-GCM cipher tag and IV size, while attempting to render encrypted ciphertext useless by removing them I'm using AES in GCM mode of operation for encryption/decryption &amp; authentication of segments of data in a file. The layout of each segment can be summerized by this diagram. Each segment is basically (enc-)decrypted separately from one another, using their individual (randomly generated) IV and Tag: 



The encryption process of such segment is done as follows:



While decryption &amp; auth would be carried out as such:



So let me explain my dilemma.

I'm trying to optimize the situation when one of those segments (pictured above) is deleted. The head-on approach would be to zero it out on disk. But, for the purpose of optimization, I was thinking to delete only its IV and Tag, thus hoping to make decryption of that segment's data computationally infeasible. But this brings up two points:


IV size of 12 bytes seems kinda low for that. I know that that is the default size of the IV for AES-GCM. But would I benefit in this scenario if I increase the IV size to 32 bytes? So that way if I remove a 256-bit IV, will it render the encrypted data "safe to discard"?
Tag itself. Is it used for decryption or just for authentication? In other words if I clear it out for my purpose of discarding the encrypted data, will it even matter. I was playing with the actual function that does AES-GCM decryption (implemented using Crypto++ function named CryptoPP::GCM&lt;CryptoPP::AES&gt;::Decryption::DecryptAndVerify()) and it seems to return different plaintext if I alter the tag, but I'm not 100% sure about it.
But, for the purpose of optimization, I was thinking to delete only its IV and Tag, thus hoping to make decryption of that segment's data computationally infeasible.


Neither work.  The IV might seem to work (as doing a brute force search over a space of size $2^{96}$ might appear to be daunting), however the attacker has another potential approach.

If an attacker has the ciphertext, has a correct guess to 16 bytes of the plaintext, and the key, he can recover the IV; from there, he can recover the rest of the plaintext.

Because of the likelihood of the attacker guessing 16 bytes of plaintext, this wouldn't appear to be feasible.

And, the tag is even worse (and so is the AAD, in case that occurs to you); an attacker with the key, iv and ciphertext can trivially decrypt the ciphertext without the tag.  He might not be certain that the ciphertext hasn't been modified; however he might be willing to assume that it wasn't.

Since I gave you two negative answers, lets give you a positive idea; why don't you make the key generation procedure:

key :=SHA2( master key || extra data )


Where the extra data is stored on in the segment header (and nowhere else); it is generated randomly when you first encrypt; when you decide to do a quick erasure, you overwrite it. The master key is the one derived from the password with PBKDF2.

If this extra data is at least 256 bits long, recovering the key is no easier than attacking AES-256 directly.