Commented by: @aafemt

ALTER DATABASE DECRYPT is better to be disabled completely. It won't help much, just close one of the ways to get decrypted database without modifying engine. Encryption of a database should be a one way ticket.

Commented by: Ann Harrison (awharrison)

Surely the Alter Database Decrypt requires the encryption key ...

Commented by: @aafemt

Yes, but in the case of superserver received key in secondary connection is neither checked nor used.

Commented by: @AlexPeshkoff

Ann, certainly (like any other operation on encrypted database) it's decryption requires the key. But as I see the problem here is that currently a key can be used by db crypt manager silently for any purpose - decrypt blocks needed for normal DB operation or decrypt hole database block by block. I.e. before decryption of whole database crypt manager should ask crypt plugin - is it OK to decrypt the database?

Disabling ALTER DATABASE DECRYPT is not an option IMHO - someone may need this operation (for example) in order to later encrypt it with new, better one plugin.

Commented by: @aafemt

IMHO, decrypting of a database is a task for standalone utility, operating on file level. "Encrypted" flag must stay on header till the end of whole process. Better yet, decryption should go into a new file to preserve original database on error.
Engine must throw error if encounter an encrypted page in unencrypted database, not silently load last known plugin.

Commented by: @asfernandes

> Yes, but in the case of superserver received key in secondary connection is neither checked nor used.

Why?

Commented by: @AlexPeshkoff

Protected encrypted checksum of valuable fields with hash stored in DB header. Check hash to be valid on database open.
In 3.0 check it only for databases having crypt process active to avoid problems when upgrading minor FB version.