As for traditional cryptographic channels induced by stateful AE schemes, a stream-based channel should allow secure transmission of data between two parties that share secret key material. In contrast to the former schemes, however, the data to be transmitted is a stream rather than a sequence of messages. From a functionality perspective, we view stream-based channels as a mathematical abstraction of reliable network protocols like the Transmission Control Protocol (TCP) [Pos81]. In what follows we formalize what ‘transmitting a stream of data’ actually means.
For stream-based channels we define message space and ciphertext space to be the set of bit strings, i.e., M = C = {0, 1}∗, as it is usually the case for real-world channel implementations.
In fact, we understand messages and ciphertexts not as atomic units but as fragments (i.e., substrings) of a message stream and of a ciphertext stream. Additionally, we do not stipulate a particular input/output behavior on the sender side but allow the sending algorithm Send to process input data at its discretion, e.g., implementing some form of buffering. This is different from the approach chosen by Boldyreva et al. [BDPS12] for modeling symmetric encryption supporting ciphertext fragmentation. There, fragmentation may occur at the receiver, while the
(from application)
m1 m2 m3 m4 m5 message stream
c1 c3 c4 c5 ciphertext stream
Send
(lower-layer transmission)
c01 c02 c03 c04 c05 ciphertext stream
m01 m02 m04 m05 message stream Recv
(to application)
Figure 3.1: Illustration of the behavior of the Send and Recv algorithms of a stream-based channel, indicating the message and ciphertext fragments being sent (mi resp. ci) and received (m0i resp. c0i).
sender only processes atomic messages (i.e., each ciphertext output by Enc is the encapsulation of the input message). To enforce that particular chunks of the message stream are sent out within a specific invocation of Send we employ the established concept of ‘flushing a stream’
known from network socket programming, and provide the Send algorithm with an auxiliary input, namely a flush flag f ∈ {0, 1}, for each call. If the flush flag is set to f = 1 then all message fragments that Send has buffered so far are processed instantaneously; otherwise, the algorithm may internally decide to accept more message fragments, to empty its buffer, or to send out only parts of it, depending on its implementation and resources. We note that our model also captures implementations that, instead of offering an explicit flushing mechanism, keep buffering their input until a specified timeout is reached. Figure 3.1 illustrates the behavior of the sending and receiving algorithms of a stream-based channel.
We proceed with defining the syntax and the correctness condition of stream-based channels.
Definition 7 (Stream-Based Channels). A stream-based channel Ch = (Init, Send, Recv) with state spaceS and error space E, E∩{0, 1}∗= ∅, consists of three efficient probabilistic algorithms:
• Init. The initializtion algorithm takes as input a security parameter 1λ and outputs ini-tial states stS, stR ∈ S for the sender and the receiver, respectively. We write this as (stS, stR) ←$Init(1λ).
• Send. The sending algorithm takes as input a state stS ∈ S, a message fragment m ∈ {0, 1}∗, and a flush flag f ∈ {0, 1}, and outputs an updated state st0S ∈ S and a ciphertext fragment c ∈ {0, 1}∗. We write (st0S, c) ←$ Send(stS, m, f ).
• Recv. The receiving algorithm takes as input a state stR∈ S and a ciphertext fragment c ∈ {0, 1}∗, and outputs an updated state st0R∈ S and a fragment m ∈ ({0, 1} ∪ E)∗. We write (st0R, m) ←$Recv(stR, c).
Our syntax allows Send to return an empty output. This is to model the situation that no flush is requested and the input fragment is too short to be processed, thus, it is buffered
for later sending. In our definition below, for any message fragment m processed by Send we denote by c the (potentially empty) resulting ciphertext output by the algorithm. We stress that c should not be interpreted as an encapsulation of m (i.e., we do not require that c decrypts to m, as we explain later), but as a label for the output of Send on input m (and the current sending state). Similar considerations hold for Recv, which may as well buffer its input and return an empty output for the moment. Observe that our syntax lets Recv output a ‘string’ of message bits, error symbols fromE, or a combination of these; this is to capture the case that a portion of an input fragment c causes the receiving algorithm to return some message bits, while the rest of it is declared as invalid, leading to a string of errors. Note that in contrast to the other channel notions considered in this thesis, stream-based channels do not support associated data.1
Before formalizing the functionality of stream-based channels we set some notation used throughout this chapter. For a fixed state pair (stS,0, stR,0), an integer ` ≥ 0, and tuples of message fragments m = (m1, . . . , m`) ∈ {0, 1}∗∗ and of flush flags f = (f1, . . . , f`) ∈ {0, 1}∗, let (stS, c) ←$Send(stS,0, m, f ) be shorthand for the sequential execution (stS,1, c1) ←$ Send(stS,0, m1, f1), . . . , (stS,`, c`) ←$ Send(stS,`−1, m`, f`) with c = (c1, . . . , c`) and stS = stS,`. For ` = 0 we define c to be the empty vector and stS,` = stS,0 to be the initial state. We use an analogous notation for the receiver’s algorithm.
Correctness requires that if Send is fed with a message stream, and later (a prefix of) the resulting ciphertext stream is processed by Recv, then no matter how the ciphertexts are fragmented at the sender’s side and re-fragmented at the receiver’s side (provided that the order of the bits is preserved), the returned message stream must be a prefix of the initial message stream. Moreover, when Recv consumes a full ciphertext fragment generated by a call to Send with the flush flag set to 1, the stream output by Recv should contain all the message fragments input to Send up to that call. We formalize this intuition in the definition below.
Definition 8 (Correctness of based channels). Let Ch = (Init, Send, Recv) be a stream-based channel. We say that Ch provides correctness if for all state pairs (stS,0, stR,0) ←$ Init(1λ), all `, `0 ∈ N, all choices of the randomness for algorithms Init, Send and Recv, all message-fragment vectors m ∈ ({0, 1}∗)`, all flush-flag vectors f ∈ {0, 1}`, all output se-quences (stS,`, c) ←$ Send(stS,0, m, f ), all ciphertext-fragment vectors c0 ∈ ({0, 1}∗)`0, and all output sequences (stR,`0, m0) ←$ Recv(stR,0, c0), we have for every 1 ≤ i ≤ ` : fi = 1 that
kc[1, . . . , i] 4 kc0 4 kc =⇒ km[1, . . . , i] 4 km0 4 km .
Our interpretation of correctness for stream-based channels is as follows. If the receiver obtains (in an arbitrarily fragmented way) a prefix kc0 of the string kc of ciphertexts created by the sender for an input-message vector m = (m1, . . . , m`) and flush-flag vector f = (f1, . . . , f`), and if the string kc0 contains the concatenation c1k . . . k ci of the first i ciphertexts of c, then the message string km0 returned on the receiver’s side contains as a prefix the concatenation m1k . . . k mi. In particular, if the last sending invocation flushed its input then the receiver outputs the full genuine message stream.
Remark 1. Let us compare our correctness condition for stream-based channel with that defined by Boldyreva et al. [BDPS12] for symmetric encryption supporting ciphertext fragmentation (abbreviated as FrSE throughout the thesis). There, correctness requires that if a sequence m of discrete messages is encrypted, and the resulting ciphertext streamkc is then decrypted (possibly in a fragmented manner), then the obtained message sequence (when message separators ¶ are removed) is identical to the original sequence m. In the special case of a single message, this
1Indeed, the concept of associated data seems to be meaningful only in the atomic setting.
implies that encryption ‘always flushes’ in the setting of [BDPS12], and is in turn the reason why encryption is necessarily an atomic operation. By contrast, in our setting the Send algorithm is equipped with a flush flag and, when the latter is set to zero, potentially the entire message fragment is buffered for delayed sending. This is, then, an essential difference between the setting of Boldyreva et al. [BDPS12] and ours. An additional difference is that the correctness condition in [BDPS12] is technically stronger than ours as it incorporates a certain amount of
‘robustness’. More specifically, the sequence of ciphertext fragments c0submitted for decryption in the correctness definition of [BDPS12] may extend the sequence produced by encryption, i.e., kc is only required to be a prefix of kc0 for decryption to still work correctly up to kc. We find such a correctness requirement artificially strong as it explicitly demands correct decryption also in case of an active attack (which appends non-genuine fragments to a genuine stream).