diff --git a/src/openvpn/crypto_epoch.c b/src/openvpn/crypto_epoch.c
index 54225bf..37933a1 100644
--- a/src/openvpn/crypto_epoch.c
+++ b/src/openvpn/crypto_epoch.c
@@ -308,9 +308,10 @@
         free_key_ctx(&co->key_ctx_bi.encrypt);
 
         /* Update the epoch_key for send to match the current key being used.
-         * This is a bit of extra work but since we are a maximum of 16
-         * keys behind, a maximum 16 HMAC invocations are a small price to
-         * pay for not keeping all the old epoch keys around in future_keys
+         * This is a bit of extra work but since we are a maximum of
+         * epoch_data_keys_future_count keys behind (4 by default),
+         * a maximum 4 HMAC invocations are a small price to pay for not
+         * keeping all the old epoch keys around in future_keys
          * array */
         while (co->epoch_key_send.epoch < new_epoch)
         {
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index fd96b85..01e45fd 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -1343,10 +1343,14 @@
 init_epoch_keys(struct key_state *ks, struct tls_multi *multi, const struct key_type *key_type,
                 bool server, struct key2 *key2)
 {
-    /* For now we hardcode this to be 16 for the software based data channel
+    /* For now we hardcode this to be 4 for the software based data channel
      * DCO based implementations/HW implementation might adjust this number
-     * based on their expected speed */
-    const uint8_t future_key_count = 16;
+     * based on their expected speed.
+     *
+     * One epoch lasts 910 GiB with 128 byte packets or 78s at 100 GBit/s.
+     * (respectively 1011 GiB and 86s with 1280 byte packets).
+     */
+    const uint8_t future_key_count = 4;
 
     int key_direction = server ? KEY_DIRECTION_INVERSE : KEY_DIRECTION_NORMAL;
     struct key_direction_state kds;