18 reputation
3
bio website selliott.org
location Austin, TX
age
visits member for 1 year, 1 month
seen Sep 23 at 17:42

I'm Steven Elliott, a computer programmer in Austin, TX.


Sep
24
awarded  Autobiographer
Oct
7
awarded  Student
Oct
6
awarded  Scholar
Oct
6
accepted Making counter (CTR) mode robust against application state loss
Oct
6
comment Making counter (CTR) mode robust against application state loss
The zero byte aside (which I still think makes sense) I like your overall approach. I think either approach will work, but your approach is easier to understand and analyze mathematically with regard to the probability of a collision. Also, there is less data to store with the cipher (only the first 96 bits in your example as opposed to nearly 160 bits for my approach). Possibly obvious - the size of the 48 random bits can be adjusted based on the longest message possible. So I'll accept your answer assuming stackexchange will let me with my lack of reputation.
Oct
6
comment Making counter (CTR) mode robust against application state loss
Let's say that instead of the 0 byte we have a counter ("C") byte. Also, let's say that for two consecutive nonces the lower nonce is combined with the highest possible random counter value and the higher nonce is combined with the lowest possible random counter value. So for one message the first counter block is 123456FFFFFFFFFF and for the next message the first counter block is 1234567000000000. In this case there is a collision as soon as the counter is incremented for the first message, which is what I was trying address. But a zero bit would work too.
Oct
6
comment Making counter (CTR) mode robust against application state loss
As to the point of the zero ("0") byte - my goal was to make the system rock solid in the functioning case (#1 and #2), but to work somewhat well in the degraded case (#3). In the functioning case the zero byte guarantees a minimum number (25610 - 2569) of blocks that can be encrypted before running into the next possible nonce.
Oct
6
comment Making counter (CTR) mode robust against application state loss
Good point about the malicious NTP resets. And I agree that you don't want your PRNG to be correlated with the time since it would redundant, but a good PRNG should get bytes from /dev/urandom, or something like that. Your proposed system is good too - good odds in exchange for fewer blocks (2**32) that can be encrypted per message.
Oct
6
comment Making counter (CTR) mode robust against application state loss
Thanks for your feedback. When you talk about the system time being reset do you mean that the nonce stored in the database is also lost (my case #3)?
Oct
5
asked Making counter (CTR) mode robust against application state loss