From: George Kadianakis <desnacked@riseup.net>
Date: Thu, 14 Jun 2018 12:23:09 +0000 (+0300)
Subject: Increase OPE_INPUT_MAX.
X-Git-Tag: tor-0.3.5.1-alpha~206^2~11
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=34a5eb5904896cfbfb8c2729fe3b029fab6deb39;p=thirdparty%2Ftor.git

Increase OPE_INPUT_MAX.
---

diff --git a/src/lib/crypt_ops/crypto_ope.h b/src/lib/crypt_ops/crypto_ope.h
index 885ce84b2a..823524f84e 100644
--- a/src/lib/crypt_ops/crypto_ope.h
+++ b/src/lib/crypt_ops/crypto_ope.h
@@ -13,8 +13,18 @@
 /** Length of OPE key, in bytes. */
 #define OPE_KEY_LEN 32
 
-/** Largest value that can be passed to crypto_ope_encrypt() */
-#define OPE_INPUT_MAX 131072
+/** Largest value that can be passed to crypto_ope_encrypt().
+ *
+ *  Expressed as 2^18 because the OPE system prefers powers of two.
+ *
+ *  The current max value stands for about 70 hours. The rationale here is as
+ *  follows: The rev counter is the time of seconds since the start of an SRV
+ *  period. SRVs are useful for about 48 hours (that's how long they stick
+ *  around on the consensus). Let's also add 12 hours of drift for clock skewed
+ *  services that might be using an old consensus and we arrive to 60
+ *  hours. The max value should be beyond that.
+ */
+#define OPE_INPUT_MAX (1<<18)
 
 typedef struct crypto_ope_c crypto_ope_t;