Compare commits

...

1 Commits

Author SHA1 Message Date
Michael Kirk
e64d373b29 Increase receiver chain count from 5 -> 10
When we ratchet, we can immediately use the new sending chain safely,
however, we have to retain some number of old receiving chain to be able
to decrypt any in-flight messages, or messages that arrive out of order
(i.e.  messages that were *sent* before we ratcheted, but not received
until after we ratcheted).

The tradeoff is storage size (how many old chains we keep around per
session) vs resilience (how many ratchet steps do we maintain the
ability to decrypt with).

Usually message delivery is quick and serial and this isn't an issue.
However sometimes message delays of several minutes have been observed.
If this delay occurs *while* the parties are engaged in an active
back-and-forth, sending messages every few seconds, it's very likely
we'll ratchet past the threshold and see bad decrypted messages.

// FREEBIE
2017-08-16 12:33:31 -04:00

View File

@ -8,6 +8,7 @@
#import "SendingChain.h"
#import "ChainAndIndex.h"
const NSUInteger kMaxReceivingChainCount = 10;
@implementation PendingPreKey
@ -181,11 +182,11 @@ static NSString* const kCoderPendingPrekey = @"kCoderPendingPrekey";
ReceivingChain *receivingChain = [[ReceivingChain alloc] initWithChainKey:chainKey senderRatchetKey:senderRatchetKey];
[self.receivingChains addObject:receivingChain];
if ([self.receivingChains count] > 5) {
// We keep some old receiving chains to be able to decrypt out of order messages.
if ([self.receivingChains count] > kMaxReceivingChainCount) {
DDLogInfo(
@"%@ Trimming excessive receivingChain count: %lu", self.tag, (unsigned long)self.receivingChains.count);
// We keep 5 receiving chains to be able to decrypt out of order messages.
[self.receivingChains removeObjectAtIndex:0];
}
}