The encrypted file can be bigger than the decrypted version for a bunch of different reasons, that's like what's going on here.
Video engineer currently implementing MPEG Common Encryption here:
Actually, there is.
MPEG CENC (Common Encryption) uses AES CTR and requires conveying one initialization vector for each audio/video frame. Those are generally 16-byte long.
To make the matter (a little) worse, MPEG CENC adds signalization to the file, to specify which parts of the streams are encrypted or not: indeed, for remux-without-decrypt reasons, each video frame must have its headers in cleartext.
In fine, you get some dozen of bytes of overhead per audio/video frame ; do the math.
Of course, this overhead remains negligible and could by no means explain a 30% size reduction when decrypting.