Correct the comments about security requirements for IVs and counters.

README.rst

@@ -772,19 +772,28 @@ Cryptographic good practice
 ---------------------------
 
 Finally, make sure that you are using the cryptographic primitives
-properly and safely. That subject is beyond the scope of this manual;
-when in doubt, consult an expert. We want to emphasize the following
-points, but this list is by no means exhaustive:
+properly and safely. libgcrypt provides cryptographic building blocks,
+and the VMOD makes some of these available in VCL. But neither the
+library nor the VMOD can prevent you from using those building blocks
+improperly, thus undermining the security of your application.
+
+The proper use of cryptography is a subject that is beyond the scope
+of this manual; when in doubt, consult an expert. We want to emphasize
+the following points, but this list is by no means exhaustive:
 
 * The ECB mode of operation is included for testing purposes, but
   should *never* be used to protect sensitive data in insecure
   environments.
 
-* Initialization and counter vectors can be sent in the clear, and do
-  not need to generated in a secure way; for example, they do not need
-  to be obtained from cryptographic random number generators. But an
-  IV or counter should never be used twice with the same key, so make
-  sure that they are generated uniquely.
+* It is important to fulfill the uniqueness and predictability
+  requirements for the initialization and counter vectors used for
+  symmetric encryption, which depend in part on the mode of
+  operation. IVs and counters MUST be unique in all cases; they must
+  never be re-used with the same encryption key. For CBC mode, the IV
+  must also be unpredictable; for example, the ``STRONG`` quality
+  level should be used if the ``random()`` function is used to
+  generate IVs for CFB. For the other modes, unpredictability is not
+  required, and the ``NONCE`` level is sufficient.
 
 * Make sure that you have a secure procedure in place for generating
   and storing cryptographic keys, and for changing the keys

src/vmod_gcrypt.vcc

@@ -701,19 +701,28 @@ Cryptographic good practice
 ---------------------------
 
 Finally, make sure that you are using the cryptographic primitives
-properly and safely. That subject is beyond the scope of this manual;
-when in doubt, consult an expert. We want to emphasize the following
-points, but this list is by no means exhaustive:
+properly and safely. libgcrypt provides cryptographic building blocks,
+and the VMOD makes some of these available in VCL. But neither the
+library nor the VMOD can prevent you from using those building blocks
+improperly, thus undermining the security of your application.
+
+The proper use of cryptography is a subject that is beyond the scope
+of this manual; when in doubt, consult an expert. We want to emphasize
+the following points, but this list is by no means exhaustive:
 
 * The ECB mode of operation is included for testing purposes, but
   should *never* be used to protect sensitive data in insecure
   environments.
 
-* Initialization and counter vectors can be sent in the clear, and do
-  not need to generated in a secure way; for example, they do not need
-  to be obtained from cryptographic random number generators. But an
-  IV or counter should never be used twice with the same key, so make
-  sure that they are generated uniquely.
+* It is important to fulfill the uniqueness and predictability
+  requirements for the initialization and counter vectors used for
+  symmetric encryption, which depend in part on the mode of
+  operation. IVs and counters MUST be unique in all cases; they must
+  never be re-used with the same encryption key. For CBC mode, the IV
+  must also be unpredictable; for example, the ``STRONG`` quality
+  level should be used if the ``random()`` function is used to
+  generate IVs for CFB. For the other modes, unpredictability is not
+  required, and the ``NONCE`` level is sufficient.
 
 * Make sure that you have a secure procedure in place for generating
   and storing cryptographic keys, and for changing the keys