diff --git a/proposals/1946-secure_server-side_storage.md b/proposals/1946-secure_server-side_storage.md
index ca4230de..5e24b3ae 100644
--- a/proposals/1946-secure_server-side_storage.md
+++ b/proposals/1946-secure_server-side_storage.md
@@ -141,13 +141,23 @@ is encrypted and MACed as follows:
 
 (We use AES-CTR to match file encryption and key exports.)
 
+For the purposes of allowing clients to check whether a user has correctly
+entered the key, clients should:
+
+  1. encrypt and MAC a message consisting of 32 bytes of 0 as described above,
+     using the empty string as the info parameter to the HKDF in step 1.
+  2. store the `iv` and `mac` in the `m.secret_storage.key.[key ID]`
+     account-data.
+
 For example, the `m.secret_storage.key.key_id` for a key using this algorithm
 could look like:
 
 ```json
 {
   "name": "m.default",
-  "algorithm": "m.secret_storage.v1.aes-hmac-sha2"
+  "algorithm": "m.secret_storage.v1.aes-hmac-sha2",
+  "iv": "random+data",
+  "mac": "mac+of+encrypted+zeros"
 }
 ```
 
diff --git a/proposals/2472-symmetric-ssss.md b/proposals/2472-symmetric-ssss.md
index 4827e2cd..7fe9f179 100644
--- a/proposals/2472-symmetric-ssss.md
+++ b/proposals/2472-symmetric-ssss.md
@@ -43,6 +43,14 @@ is able to store data.
   bits that should be generated from PBKDF2 (in other words, the size of the
   key).
 
+* For the purposes of allowing clients to check whether a user has correctly
+  entered the key, clients should:
+
+  1. encrypt and MAC a message consisting of 32 bytes of 0 as described above,
+     using the empty string as the info parameter to the HKDF in step 1.
+  2. store the `iv` and `mac` in the `m.secret_storage.key.[key ID]`
+     account-data.
+
 * The `passthrough` property specified in the "Enconding the recovery key for
   server-side storage via MSC1946" section of MSC1219 is removed.  The primary
   purpose of that property was to allow easy migration of pre-MSC1946 backups,