On 03/02/2017 05:54 PM, Hal Murray wrote: > > cry...@brainhub.org said: >> I also think that counting in blocks is cleaner. Counting in bytes is a >> close alternative. > > Does counting bytes work? If the real limit is blocks, I think you will have > to round up the byte count when you send a partial block. > > If re-keying too often isn't too expensive, you could get a safe answer by > counting bytes and assuming that every byte went in a separate block. > > You might want to round down many more orders of magnitude so the re-key code > gets exercised often enough. Or maybe provide a back door to set the limit > so that path can be tested with reasonable resources. >
I like the idea of setting the rekey limits, so that the code can be tested. There is no 3DES in TLS 1.3. You refer to some under-counting. The worst case is mod 16 = 1 byte sized TLS records, in which case the "tails" will only be counted as 1 block per 16 TLS records v.s. desired 16. We are undercounting less than one 16-byte block per record. One can count in record_size_in_bytes + 16 as one solution (overcount). However, is it true that 1-byte terminal blocks must be counted as full 16-byte blocks? 1-byte blocks don't seem to directly apply to the proofs with distinguishing game. With 1-byte plaintext / ciphertext we are not making statements about two values from the 1^128 members space. Rather, we are discussing two values from the tiny 256 members space. Also, a truncated AES-GCM encryption behaves as PRF and not PRP. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
