* the verification key-id if the message is signed.
*
* Next comes the key-encapsulation chunk. This is decrypted in some
- * KEM-specific way to yield a secret hash. This hash is what is signed if
- * the message is signed. The hash is expanded using an MGF (or similar) to
- * make a symmetric encryption and MAC key.
+ * KEM-specific way to yield a secret hash. The hash is expanded using an
+ * MGF (or similar) to make a symmetric encryption and MAC key.
*
* If the message is signed, there comes a signature chunk. The signature is
- * on the secret hash. This means that the recipient can modify the message
- * and still have a valid signature, so it's not useful for proving things to
- * other people; but it also means that the recipient knows that the message
- * is from someone who knows the hash, which limits the possiblities to (a)
- * whoever encrypted the message (good!) and (b) whoever knows the
- * recipient's private key.
+ * on the further output of the MGF. This means that the recipient can
+ * modify the message and still have a valid signature, so it's not useful
+ * for proving things to other people; but it also means that the recipient
+ * knows that the message is from someone who knows the hash, which limits
+ * the possiblities to (a) whoever encrypted the message (good!) and (b)
+ * whoever knows the recipient's private key.
*
* Then come message chunks. Each one begins with a MAC over an implicit
* sequence number and the ciphertext. The final chunk's ciphertext is