Manuscript.

Provably Fixing the SSH Binary Packet Protocol

Mihir Bellare

Tadayoshi Kohno

Chanathip Namprempre

June 2002
Abstract
The Secure Shell (SSH) protocol is one of the most popular cryptographic protocols on the
Internet. Unfortunately, the current SSH authenticated encryption mechanism is insecure. In
this paper we propose several xes to the SSH protocol and, using techniques from modern
cryptography, we prove that our modied versions of SSH meet strong new chosen-ciphertext
privacy and integrity requirements. Furthermore, our proposed xes will require relatively little
modication to the SSH protocol (or to SSH implementations). We believe that our new notions
of privacy and integrity for encryption schemes with stateful decryption algorithms will be of
independent interest.
Keywords: Authenticated Encryption, Secure Shell, SSH, Stateful Decryption, Security Proofs.

Dept. of Computer Science & Engineering, University of California at San Diego, 9500 Gilman Drive, La Jolla,
California 92093, USA. E-Mail: [email protected]. URL: http://www-cse.ucsd.edu/users/mihir. Supported in
part by NSF Grant CCR-0098123, NSF Grant ANR-0129617 and an IBM Faculty Partnership Development Award..

Dept. of Computer Science & Engineering, University of California at San Diego, 9500 Gilman Drive, La Jolla,
California 92093, USA. E-mail: [email protected]. URL: http://www-cse.ucsd.edu/users/tkohno. Supported
by a National Defense Science and Engineering Graduate Fellowship.

Dept. of Computer Science & Engineering, University of California at San Diego, 9500 Gilman Drive, La Jolla,
California 92093, USA. E-mail: [email protected]. URL: http://www-cse.ucsd.edu/users/cnamprem. Supported
in part by grants of rst author..
1
Contents
1 Introduction 3
2 The SSH Binary Packet Protocol 5
3 Attack Against the Standard Implementation of SSH 6
4 Attacks Against a Natural Fix 6
5 Secure Fixes to SSH 9
6 Provable Security Results 10
6.1 Denitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2 Security Notions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3 SSH Security Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7 Discussion and Recommendations 17
A Formal Notions of Security 21
B General Security Results for the Encode-then-E&M Paradigm 24
B.1 Chosen-Plaintext Privacy (Proof of Lemma 6.4) . . . . . . . . . . . . . . . . . . . . . 24
B.2 Integrity of Plaintexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.3 Obtaining Chosen-Ciphertext Privacy (Proof of Proposition 6.2) . . . . . . . . . . . 29
C SSH Proofs 29
C.1 Proof of Lemma 6.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
C.2 Proof of Theorem 6.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2
1 Introduction
Conceived as a secure alternative to traditional Unix tools like rsh and rcp [25], the IETF stan-
dardization bodys Secure Shell (SSH) protocol [15]
1
has become one of the most popular and
widely used cryptographic protocols on the Internet. Because of its popularity and because of the
insecurity of programs like rsh and telnet, a number of institutions only allow users to remotely
access their facilities using SSH. The cryptographic heart of the SSH protocol is its Binary Packet
Protocol (BPP) [26]; the BPP is responsible for the underlying symmetric encryption and authen-
tication (or the authenticated encryption) of all messages sent between two parties involved in an
SSH connection.
Although others have discussed specic properties of the SSH BPP (e.g., problems with not using
a MAC [24] or problems with SSHs use of CBC mode [8]), to the best of our knowledge no one
has performed a rigorous, provable security-based analysis of the entire SSH BPP authenticated
encryption mechanism. Our goal was thus to thoroughly analyze the SSH BPP authenticated
encryption scheme and, in the event that we found any problems, to present provably-secure xes
to the protocol.
In order for our xes to be as useful as possible to the Internet community, when developing
our xes we considered both (1) provable security and (2) eciency. Additionally, since retroac-
tively modifying existing implementations is often very expensive, we required that our suggested
modications (3) not signicantly alter the current SSH specication. For the last point, we note
that the creators of SSH had the foresight to design the SSH BPP in a modular way: in particular,
it is relatively easy to change the SSH BPPs underlying encryption and message authentication
modules.
Analysis and provably secure recommendations. The SSH BPP specication says that SSH
implementations should use CBC mode encryption [9] with chained initialization vectors (IVs);
i.e., the IV used when encrypting a message should be the last block of the previous ciphertext.
Unfortunately, CBC mode encryption with chained IVs is insecure [21], and this insecurity extends
to SSH (this extension was also reported by Dai [8]).
Since CBC mode encryption with chained IVs is insecure, but CBC mode with random IVs
is provably secure against chosen-plaintext attacks [1], a natural x to the SSH protocol might
be to replace the use of chained-IV CBC mode with randomized CBC mode. Unfortunately, we
show that doing so is not sucient. In particular, since the SSH specication does not require the
padding to be random, the resulting SSH implementation may be vulnerable to a rather serious
reaction-attack (a privacy attack that works by modifying a senders ciphertexts and observing the
receivers response).
We next present several secure xes to the SSH authenticated encryption mechanism. For ex-
ample, we suggest using randomized CBC mode encryption; the dierence between this suggestion
and the suggestion in the above paragraph is that we require at least one full block of random
padding (this could, however, result in having to encipher more blocks than the previous SSH al-
ternative). We also suggest another CBC variant that does not require additional random padding:
CBC mode where the IV is generated by encrypting a counter with a dierent key. As an addi-
tional alternative, we suggest replacing the underlying encryption scheme with a variant of counter
(CTR) mode [10, 20] in which both the sender and receiver maintain a copy of the counter. We
also present a framework within which to analyze other possible replacements.
One important advantage of these xes over the current SSH specication is provable security.
Making reasonable assumptions (e.g., that SSHs underlying block cipher is secure), we are able
1
SSH version 1.5 [25] and SSH version 2.0 [15] are radically dierent (e.g., version 1.5 uses 32-bit CRCs for
authenticity). We therefore focus our analysis on SSH version 2.0.
3
to show that our alternatives will preserve privacy against adaptive chosen-plaintext and adaptive
chosen-ciphertext attacks. We also show that our alternatives will resist forgery, replay, and out-
of-order delivery attacks. Finally, we argue that our alternatives, and especially the latter two, also
satisfy the other two requirements listed above (eciency and ease of modication). (We note that
our CTR mode construction addresses the concerns with CTR mode raised in [5].)
Theoretical contributions. The previous notions of privacy [1] and integrity [17, 3] for authen-
ticated encryption schemes only address encryption schemes with stateless decryption algorithms.
The SSH BPP decryption algorithm is, however, stateful. Motivated by a desire to analyze the
SSH BPP authenticated encryption scheme, and by the desire to capture the potential power
of stateful decryption algorithms, we extend the previous notions of privacy and integrity to en-
cryption schemes with stateful decryption algorithms. The aforementioned power refers to the
fact that if a scheme meets our new notions of security, then, in addition to satisfying the existing
notions of privacy [1] and integrity [17, 3], the scheme will be secure against replay attacks and
out-of-order delivery attacks attacks not captured under the previous models.
One alternative approach to our analysis would have been to model the SSH BPP as a secure
channel [7] since the notion of secure channels can be applied to encryption schemes with stateful
decryption algorithms. We point out that the combination of our notions is stronger than the notion
of secure channels: combining a secure key agreement protocol with an authenticated encryption
scheme that meets both of our notions will yield a secure channel. Consequently, since our xes for
SSH BPP provably meet our strong notions, the resulting SSH BPP is also a secure channel.
We acknowledge that one potential disadvantage of our new notions of security is that they may
be too strong for some applications: some applications may not require the strength associated
with our notions (see [7, 18] for reasons). For those applications, the notion of a secure channel
might be more appropriate. Our notions are, however, more appropriate for applications (like SSH)
that do require a higher level of protection such as protection against out-of-order delivery attacks.
Finally, we note that side-channel attacks (such as those exploiting information leaked through the
length of packets or the interval of time between packets [23]) are not captured by our security
models nor any other provable security models that we are aware of.
Overview. After describing the SSH Binary Packet Protocol in Section 2, we present a simple
attack against the current SSH specication (Section 3). In Section 4 we show that xing the
SSH BPP in the natural way may result in an insecure protocol. Motivated by the lessons we
learned from Sections 3 and 4, we then present provably-secure xes to the SSH Binary Packet
Protocol (Section 5). In Section 6 we present our provable security results in more detail (deferring
the details of the proofs to the appendices). Finally, in Section 7 we discuss our results and make
recommendations to the SSH and applied cryptographic communities. We discuss the signicance of
our earlier attacks and the advantages and disadvantages of switching to our proposed modications.
We also discuss the possibility of changing the SSH BPP from an Encrypt-and-MAC-based
construction to an Encrypt-then-MAC-based construction and the possibility of modifying SSH
to use a dedicated authenticated encryption scheme such as XCBC [11] or OCB [22].
We close this introduction with some denitions. They are stated more formally in Section 6.
Background: Encryption and authentication. A symmetric encryption scheme is a cryp-
tographic scheme designed to protect the privacy of information. An encryption scheme consists
of three main components: a key generation method, an encryption algorithm (that takes a users
plaintext message and a key and that produces a ciphertext), and a decryption algorithm (that
takes a ciphertext and a key and that produces the corresponding plaintext). A message authenti-
cation (tagging) scheme is a cryptographic scheme designed to protect the integrity of information.
A message authentication scheme also consists of three components: a key generation method, a
4
ENCODE
counter
MAC
ENC
Payload M
tag Intermediate ciphertext
Ciphertext
padl pl padding payload M
pl : length in bytes of remaining part of packet
padl : length in bytes of padding
padl is 1 byte long
Encoded packet
counter is 32 bits
pl is 4 bytes long
Figure 1: SSH authenticated encryption scheme
tagging (MACing) algorithm (that takes a message and a key as input and that produces as output
a MAC tag) and a verication algorithm (that takes a message, a tag, and a key as input and that
outputs a 1 if it accepts the tag and a 0 otherwise).
An authenticated encryption scheme is a scheme designed to provide both privacy and integrity.
From an API perspective, an authenticated encryption scheme is equivalent to an encryption scheme
except that the decryption algorithm can return a special error code. There are two types of au-
thenticated encryption schemes: dedicated constructions (e.g., RPC [17], XCBC [11], IACBC [16],
and OCB [22]) and generic composition constructions that use standard encryption and message
authentication schemes as black boxes (such as SSH; see [3, 18] for additional discussions about
generic composition schemes). As others point out (e.g., [4]), most real-world applications require
authenticated encryption scheme, not just traditional encryption schemes.
2 The SSH Binary Packet Protocol
The SSH Binary Packet Protocol [26] is responsible for encrypting and authenticating all messages
between two parties involved in an SSH session. Before beginning the authenticated encryption
portion of an SSH session, a client and a server rst agree upon a set of shared symmetric keys (a
dierent set for each direction of a connection). The client and the server also agree upon which
encryption and message authentication schemes they wish to use. All of the encryption schemes
recommended by [26] are based on CBC mode encryption [9], and all of the recommended message
authentication schemes are based on HMAC [19].
The SSH authenticated encryption scheme works as depicted in Figure 1. Given a payload
message (in bytes), the SSH BPP encodes that message into an encoded packet consisting of the
following elds: a four-byte packet length eld containing the length of the remaining encoded
packet (in bytes), a one-byte padding length eld, the payload message, and (possibly random)
padding. The length of the total packet must be a multiple of the underlying block ciphers
block length, and the padding must be at least four bytes long. Although the SSH specication
allows up to 255 bytes of padding per encoded packet, both implementations that we evaluated
(openssh-2.9p2 and SSH Communications ssh-3.0.1) use the minimum padding necessary. The
resulting ciphertext is the concatenation of the encryption of the above encoded packet and the
MAC of the above encoded packet prepended with a 32-bit counter. In the following discussions we
try to make clear whether we are referring to the intermediate ciphertext output by the underlying
5
encryption scheme or the ciphertext packet (the concatenation of the intermediate ciphertext and
the MAC tag) output by the SSH BPP.
Decryption is dened in a natural way: the receiver rst decrypts the intermediate ciphertext
portion of a ciphertext to get an encoded packet. The receiver then prepends a 32-bit counter
(which it also maintains) to the encoded packet and determines whether the received MAC tag is
valid. If so, the decryptor removes the payload from the encoded packet and delivers the payload
to the user (or a higher-level protocol). If the MAC verication fails, the connection is terminated.
The SSH specication recommends the use of CBC mode with inter-packet chaining. This
means that, when encrypting an encoded payload, the sender uses as the initialization vector (IV)
either the last block of the immediately preceding ciphertext or, when encrypting the rst message,
an IV computed during the SSH key agreement protocol. We refer to the current instantiation of
the SSH protocol as SSH-IPC, or SSH with inter-packet chaining.
3 Attack Against the Standard Implementation of SSH
There is a simple attack against SSH-IPC; this attack was also recently reported by Dai [8]. The
problem with SSH-IPC is that an attacker will know the IV for the next message to be encrypted
before the next message is actually encrypted (since SSH-IPC uses CBC mode with inter-packet
chaining). This means that if an attacker can control the entire rst block of the input into
SSH-IPCs underlying CBC encryption scheme, it will be able to control the corresponding input
to the underlying block cipher. Since a block cipher is deterministic, an attacker could use this to
glean information about a previously encrypted message (by looking to see if some value was ever
the input to a previous block cipher invocation).
We describe the attack in slightly more detail. We assume for now that an adversary can control
the entire rst block of an encoded packet. Suppose that an adversary has a guess G of the rst
encoded block of the ith packet, and let C
1
be the last CBC block of the i 1st intermediate
ciphertext. Since we are considering SSH-IPC, the block C
1
was used as the IV when encrypting
the ith packet. Let C
2
be the rst block of the ith ciphertext. And let C
3
be the last CBC block
of the underlying ciphertext the user just output (i.e., the user will use C
3
as its next IV). If the
adversary is able to force the user to encrypt the block C
1
C
3
G, where is the xor operation,
and if the resulting block is C
2
, the adversary knows its guess of for G was correct; otherwise the
adversary knows its guess was incorrect.
A small complication arises when mounting this attack against SSH-IPC because the attacker
cannot control the entire rst block of an encoded message (because the rst 40 bits of an encoded
packet contain metadata). This means that an attacker may not be able to force a users underlying
CBC scheme to encrypt the block C
1
C
3
G. An attacker will, however, be able to mount this
attack if C
1
and C
3
are identical in the bits that the attacker cannot control. Let l be the block
length (in bits) of the underlying block cipher. Since an attacker can control approximately lg(l/8)
bits of the padding length eld and approximately 15 lg(l/8) bits of the packet length eld of
an encoded message (SSH implementations are only required to support packets with payloads
containing less than 2
15
bytes and all packets must be padded to a multiple of the block length),
an attacker could mount a variant of the above attack by waiting for a collision on approximately
25 bits (but the adversarys last encryption request may be up to 2
15
bytes long).
4 Attacks Against a Natural Fix
The problem with SSH-IPC stems from the fact that its underlying encryption scheme, CBC mode
with inter-packet chaining, is itself insecure against chosen-plaintext attacks. A logical x might
6
therefore be to replace the underlying encryption scheme with randomized CBC mode (i.e., CBC
mode in which a new random IV is chosen for each message; this new IV must also be sent with
the ciphertext). Randomized CBC mode was proven to resist chosen-plaintext attacks in [1]. We
refer to an SSH implementation that uses randomized CBC mode as SSH-NPC, or SSH with no
packet chaining.
It is possible to prove that SSH-NPC preserves privacy (against chosen-plaintext attacks) and
integrity (under a notion called integrity of plaintexts) provided that a user does not use SSH-NPC
to encrypt more than 2
32
messages with any given key. This proof holds even if the paddings used
in encoded packets are not random (which is allowed by the SSH specication). As the following
attack shows, however, even though SSH-NPC with non-random padding preserves privacy against
chosen-plaintexts attacks, it does not preserve privacy against chosen-ciphertext attacks.
Reaction attack against SSH-NPC. The SSH specication encourages, although does not
require, implementations to use random padding. Unfortunately, when the padding value is xed
(e.g., all zeros), SSH-NPC is susceptible to an easily-mountable reaction attack. Furthermore, this
attack can be made to work even when the padding values are not xed but short and not hard
to predict: an attacker can simply wait until the predicted padding values collide and then use the
predicted value to successfully mount an attack. The attack we describe here is similar in spirit to
Wagners attack in [4] and to the attacks in [18, 24] (the term reaction attack comes from [14]).
Since the SSH draft allows the use of non-random padding, we consider the existence of this attack
to be a serious problem.
The attack proceeds roughly as follows: an attacker intercepts (and prevents the delivery of)
two ciphertexts sent by one party involved in an SSH connection. The adversary then makes a guess
about the relationship between the two plaintexts corresponding to the two intercepted ciphertexts.
The adversary then uses that guess and those two ciphertexts to create a new ciphertext, which
the adversary then sends to the other party involved in the SSH session. By observing the sec-
ond partys reaction (recall that if the second party does not accept the doctored ciphertext, the
connection will be terminated), an adversary will learn whether its guess was correct. Intuitively,
this attack works because an attacker can modify the ciphertext in such a way that if its guess was
correct, the ciphertext that the second party receives will verify. If its guess was incorrect, with
high probability the ciphertext will not verify.
We now describe the attack in more detail. As before, let denote the xor operation, let
| denote the concatenation of two strings, and let l denote the block length (in bits) of the block
cipher that SSH-NPC uses in CBC mode. Suppose a user uses SSH-NPC to encrypt two equal-
length messages M
1
and M
2
with lengths at most l 40 (or that are identical after their l 40-th
bit). (For simplicity of exposition, assume that the two messages are exactly l 40 bits long.) Let
P
11
and P
12
be the rst and the second block of the encoded packet corresponding to the payload
M
1
, respectively. Similarly, let P
21
and P
22
be the rst and the second block of the encoded packets
corresponding to M
2
, respectively. The blocks P
11
and P
21
correspond to the packet length, the
padding length, and the payload elds of the two encoded packets, and the blocks P
12
and P
22
correspond to the padding elds. Since we are assuming xed padding (such as padding with all
zeros), the padding blocks P
12
and P
22
will be equal.
When SSH-NPCs underlying CBC mode encryption scheme encrypts the rst encoded packet
P
11
|P
12
, it will generate a ciphertext
1
= C
10
|C
11
|C
12
; SSH-NPCs underlying MAC will also
generate a tag
1
(the MAC being computed over the concatenation of a counter and P
11
|P
12
).
Similarly, SSH-NPC will generate the CBC ciphertext C
20
|C
21
|C
22
and the MAC tag
2
for the
encoded packet P
21
|P
22
. (The blocks C
10
and C
20
correspond to the underlying CBC modes
random initialization vectors.)
Now assume that the receiver has not yet received the two ciphertexts corresponding to M
1
and
7
M
2
(i.e., the recipients counter is identical to the counter that the sender used when she encrypted
the rst message). Assume that the attacker knows either M
1
or M
2
and wants to verify a guess of
the other (or that the attacker wants to verify a guess of the relationship between M
1
and M
2
). Let
X be the value P
11
P
21
C
20
(recall that the blocks P
11
and P
12
both begin with the same 40 bits
of header information and that they respectively end in M
1
and M
2
). The attacker then asks the
receiver to decrypt the message X|C
21
|C
22
|
1
. If the attackers guess is correct, then X|C
21
|C
22
will decrypt, via SSH-NPCs underlying CBC scheme, to P
11
|P
12
, the MAC tag
1
will verify, and
the decryptor will accept the message. If the attackers guess is incorrect, however, X|C
21
|C
22
will not decrypt to P
11
|P
12
, the tag
1
will not verify (unless the attacker also succeeds in breaking
the security of the underlying MAC scheme), and the SSH-NPC connection will terminate. The
adversary, by watching the recipients reaction, therefore learns information about the plaintexts
the sender is encrypting.
There are two aspects of this attack that make it easy to mount. First, this attack only requires
modifying encrypted packets; no chosen-plaintexts are required. Second, an attacker can learn
whether its guess is correct simply by watching the recipients response. These observations mean
that all an attacker needs to perform this attack is the ability to monitor, prevent the delivery of,
and inject messages in the encrypted communications between two parties. Similar to Wagners
attack in [4], this attack can be used to (among other things) infer the characters that a user
types over an interactive SSH-NPC session. Of course, once the attacker makes an incorrect guess,
SSH-NPC terminates the connection. Nonetheless, an attacker might still be able to repeat its
attack after the user begins a new session.
Information leakage, replay, and out-of-order delivery attacks. Although the SSH
draft suggests that an SSH session rekey after every gigabyte of transmitted data, doing so is not
required. We caution that if an SSH-NPC (or SSH-IPC) session is not rekeyed frequently enough,
then the session will be vulnerable to a number of other attacks. Recall that the SSH binary packet
protocol includes a 32-bit counter in each message to be MACed. These attacks make use of the
fact that if the SSH connection is not rekeyed frequently enough, then the counter will begin to
repeat.
The simple observation exploited by the information leakage attack is the following. Recall
that SSH generates each MAC using the encoded payload prepended with a counter as an input
and then appends the MAC to the intermediate ciphertext to generate a ciphertext packet. As a
result, if the underlying MAC algorithm is stateless and deterministic (which many MACs are),
then allowing the counter to repeat will leak information about a users plaintexts (through the
MAC). We present the attacks in more details for completeness. Suppose that the underlying
message authentication scheme is stateless and deterministic and that the padding is some xed
value. Suppose that an attacker A sees a ciphertext with a MAC tag and suspects that the
underlying payload is M. To verify its guess, A waits for the sender to encrypt 2
32
1 more
packets and then requests the sender to encrypt the payload M. Let
t
be the MAC tag returned
in response to the request. If As guess is correct, then
t
will equal . Otherwise
t
= with very
high probability. The attack can also be used to break the privacy of SSH-NPC when SSH-NPC
uses random padding. In particular, if the rst 2
32
messages that a user tags result in encoded
packets that use the minimum 4 bytes of random padding, then an attacker capable of forcing a
user to tag an additional 2
32
chosen-plaintexts will be able to learn information about the users
initial 2
32
messages. The property used in this attack (that tagging with a deterministic MAC
leaks information about plaintexts) was also exploited by [3] and [18].
If the counter is allowed to repeat, SSH-NPC also becomes vulnerable to replay attacks and
out-of-order delivery attacks. For replay attacks, once the receiver has decrypted 2
32
messages,
an attacker will be able to convince the receiver to re-accept a previously received message. For
8
out-of-order delivery attacks, after the sender has encrypted more that 2
32
messages, an attacker
will be able to modify the order in which the messages are decrypted.
5 Secure Fixes to SSH
We now briey describe our new SSH instantiations. We show in Section 6 that these new al-
ternatives provably meet our strongest notions of security. That is, assuming that these xes are
not used to encrypt more than 2
32
packets between rekeying, these new constructions will resist
chosen-plaintext and chosen-ciphertext privacy attacks as well as forgery, replay, and out-of-order
delivery attacks. Security above 2
32
is not guaranteed because, after 2
32
packets are encrypted,
the SSH BPPs 32-bit internal counter will begin to wrap. We will compare these instantiations
of SSH to others and discuss additional possible modications, including extending the length of
SSHs internal counter, in Section 7.
SSH via randomized CBC mode with random padding: SSH-$NPC. Recall that the attack
against SSH-NPC worked by having an attacker create a new intermediate ciphertext that would
decrypt to an encoded packet that the user previously encrypted (assuming the attackers guess
was correct). With this in mind, we propose a provably secure SSH instantiation (SSH-$NPC)
that uses randomized CBC mode for the underlying encryption scheme and that requires that
encoded packets use random padding. We require that the random padding be chosen anew for
each encryption and that the random padding occupy at least one full block of the encoded packet.
This conforms to the current SSH specication since the latter allows padding up to 255 bytes.
The intuition behind the security of this alternative, and in particular why this alternative resists
the attack in Section 4, is that, since the random padding is not sent in the clear, an attacker will
not know what the random padding is and will not be able to forge a ciphertext that will decrypt to
that previously encoded message (with the same random padding). Furthermore, any other attack
against SSH-$NPC would translate into an attack against the underlying CBC mode encryption
scheme, the underlying MAC, the encoding scheme, or the underlying block cipher.
SSH via CBC mode with CTR generated IVs: SSH-CTRIV-CBC. Instead of using CBC
mode with a random IV, it is also possible to generate a random-looking IV by encrypting a
counter with a dierent key; we call this alternative SSH-CTRIV-CBC. Unlike SSH-$NPC, for
SSH-CTRIV-CBC we do not require a full block of padding and we do not require the padding
to be random. The reason we do not require random padding for this alternative is because
the decryptor is stateful and that any modication to an underlying CBC ciphertext will, with
probability 1, change the encoded packet. This alternative is more attractive than SSH-$NPC
because it does not increase the size of ciphertexts compared to SSH-IPC (but it does require one
additional block cipher application compared to SSH-IPC).
SSH via CTR mode with stateful decryption: SSH-CTR. SSH-CTR uses standard CTR
mode as the underlying encryption scheme with one modication: both the sender and the receiver
maintain the counters themselves, rather than transmitting them as part of the ciphertexts. We
refer to this variant of CTR mode as CTR mode with stateful decryption. We point out that this
CTR mode variant oers the same level of chosen-plaintext privacy as standard CTR mode, the
security of which was shown in [1]. As with SSH-CTRIV-CBC, SSH-CTR does not require addi-
tional padding and does not require the padding to be random. Furthermore, unlike SSH-$NPC and
SSH-CTRIV-CBC, SSH-CTR requires the same number of block cipher invocations as SSH-IPC.
Other possibilities. There are numerous other possible xes to the SSH BPP. Rather than
enumerate all possible xes to the SSH BPP, in Section 6 we discuss how one can use our general
9
proof techniques to prove the security of other xes (assuming, of course, that the other xes are
indeed secure). For example, another x of interest might be SSH-EIV-CBC, or SSH where the
underlying encryption scheme is replaced by a CBC variant in which the IV is the encipherment
of the last block of the previous ciphertext.
6 Provable Security Results
Practice-oriented provable security. Provable security was rst introduced by Goldwasser
and Micali in [13]. It encompasses both the design and the analysis of cryptographic constructs. In
this approach, one designs a construct based on computationally hard problems such as factoring
large composite integers. These hard problems are treated as atomic primitives whose compu-
tational hardness the security of the desired construct is based upon. Before the construct can
be analyzed, however, one must determine what it means for it to be considered secure. This
requires precisely dened security denitions and adversary models. The former should capture the
security objectives that the construct is to achieve while the latter should capture the settings in
which adversaries operate. The goal here is to capture the settings in which the construct will be
deployed in the real-world.
Once security denitions and adversary models are in place, one proves security of the desired
construct via a reduction from the hardness of the underlying primitives, similar to the way one
reduces SAT to a problem to prove that the problem is NP-complete. The term proves is in quotes
here because, in eect, one does not prove that a construct is secure in this approach. Rather, one
provides a reduction of the security of the construct from that of its underlying primitives. This
technique allows us to arrive at a powerful conclusion: the only way to defeat the desired construct
in the prescribed models is to break the underlying primitives. Thus, as long as the primitives
are unbroken, we know that the construct is secure under the prescribed security denitions and
adversary models.
Our application of provable security in this paper is also practice-oriented in that we provide
concrete bounds for our reductions. This approach, which was introduced in [2], allows practitioners
to quantitatively determine the security of the construct. For example, they can use the best,
currently known attack against the underlying primitives such as AES and derive the upper bound
on the insecurity of the construct in question. We note, however, that for simplicity we do not
provide exact bounds in this paper but simply state roughly how the resources for breaking the
construct and those for breaking the underlying primitives compare. In most cases, they are equal.
In other cases, they can be easily determined by looking at the expansion between a payload
message and its encoded packet.
Analyzing SSH via a new paradigm. An SSH ciphertext is the concatenation of the encryption
and the MAC of (some encodings of) an underlying payload message. At rst glance, this seems to
fall into the Encrypt-and-MAC method of composing an encryption scheme with a MAC scheme:
to encrypt a message M, apply the encryption algorithm to M and the tag generation algorithm
to M, then concatenate the resulting strings to produce the nal ciphertext to be transmitted.
As pointed out in [3, 18], this particular composition method is not generically secure: security
under standard notions of the encryption and MAC schemes used as building blocks under this
composition method is not enough to guarantee the privacy of the payload. Naturally, this raises
a question regarding the security of SSH.
We show here that, with an appropriate encoding method, such as the method used in SSH,
an Encode-then-E&M scheme can actually be made secure. In fact, our analysis models SSH more
generally as an authenticated encryption scheme constructed via a paradigm we call Encode-then-
10
E&M: to encrypt a message, rst encode it (as SSH does), then encrypt and MAC the encoded
packets. Our analysis was done in a general way in order to ensure that that the denitions and
techniques we developed will be useful to the evaluators of other SSH-like schemes.
As described in Section 2, an SSH BPP encoded message (for encryption) consists of a packet
length eld, a padding length eld, payload data, and padding. An encoded message (for MACing)
is identical to an encoded message for encryption except that it is prepended with a 32-bit counter.
6.1 Denitions
Notation. If x and y are strings, then [x[ denotes the length of x in bits and x|y denotes their
concatenation. If i is a non-negative integer, then 'i`
l
denotes the unsigned l-bit binary represen-
tation of i. The empty string is denoted . When we say an algorithm is stateful, we mean that it
uses and updates its state and that the entity executing it maintains the state between invocations.
Let denote the initial state of any (stateful or stateless) algorithm. If f is a randomized (resp.,
deterministic) algorithm, then x
R
f(y) (resp., x f(y)) denotes the process of running f on
input y and assigning the result to x. If A is a program, A x means return the value x to A.
Encryption schemes with stateful decryption. As usual a symmetric encryption scheme or
authenticated encryption scheme oc = (/, c, T) consists of three algorithms. The randomized key
generation algorithm returns a key K. The encryption algorithm, which may be both randomized
and stateful, takes key K and a plaintext and returns a ciphertext. Motivated by SSH, the novel
feature here is that the decryption algorithm may also be stateful (but not randomized); the
decryption algorithm takes key K and a ciphertext and returns either a plaintext or a special
symbol (indicating failure).
Consider the interaction between an encryptor and a decryptor. If, at any point in time, the
sequence of inputs to the decryptor is not a prex of the sequence of outputs of the encryptor,
then we say that the encryption and decryption processes have become out-of-sync and refer to
the decryption input at that point in time as the rst out-of-sync input. The usual correctness
condition, which said that if C is produced by encrypting M under K then decrypting C under K
yields M, is replaced with a less stringent condition requiring only that decryption succeed when
the encryption and decryption processes are in-sync. More precisely, the following must be true for
any key K and plaintexts M
1
, M
2
, . . .. Suppose that both c
K
and T
K
are in their initial states.
For i = 1, 2, . . ., let C
i
= c
K
(M
i
) and let M
t
i
= T
K
(C
i
). It must be that M
i
= M
t
i
for all i.
Message authentication schemes. A message authentication scheme or MAC / = (/, T , 1)
consists of three algorithms. The randomized key generation algorithm returns a key K. The tag-
ging algorithm, which may be both randomized and stateful, takes key K and a plaintext and
returns a tag. The deterministic and stateless verication algorithm takes key K, a plaintext, and
a candidate tag and returns a bit. For any key K and message M, and for any internal state of
T
K
, we require that 1
K
(M, T
K
(M)) = 1.
Encoding schemes. An encoding is an unkeyed transformation. We use encodings to model
the process of loading a payload message into a packet for encryption and a packet for message
authentication (recall that the encoded packet that the SSH BPP encrypts is slightly dierent than
the encoded packet that the SSH BPP MACs). Syntactically, an encoding scheme c( = (Enc, Dec)
consists of an encoding algorithm and a decoding algorithm. The encoding algorithm Enc, which
may be both randomized and stateful, takes as input a message M and returns a pair of messages
(M
e
, M
t
). The decoding algorithm Dec, which may also be stateful but not randomized, takes as
input a message M
e
and returns a pair of messages (M, M
t
), or (, ) on error. The following
consistency requirement must be met. Consider any two messages M, M
t
where [M[ = [M
t
[. Let
11
(M
e
, M
t
)
R
Enc(M) for Enc in some state, and let (M
t
e
, M
t
t
)
R
Enc(M
t
) for Enc is in some
(possibly dierent) state. We require that [M
e
[ = [M
t
e
[ and [M
t
[ = [M
t
t
[. Furthermore, suppose
that both Enc and Dec are in their initial states. For any sequence of messages M
1
, M
2
, . . . and for
i = 1, 2, . . ., let (M
i
e
, M
i
t
) = Enc(M
i
), and then let (m
i
, m
i
t
) = Dec(M
i
e
). We require that M
i
= m
i
and that M
i
t
= m
i
t
for all i.
Encode-then-E&M paradigm. Consider an encoding scheme, and let (M
e
, M
t
) be the encoding
of some message M. To generate a ciphertext for M using the Encode-then-E&M construction,
the message M
e
is encrypted with an underlying encryption scheme, the message M
t
is MACed
with an underlying message authentication scheme algorithm, and the resulting two values (inter-
mediate ciphertext and MAC) are concatenated to produce the nal ciphertext. The composite
decryption procedure is similar except the way errors (e.g., decoding problems or tag verication
failures) are handled: in particular, should the composite decryption algorithm enter a new state
or return to its previous state? We take the approach used in SSH whereby, if a decryption fails,
the composite decryption algorithm enters a halting state. This approach is perhaps the most
intuitive since, upon detecting a chosen-ciphertext attack, the decryption algorithm prevents all
subsequent ciphertexts from being decrypted (of course, this also makes the decryptor vulnera-
ble to a denial-of-service-type attack). Construction 6.1 shows the Encode-then-E&M composition
method in details.
Construction 6.1 (Encode-then-E&M) Let c( = (Enc, Dec), oc = (/
e
, c, T), and / =
(/
t
, T , 1) be encoding, encryption, and message authentication schemes with compatible message
space (the outputs from Enc are suitable inputs to c and T ). Let all states initially be . We
associate to these schemes a composite Encode-then-E&M scheme oc = (/, c, T) as follows:
Algorithm /
K
e
R
/
e
; K
t
R
/
t
Return 'K
e
, K
t
`
Algorithm c
/Ke,Kt)
(M)
(M
e
, M
t
)
R
Enc(M)

R
c
Ke
(M
e
) ;
R
T
Kt
(M
t
)
C |
Return C
Algorithm T
/Ke,Kt)
(C)
If st = then return
If cannot parse C then st ; return
Parse C as | ; M
e
T
Ke
()
If M
e
= then st ; return
(M, M
t
) Dec(M
e
)
If M = then st ; return
v 1
K
t
(M
t
, )
If v = 0 then st ; return
Return M
Although only T explicitly maintains state in the above pseudocode, the underlying encoding,
encryption, and MAC schemes may also maintain state.
6.2 Security Notions
Since the goal is to model schemes based on block ciphers and cryptographic hash functions, a
concrete security treatment is used. We associate to any adversary a number called its advantage
that measures its success in breaking a given scheme with respect to a given security notion. The
smaller an adversarys advantage is against a given scheme, the stronger that scheme is with respect
to that adversary. In discussion, take secure to mean that the advantage of any adversary with
practical resources is small. We briey describe the security notions here. Appendix A presents
these notions in more detail.
Security notions for encryption schemes with stateful decryption. A secure authen-
ticated encryption scheme oc = (/, c, T) is one that preserves both privacy and integrity. The
12
standard notion of indistinguishability (privacy) under chosen-plaintext attacks (ind-cpa) is as fol-
lows [1]: we consider a game in which an adversary A is given access to an left-or-right-encryption
(lr-encryption) oracle c
K
(L{(, , b)), for some hidden bit b, that on input two equal length message
M
0
, M
1
, returns c
K
(M
b
). After performing a number of lr-encryption queries, the adversary must
return a guess for the bit b. We dene Adv
ind-cpa
Sc
(A) as the probability that A returns 1 when
b = 1 minus the probability that A returns 1 when b = 0.
For our notion of chosen-ciphertext privacy for stateful decryption (ind-sfcca), we consider
a game in which an adversary B is given access to an lr-encryption oracle c
K
(L{(, , b)) and a
decryption oracle T
K
(). As long as Bs queries to T
K
() are in-sync with the responses from
c
K
(L{(, , b)), the decryption oracle performs the decryption (and updates its internal state) but
does not return a response to B. Once B makes an out-of-sync query to T
K
(), the decryption
oracle returns the output of the decryption. We dene Adv
ind-sfcca
Sc
(B) as the probability that B
returns 1 when b = 1 minus the probability that B returns 1 when b = 0. The new ind-sfcca
notion implies the previous notion of indistinguishability under chosen-ciphertext attacks (ind-
cca [1]). Note that, without allowing an adversary to query the decryption oracle with in-sync
ciphertexts (e.g., in the standard ind-cca setting), we would not be able to model attacks in which
the adversary attacks a stateful decryptor after the latter had decrypted a number of legitimate
ciphertexts (perhaps because of some weakness related to the state of the decryptor at that time).
The standard notion for integrity of plaintexts (int-ptxt) is as follows [3]: we consider a game
in which an adversary A is given access to an encryption oracle c
K
() and a decryption-verication
oracle T

K
(). On input a candidate ciphertext C, the decryption-verication oracle invokes T
K
(C)
and returns 1 if T
K
(C) = and 0 otherwise. We dene Adv
int-ptxt
Sc
(A) as the probability that A
can nd a ciphertext C such that T

K
(C) = 1 but that the decrypted value of C, i.e. T
K
(C), was
not previously a query to c
K
(). For our notion of integrity of ciphertexts for stateful decryption
(int-sfctxt), we again consider a game in which an adversary B is given access to the two oracles
c
K
() and T

K
(). Let C
i
denote the i-th ciphertext returned by the encryption oracle and let C
t
i
denote Bs i-th query to T

K
(). We dene Adv
int-sfctxt
Sc
(B) as the probability that B can generate
a ciphertext C
t
i
such that T

K
(C
t
i
) = 1 and C
t
i
is an out-of-sync query. The new notion of int-sfctxt
implies the previous notion of integrity of ciphertexts (int-ctxt [3]) as well as security against
replay and out-of-order delivery attacks.
The following proposition states that, if a scheme is indistinguishable under chosen-plaintexts
attacks and if the scheme meets our strong denition of integrity of ciphertexts, then the scheme
will meet our strong denition of indistinguishability under chosen-ciphertext attacks. The proof
appears in Appendix B.3. It is similar to the results in [3] and [17] which show that the standard
ind-cpa and the standard int-ctxt notion imply the standard ind-cca notion.
Proposition 6.2 Let oc = (/, c, T) be a symmetric authenticated encryption scheme. Given any
ind-sfcca adversary A, we can construct an int-sfctxt adversary I and an ind-cpa adversary B such
that
Adv
ind-sfcca
Sc
(A) 2 Adv
int-sfctxt
Sc
(I) +Adv
ind-cpa
Sc
(B)
and I and B use the same resources as A.
Unforgeability of MAC schemes. A secure MAC / = (/, T , 1) is one that is strongly
unforgeable under chosen-message attacks [3]. We consider a game in which a forger F is given
access to a tagging oracle T
K
() and a verication oracle 1
K
(). The forger is allowed arbitrary
queries to the oracles and wins if it can nd a pair (M, ) such that 1
K
(M, ) = 1 but was
never returned by T
K
() as a tag for M. We denote the advantage of this forger as Adv
uf-cma
/.
(F).
Although this notion is in general stronger than the standard notion of unforgeability [2], we note
13
that any pseudorandom function is a strongly unforgeable MAC, and most practical MACs seem
to be strongly unforgeable.
Pseudorandom functions. We formalize pseudorandom functions and their security following
[12, 2]. Suppose T is a family of functions from some message space to 0, 1
L
, and let Rand
/L
denote the family of all functions from to 0, 1
L
. We dene Adv
prf
T
(D) as the advantage of a
distinguisher D in distinguishing a random instance of T from a random instance of Rand
/L
.
Collision resistance of encoding schemes. The security of a composite Encode-then-E&M
construction depends on properties of the underlying encoding, encryption, and MAC schemes. In
addition to the standard assumptions of indistinguishability of the encryption scheme and unforge-
ability and pseudorandomness of the MAC scheme, we require collision resistance of the encoding
scheme. We motivate this notion as follows. Consider an integrity adversary against a composite
Encode-then-E&M scheme. If the adversary can nd two dierent messages that encode (or de-
code) to the same input for the underlying MAC, then the adversary may be able to compromise
the integrity of the composite scheme. Consider now an indistinguishability adversary against the
composite scheme. As long as the adversary does not generate two inputs for the underlying MAC
that collide, the underlying MAC should not leak information about the plaintext. The following
describes the notions of collision resistance for encoding schemes. Formal denitions appear in
Appendix A.
An adversary A mounting a chosen-plaintext attack against an encoding scheme c( = (Enc,
Dec) is given access to an encoding oracle Enc(). If A can make the encoding oracle output
two pairs that collide on their second components (i.e., the M
t
s), then A wins. We allow A to
repeatedly query the encoding oracle with the same input. Similarly, an adversary B mounting a
chosen-ciphertext attack against c( is given access to both an encoding oracle and a decoding
oracle Dec(). If B can cause a collision in the second components of the outputs of Enc(), Dec(),
or both, then it wins. Of course, we exclude the cases where B uses the two oracles in a trivial
way to obtain collisions (e.g. submitting a query to Enc() and then immediately submitting the
rst component of the result, namely M
e
, to Dec()). We refer to the advantages of the adversaries
in these two settings as Adv
collcpa
c(
(A) and Adv
collcca
c(
(B), respectively. All encoding schemes
with deterministic and stateless encoding algorithms are insecure under chosen-plaintext collision
attacks. Furthermore, all encoding schemes with stateless decoding algorithms are insecure under
chosen-ciphertext collision attacks.
6.3 SSH Security Results
The SSH encoding scheme, when used with an l-bit block cipher, is shown in Figure 2 (see also
Section 2). Recall that [x[ denotes the length of string x in bits, not bytes, and that 'x`
k
de-
notes the representation of x as a k-bit unsigned integer. As mentioned, although Figure 2 shows
the padding p as a random string (the second boxed equation), the SSH specication does not
require that p be random. Additionally, although the SSH specication allows up to 255 bytes
of padding, the two major implementations of the SSH protocol, openssh-2.9p2 and SSH Com-
munications ssh-3.0.1, use the minimum-recommended padding length shown in Figure 2. The
proposed SSH-$NPC instantiation of SSH replaces the rst boxed statement with bpl bpl + l if
bpl < l and always uses random padding as shown in the second boxed statement. The instanti-
ations SSH-CTRIV-CBC, SSH-EIV-CBC, and SSH-CTR, on the other hand, uses the rst boxed
statement with no modication and allows padding p to be non-random.
The following lemma gives the collision bounds for the SSH encoding as shown in Figure 2.
Notice that if q
e
2
32
, then q
e
2
32
| 1 0 and Adv
collcpa
c(
(A) = 0 for any adversary A.
Also, if a coll-cca adversary C submits more than 2
32
encoding queries or 2
32
decoding queries,
14
Algorithm Enc(M) // [M[ 0 (mod 8)
If st
n
= then st
n
0
bpl l

([M[ + 40) (mod l)

If bpl < 32 then bpl bpl + l

p
R
0, 1
bpl
tl (8 +[M[ + bpl)/8 ; pl bpl/8
M
e
'tl`
32
|'pl`
8
|M|p ; M
t
'st
n
`
32
|M
e
st
n
st
n
+ 1 mod 2
32
Return (M
e
, M
t
)
Algorithm Dec(M
e
)
If st
u
= then st
u
0
M
t
'st
u
`
32
|M
e
st
u
st
u
+ 1 mod 2
32
If cannot parse M
e
then return (, )
Parse M
e
as 'tl`
32
|'pl`
8
|M|p
Return (M, M
t
)
Figure 2: The SSH encoding algorithm c( = (Enc, Dec) for l-bit blocks, where l 0 (mod 8) and
64 l 252 8. The states st
n
and st
u
are maintained across invocations. When considering these
encoding algorithms, recall that [M[ denotes the length of M in bits and not bytes (hence the need
to divide lengths by 8).
then it can completely break the scheme, i.e. Adv
collcca
c(
(C) = 1. (For coll-cca security of up
to 2
32
decoding queries it is critical that the decoding algorithm increment its counter on every
invocation, even for messages that do not correctly decode.) The proof appears in Appendix C.1.
Lemma 6.3 (Collision Resistance of the SSH Encoding) Let c( be the encoding scheme
shown in Figure 2 and let mbpl be the minimum padding length (32 bits in Figure 2; the 32 in
the equations below corresponds to the length of the encoding schemes internal counter, not the
minimum padding length). For any coll-cpa adversary A and any coll-cca adversary B, each making
q
e
encoding queries and, in the case of B, making q
d
decoding queries, we have that
Adv
collcpa
c(
(A)

q
e
2
32

q
e
2
32

2
31mbpl
Adv
collcca
c(
(B) = 0 if q
e
, q
d
2
32
and that coll-cca collision resistance is not provided if q
e
or q
d
> 2
32
.
Integrity and privacy of our recommendations. Our proposed xes from Section 5 are
secure under our strong notions of integrity (int-sfctxt) and indistinguishability (ind-sfcca). We
sketch our proof of security for SSH-CTR (see Appendix C.2 for details). The proof technique
extends naturally to other possible xes to the SSH BPP.
We rst present a general result that holds for all Encode-then-E&M constructions. This result
states that if an Encode-then-E&M constructions underlying encryption scheme is ind-cpa-secure,
if the underlying MAC is a secure pseudorandom function, and if the encoding scheme is coll-cpa
collision resistant, then the composite Encode-then-E&M scheme will be ind-cpa-secure. The proof
is given in Appendix B.1.
Lemma 6.4 (Chosen-Plaintext Privacy of Encode-then-E&M) Let oc be an encryption
scheme, let / be a message authentication scheme, and let c( be an encoding scheme. Let oc
be the encryption scheme associated to them as per Construction 6.1. Then, given any ind-cpa
adversary S against oc, we can construct adversaries A, D, and C such that
Adv
ind-cpa
Sc
(S) Adv
ind-cpa
Sc
(A) + 2 Adv
prf
/.
(D) + 2 Adv
collcpa
c(
(C) .
Furthermore, A, D, and C use the same resources as S except that As and Ds inputs to their
respective oracles may be slightly larger than those of S (due to the encoding).
15
We now state our result for SSH-CTR:
Theorem 6.5 (Security of SSH-CTR) Let oc be the CTR-mode encryption scheme with stateful
decryption, let / be a message authentication scheme, and let c( be the encoding scheme de-
scribed above. Let SSH-CTR be the encryption scheme associated to them as per Construction 6.1.
Then, given any int-sfctxt adversary I against SSH-CTR, we can construct adversaries F and C
such that Equation (1) holds. Similarly, given any ind-sfcca adversary A against SSH-CTR, we can
construct adversaries S, B, E, and G such that Equation (2) holds.
Adv
int-sfctxt
SSH-CTR
(I) Adv
uf-cma
MA
(F) +Adv
collcca
EC
(C) (1)
Adv
ind-sfcca
SSH-CTR
(A) 2 Adv
int-sfctxt
SSH-CTR
(S) +Adv
ind-cpa
SE
(B) + 2 Adv
prf
MA
(E) + 2 Adv
collcpa
EC
(G) (2)
Furthermore, F and C use the same resources as I except that Fs messages to its oracles may be
slightly larger than Is queries to its oracles (due to encoding) and Cs messages to its decoding
oracle may have slightly dierent lengths than Is decryption queries. Also, S, B, E, and G use
the same resources as A except that Bs and Es inputs to their respective oracles may be slightly
larger than those of A (due to the encoding).
Theorem 6.5 can be interpreted as follows. Equation (1) states that SSH-CTR provides state-
ful chosen-ciphertext integrity if the MAC is strongly unforgeable and if the encoding is coll-cca
collision resistant. Equation (2) states that SSH-CTR provides stateful chosen-ciphertext privacy
if SSH-CTR provides stateful chosen-ciphertext integrity, if the underlying encryption scheme is
ind-cpa secure, if the MAC is a secure pseudorandom function, and if the encoding is coll-cpa se-
cure. As as example, making reasonable assumptions about the security of the HMAC scheme, an
implementation of SSH-CTR that uses HMAC and AES in stateful-decryption CTR mode will be
secure under both of the strong notions provided that at most 2
32
messages are encrypted between
rekeying. Notice here that we use dierent security properties of the MAC to obtain dierent se-
curity aspects of SSH-CTR, namely strong unforgeability for integrity and pseudorandomness for
privacy. This distills the property of the MAC that leads to each aspect of security. We point out,
however, that the notion of strong unforgeability is relatively new [3] and that we do not know of
any provably-secure strongly unforgeable MACs that are not also pseudorandom functions.
To prove Theorem 6.5 (Appendix C.2), we rst use Lemma 6.4, Lemma 6.3, the ind-cpa proof
of security for CTR mode [1], and the assumed pseudorandomness of the underlying MAC to show
that SSH-CTR is ind-cpa-secure. We then prove Equation (1). Applying Proposition 6.2 and our
ind-cpa and int-sfctxt results for SSH-CTR gives Equation (2). We briey discuss our proof of
Equation (1). Let I be an int-sfctxt adversary and let M
i
be Is i-th chosen-plaintext query to
its encoding oracle, let M
i
e
, M
i
t
be the encoding of M
i
, and let
i
|
i
be the returned ciphertext.
Let
t
j
|
t
j
be Is j-th decryption-verication oracle query, let m
j
e
be the decryption of
t
j
by the
underlying decryption algorithm. To prove Equation (1), we basically show that given an int-sfctxt
adversary attacking SSH-CTR, that adversary can also be used to attack the unforgeability of the
underlying MAC, to attack the coll-cca collision resistance of the underlying encoding scheme, or
that the rst out-of-order ciphertext submitted by the adversary,
t
j
|
t
j
, is such that
j
=
t
j
but
M
j
e
= m
j
e
. By properties of CTR mode with stateful decryption, the latter event cannot occur. The
same property holds for SSH-CTRIV-CBC and SSH-EIV-CBC. For SSH-$NPC the latter event
can occur, but the probability the latter event occurs is small because the last (random) block of
the encoded packet is not given to the adversary. The strategy we outlined in this paragraph can
be used to prove the security of other xes to the SSH BPP that work by replacing the underlying
encryption scheme; namely, prove that the underlying encryption scheme is ind-cpa secure and that
the probability of the event we described is small. (As an important side note, we only consider the
16
rst out-of-order ciphertext query an adversary makes because if the rst out-of-order ciphertext
query does not decrypt, the decryptor enters a halting state.)
7 Discussion and Recommendations
Having thus presented our main results, we are now in a position to make specic recommendations
to the SSH community. We begin by noting that a fundamental problem with the current SSH
specication is that the counter (that is prepended to the encoded payload before MACing) is only
32 bits long. As shown in Section 4, once the 32 bit counter repeats, an SSH sessions MAC tags
may begin to leak information about a users plaintexts. Our provable security results reect this
constraint: strong security is maintained only if the parties rekey at least once every 2
32
packets.
Two natural solutions to this problem are to either make the counter longer or to require an SSH
session to rekey at least once every 2
32
messages. We recommend the second option because it does
not aect the packet format and thus will likely require minimal changes to existing implementations
of SSH. In the following discussion we assume that all implementations will rekey frequently.
We consider the current instantiation of the SSH BPP transport protocol, SSH-IPC, and our
specic recommendations. We also consider two other possible alternatives, namely switching to
an Encrypt-then-MAC-based construction or to a dedicated authenticated encryption construction.
The former involves re-engineering the SSH BPP so that it rst encrypts a message with some un-
derlying encryption scheme and then MACs the resulting ciphertext. The latter involves modifying
SSH to use a dedicated authenticated encryption scheme (e.g., XCBC [11] or OCB [22]).
Continue to use SSH-IPC? As mentioned, SSH-IPC is susceptible to an adaptive chosen-
plaintext attack requiring an SSH user to encrypt on the order of 2
13
packets. However, the attack
may not be considered practical since it requires the attacker to, after seeing a ciphertext collision,
control the next message that a user encrypts. If the session is encrypting a lot of data very
quickly (e.g., while transferring a le), then an attacker may not have time to both recognize that a
collision has occurred and to force the user to encrypt a specially-doctored message. Additionally,
if we consider how the SSH transport protocol is used within SSH (and not as an entity by itself),
then the attack is complicated by the fact that an application may compress and further encode
user data before passing the resulting compressed payload to the SSH-IPC protocol. Nonetheless,
we suggest that the use of SSH-IPC be deprecated. One simple reason is that, even if these
attacks may be dicult to mount in practice, in the modern era of strong cryptography it would
seem counterintuitive to voluntarily use a protocol with low security when it is possible to x the
security of SSH at minimal cost.
Switch to SSH-NPC? Since SSH-NPC requires similar changes to the specication and imple-
mentations as SSH-$NPC while achieving less security than our other xes, there does not appear
to be any substantial reasons to switch to SSH-NPC. Therefore, we do not consider it further.
Switch to SSH-$NPC? The advantages oered by SSH-$NPC are clear: it is provably secure and
requires relatively minor and mostly localized changes to the SSH specication and to implemen-
tations. The added security, however, comes with the additional cost of up to two extra blocks per
packet. In interactive sessions where an individual packet may only contain a few bytes of user data,
the additional cost associated with those extra blocks may be signicant (in terms of bandwidth
consumption, the time necessary to encrypt and MAC those two extra blocks, and the time required
to generate the extra block of randomness). Another potential problem with SSH-$NPC is that it
is prone to accidental implementation mistakes. Recall that if the padding used with SSH-$NPC
is not randomized, then the same reaction attack against SSH-NPC will be eective here. Since
two SSH implementations will inter-operate regardless of whether their padding is random or xed,
17
an SSH developer might accidentally use non-random or predictable padding. Such an accidental
implementation mistake could have serious security consequences.
Switch to SSH-CTR? SSH-CTRIV-CBC? SSH-EIV-CBC? The SSH-CTR instantiation is a
promising candidate since it is provably secure, does not incur packet expansion, and does not
require the padding to be random. Furthermore, there are several performance advantages with
using CTR mode instead of CBC mode; for example, a software CTR mode implementation can
be up to four times faster than a well-optimized CBC implementation [20]. Although perhaps not
as attractive as SSH-CTR, SSH-CTRIV-CBC and SSH-EIV-CBC are also promising candidates
because they also require no additional padding and because they only use one more block cipher
invocation per packet than SSH-IPC.
Recall that the underlying encryption schemes for SSH-CTR, SSH-CTRIV-CBC, and SSH-EIV-
CBC require both the sender and the receiver to maintain state. Prior to this work, most prov-
able security analyses focused on encryption schemes with stateless decryption algorithms (hence
our need to dene security notions for encryption schemes with stateful decryption algorithms).
Consequently, one initial objection to these three constructions might be that they require the
underlying decryption algorithms to maintain state. However, since the composite SSH BPP de-
cryption algorithm is already stateful (because the decoding algorithm is stateful), the fact that
these three xes use underlying encryption schemes with stateful decryption algorithms should be
of little concern. Another potential disadvantage with CTR mode is that it is often perceived as
being too risky [20]. As [20] points out, however, when used correctly and with proofs of security,
CTR mode has many advantages over other encryption modes. Furthermore, as Bellovin and Blaze
point out in [5], one can minimize the risk incurred with using CTR mode (including the risk of
being forced to use repeating counters) if key management is done dynamically and properly, if
it is not used with multiple senders who share keys, and if it is used in conjunction with strong
integrity checks. All of these conditions hold in the case of SSH-CTR.
Switch to Encrypt-then-MAC? Instead of insisting on using the current SSH Encode-then-
E&M construction, it would also be possible to switch to another paradigm such as Encrypt-then-
MAC (in which the message is rst encrypted with an underlying encryption scheme and then the
resulting ciphertext is MACed with an underlying message authentication scheme). This alterna-
tive is attractive because an Encrypt-then-MAC construction is provably secure assuming that its
underlying encryption and message authentication schemes are also secure [3, 18]. We note, how-
ever, that since our recommended xes provably meet our strongest notions of security, there may
be little motivation to switch to an Encrypt-then-MAC-based construction. Additionally, switch-
ing to an Encrypt-then-MAC construction will likely require more intrusive modications to the
current SSH specication and to SSH implementations. Furthermore, unless care is taken, imple-
mentations of the modied SSH specication may not be compatible with implementations of the
current SSH specication. Conceptually speaking, the changes incurred by SSH-CTR, SSH-$NPC,
SSH-CTRIV-CBC, and SSH-EIV-CBC involve only changing the underlying encryption module
and, in the case of SSH-$NPC, adding more random number generation for the padding. In con-
trast, the changes incurred by switching to the Encrypt-then-MAC construction involve changing
the whole construction. Of course, the dierence in the actual eorts that developers need to put
in is highly implementation dependent.
Switch to dedicated authenticated encryption schemes? There are symmetric key-based
authenticated encryption schemes that are designed from scratch and, thus, are potentially more
ecient than schemes based on a black-box composition of o-the-shelf encryption and MAC com-
ponents. These include RPC [17], XCBC [11], IACBC [16], and OCB [22]. Recall that currently the
input to the SSH BPPs underlying encryption scheme is dierent from the input to the underlying
18
MAC. There are two possible ways to incorporate a dedicated authenticated encryption scheme
into SSH: (1) specically re-design the SSH specication around a single authenticated encryption
component or (2) somehow plug a dedicated authenticated encryption scheme into the current SSH
design. As we mentioned when we considered the Encrypt-the-MAC paradigm, re-designing the
SSH specication is probably not an attractive option.
For (2), the most logical way to incorporate a dedicated scheme into SSH would be to replace
the current encryption scheme (CBC mode with chained IVs) with something like XCBC or OCB
and to use the none message authentication scheme. As we argued for SSH-CTR, SSH-$NPC,
SSH-CTRIV-CBC, and SSH-EIV-CBC, this modication should be fairly easy to do, and, given the
eciency of dedicated authenticated encryption schemes, could result in signicant performance
gains. The present drawback with this approach is that the current SSH specication does not
use include the 32-bit counter in the input to the underlying encryption scheme. Since, under this
construction, the counter will not be bound to the input to the dedicated authenticated encryption
scheme, this construction cannot protect against replay and out-of-order delivery attacks messages
(while our proposed recommendations can). To rectify this situation, one would still have to
modify more than just the black-box encryption component of the SSH BPP; doing so has the
same drawbacks as possibility (1) above.
Closing remarks. We acknowledge that there are many possible ways to x the current problems
with the SSH protocol. We are biased towards our recommended xes (e.g., SSH-CTR) because
they are less intrusive than the other possible modications but are still ecient and secure.
Less intrusive is, however, a subjective measure and the IETF SSH working group may decide
that it is feasible to re-engineer the SSH protocol to use an Encrypt-then-MAC-based construction
or a dedicated authenticated encryption scheme. Given the inertia of the current SSH protocol,
however, we feel that the working group may have a hard time justifying signicant modications
to the SSH specication. The goal of this work is to provide enough information to the SSH
community so that the SSH community can make an informed decision when deciding how to x
the current problems with SSH.
Acknowledgments
We thank Alexandra Boldyreva, Gregory Neven, Adriana Palacio, Bill Sommerfeld, and David
Wagner. The second author thanks the USENIX Association for a Student Grant supporting his
earlier work with SSH.
References
[1] M. Bellare, A. Desai, E. Jokipii, and P. Rogaway. A concrete security treatment of symmetric
encryption. In IEEE, editor, Proceedings of the Thirty-eighth Symposium on Foundations of
Computer Science, pages 394403. IEEE, 1997.
[2] M. Bellare, J. Kilian, and P. Rogaway. The security of the cipher block chaining message
authentication code. In Y. Desmedt, editor, Advances in Cryptology CRYPTO 94, volume
839 of Lecture Notes in Computer Science. Springer-Verlag, Berlin Germany, Aug. 1994.
[3] M. Bellare and C. Namprempre. Authenticated encryption: Relations among notions and
analysis of the generic composition paradigm. In T. Okamoto, editor, Advances in Cryptology
ASIACRYPT 2000, volume 1976 of Lecture Notes in Computer Science, pages 531545.
Springer-Verlag, Berlin Germany, Dec. 2000.
19
[4] S. Bellovin. Problem areas for the IP security protocols. In Sixth USENIX Security Symposium,
1996.
[5] S. Bellovin and M. Blaze. Cryptographic modes of operation for the internet. In Second NIST
Workshop on Modes of Operation, 2001.
[6] J. Black and P. Rogaway. CBC MACs for arbitrary-length messages: The three-key con-
struction. In M. Bellare, editor, Advances in Cryptology CRYPTO 2000, Lecture Notes in
Computer Science. Springer-Verlag, Berlin Germany, Aug. 2000.
[7] R. Canetti and H. Krawczyk. Analysis of key-exchange protocols and their use for building
secure channels. In B. Ptzmann, editor, Advances in Cryptology EUROCRYPT 2001,
volume 2045 of Lecture Notes in Computer Science, pages 451472. Springer-Verlag, Berlin
Germany, 2001.
[8] W. Dai. An attack against SSH2 protocol, Feb. 2002. Email to the [email protected]
email list.
[9] DES modes of operation. National Institute of Standards and Technology, NIST FIPS PUB
81, U.S. Department of Commerce, Dec. 1980.
[10] W. Die and M. E. Hellman. Privacy and authentication: An introduction to cryptography.
Proceedings of the IEEE, 67(3):397427, Mar. 1979.
[11] V. Gligor and P. Donescu. Fast encryption and authentication: XCBC encryption and XECB
authentication modes. In Fast Software Encryption. Springer-Verlag, Berlin Germany, 2001.
[12] O. Goldreich, S. Goldwasser, and S. Micali. On the cryptographic applications of random
functions. In G. R. Blakley and D. C. Chaum, editors, Advances in Cryptology CRYPTO
84, volume 196 of Lecture Notes in Computer Science, pages 276288. Springer-Verlag, Berlin
Germany, 1985.
[13] S. Goldwasser and S. Micali. Probabilistic encryption. Journal of Computer and System
Science, 28:270299, 1984.
[14] C. Hall, I. Goldberg, and B. Schneier. Reaction attacks against several public-key cryptosys-
tems. In Proceedings of Information and Communication Security, ICICS99, 1999.
[15] Internet Engineering Task Force. Secure Shell (secsh) charter, 2002. http://www.ietf.org/
html.charters/secsh-charter.html.
[16] C. Jutla. Encryption modes with almost free message integrity. In B. Ptzmann, editor,
Advances in Cryptology EUROCRYPT 2001, volume 2045 of Lecture Notes in Computer
Science. Springer-Verlag, Berlin Germany, May 2001.
[17] J. Katz and M. Yung. Unforgeable encryption and chosen ciphertext secure modes of operation.
In B. Schneier, editor, 7th International Workshop, Fast Software Encryption, volume 1978 of
Lecture Notes in Computer Science, pages 284299. Springer-Verlag, Berlin Germany, 2000.
[18] H. Krawczyk. The order of encryption and authentication for protecting communications (or:
How secure is SSL?). In J. Kilian, editor, Advances in Cryptology CRYPTO 2001, volume
2139 of Lecture Notes in Computer Science. Springer-Verlag, Berlin Germany, Aug. 2001.
20
[19] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-hashing for message authenticationa.
RFC 2104, 1997.
[20] H. Lipmaa, P. Rogaway, and D. Wagner. CTR-mode encryption. In First NIST Workshop on
Modes of Operation, 2000.
[21] P. Rogaway. Problems with proposed IP cryptography, 1995. Available at http://www.cs.
ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt.
[22] P. Rogaway, M. Bellare, J. Black, and T. Krovetz. OCB: A block-cipher mode of operation
for ecient authenticated encryption. In Eighth ACM Conference on Computer and Commu-
nications Security, pages 196205. ACM, 2001.
[23] D. X. Song, D. Wagner, and X. Tian. Timing analysis of keystrokes and timing attacks on
SSH. In Tenth USENIX Security Symposium, 2001.
[24] S. Vaudenay. Security aws induced by CBC padding applications to SSL, IPSEC, WTLS
. . . . In L. Knudsen, editor, Advances in Cryptology EUROCRYPT 2002, volume 2332 of
Lecture Notes in Computer Science, pages 534545. Springer-Verlag, Berlin Germany, 2002.
[25] T. Ylonen. SSH Secure login connections over the Internet. In Sixth USENIX Security
Symposium, 1996.
[26] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. Lehtinen. SSH transport
layer protocol, 2002. Draft, available at http://www.ietf.org/internet-drafts/
draft-ietf-secsh-transport-12.txt.
A Formal Notions of Security
Denition A.1 (Collision resistance of encoding schemes) Let c( = (Enc, Dec) be a en-
coding scheme. Let A
cpa
be an adversary with access to an encoding oracle and let A
cca
be an
adversary with access to an encoding oracle Enc() and a decoding oracle Dec(). Let M
i
denote
an adversarys i-th encoding query and let (M
i
e
, M
i
t
) denote the response for that query. Let m
i
e
denote A
cca
s i-th decoding query and let (m
i
, m
i
t
) denote the response for that query. Consider
the following experiments:
Experiment Exp
coll-cpa
c(
(A
cpa
)
If A
Enc()
cpa
makes two queries M
i
, M
j
to Enc() such that i = j and M
i
t
= M
j
t
then return 1 else return 0
Experiment Exp
coll-cca
c(
(A
cca
)
Run A
Enc(),Dec()
cca
and, if one of the following occurs:
A
cca
makes two queries M
i
, M
j
to Enc() such that i = j and M
i
t
= M
j
t
A
cca
makes two queries m
i
e
, m
j
e
to Dec() such that i = j, m
i
t
=, and m
i
t
= m
j
t
A
cca
makes a query M
i
to Enc() and a query m
j
e
to Dec() such that
(i = j or M
i
= m
j
or M
i
e
= m
j
e
) and M
i
t
= m
j
t
then return 1 else return 0
21
We dene the advantages of the adversaries A
cpa
and A
cca
in nding a collision as
Adv
collcpa
c(
(A
cpa
) = Pr

Exp
coll-cpa
c(
(A
cpa
) = 1

Adv
collcca
c(
(A
cca
) = Pr

Exp
coll-cca
c(
(A
cca
) = 1

.
Denition A.2 (Privacy for symmetric encryption schemes) Let oc = (/, c, T) be a sym-
metric encryption scheme, and let b 0, 1. Let A
cpa
be an adversary that has access to a
left-or-right encryption oracle c
K
(L{(, , b)); let A
cca
and A
sfcca
be adversaries that have access
to a left-or-right encryption oracle and a decryption oracle T
K
(). Each adversary returns a bit.
Consider the following experiments:
Experiment Exp
ind-cpa-b
Sc
(A
cpa
)
K
R
/
Run A
c
K
(/1(,,b))
cpa
Reply to c
K
(L{(M
0
, M
1
, b)) queries
as follows:
C
R
c
K
(M
b
) ; A
cpa
C
Until A
cpa
returns a bit d
Return d
Experiment Exp
ind-cca-b
Sc
(A
cca
)
K
R
/
Run A
c
K
(/1(,,b)),T
K
()
cca
Reply to c
K
(L{(M
0
, M
1
, b)) queries
as follows:
C
R
c
K
(M
b
) ; A
cca
C
Reply to T
K
(C) queries as follows:
M T
K
(C) ; A
cca
M
Until A
cca
returns a bit d
Return d
Experiment Exp
ind-sfcca-b
Sc
(A
sfcca
)
K
R
/
i 0 ; j 0 ; phase 0
Run A
c
K
(/1(,,b)),T
K
()
sfcca
Reply to c
K
(L{(M
0
, M
1
, b)) queries
as follows:
i i + 1 ; C
i
R
c
K
(M
b
)
A
sfcca
C
i
Reply to T
K
(C) queries as follows:
j j + 1 ; M T
K
(C)
If j > i or C = C
j
then phase 1
If phase = 1 then A
sfcca
M
Until A
sfcca
returns a bit d
Return d
We require that, for all queries (M
0
, M
1
) to c
K
(L{(, , b)), [M
0
[ = [M
1
[. For Exp
ind-cca-b
Sc
(A
cca
),
we require that A
cca
not query T
K
() on a ciphertext previously returned by c
K
(L{(, , b)). We
respectively dene the chosen-plaintext, chosen-ciphertext, and stateful chosen-ciphertext privacy
advantages of the adversaries as
Adv
ind-cpa
Sc
(A
cpa
) = Pr

Exp
ind-cpa-1
Sc
(A
cpa
) = 1

Pr

Exp
ind-cpa-0
Sc
(A
cpa
) = 1

Adv
ind-cca
Sc
(A
cca
) = Pr

Exp
ind-cca-1
Sc
(A
cca
) = 1

Pr

Exp
ind-cca-0
Sc
(A
cca
) = 1

Adv
ind-sfcca
Sc
(A
sfcca
) = Pr

Exp
ind-sfcca-1
Sc
(A
sfcca
) = 1

Pr

Exp
ind-sfcca-0
Sc
(A
sfcca
) = 1

.
Denition A.3 (Integrity for symmetric encryption schemes) Let oc = (/, c, T) be a
symmetric encryption scheme. Let A
ptxt
, A
ctxt
, and A
sfctxt
be adversaries each with access to an
encryption oracle c
K
() and a decryption-verication oracle T

K
(). The decryption-verication
oracle invokes T
K
(C) and returns 1 if T
K
() = and 0 otherwise. Consider the experiments
22
Experiment Exp
int-ptxt
Sc
(A
ptxt
)
K
R
/ ; S
Run A
c
K
(),T

K
()
ptxt
Reply to c
K
(M) queries as follows:
C
R
c
K
(M)
S S M
A
ptxt
C
Reply to T

K
(C) queries as follows:
M T
K
(C)
If M = and M S then return 1
If M = then A
ptxt
1
Else A
ptxt
0
Until A
ptxt
halts
Return 0
Experiment Exp
int-sfctxt
Sc
(A
sfctxt
)
K
R
/
i 0 ; j 0 ; phase 0
Run A
c
K
(),T

K
()
ctxt
Reply to c
K
(M) queries as follows:
i i + 1 ; C
i
R
c
K
(M
b
)
A
sfctxt
C
i
Reply to T

K
(C) queries as follows:
j j + 1 ; M T
K
(C)
If j > i or C = C
j
then phase 1
If M = and phase = 1 then return 1
If M = then A
sfctxt
1
Else A
sfctxt
0
Until A
sfctxt
halts
Return 0
and an experiment Exp
int-ctxt
Sc
(A
ctxt
) that is identical to Exp
int-ptxt
Sc
(A
ptxt
) except that the rst
boxed equation is S S C and the second boxed equation is C S. We dene the advantages
of the adversaries in attacking the plaintext, ciphertext, and stateful ciphertext integrity of the
scheme respectively as
Adv
int-ptxt
Sc
(A
ptxt
) = Pr

Exp
int-ptxt
Sc
(A
ptxt
) = 1

Adv
int-ctxt
Sc
(A
ctxt
) = Pr

Exp
int-ctxt
Sc
(A
ctxt
) = 1

Adv
int-sfctxt
Sc
(A
ctxt
) = Pr

Exp
int-sfctxt
Sc
(A
sfctxt
) = 1

.
Denition A.4 (Strong Unforgeability of message authentication schemes) Let / =
(/, T , 1) be a message authentication scheme. Let F be a forger with access to a tagging oracle
T
K
() and a verication oracle 1
K
(, ). Consider the following experiment:
Experiment Exp
ufcma
/.
(F)
K
R
/ ; S
Run F
T
K
(),1
K
(,)
Reply to T
K
(M) queries as follows:

R
T
K
(M) ; S S (M, ) ; F
Reply to 1
K
(M, ) queries as follows:
v 1(M, )
If v = 1 and (M, ) S then return 1
F v
Until F halts
Return 0
We dene the advantage of F in forging a message as
Adv
uf-cma
/.
(F) = Pr

Exp
ufcma
/.
(F) = 1

.
23
Denition A.5 (Pseudorandom functions and super-pseudorandom permutations) Let
T : 0, 1
k
0, 1
L
be a family of functions from some message space to 0, 1
L
, and let
Rand
/L
denote the family of all functions from to 0, 1
L
. Let { : 0, 1
k
0, 1
l
0, 1
l
denote a family of permutations on 0, 1
l
, and let Perm
l
be the family of all permutations on
0, 1
l
. Let D
prf
be a PRF distinguisher for T and let D
prp
be a super-pseudorandom distinguisher
for {. Consider the following experiments:
Experiment Exp
prf-b
T
(D
prf
)
If b = 1 then K
R
0, 1
k
; g T
K
Else g
R
Rand
/L
Run D
g
prf
Reply to g(M) queries as follows:
D
prf
g(M)
Until D
prf
returns a bit d
Return d
Experiment Exp
prp-cca-b
T
(D
prp
)
If b = 1 then K
R
0, 1
k
; g {
K
Else g
R
Perm
l
Run D
g,g
1
prp
Reply to g(M) queries as follows:
D
prp
g(M)
Reply to g
1
(C) queries as follows:
D
prp
g
1
(C)
Until D
prp
returns a bit d
Return d
We dene the advantages of the adversaries as
Adv
prf
T
(D
prf
) = Pr

Exp
prf-1
T
(D
prf
) = 1

Pr

Exp
prf-0
T
(D
prf
) = 1

Adv
prpcca
1
(D
prp
) = Pr

Exp
prp-cca-1
1
(D
prp
) = 1

Pr

Exp
prp-cca-0
1
(D
prp
) = 1

.
B General Security Results for the Encode-then-E&M Paradigm
We present here general results for the Encode-then-E&M composition method. We use these
results when proving the security of our proposed xes. These results will also be useful to the
evaluators of other Encode-the-E&M constructions.
B.1 Chosen-Plaintext Privacy (Proof of Lemma 6.4)
Lemma 6.4 states that, to construct a composed scheme that provides chosen-plaintext privacy via
this paradigm, it is enough to use an ind-cpa secure encryption scheme, a pseudorandom MAC, and
a coll-cpa secure encoding scheme as building blocks. One notable feature of the proof is that it
actually uses a weaker property than pseudorandomness for the underlying MAC. But since most
MACs in practice are pseudorandom, the distinction is perhaps mainly of theoretical interest.
Distinct plaintext privacy of message authentication schemes. Before proving Lemma
6.4, we rst present a new notion of security for message authentication schemes: indistinguishabil-
ity under distinct chosen-plaintext attacks, ind-dcpa for short. Let / = (/, T , 1) be a message
authentication scheme. The notion of ind-dcpa for / is based on the notion of ind-cpa for en-
cryption schemes. For bit b and key K let T
K
(L{(, , b)) denote the lr-tag oracle which, given
equal-length plaintexts M
0
, M
1
, returns T
K
(M
b
). (We stress that the lr-tag oracle returns only the
tag and not the message-tag pair M
b
|T
K
(M
b
).) The ind-dcpa notion is dened as follows.
Denition B.1 (Indistinguishability against Distinct Chosen-Plaintext Attacks) Let /
= (/, T , 1) be a message authentication scheme. Let b 0, 1. Let A be an adversary that has
access to an oracle T
K
(L{(, , b)). Consider the following experiment:
24
Experiment Exp
ind-dcpa-b
Sc
(A
cpa
)
K
R
/
Run A
c
K
(/1(,,b))
cpa
Reply to c
K
(L{(M
0
, M
1
, b)) queries as follows:
C
R
c
K
(M
b
) ; A
cpa
C
Until A
cpa
returns a bit d
Return d
Above it is mandated that all left messages of As queries be unique and that all right messages of
As queries be unique. We dene the advantage of A via
Adv
ind-dcpa
/.
(A) = Pr

Exp
ind-dcpa-1
/.
(A) = 1

Pr

Exp
ind-dcpa-0
/.
(A) = 1

.
Theorem B.2 (Relation between IND-DCPA and PRF) Let / be a MAC scheme. Then,
given any ind-dcpa adversary A against /, we can construct a distinguisher D against / such
that
Adv
ind-dcpa
/.
(A) 2 Adv
prf
/.
(D)
Furthermore, D uses the same resources of A.
This theorem implies that if / is secure as a PRF (as is expected of many MACs; e.g., [2, 6]),
then it will also be ind-dcpa secure. The theorem is easy to verify. Therefore, we omit the proof.
Now we state and prove Lemma B.3 below. Lemma 6.4 follows directly from Theorem B.2 and
Lemma B.3. Throughout, we let Enc

(, ) and Dec

(, ) denote the encoding algorithms Enc()

and Dec() except that they explicitly take a state as part of the input and return a new state as
part of the output.
Lemma B.3 Let oc = (/
e
, c, T) be an encryption scheme, let / = (/
t
, T , 1) be a message
authentication scheme, and let c( = (Enc, Dec) be an encoding scheme. Let oc be the encryption
scheme associated to them as per Construction 6.1. Then, given any ind-cpa adversary S against
oc, we can construct an ind-cpa adversary A against oc, an ind-dcpa adversary B against /,
and a collision nder C such that
Adv
ind-cpa
Sc
(S) Adv
ind-cpa
Sc
(A) +Adv
ind-dcpa
/.
(B) + 2 Adv
collcpa
c(
(C) .
Furthermore, A, B, and C use the same resources as S except that As and Bs inputs to their
respective oracles may be slightly larger than those of S (due to the encoding).
Proof of Lemma B.3: Let S denote an ind-cpa adversary that has oracle access to c
K
(L{(, , b)),
b 0, 1. Let x 1, 2, 3. We dene three experiments associated with S as follows.
Experiment ExpH
x
K
e
R
/
e
; K
t
R
/
t
; st
0
; st
1

Run S replying to its oracle query (M
0
, M
1
) as follows:
(M
e,0
, M
t,0
, st
0
)
R
Enc

(M
0
, st
0
) ; (M
e,1
, M
t,1
, st
1
)
R
Enc

(M
1
, st
1
)
Switch (x):
Case x = 1:
R
c
K
e
(M
e,1
) ;
R
T
K
t
(M
t,1
)
Case x = 2:
R
c
K
e
(M
e,0
) ;
R
T
K
t
(M
t,1
)
Case x = 3:
R
c
K
e
(M
e,0
) ;
R
T
K
t
(M
t,0
)
Return | to S
Until S halts and returns a bit b
Return b.
25
Let P
x
def
= Pr [ ExpH
x
= 1 ] denote the probability that experiment ExpH
x
returns 1, for x
1, 2, 3. By the denition of Adv
ind-cpa
Sc
(S), we have
Adv
ind-cpa
Sc
(S) = P
1
P
3
= (P
1
P
2
) + (P
2
P
3
) . (3)
Given S, we can construct three new adversaries A, B, and C such that the following lemmas hold
and the new adversaries use the resources specied in the statement of Lemma B.3.
Lemma B.4 P
1
P
2
Adv
ind-cpa
Sc
(A).
Lemma B.5 P
2
P
3
Adv
ind-dcpa
/.
(B) + 2 Adv
collcpa
c(
(C).
Equation (3) and the above lemmas imply Lemma B.3.
Proof of Lemma B.4: We construct an adversary A breaking privacy of the underlying encryption
scheme oc = (/
e
, c, T) using the adversary S below.
Adversary A
c
K
(/1(,,b))
K
t
R
/
t
; st
0
; st
1

Run S replying to its oracle query (M
0
, M
1
) as follows:
(M
e,0
, M
t,0
, st
0
)
R
Enc

(M
0
, st
0
) ; (M
e,1
, M
t,1
, st
1
)
R
Enc

(M
1
, st
1
)

R
c
K
(L{(M
e,0
, M
e,1
, b)) ;
R
T
Kt
(M
t,1
)
Return | to S
Until S halts and returns a bit b
Return b.
If b = 1, the adversary A simulates S in the exact same environment as that of ExpH
1
. Similarly,
if b = 0, the adversary A simulates S in the exact same environment as that of ExpH
2
. Thus,
P
1
P
2
= Pr

Exp
ind-cpa-1
Sc
(A) = 1

Pr

Exp
ind-cpa-0
Sc
(A) = 1

= Adv
ind-cpa
Sc
(A) .
The adversary A uses the same resources as S except that, due to the encoding, the queries that
A makes to its oracle may be slightly larger than the queries that S makes to its oracle. Also, A
performs two encodings for each query that S makes and, thus, its running time is (polynomially)
larger than that of S. Recall the standard convention that running time of an adversary is measured
with respect to the entire experiment in which it runs. Hence, Lemma B.4 follows.
Proof of Lemma B.5: Given S, we can construct an adversary B that can break the distinct
chosen-plaintexts privacy of the underlying MAC scheme / = (/
t
, T , 1) and an adversary C
that can break the collision resistance of the underlying encoding scheme c( = (Enc, Dec). These
adversaries are dened in below.
26
Adversary B
T
K
(/1(,,b))
K
e
R
/
e
; st
0
; st
1

Run S replying to its ith oracle
query (M
i
0
, M
i
1
) as follows:
(M
i
e,0
, M
i
t,0
, st
0
)
R
Enc

(M
i
0
, st
0
)
(M
i
e,1
, M
i
t,1
, st
1
)
R
Enc

(M
i
1
, st
1
)
If M
i
t,0
M
1
t,0
, . . . , M
i1
t,0
or
M
i
t,1
M
1
t,1
, . . . , M
i1
t,1
then return 0

R
c
K
e
(M
i
e,0
)

R
T
K
(L{(M
i
t,0
, M
i
t,1
, b))
Return | to S
Until S halts and returns a bit b
Return b
Adversary C
Enc()
K
e
R
/
e
; K
t
R
/
t
; st
n

d
R
0, 1 ; c d
Run S replying to its oracle
query (M
0
, M
1
) as follows:
(M
e,d
, M
t,d
)
R
Enc(M
d
)
(M
e,c
, M
t,c
, st
n
)
R
Enc

(M
c
, st
n
)

R
c
K
e
(M
e,0
)

R
T
K
t
(M
t,1
)
Return | to S
Until S halts and returns a bit b
Let Pr
2
[ ] and Pr
3
[ ] denote the probabilities associated with the experiment ExpH
2
and ExpH
3
,
respectively. Let E
2
denote an event that there exists at least one collision among the M
t,0
s or
among the M
t,1
s in ExpH
2
. Let E
3
denote an event that there exists at least one collision among
the M
t,0
s or among the M
t,1
s in ExpH
3
. We make the following claims.
Claim B.6 Pr
2
[ E
2
] 2 Adv
collcpa
c(
(C).
Claim B.7 Pr
2

ExpH
2
= 1 E
2

Pr
3

ExpH
3
= 1 E
3

= Adv
ind-dcpa
Sc
(B).
We can now bound the dierence P
2
P
3
as follows:
P
2
P
3
= Pr
2
[ ExpH
2
= 1 ] Pr
3
[ ExpH
3
= 1 ]
= Pr
2

ExpH
2
= 1 E
2

+ Pr
2
[ ExpH
2
= 1 E
2
]
Pr
3

ExpH
3
= 1 E
3

Pr
3
[ ExpH
3
= 1 E
3
]
Adv
ind-dcpa
Sc
(B) + 2 Adv
collcpa
c(
(C) .
To justify Claim B.6, let E
0
be the event that there exists at least one collision among the M
t,0
s in
ExpH
2
and let E
1
be the event that there exists at least one collision among the M
t,1
s in ExpH
2
.
Let Pr [ ] be over Exp
coll-cpa
c(
(C). Then,
Pr

Exp
coll-cpa
c(
(C) = 1

= Pr [ E
0
d = 0 ] + Pr [ E
1
d = 1 ]
=
1
2

Pr
2
[ E
0
] + Pr
2
[ E
1
]

1
2
Pr
2
[ E
2
]
where the second equality comes from the fact that the messages C returns to A are independent
of the bit d. To justify Claim B.7, we note that B returns 1 only if all the M
t,0
s and M
t,1
s are
unique (i.e., events E
2
or E
3
did not occur).
The adversaries B and C use the same resources as S except that the queries that B makes to its
oracle may be slightly larger than those of S due to the encoding. Also, B and C each perform
two encodings for each query that S makes and, thus, their running times are (polynomially) larger
than that of S. Recall the standard convention that running time of an adversary is measured with
respect to the entire experiment in which it runs. Hence, Lemma B.5 follows.
27
B.2 Integrity of Plaintexts
Theorem B.8 states that the composed scheme provides plaintext integrity if the underlying MAC is
unforgeable
2
and if the underlying encoding scheme is collision-resistant against chosen-ciphertext
attacks. As one would expect, we need more than chosen-plaintext collision resistance of the
underlying encoding scheme here because an adversary is allowed to submit ciphertext queries
when mounting an integrity attack.
Theorem B.8 (Integrity of Plaintexts for Encode-then-E&M) Let oc be an encryption
scheme, let / be a message authentication scheme, and let c( be an encoding scheme. Let oc
be the encryption scheme associated to them as per Construction 6.1. Then, given any int-ptxt
adversary A against oc, we can construct adversaries F and C such that
Adv
int-ptxt
Sc
(A) Adv
uf-cma
/.
(F) +Adv
collcca
c(
(C) .
Furthermore, F and C use the same resources as A except that Fs messages to its tagging and tag
verication oracles may be slightly larger than As encryption queries (due to the encoding) and
that Cs messages to its decoding oracle may have dierent lengths than As decryption queries.
We prove Theorem B.8 as follows. Let oc = (/, c, T) be the composite encryption scheme con-
structed via Construction 6.1 from the encryption scheme oc = (/
e
, c, T), the MAC scheme
/ = (/
t
, T , 1), and the encoding scheme c( = (Enc, Dec). Assume we have an adversary A
attacking the integrity of plaintexts of oc. We associate to A two adversaries: a forger F breaking
the unforgeability of / and a collision nder C breaking the collision resistance of c( such that
Adv
int-ptxt
Sc
(A) Adv
uf-cma
/.
(F) +Adv
collcca
c(
(C) . (4)
The forger F and the collision nder C are simple. The forger F uses /
e
to generate an encryption
key and uses the encryption key and its tagging oracle to answer As queries in a straight-forward
manner. In particular, it follows Construction 6.1. Similarly, the collision nder C uses the same
approach. This ensures that A is executed in the same environment as that in Exp
int-ptxt
Sc
(A).
Let Pr
1
[ ], Pr
2
[ ], and Pr
3
[ ] respectively denote the probabilities associated with the exper-
iments Exp
int-ptxt
Sc
(A), Exp
ufcma
/.
(F), and Exp
coll-cca
c(
(C). Let E denote the event that A makes
a query that would cause C to succeed in nding a collision. Then, by the denition of E, Pr
1
[ E ] =
Pr
3

Exp
coll-cca
c(
(C) = 1

. Furthermore, Pr
1

Exp
int-ptxt
Sc
(A) = 1 E

Pr
2

Exp
ufcma
/.
(F) = 1

since E implies that the verication request that caused A to succeed must have produced (through
the decoding) a previously unseen tagging message M
t
(thereby allowing F to succeed). Conse-
quently,
Pr
1

Exp
int-ptxt
Sc
(A) = 1

= Pr
1

Exp
int-ptxt
Sc
(A) = 1 E

+ Pr
1

Exp
int-ptxt
Sc
(A) = 1 E

Pr
2

Exp
ufcma
/.
(F) = 1

+ Pr
3

Exp
coll-cca
c(
(C) = 1

and Equation (4) follows. Adversaries F and A use equivalent resources except that Fs messages
to its oracles may be slightly larger due to the encoding. Adversaries C and A also use equiva-
lent resources except that Cs message to its oracle may not be the exactly the same size as As
decryption-verication queries, although they are polynomially related.
2
Although the theorem statement refers to strong unforgeability, weak unforgeability of the underlying MAC
scheme is actually sucient here since the coll-cca property of the underlying encoding scheme ensures that inputs
to the MAC algorithm will not collide.
28
B.3 Obtaining Chosen-Ciphertext Privacy (Proof of Proposition 6.2)
Our proof is modeled after the proof in [3]. Let oc = (/, c, T) be a symmetric encryption scheme,
and let A be any ind-sfcca adversary against oc. We associate to A an ind-cpa adversary B and
an int-sfctxt adversary I. These adversaries are simple. The adversary B runs A almost exactly as
in Exp
ind-sfcca-b
Sc
(A) where b is Bs lr-encryption oracle bit. The only exception is that B return
to A if A submits an out-of-sync decryption query. Then, B outputs what A outputs. Similarly, I
runs A almost exactly as in Exp
ind-sfcca-A
Sc
(b) where b is a bit that I chooses at random. The only
exception is that, when A successfully submits an out-of-sync decryption query, the adversary I
terminates.
Let Pr
1
[ ] denote the probability over Exp
ind-sfcca-b
Sc
(A) and a random choice for b 0, 1,
and let b
t
denote the output of A in these experiments. Let Pr
2
[ ] denote the probability in
Exp
int-sfctxt
Sc
(I). Let Pr
3
[ ] denote the probability over Exp
ind-cpa-c
Sc
(B) where c is randomly selected
from 0, 1 and let c
t
be the bit B returns. Let E denote the event that A makes at least one query
to a phase 1 decryption oracle that would successfully decrypt. Note that
Pr
1

b
t
= b E

Pr
1
[ E ] Adv
int-sfctxt
Sc
(I)
since, prior to E occurring, Exp
int-sfctxt
Sc
(I) runs A exactly as in Exp
ind-sfcca-b
Sc
(A) for a random b
and, once E occurs, I succeeds in forging a ciphertext. Also note that
Pr
1

b
t
= b E

Pr
3

c
t
= c

=
1
2
Pr

Exp
ind-cpa-1
Sc
(B) = 1

+
1
2

1 Pr

Exp
ind-cpa-0
Sc
(B) = 1

=
1
2
Adv
ind-cpa
Sc
(B) +
1
2
since whenever A does not cause event E to occur, As view when run by B is equivalent to its
view when run in Exp
ind-sfcca-b
Sc
(A). Consequently,
1
2
Adv
ind-sfcca
Sc
(A) +
1
2
= Pr
1

b
t
= b

= Pr
1

b
t
= b E

+ Pr
1

b
t
= b E

Adv
int-sfctxt
Sc
(I) +
1
2
Adv
ind-cpa
Sc
(B) +
1
2
.
The adversaries B and I use the same resources as A except that B does not perform any chosen-
ciphertext queries to a decryption oracle.
C SSH Proofs
C.1 Proof of Lemma 6.3
First, we prove the rst inequality in the theorem. Recall that the padding is chosen independently
at random from 0, 1
mbpl
where mbpl is the minimum padding length. For a coll-cpa adversary A
to win, it must make at least two encoding queries M
i
, M
j
such that i = j and M
i
t
= M
j
t
. From
the construction, this means that the values of the counters and the paddings must collide (i.e.
st
i
n
= st
j
n
and p
i
= p
j
). For each counter value, the probability that the paddings collide is 2
mbpl
.
There are 2
32
possible values for the counter, and each value occurs at most q
e
/2
32
| times over
29
the course of the experiment. Therefore, the probability that any coll-cpa adversary A making at
most q
e
encoding queries can win is at most

q
e
2
32
|
2

2
32
2
mbpl
After some simplication, the rst inequality in the theorem follows.
Now, we prove the second equality in the theorem. Recall that the construction in Figure 2
species that M
t
'st
n
`
32
|M
e
for the encoding and that M
t
'st
u
`
32
|M
e
for the decoding.
Since the states st
n
, st
u
are counters that are maintained internally by the oracles, no adversary B
can have control over them. Since both states start at 0, if B is limited to fewer than 2
32
encoding
queries and 2
32
decoding queries, then it is easy to see that B cannot possibly make two queries
satisfying either of the rst two conditions in the experiment Exp
coll-cca
c(
(B). We now turn our
attention to the last condition in the experiment and argue that B cannot possibly satisfy it either.
Suppose toward a contradiction that B can somehow make a query M
i
to Enc() and a query m
j
e
to Dec() such that (i = j or M
i
= m
j
or M
i
e
= m
j
e
) and M
i
t
= m
j
t
where i, j 2
32
. From Figure 2,
M
i
t
= m
j
t
implies that M
i
e
= m
j
e
and consequently that M
i
= m
j
. Therefore, for this condition to
be satised i must be dierent from j. However, i, j 2
32
. Therefore, i = j implies that st
i
n
= st
j
u
.
Therefore, M
i
t
= m
j
t
, and we have a contradiction. Thus, Adv
collcca
c(
(B) = 0.
C.2 Proof of Theorem 6.5
Equation (2) follows directly from Proposition 6.2 and Lemma 6.4. Now, we prove Equation (1).
Let oc = (/, c, T) be the composite encryption scheme (SSH-CTR in this case) constructed via
Construction 6.1 from the encryption scheme oc = (/
e
, c, T), the MAC scheme / = (/
t
, T , 1),
and the encoding scheme c( = (Enc, Dec). Consider any int-sfctxt adversary I against oc. We
associate to I a uf-cma forger F against / and a coll-cca collision nder C against c( as follows.
The forger F uses /
e
to generate an encryption key and uses the encryption key and its tagging
oracle to answer Is queries in a straight-forward manner. In particular, it follows Construction 6.1.
Similarly, the collision nder C uses the same approach. This ensures that I is executed in the
same environment as that in Exp
int-sfctxt
Sc
(I) until I succeeds in making an out-of-sync query.
Recall that the int-sfctxt adversary I can make two types of queries: encryption queries to
c
K
and decryption-verication queries to T

K
. Suppose I makes q
e
encryption queries and q
d
decryption-verication queries. We denote Is i-th query to c
K
as M
i
, the encoding of M
i
as
M
i
e
, M
i
t
, and the returned ciphertext as
i
|
i
. We denote Is i-th query to T

K
as
t
i
|
t
i
(assuming
that Is i-th query is parsable since otherwise T

K
would enter a halting state). We denote the
decryption (via T) of
t
i
as m
i
e
and the decoding of m
i
e
as (m
i
, m
i
t
). By convention, if T

k
s internal
state is , then m
i
e
=. Also, if m
i
e
=, then (m
i
, m
i
t
) = (, ).
Now, let j be the index of Is rst out-of-sync decryption query, and let k be the number of
encryption queries prior to Is j-th decryption query. Let Bad be an event in which all of the
following conditions hold: Is j-th decryption query correctly veries, m
j
t
M
1
t
, . . . , M
k
t
, k j,

t
j
=
j
, and m
j
e
= M
j
e
. (Recall that if the rst out-of-sync decryption query fails to verify, the
decryption algorithm will return for all subsequent decryption queries.) We state the following
lemmas.
Lemma C.1 Adv
int-sfctxt
Sc
(I) Adv
uf-cma
/.
(F) +Adv
collcca
c(
(C) + Pr [ Bad ]
Lemma C.2 Pr [ Bad ] = 0
Then, Equation (1) in Theorem 6.5 follows. Now, we prove the lemmas.
30
Proof of Lemma C.1: Let Pr [ ] denote the probability function underlying Exp
int-sfctxt
Sc
(I). Let

t
j
|
t
j
be Is rst out-of-sync query to T

K
(). Recall that, prior to Is j-th decryption-verication
query, I made k queries to c
K
(). We dene the following events.
Event E : Is rst out-of-sync query to its oracle T

K
() correctly veries
Event E
1
: E occurs and m
j
t
M
1
t
, . . . , M
k
t

Event E
2
: E occurs and m
j
t
M
1
t
, . . . , M
k
t

Event E
2,1
: E
2
occurs and either k < j or m
j
e
= M
j
e
Event E
2,2
: E
2
occurs and k j and m
j
e
= M
j
e
Event E
2,2,1
: E
2,2
occurs and
t
j
=
j
and m
j
t
M
1
t
, . . . , M
j1
t
, M
j+1
t
, . . . , M
k
t

Event E
2,2,2
: E
2,2
occurs and
t
j
=
j
and m
j
t
M
1
t
, . . . , M
j1
t
, M
j+1
t
, . . . , M
k
t

Event E
2,2,3
: E
2,2
occurs and
t
j
=
j
.
If Is rst out-of-sync query to T

K
() does not correctly verify, then the decryption oracle enters its
halting state, and thus, no further decryption queries will correctly verify and Exp
int-sfctxt
Sc
(I) cannot
return 1. Therefore, Adv
int-sfctxt
Sc
(I) = Pr [ E ]. Also, notice that Pr [ E ] = Pr [ E
1
E
2,2,1
] +
Pr [ E
2,1
E
2,2,2
] + Pr [ E
2,2,3
].
As previous pointed out, the adversaries F and C run I exactly as in Exp
int-sfctxt
Sc
(I) until I succeeds
in making an out-of-sync decryption-verication query. Therefore, it is easy to see that, if events
E
1
or E
2,2,1
occur, then F succeeds in nding a uf-cma forgery against /. Similarly, if events
E
2,1
or E
2,2,2
occur, C succeeds in nding a collision against c(. Consequently,
Adv
int-sfctxt
Sc
(I) = Pr [ E
1
E
2,2,1
] + Pr [ E
2,1
E
2,2,2
] + Pr [ E
2,2,3
]
Adv
uf-cma
/.
(F) +Adv
collcca
c(
(C) + Pr [ Bad ]
as desired.
Proof of Lemma C.2: We are interested in the event that
t
j
=
j
but m
j
e
= M
j
e
(where j
is the index of the rst out-of-order decryption query and the adversary has already queried the
encryption oracle at least j times). Since SSH-CTR uses CTR mode with stateful decryption, since
the encryption and decryption states are in-sync prior to the j-th decryption query, and since, for
each CTR mode state, there is a bijection between plaintexts and ciphertexts, if
t
j
=
j
, then
m
j
e
= M
j
e
. This means that Pr[Bad] = 0.
31