diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 55f33a2f5f..06e1c077d5 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1588,7 +1588,33 @@ export PGCMKLOOKUP
card numbers). But if there are signficant length differences between
valid values and that length information is security-sensitive, then
application-specific workarounds such as padding would need to be applied.
- How to do that securely is beyond the scope of this manual.
+ How to do that securely is beyond the scope of this manual. Note that
+ column encryption is applied to the text representation of the stored value,
+ so length differences can be leaked even for fixed-length column types (e.g.
+ bigint, whose largest decimal representation is longer
+ than 16 bytes).
+
+
+
+ Column encryption provides only partial protection against a malicious
+ user with write access to the table. Once encrypted, any modifications to a
+ stored value on the server side will cause a decryption failure on the
+ client. However, a user with write access may still freely swap encrypted
+ values between rows or columns (or even separate database clusters) as long
+ as they were encrypted with the same key. Attackers may also remove values
+ by replacing them with nulls, and users with ownership over the table schema
+ may replace encryption keys or strip encryption from the columns entirely.
+ All of this is to say: proper access control is still of vital importance
+ when using this feature.
+
+
+
+ When using the RSA-OAEP CEK encryption methods, the "public" half of the CMK
+ may be used to replace existing column encryption keys with keys of an
+ attacker's choosing, compromising confidentiality and authenticity for
+ values encrypted under that CMK. For this reason, it's important to keep
+ both the private and public halves of the CMK keypair
+ confidential.