Symmetric Signcryption and

E2EE Group Messaging in Keybase

Joseph Jaeger1 , Akshaya Kumar1 , and Igors Stepanovs2

1
School of Cybersecurity and Privacy
Georgia Institute of Technology, Atlanta, Georgia, US
{josephjaeger,akshayakumar}@gatech.edu
https://cc.gatech.edu/∼josephjaeger/
https://cc.gatech.edu/∼akumar805/
2
[email protected]
https://igors.org/

23 May 2024

Abstract. We introduce a new cryptographic primitive called symmetric signcryption, which differs
from traditional signcryption because the sender and recipient share a secret key. We prove that
a natural composition of symmetric encryption and signatures achieves strong notions of security
against attackers that can learn and control many keys. We then identify that the core encryption
algorithm of the Keybase encrypted messaging protocol can be modeled as a symmetric signcryption
scheme. We prove the security of this algorithm, though our proof requires assuming non-standard,
brittle security properties of the underlying primitives.
Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Standard Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Standard Security Notions in a Multi-key Setting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Symmetric Signcryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 In-Group Unforgeability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Out-Group Authenticated Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Symmetric Signcryption from Encryption and Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 Sign-then-Encrypt Based Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Encrypt-then-Sign Based Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Modeling Keybase Chat Encryption as Symmetric Signcryption . . . . . . . . . . . . . . . . . . . . . . . . 16

5.1 Message and Header Encryption Schemes BoxMessage and SealPacket . . . . . . . . . . . . . . . . . . . . . . . 18

6 Security Analysis of Keybase Chat Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.1 In-Group Unforgeability of BoxMessage and SealPacket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2 Out-Group AE Security of BoxMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.3 Out-Group AE Security of SealPacket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.4 Stronger Out-Group AE Security Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.5 Instantiation and Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

A Proofs for Sign-Then-Encrypt Based Symmetric Signcryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

A.1 In-Group Unforgeability of StE (Proof of Theorem 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.2 Out-group Authenticated Encryption of StE (Proof of Theorem 1) . . . . . . . . . . . . . . . . . . . . . . . . . . 34

B Proofs for the In-Group Unforgeability of Keybase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

B.1 In-Group Unforgeability of BoxMessage (Proof of Theorem 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
B.2 In-Group Unforgeability of SealPacket (Proof of Theorem 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

C Analysis and Proofs for the Out-Group AE Security of Keybase . . . . . . . . . . . . . . . . . . . . . . . . 42

C.1 M-sparsity of Ed25519 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
C.2 ΦSP Derives Messages from Hashed NE Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
C.3 KDMAE for Messages Derived from a Hashed Key (Proof of Proposition 1) . . . . . . . . . . . . . . . . . 51
C.4 Out-Group AE Security of BoxMessage (Proof of Theorem 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
C.5 Out-group AE Security of SealPacket (Proof of Theorem 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

D Proofs for the Stronger Out-Group AE Security Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

D.1 Proof for the UV Security of StE (Proof of Proposition 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
D.2 Proof for the UV Security of Ed25519 (Proof of Proposition 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
D.3 Stronger Out-Group AE Security Results (Proof of Proposition 4). . . . . . . . . . . . . . . . . . . . . . . . . . . 61

E Other Uses of Symmetric Signcryption in Keybase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

E.1 Security of SealPacket as a Standalone Encryption Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
E.2 Multi-purpose Scheme SealWhole for Encrypting Long Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
E.3 Encryption of Attachments with PostFileAttachment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
1 Introduction
Keybase is a suite of encryption tools. It encompasses a public-key directory, an instant messenger, and a
cloud storage service. Keybase was launched in 2014. In February 2020, it reported having accumulated
more than 1.1M user accounts [Keyi]. In May 2020, Keybase was acquired by Zoom. At the time, Zoom
issued a public statement [Zoo20] saying that the Keybase’s team was meant to play a critical part in
building scalable end-to-end encryption for Zoom. The acquisition appears to have put an end to the active
development of new Keybase features, but as of February 2024 it keeps receiving regular maintenance
updates.
Instant Messaging in Keybase. Keybase implements its own end-to-end encrypted instant messaging
protocol. This protocol is designed to support large groups. One-on-one chats are treated as group chats
and hence use the same protocol. The protocol also allows to send large files as encrypted attachments
in chat. It is impossible to opt out of end-to-end encryption in Keybase. In this work we analyze the
security of this protocol.
The Keybase client is open source [Keyc], but the server is not. Our security analysis primarily relies on
the source code. Keybase also provides the “Keybase Book” website [Keya] with excellent documentation
that explains its cryptographic design. The only prior security analysis of Keybase was done by the
NCC Group in 2019 [RPF19], which broadly looked at the security of the entire Keybase ecosystem. In
comparison, we provide an in-depth analysis of a single component in Keybase.
Encrypted Group Chats. In this work we consider a setting in which an arbitrary number of users can
form a group. All group members share a key for a symmetric encryption scheme. Each instant message
within the group is encrypted with this key. Let us use g to denote the identity of a group and Kg to
denote the key shared between the members of this group. In Keybase, every member of group g uses the
same long-term key Kg to encrypt their outgoing chat messages. Each message is encrypted only once,
simultaneously for all recipients. The resulting ciphertext is then broadcast to all members of the group.
The Sender Keys protocol [BCG23,Mar14] can be seen as building on this basic design idea. In Sender
Keys, every member of the group owns a distinct symmetric encryption key; they share it with other group
members. Each outgoing message is encrypted with the sender’s own key, and the resulting ciphertext
is broadcast to the group. Furthermore, each key is used to encrypt only a single message, and immedi-
ately afterwards a new key is derived to be used for the next encryption. So every group member tracks
every other member’s current encryption key, decrypting each incoming ciphertext with the correspond-
ing sender’s key and subsequently replacing it with an appropriately derived new key. Variants of the
Sender Keys protocol are used in the Signal [Mar14], WhatsApp [Wha23], and Matrix [ACDJ22,ADJ23]
messengers. In addition, the Messaging Layer Security (MLS) [BBR+ 23] protocol contains a component
called FS-GAEAD [ACDT21] or TreeDEM [WPBB23] that similarly uses a sender’s key to encrypt and
broadcast a message (but its overall design significantly differs from design of the Sender Keys protocol).
An encrypted group chat protocol should provide at least confidentiality and integrity of communi-
cation, with respect to an attacker that is not a member of the group. In part, this could be achieved by
building the protocol from a symmetric encryption scheme that satisfies some notion of authenticated-
encryption security. But care is needed to also prevent undesired message replays, reordering, or drops.
These requirements are specific to a stateful protocol and do not necessarily follow from properties pro-
vided by the underlying stateless scheme.
Sender Authentication in Group Chats. Consider a group chat protocol that is built from a single
symmetric encryption scheme where every symmetric key is known to all group members. In such a
protocol, group members can impersonate each other. This is true regardless of whether each group uses
a single shared encryption key or has each member own a distinct encryption key. To prevent group
members from impersonating each other, it is natural to use a digital signature scheme. Let us use u to
denote the identity of a user and sku to denote this user’s signing key for a digital signature scheme.
What is a sound way to compose a symmetric encryption scheme with a digital signature scheme? Let
us consider two sequential compositions of a signing algorithm Sign with an encryption algorithm Encrypt.
We call the resulting schemes Sign-then-Encrypt and Encrypt-then-Sign, and we show them in Fig. 1. The
Sign-then-Encrypt scheme first signs a message m to obtain its digital signature s and then encrypts (s, m)

3
Fig. 1: Warmup schemes obtained by composing digital signatures with symmetric encryption. Left pane:
Sign-then-Encrypt. Right pane: Encrypt-then-Sign.

Fig. 2: A high-level representation of the SealPacket scheme in Keybase.

to obtain and return a symmetric ciphertext c. The Encrypt-then-Sign scheme first encrypts m as c and
then computes a signature s over c; it returns the pair (c, s).
These compositions closely mirror those that are commonly used to build signcryption [ADR02], which
is a standard cryptographic primitive that combines digital signatures with public-key encryption [Zhe97],
except we replace public-key encryption with symmetric encryption. It is well known that the correspond-
ing compositions for signcryption are not secure in the multi-user setting, unless some effort is taken to
bind together the message with the sender and recipient identities [ADR02]. The standard advice is to
always sign the recipient’s identity and always encrypt the sender’s identity. Our basic schemes in Fig. 1
would intuitively suffer from similar issues and benefit from similar countermeasures. However, the exact
details would depend on what kind of security one expects from these schemes, so we defer this discussion.
The Sender Keys protocol [BCG23] prescribes to sign a symmetric ciphertext; and this is indeed
done by the Signal, WhatsApp, and Matrix messengers. The MLS protocol [BBR+ 23] protocol prescribes
encrypting a digital signature with a symmetric encryption scheme. So either protocol can be seen as
using some variant of Encrypt-then-Sign or Sign-then-Encrypt as a subroutine. We will now discuss that
Keybase can be seen as extending both of these basic schemes.
SealPacket: Sign-then-Encrypt in Keybase. Keybase uses a variant of the basic Sign-then-Encrypt
scheme. It signs the symmetric encryption key along with the plaintext, meaning it signs (Kg , m) instead
of just m. The resulting scheme is called SealPacket and is shown in Fig. 2. In the source code, the decision
to sign Kg is explained as follows [Keye]:
simply using encryption and signing together isn’t good enough . . . the inner layer needs to assert
something about the outer layer . . . a better approach is to mix the outer key into the inner crypto,
so that it’s impossible to forget to check it . . . That means the inner signing layer needs to assert the
encryption key . . . We don’t need to worry about whether the signature might leak the encryption
key either, because the signature gets encrypted.
Keybase uses SealPacket to encrypt the following three types of plaintexts: (1) a metadata header that
is automatically created and sent along with every chat message, (2) a file that is sent as an attachment
in chat, and (3) an arbitrary string chosen by a chatbot (for secure server-side storage of bot data).
BoxMessage: Encrypt-then-Sign in Keybase. The BoxMessage scheme in Keybase is a variant of the
basic Encrypt-then-Sign scheme. This scheme, unlike SealPacket, is used only for one purpose: to encrypt
the body of a chat message. So we denote by cbody the symmetric ciphertext that is created in the inner
(encryption) layer of BoxMessage. The BoxMessage scheme extends the basic Encrypt-then-Sign scheme in
two ways and is shown in Fig. 3. First, it takes an associated-data field ad and signs (cbody , ad) instead
of just cbody . Second, rather than use a signature scheme, BoxMessage uses SealPacket to sign (cbody , ad).

4
 Fig. 3: A high-level representation of the BoxMessage scheme in Keybase.

Keybase uses the auxiliary-data field ad to authenticate a metadata header for the chat message. This
header contains the group’s identity and the sender’s identity among multiple other values. The data in
ad is sent in plain over the network (along with cbody ), meaning that SealPacket is not meant to provide
confidentiality of ad. Indeed, the Keybase documentation explains that SealPacket is used to provide the
confidentiality of the signature over (cbody , ad) [Keyb]:

The fields in the header aren’t secret from the server, and it actually needs to know several of them
. . . The reason for sign-then-encrypting/signencrypting the header is instead to keep the signature
itself private. Even though the server knows who’s talking to whom, because it’s delivering all the
messages, it’s better that it can’t prove what it knows.

Interestingly, BoxMessage reuses the group’s symmetric encryption key Kg between its calls to Encrypt
and SealPacket. As mentioned above, SealPacket will itself first sign Kg and then run another instance of
Encrypt with Kg as the key. In total, the same value of Kg is therefore used in 3 distinct contexts.
Symmetric Signcryption. We define symmetric signcryption as a new cryptographic primitive that
combines symmetric encryption with digital signatures. We capture the setting where every user owns a
signing key pair and in each group, all users share a single symmetric encryption key. The encryption key
is long-term, meaning it can be used an arbitrary number of times, simultaneously by all members of the
group. This will allow us to formalize and analyze the SealPacket and BoxMessage schemes.
Note that the use of sender-specific encryption keys in the Sender Keys [BCG23] and MLS [BBR+ 23]
protocols can also be captured by symmetric signcryption. Indeed, in either protocol, all symmetric
encryption keys can seen as being independently sampled, and each individual key is used only once. This
can be thought of as a collection of “one-time-use” symmetric signcryption schemes.
We adapt the standard syntax of (asymmetric) signcryption to suit our setting, defining algorithms
SigEnc and VerDec. They both take explicit sender and group identities, nonces, and associated data.
Security of Symmetric Signcryption. We define two security notions for symmetric signcryption.
The out-group authenticated encryption (OAE) security requires confidentiality and integrity of communi-
cation against an adversary that does not know the symmetric key of the group it attacks. This is required
to hold even against an adversary that can assign to every user an arbitrary (possibly malformed) digital
signature key pair. The in-group unforgeability (IUF) security requires the unforgeability of messages sent
by users whose signing keys are not known to the adversary. This is required to hold even against an
adversary that can assign to every group an arbitrary (possibly malformed) symmetric key.
We show how to extend the basic Sign-then-Encrypt scheme, by carefully incorporating user and group
identifiers, to achieve both of our security notions. We assume strong unforgeability of the underlying
digital signature scheme and authenticated-encryption security of the underlying encryption scheme.
Implementation of SealPacket and BoxMessage. In the source code of the Keybase client, SealPacket is
implemented in [Keyf] and BoxMessage is implemented in [Keyd]. These schemes are instantiated with the
nonce-based authenticated encryption scheme XSalsa20-Poly1305 [Ber05,Ber08] and the digital signature
scheme Ed25519 [BDL+ 11,BDL+ 12]. They also use SHA-512 and SHA-256 which does not significantly
affect the design of either scheme so we omit discussing it here, but in the main body of the paper, we
attempt to formalize both schemes precisely.
Keybase implements four versions of the BoxMessage scheme: V1, V2, V3, and V4. V1 is deprecated;
the Keybase client allows to receive but not send messages that use V1. V2 is the default version that

5
we formalize and analyze in this work. V3 is the same as V2, except it supports exploding messages; the
body of an exploding message is encrypted using an ephemeral key instead of Kg . V4 is the same as V3,
except it makes all group members use a dummy (zero) signing key and instead authenticate messages
using pairwise MACs.

Provable Security Analysis. We model both BoxMessage and SealPacket as symmetric signcryption
schemes and provide formal reductions for their IUF and OAE security. Our analysis is done in a concrete
security framework [BDJR97], and in a multi-key setting; we state precise bounds on the advantage of an
attacker. The analysis of BoxMessage largely encompasses that of SealPacket, because BoxMessage uses
SealPacket in a modular way. So we focus on the analysis of BoxMessage here. The main challenges arise
from using Kg in 3 distinct contexts.
First, we aim to show it is hard to switch the context of the XSalsa20-Poly1305 ciphertexts cbody and
cheader . Both are encrypted using the same key Kg , so there is a risk that an attacker could forge a valid
encryption of some body-plaintext m from a known encryption of some header-plaintext (s, cbody , ad), or
vice versa. To rule out such attacks, we rely on an observation that every application-layer message m that
is queried to be encrypted by BoxMessage is encoded in a specific way, whereas every header-plaintext
(s, cbody , ad) is expected to start with a valid Ed25519 signature. Based on the specification of Ed25519 we
show (in the ROM and GGM) that it is hard to cast the encoding used in m as a valid Ed25519 signature
(with respect to any verification key of adversary’s choice).
Second, we need to show that XSalsa20-Poly1305 provides authenticated encryption even for certain
messages derived from its secret key. This arises because in SealPacket the XSalsa20-Poly1305 key Kg is
first signed with Ed25519 and then the resulting signature is encrypted using XSalsa20-Poly1305 under
the same key. Here again we rely on the specification of Ed25519. An Ed25519 signature depends on two
SHA-512 hash values of the message that is being signed, but it does not depend on the signed message
beyond that. We use this (in the ROM) to eliminate the need to consider key-dependent messages and
hence only require XSalsa20-Poly1305 to provide the standard notion of authenticated encryption.
We do not know any way to avoid the above analysis. The necessity to use non-standard security
notions appears to be inherently implied by the design decisions made in Keybase. This could have been
avoided (e.g. with our Sign-then-Encrypt scheme). Overall, our reductions (in the ROM and GGM) rely
on the AEAD security of XSalsa20-Poly1305, collision resistance of SHA-256 and SHA-512, and strong
unforgeability of Ed25519. We note that Keybase uses the version of Ed25519 that was recently shown to
be SUF-CMA secure [BCJZ21,BDD23].

Limitations of Our Work. Our analysis of Keybase is intentionally narrow in scope. We perform an in-
depth, algorithmic analysis of specific chat components that can be modeled as symmetric signcryption.
Other analysis is outside the scope of our work, such as whether these algorithms are secure against
timing attacks and whether they provide protection against message replays, reordering, or drops when
used within the broader stateful chat protocol. More broadly, our analysis does not explicitly cover many
other applications of cryptography in Keybase, including other versions of BoxMessage, encryption of
attachments or bot data, the initial key exchange used to agree on group keys, the public-key directory
used to share user keys, and the cloud storage service. These applications are important for the overall
security of Keybase and have the potential to interplay with each other in subtle ways. For example, user
signing keys are used for multiple tasks in Keybase. We believe appropriate context separation is used
for these purposes (e.g. all messages signed in SealPacket start with “Keybase-Chat-2”). If not, subtle
cross-application attacks may be possible.

Related Work. The Hybrid Public-Key Encryption (HPKE) scheme is specified in RFC 9180 [BBLW22].
Alwen, Janneck, Kiltz, and Lipp [AJKL23] analyze the “pre-shared key” modes from RFC 9180. They
cast the HPKEAuthPSK mode as an asymmetric signcryption scheme that is augmented with a pre-shared
symmetric key, and they define the corresponding security notions. They analyze the security that is
achieved by HPKEAuthPSK depending on which combinations of keys are secure. Our definitions are sim-
ilar in the sense that both works define a signcryption-type primitive that in addition uses a symmetric
key. However, the algorithms in [AJKL23] use one more set of keys, and the definitions in [AJKL23] are

6
stated in the two-user setting. In essence, our primitives are similar in form but are tailored to be used
as tools in different settings.

2 Preliminaries

Basic Notation. Let N = {0, 1, 2, . . .}. We denote the empty string by ε. If x ∈ {0, 1}∗ is a bit-string then
|x| denotes its length, x[i] denotes its i-th bit for 1 ≤ i ≤ |x|, and x[i..j] = x[i] . . . x[j] for 1 ≤ i ≤ j ≤ |x|.
By x ∥ y we denote the concatenation of bit-strings x, y ∈ {0, 1}∗ . We write ⟨a, b, . . .⟩ to denote an injective
encoding of a, b, . . . into a bit-string that is uniquely decodable, where each of the encoded elements can
have an arbitrary data type. If X is a finite set, we let x ←$ X denote picking an element of X uniformly
at random and assigning it to x. If mem is a table, mem[i] denotes the element of the table that is indexed
by i. We let ⊥ ̸∈ {0, 1}∗ be an error code that indicates rejection. Explicitly uninitialized integers are
assumed to be initialized to 0, Booleans to false, strings to ⊥, and sets to the empty set. Uninitialized
elements of a table are initialized similarly, based on the type of data they will hold.
Algorithms and Adversaries. By y ←$ AO (x) we denote the randomized execution of algorithm A
on input x, with oracle access to O, producing output y. We generalize this to multiple inputs or oracles
in the natural way. If multiple oracles are provided, then A is allowed to call them arbitrarily many
times, in any order. If A is deterministic, we use ← instead. Running time is worst case. We let [A(x)]
denote the set of all possible outputs of A when invoked with input x. The instruction abort(x) is used
to immediately halt an algorithm with output x. Adversaries are algorithms. We require that adversaries
never pass ⊥ as input to their oracles.
Security Games and Reductions. We use the code-based game-playing framework of [BR06] for spec-
ifying security definitions and writing proofs. We write “require d” as shorthand for “If ¬d then return ⊥”.
Pr [G ] denotes the probability that game G returns true. Variables in each game are shared with its ora-
cles. In the security reductions, we omit specifying the running times of the constructed adversaries when
they are roughly the same as the running time of the initial adversary. In our security-reduction games,
we annotate some lines with comments of the form “// G[i,j) ” to indicate that a particular line belongs
only to games Gi , . . . ,Gj−1 ; we write j = ∞ when the line belongs to all games through the end of the
reduction. The lines not annotated with such comments are shared by all of the games that are shown
in the particular figure. To determine the difference between Gj−1 and Gj , look for subscripts [i, j) and
[j, k).
Fundamental Lemma of Game Playing. In our proofs, we frequently make use of the Fundamental
Lemma of Game Playing [BR06]. Suppose that games Gi and Gi+1 are syntactically identical except after
a Boolean flag bad is set. Then
Pr[Gi ] − Pr[Gi+1 ] ≤ Pr[badGi ] = Pr[badGi+1 ],
where Pr[badG ] denotes the probability of setting the flag bad in game G .

2.1 Standard Primitives

We will use several standard cryptographic primitives including hash functions, function families, nonce-
based encryption schemes, and digital signature schemes.
Hash Functions and Random Oracles. A hash function is a function H : {0, 1}∗ → {0, 1}H.ol for
some fixed output length H.ol ∈ N. The advantage of an adversary ACR in breaking the collision resistance
of H is defined as AdvCR
H (ACR ) = Pr [ H(x) = H(y) ∧ x ̸= y : (x, y) ←$ ACR ]. Our use of keyless hash
functions follows the human ignorance interpretation of Rogaway [Rog06]. Some of our analysis will be
performed in the random oracle model in which a function is chosen at random.
Nonce-Based Encryption. A nonce-based encryption scheme NE specifies deterministic algorithms
NE.Enc and NE.Dec. Associated to every instance of NE is a key length NE.kl ∈ N, a nonce length
NE.nl ∈ N, and an associated-data space NE.AD. The encryption algorithm NE.Enc takes a symmet-
ric key K ∈ {0, 1}NE.kl , a nonce n ∈ {0, 1}NE.nl , a plaintext m ∈ {0, 1}∗ , and associated data ad ∈

7
NE.AD to return a ciphertext c. The decryption algorithm NE.Dec takes K, n, c, ad to return a plain-
text m ∈ {0, 1}∗ ∪ {⊥}, where ⊥ indicates a failure to recover a plaintext. Decryption correctness re-
quires that for all K ∈ {0, 1}NE.kl , n ∈ {0, 1}NE.nl , m ∈ {0, 1}∗ , and ad ∈ NE.AD, the following holds:
NE.Dec(K, n, NE.Enc(K, n, m, ad), ad) = m. The tidiness property [NRS14] requires that NE.Enc(K, n,
NE.Dec(K, n, c, ad), ad) = c whenever NE.Dec(K, n, c, ad) ̸= ⊥. It implies that NE.Dec(K, n, c, ad) =
NE.Dec(K, n, c′ , ad) ̸= ⊥ is impossible for c ̸= c′ .
Associated Data in Nonce-Based Encryption. We define every nonce-based encryption scheme NE
with respect to an associated-data space NE.AD that contains either all bit-strings (i.e. NE.AD = {0, 1}∗ )
or a single element (i.e. NE.AD = {ε}). For the sake of simplicity, in the latter case, we omit the associated
data field ad from the syntax of all NE algorithms.
Digital Signatures. A digital signature scheme DS specifies algorithms DS.Kg, DS.Sig and DS.Ver,
where DS.Ver is deterministic. Associated to every instance of DS is a signing key length DS.skl ∈ N
and a signature length DS.sl ∈ N. The key generation algorithm DS.Kg returns a key pair (sk, vk) where
sk ∈ {0, 1}DS.skl is a signing key and vk is the corresponding verification key. The signing algorithm DS.Sig
takes sk and a message m ∈ {0, 1}∗ to return a signature s ∈ {0, 1}DS.sl . The deterministic verification
algorithm DS.Ver takes vk, m, s to return a decision d ∈ {true, false} regarding whether s is a valid
signature of m under vk. Correctness condition requires that for all (sk, vk) ∈ [DS.Kg], all m ∈ {0, 1}∗ ,
and all s ∈ [DS.Sig(sk, m)], the following holds: DS.Ver(vk, m, s) = true.

2.2 Standard Security Notions in a Multi-key Setting

Key Management Oracles. Throughout this work, we consider multi-key security notions. Adver-
saries in security games will be provided with three types of key management oracles. These oracles will
allow (1) sampling new honest (i.e. challenge) keys, (2) exposing existing honest keys, and (3) adding cor-
rupt keys of the adversary’s choice. When an honest key is exposed it becomes corrupt, but we nonetheless
know that it was initially sampled from a correct key distribution. In contrast, when an adversary adds
its own corrupt key, such a key could be maliciously crafted in an arbitrary way. In basic security no-
tions, an adversary cannot benefit from crafting corrupt keys, because no challenge queries are normally
permitted with respect to such keys. This changes for more complex systems built from more than one
keyed primitive when some security is required to hold even if some underlying secrets are exposed. The
ability to use malicious keys was modeled in prior work on (asymmetric) signcryption [BS20], and will
likewise be needed in this work.
Our security model for symmetric signcryption in Section 3 will define two sets of key management ora-
cles. The set of user oracles U = {NewHonUser, ExposeUser, NewCorrUser} will manage the keys
for a digital signature scheme, whereas the set of group oracles G = {NewHonGroup, ExposeGroup,
NewCorrGroup} will manage the keys for a nonce-based encryption scheme. We adopt the same
terminology and notation across all of the multi-key security notions; each notion for an asymmetric
primitive will define a set of user oracles U, and each notion for a symmetric primitive will define a set
of group oracles G. For consistency, we include oracles for adding corrupt keys even when an adversary
cannot benefit from using them. When simulating user oracles in a security reduction, we write SimU to
denote the set {SimNewHonUser, SimExposeUser, SimNewCorrUser} and do similarly for group
oracles.
Nonce-Based Authenticated Encryption. Consider game G AEAD of Fig. 4 for nonce-based encryp-
tion scheme NE and adversary AAEAD . The advantage of adversary AAEAD in breaking the AEAD security
of NE is defined as AdvAEAD
NE
AEAD
(AAEAD ) = 2 · Pr[GNE (AAEAD )] − 1. The game samples a challenge bit b, and
AAEAD is required to guess it. Adversary AAEAD is given the group oracles G, encryption oracle Enc, and
decryption oracle Dec. Among the group oracles, NewHonGroup creates new groups with honestly
generated NE keys, ExposeGroup reveals the keys of existing groups, and NewCorrGroup instan-
tiates new corrupt groups with NE keys of AAEAD ’s choice. The encryption oracle Enc takes a group
identifier g, a nonce n, two challenge messages m0 , m1 , and associated data ad; it returns the encryption
of mb under the provided parameters. We require NE to be nonce-misuse resistant [RS06], meaning that

8
no challenge message m is allowed to be queried across two distinct calls to Enc with respect to the same
set of g, n, ad. To prevent trivial wins, a corrupt group key can only be used to call Enc with m0 = m1
and a group key cannot be exposed after it has been used in Enc with m0 ̸= m1 . The decryption oracle
Dec takes g, n, c, ad as input and decrypts this to the corresponding plaintext m. Following the all-in-one
style of [Shr04,RS06], it returns ⊥ if b = 0, and it returns m otherwise. To prevent trivial wins, this oracle
never decrypts a ciphertext with an exposed group’s key, and it never decrypts ciphertexts previously
produced by Enc (with the same g, c, ad).

AEAD KR
Game GNE (AAEAD ) Game GNE (AKR )
b ←$ {0, 1} ; b′ ←$ AG,Enc,Dec
AEAD ; Return b = b′ G,Enc,Dec,Guess
AKR ; Return win
Enc(g, n, m0 , m1 , ad) Enc(g, n, m, ad)
require K[g] ̸= ⊥ and |m0 | = |m1 | require K[g] ̸= ⊥
require ∀d ∈ {0, 1}, (g, n, md , ad) ̸∈ Nd require (g, n, m, ad) ̸∈ N
If m0 ̸= m1 then c ← NE.Enc(K[g], n, m, ad)
If group is corrupt[g] then return ⊥ N ← N ∪ {(g, n, m, ad)} ; Return c
chal[g] ← true Dec(g, n, c, ad)
c ← NE.Enc(K[g], n, mb , ad)
N0 ← N0 ∪ {(g, n, m0 , ad)} require K[g] ̸= ⊥
N1 ← N1 ∪ {(g, n, m1 , ad)} m ← NE.Dec(K[g], n, c, ad)
C ← C ∪ {(g, n, c, ad)} ; Return c Return m

Dec(g, n, c, ad) Guess(K)

require K[g] ̸= ⊥ and ¬group is corrupt[g] If ∃g : (K[g] = K and

require (g, n, c, ad) ̸∈ C ¬group is corrupt[g]) then
m ← NE.Dec(K[g], n, c, ad) win ← true
If b = 0 then return ⊥ else return m

NewHonGroup(g) ExposeGroup(g) NewCorrGroup(g, K)

require K[g] = ⊥ require K[g] ̸= ⊥ and ¬chal[g] require K[g] = ⊥
K[g] ←$ {0, 1}NE.kl group is corrupt[g] ← true group is corrupt[g] ← true
Return K[g] K[g] ← K

Fig. 4: Left pane: Game defining authenticated-encryption security of a nonce-based encryption scheme
NE. Right pane: Game defining key-recovery security of NE. Bottom pane: Group oracles G =
{NewHonGroup, ExposeGroup, NewCorrGroup} that are provided to an adversary in either game,
except that the boxed code only appears in the AEAD security game.

Key-Recovery Security of NE. Consider game G KR of Fig. 4 for nonce-based encryption scheme NE
and adversary AKR . The advantage of AKR in breaking the KR security of NE is defined as AdvKRNE (AKR ) =
KR
Pr[GNE (AKR )]. Adversary AKR is given group oracles G, encryption oracle Enc, decryption oracle Dec,
and key-guessing oracle Guess. The group oracles G match those from G AEAD . The encryption oracle Enc
takes a group identifier g, a nonce n, a message m, and associated data ad, and returns the encryption
of m under the provided parameters. For consistency with other games, we disallow querying a message
m across two distinct calls to Enc with repeated g, n, and ad values. The decryption oracle Dec takes
g, n, c, ad as input and returns the decryption m of c under the corresponding parameters. The Guess
oracle takes key K as input and sets the win flag if K is an honest group key. Note that KR security
of NE is implied by its AEAD security. Meaning that for any adversary AKR against the KR security of
NE, one can build an adversary AAEAD against the AEAD security of NE such that AAEAD wins whenever
AKR does. Intuitively, if AKR successfully guesses an honest key then AAEAD can use that key to decrypt
challenge ciphertexts previously returned by its Enc oracle. The decryption correctness of NE guarantees
that AAEAD would be able to deduce the challenge bit.

9
 SUFCMA
Game GDS (ASUFCMA ) Sign(u, m)
(u, m, s) ←$ AU,Sign
SUFCMA ; If vk[u] = ⊥ then return false
require sk[u] ̸= ⊥
win1 ← ¬user is corrupt[u] ; win2 ← ((u, m, s) ̸∈ S) s ←$ DS.Sig(sk[u], m)
win3 ← DS.Ver(vk[u], m, s) S ← S ∪ {(u, m, s)}
Return win1 and win2 and win3 Return s

NewHonUser(u) ExposeUser(u) NewCorrUser(u, sk, vk)

require sk[u] = vk[u] = ⊥ require sk[u] ̸= ⊥ require sk[u] = vk[u] = ⊥
(sk[u], vk[u]) ←$ DS.Kg user is corrupt[u] ← true user is corrupt[u] ← true
Return vk[u] Return sk[u] sk[u] ← sk ; vk[u] ← vk

Fig. 5: Game defining strong unforgeability of a digital signature scheme DS, where U = {NewHonUser,
ExposeUser, NewCorrUser}.

Strong Unforgeability of Digital Signatures. Consider game G SUFCMA of Fig. 5 for digital signa-
ture scheme DS and adversary ASUFCMA . The advantage of ASUFCMA in breaking the SUFCMA security of
DS is defined as AdvSUFCMA
DS (ASUFCMA ) = Pr[GDSSUFCMA
(ASUFCMA )]. Adversary ASUFCMA is given access to
user oracles U, where oracle NewHonUser creates new users with an honestly generated DS key pairs,
oracle ExposeUser reveals signing keys of existing users, and oracle NewCorrUser instantiates new
corrupt users with DS key pairs of ASUFCMA ’s choice. Adversary ASUFCMA is also given signing oracle Sign
that on input (u, m) signs message m with the signing key of user u. The game requires ASUFCMA to forge
a signature s for any user-message pair (u, m) with honest user u such that s was not previously returned
in response to a Sign(u, m) query.

3 Symmetric Signcryption

In this section, we define syntax and security for multi-user symmetric signcryption. In symmetric sign-
cryption, a user encrypts messages using their signing key and a symmetric key shared by a group of
users. We want that nobody outside a group can learn what messages are being encrypted, and nobody
at all can forge a message as having come from someone other than themself.

(sk, vk) ←$ SS.UserKg

c ←$ SS.SigEnc(g, Kg , u, sku , n, m, ad)
m ← SS.VerDec(g, Kg , u, vku , n, c, ad)

Fig. 6: Syntax of a symmetric signcryption scheme SS.

Syntax. A symmetric signcryption scheme SS specifies algorithms SS.UserKg, SS.SigEnc, SS.VerDec,

where SS.VerDec is deterministic. The syntax used for the algorithms of SS is given in Fig. 6. Associ-
ated to SS is a group-key length SS.gkl ∈ N, a nonce space SS.NS, a plaintext space SS.MS ⊆ {0, 1}∗ ,
and an associated-data space SS.AD. The user’s key generation algorithm SS.UserKg returns a key pair
(sk, vk) where sk is a signing key and vk is the corresponding verification key. The signcryption algo-
rithm SS.SigEnc takes a group’s identifier g ∈ {0, 1}∗ and its symmetric key Kg ∈ {0, 1}SS.gkl , a sender’s
identifier u ∈ {0, 1}∗ and its signing key sku , a nonce n ∈ SS.NS, a plaintext m ∈ SS.MS, and associated
data ad ∈ SS.AD; it returns a signcryption ciphertext c. The deterministic unsigncryption algorithm
SS.VerDec takes g, Kg , u, vku , n, c, ad, where vku is the verification key of the sender u; it returns a plain-
text m ∈ {0, 1}∗ ∪ {⊥}, where ⊥ indicates a failure to recover a plaintext. We say that SS is deterministic
SS.SigEnc is deterministic.

10
Correctness. The decryption correctness of a symmetric signcryption scheme SS requires that for all
g ∈ {0, 1}∗ , all Kg ∈ {0, 1}SS.gkl , all u ∈ {0, 1}∗ , all (sku , vku ) ∈ [SS.UserKg], all n ∈ SS.NS, all m ∈ SS.MS,
all ad ∈ SS.AD, and all c ∈ [SS.SigEnc(g, Kg , u, sku , n, m, ad)] the following holds: SS.VerDec(g, Kg , u, vku ,
n, c, ad) = m

3.1 In-Group Unforgeability

The strongest variant of in-group unforgeability requires that an attacker cannot modify anything about
ciphertexts. We also capture weaker variants. For example, the SealPacket encryption algorithm in Key-
base (as defined in Section 5) uses a signing key to bind its ciphertexts to a group’s symmetric key but
not to a group’s identifier. So we parameterize our security definition to capture the type of authenticity
that is as restrictive as possible except for allowing (what can be described as) cross-group forgeries.
IUF Game: The Basics. Consider game G IUF of Fig. 7, defined for symmetric signcryption scheme SS,
ciphertext-triviality predicate predauth
trivial , and adversary AIUF . The advantage of AIUF in breaking the IUF
security of SS is defined as AdvIUF
SS,predauth
IUF
(AIUF ) = Pr[GSS,pred auth (AIUF )]. Adversary AIUF is given access to
trivial trivial
user oracles U, group oracles G, encryption oracle SigEnc, and decryption oracle VerDec. Its goal is
to set the win flag by forging a ciphertext for an honest user.
IUF Game: User and Group Oracles. Among user oracles, NewHonUser creates honest users with
honestly generated signing keys, NewCorrUser creates corrupt users with malicious signing keys, and
ExposeUser exposes the signing keys of existing users. Among group oracles, NewHonGroup cre-
ates honest groups with honestly sampled symmetric keys, NewCorrGroup creates corrupt groups
with malicious symmetric keys, and ExposeGroup exposes symmetric keys of existing groups. Oracles
NewHonGroup and NewCorrGroup take as input a set users identifying the new group’s users; the
encryption and decryption oracles then disallow queries that match a group to a non-member user. The
user and group oracles use tables user is corrupt and group is corrupt to keep track of the users and groups
whose keys are not secure, respectively. The IUF game never checks group is corrupt, deliberately giving
the adversary full control over group keys.
IUF Game: The SigEnc Oracle. The encryption oracle SigEnc takes (g, u, n, m, ad) and returns a
ciphertext c that is produced by running SS.SigEnc(g, K[g], u, sk[u], n, m, ad). Here note that the group
and user keys K[g] and sk[u] are the only two inputs to SS.SigEnc that are not directly chosen by the
adversary at the moment of querying the SigEnc oracle. At the end of each SigEnc query, the set C
is updated to add the tuple ((g, u, n, m, ad), c) that can be interpreted as containing the input-output
transcript of this query.
IUF Game: The VerDec Oracle. The decryption oracle VerDec takes (g, u, n, c, ad) and returns the
message m that is recovered by running SS.VerDec(g, K[g], u, vk[u], n, c, ad). Keys K[g], sk[g] are the only
inputs to SS.VerDec not directly chosen by the adversary. If m ̸= ⊥, then the oracle determines if the
current oracle query is a valid forgery and sets the win flag if so. In particular, VerDec builds the
tuple z = ((g, u, n, m, ad), c) with all input and output values of the current decryption query. It checks
z against the set C that contains the input-output behavior of all the prior encryption queries. If z is
determined to be trivially obtainable from the information in C, then VerDec exits early (with m as its
output value); otherwise, it sets the win flag. This check is performed by the ciphertext-triviality predicate
predauth auth
trivial . We will describe the syntax and the sample variants of predtrivial below.

Ciphertext-Triviality Predicates. The IUF game is parameterized by ciphertext-triviality predicate

predauth auth auth
trivial (we will also parameterize the OAE game with predtrivial ). Predicate predtrivial takes a tuple z =
((g, u, n, m, ad), c) and a set C as input, where C contains tuples of the same format. Here z describes
the input-output values of the current query to VerDec oracle and each element of C contains an input-
output transcript of a prior SigEnc oracle query. Predicate predauth trivial returns true if z is considered to be
trivially forgeable based on the information in C and false otherwise.
In Fig. 8 we define several ciphertext-triviality predicates. Predicate predsuf trivial checks if z ∈ C, captur-
ing the strongest possible level of authenticity. This requires that only prior outputs of SigEnc can be
successfully queried to the VerDec oracle; any other successful decryption query causes the adversary to

11
 IUF OAE
Game GSS,predauth (AIUF ) Game GSS,predsec ,funcsec (AOAE )
trivial trivial out
′
AU,G,SigEnc,VerDec
IUF
b ←$ {0, 1} ; b ←$ AU,G,SigEnc,VerDec
OAE
Return win Return b = b′
SigEnc(g, u, n, m, ad) SigEnc(g, u, n, m0 , m1 , ad)
require K[g] ̸= ⊥ require K[g] ̸= ⊥ and |m0 | = |m1 |
require sk[u] ̸= ⊥ and u ∈ members[g] require sk[u] ̸= ⊥ and u ∈ members[g]
c ←$ SS.SigEnc(g, K[g], u, sk[u], n, m, ad)require ∀d ∈ {0, 1}, (g, u, n, md , ad) ̸∈ Nd
C ← C ∪ {((g, u, n, m, ad), c)} If m0 ̸= m1 then
Return c If group is corrupt[g] then return ⊥
chal[g] ← true
VerDec(g, u, n, c, ad)
c ←$ SS.SigEnc(g, K[g], u, sk[u], n, mb , ad)
require K[g] ̸= ⊥ N0 ← N0 ∪ {(g, u, n, m0 , ad)}
require vk[u] ̸= ⊥ and u ∈ members[g] N1 ← N1 ∪ {(g, u, n, m1 , ad)}
m ← SS.VerDec(g, K[g], u, vk[u], n, c, ad) C ← C ∪ {((g, u, n, mb , ad), c)}
If m = ⊥ then return ⊥ Q ← Q ∪ {((g, u, n, m0 , m1 , ad), c)}
z ← ((g, u, n, m, ad), c) Return c
If predauth
trivial (z, C) then return m
If ¬user is corrupt[u] then win ← true VerDec(g, u, n, c, ad)
Return m require K[g] ̸= ⊥ and ¬group is corrupt[g]
require vk[u] ̸= ⊥ and u ∈ members[g]
m ← SS.VerDec(g, K[g], u, vk[u], n, c, ad)
If m = ⊥ then return ⊥
z ← ((g, u, n, m, ad), c)
If predsec sec
trivial (z, C) then return funcout (z, Q)
If b = 0 then return ⊥ else return m

NewHonUser(u) NewHonGroup(g, users)

require sk[u] = vk[u] = ⊥ require K[g] = ⊥
(sk[u], vk[u]) ←$ SS.UserKg K[g] ←$ {0, 1}SS.gkl
Return vk[u] members[g] ← users
ExposeUser(u) ExposeGroup(g)
require sk[u] ̸= ⊥ require K[g] ̸= ⊥ and ¬chal[g]
user is corrupt[u] ← true group is corrupt[g] ← true
Return sk[u] Return K[g]
NewCorrUser(u, sk, vk) NewCorrGroup(g, K, users)
require sk[u] = vk[u] = ⊥ require K[g] = ⊥
user is corrupt[u] ← true group is corrupt[g] ← true
sk[u] ← sk ; vk[u] ← vk K[g] ← K ; members[g] ← users

Fig. 7: Left pane: Game defining in-group unforgeability IUF of a symmetric signcryption scheme
SS with respect to a ciphertext-triviality predicate predauth
trivial . Right pane: Game defining out-group
authenticated-encryption security OAE of SS with respect to a ciphertext-triviality predicate predsec
trivial and
an output-guarding function funcsec
out . Bottom pane: User oracles U = {NewHonUser, ExposeUser,
NewCorrUser} and group oracles G = {NewHonGroup, ExposeGroup, NewCorrGroup} that
are provided to an adversary in either game, except that the boxed code only appears in the OAE secu-
rity game.

12
 suf-except-group
predsuf
trivial (z, C) predtrivial (z, C)
Return z ∈ C ((g, u, n, m, ad), c) ← z
predeuf Return ∃g ′ : ((g ′ , u, n, m, ad), c) ∈ C
trivial (z, C)
((g, u, n, m, ad), c) ← z predsuf-except-user
trivial (z, C)
Return ∃c′ : ((g, u, n, m, ad), c′ ) ∈ C ((g, u, n, m, ad), c) ← z
Return ∃u′ : ((g, u′ , n, m, ad), c) ∈ C

Fig. 8: Sample ciphertext-triviality predicates which capture rules for deciding if a successfully decrypted
VerDec query was trivially obtainable or forgeable.

win the IUF game. This predicate can be thought of as making the IUF game capture the “strong” unforge-
ability of ciphertexts in our group setting. One could capture existential unforgeability by considering
the predicate predeuf trivial that does not allow the adversary to win by merely producing new ciphertexts
that decrypt to some tuple (g, u, n, m, ad) previously queried to SigEnc. Predicates predsuf-except-group
trivial and
suf-except-user
predtrivial capture the authenticity of schemes where a ciphertext encrypting (g, u, n, m, ad) is not
suf-except-group
bound to the group’s identifier or the user’s identifier, respectively. We use predsuf trivial , predtrivial ,
and predsuf-except-user
trivial in our security analysis of Keybase. In this work, we do not use pred suf-except-user
trivial with
the IUF game – we need it for OAE.

3.2 Out-Group Authenticated Encryption

The strongest version of the out-group AE security requires that an attacker outside a chat group can
neither learn any information about the exchanged messages nor modify the exchanged ciphertexts in
any way. We also capture weaker variants of this security notion. For example, the SealPacket encryption
algorithm (as defined in Section 5) does not use a group’s symmetric key to explicitly bind its ciphertexts
to a user’s signing key or a user’s identifier when used in isolation. So we capture a variant of out-
group AE security that is as restrictive as possible except for allowing an attacker to violate the sender’s
authenticity within any particular group.
OAE Game: The Basics. Consider game G OAE of Fig. 7 for symmetric signcryption scheme SS, ciphertext-
triviality predicate predauth sec
trivial , output-guarding function funcout , and adversary AOAE . The advantage in
OAE OAE
breaking the OAE security of SS is defined as AdvSS,predauth ,funcsec (AOAE ) = Pr[GSS,predauth ,funcsec (AOAE )]. Ad-
trivial out trivial out
versary AOAE is given access to user and group oracles U and G and to the encryption and decryption
oracles SigEnc and VerDec. The goal of the adversary is to guess the challenge bit b. Our security
game is defined in the all-in-one style of [Shr04,Rog04], where an adversary can learn the challenge bit
by forging a ciphertext to its decryption oracle.
OAE Game: User and Group Oracles. The user and group oracles in the OAE game are defined as
in the IUF game, except it does not allow calling the ExposeGroup oracle to expose the key of a group
that was previously used for a left-or-right challenge-encryption query (as explained below). The OAE
game never checks the contents of user is corrupt, deliberately giving the adversary full control over user
keys.
OAE Game: The SigEnc Oracle. The encryption oracle SigEnc takes (g, u, n, m0 , m1 , ad) and re-
turns a ciphertext c by running SS.SigEnc(g, K[g], u, sk[u], n, mb , ad). The group and user keys K[g] and
sk[u] are the only inputs to SS.SigEnc not directly chosen by the adversary querying the SigEnc or-
acle (and the encrypted message mb depends on the challenge bit). The SigEnc query requires that
|m0 | = |m1 | and will only use insecure group keys for non-challenge encryptions (i.e. for m0 = m1 ). This
SigEnc oracle captures nonce-misuse resistance [RS06], using the sets Nd to prevent trivial wins. At the
end of SigEnc queries, the set C is updated to add the tuple ((g, u, n, mb , ad), c), and the set Q is up-
dated to add the tuple ((g, u, n, m0 , m1 , ad), c). Here the Q set can contain the input-output “transcript”
of SigEnc queries from the adversary’s point of view, whereas the set C is more informative because it
contains the message that was actually encrypted. We will explain the purpose of these sets below.

13
OAE Game: The VerDec Oracle. The decryption oracle VerDec takes (g, u, n, c, ad) and returns the
message m output by SS.VerDec(g, K[g], u, vk[u], n, c, ad). Keys K[g], sk[g] are the only inputs to SS.VerDec
not directly chosen by the adversary querying the VerDec oracle. The VerDec oracle disallows queries
with corrupt group keys; if an adversary knows a group’s key then it can decrypt ciphertexts for the group
on its own. If SS.VerDec recovers a non-⊥ message m and the end of the VerDec oracle is reached, then
the challenge bit is meant to be revealed through returning m if b = 1 and ⊥ otherwise. However, this
intuition is not precise; it depends on how VerDec responds to queries that are identified as being
trivially forgeable. Similarly to how trivial forgeries were handled in the IUF game, here VerDec builds
z = ((g, u, n, m, ad), c) and uses a ciphertext-triviality predicate predsec
trivial to check z against the set C from
SigEnc. If z is considered not trivially obtainable from the information in C, then VerDec proceeds
to its last instruction that returns ⊥ or m depending on the challenge bit. Otherwise, VerDec should
return an output that does not depend on the challenge bit to prevent trivial wins. Such an output is
produced by the output-guarding function funcsec sec
out , i.e. VerDec returns the output of funcout (z, Q). We
sec
now describe the syntax and variants of funcout .
Output-Guarding Functions. The OAE game can be parameterized by different choices of an output-
guarding function funcsec sec
out . We define funcout to take a tuple z = ((g, u, n, m, ad), c) and a set Q as input,
where Q contains tuples with the format ((g, u, n, m0 , m1 , ad), c). Here z describes the input-output values
of a single query to the VerDec oracle, and each element of C specifies the input-output of a prior SigEnc
oracle query. At a high level, z contains the message m that was recovered during an ongoing VerDec
call, and m is the only value in z, Q not necessarily known by the adversary. One might want to define
VerDec to return m whenever the input is identified as a trivial forgery, but m could potentially trivially
reveal the challenge bit. So one could roughly think of funcsecout as the function that should enable VerDec
to return m when possible. However, it should determine – from z and Q – if m would trivially help the
adversary win and then “guard” VerDec against returning this m.

silence-with-m1
func⊥
out (z, Q) funcout [predtrivial ](z, Q)
Return ⊥ For each ((g, u, n, m0 , m1 , ad), c) ∈ Q do
If m0 ̸= m1 then
If predtrivial (z, {((g, u, n, m0 , ad), c)}) then return m1
If predtrivial (z, {((g, u, n, m1 , ad), c)}) then return m1
((g, u, n, m, ad), c) ← z ; Return m

Fig. 9: Sample output-guarding functions func⊥ silence-with-m1

out and funcout . Function funcsilence-with-m
out
1
is param-
eterized by a ciphertext-triviality predicate predtrivial .

In Fig. 9 we define two output-guarding functions. The function func⊥ out always returns ⊥. This provides
no useful information to the adversary and so captures a comparatively weaker security notion. The
silence-with-m1
function funcout [predtrivial ] is parameterized by an arbitrary ciphertext-triviality predicate predtrivial
and captures the following logic. For every element in Q that describes a challenge encryption (i.e. m0 ̸=
m1 ) performed by SigEnc, this function checks whether z is trivially forgeable based on the information
that the adversary could have learned from the corresponding response. This is checked if z would be
trivially forgeable for both choices of b ∈ {0, 1} or only for only one choice of b. The output-guarding
function returns m1 when this condition passes. If no element of Q triggered the above, then the output-
guarding function returns the m contained in z, i.e. the actual message recovered in VerDec.
silence-with-m1
The Use of funcout in Our Work. We target funcsilence-with-m
out
1
[predtrivial ] as the output-guarding
function that provides the strongest possible security guarantees for the schemes that we analyze in this
work. For every predtrivial we use, predtrivial (z, {((g, u, n, m∗ , ad), c)}) can only be true when z contains m∗ .
So for elements of Q with m0 ̸= m1 , only one of the two if conditions can pass, meaning it is necessary to
silence the output. Otherwise, the adversary can trivially win the game by building z, Q and evaluating
predtrivial to distinguish between b = 0 or b = 1. (This attack assumes the adversary can always compute

14
 StE.UserKg StE.VerDec(g, Kg , u, vku , n, c, ad)
(sk, vk) ←$ DS.Kg ; Return (sk, vk) adNE ← ⟨u, ad⟩
StE.SigEnc(g, Kg , u, sku , n, m, ad) me ← NE.Dec(Kg , n, c, adNE )
If me = ⊥ then return ⊥
ms ← ⟨g, n, m, ad⟩
s ∥ m ← me // s.t. |s| = DS.sl, |m| ≥ 0
s ←$ DS.Sig(sku , ms )
ms ← ⟨g, n, m, ad⟩
me ← s ∥ m ; adNE ← ⟨u, ad⟩
If ¬DS.Ver(vku , ms , s) then return ⊥
c ← NE.Enc(Kg , n, me , adNE ) ; Return c
Return m

Fig. 10: Signcryption scheme StE = SIGN-THEN-ENCRYPT-SS[DS, NE].

predtrivial (z, C) for SS, despite not knowing the challenge bit b that is needed to explicitly build C. This
is true in all of our proofs.)
The Necessity of C. It would not suffice to use Q instead of C for identifying trivial forgeries. Consider
an SS that produces malleable ciphertexts which we want to analyze with respect to the existential
unforgeability predicate predeuf
trivial . Let Q contain an entry that maps one of m0 , m1 to c. Then upon
VerDec decrypting some c′ ̸= c into m0 , the set Q does not allow to distinguish between the following
two cases: (1) if c is an encryption of m0 then c′ could have been trivially obtained by mauling c; (2) if c
is an encryption of m1 then c′ might represent an actual forgery that was not obtained in a trivial way.

4 Symmetric Signcryption from Encryption and Signatures

In this section, we build symmetric signcryption schemes by sequentially composing a digital signature
scheme with a nonce-based encryption scheme. We prove that one of constructions achieves strong
variants of the security notions that we defined in Section 3. In particular, we compose an SUFCMA-
secure digital signature scheme with an AEAD-secure nonce-based encryption scheme using the Sign-
then-Encrypt (StE) and Encrypt-then-Sign (EtS) compositions. The StE-based symmetric signcryption
scheme achieves IUF security with ciphertext-triviality predicate predsuf trivial and achieves OAE security with
predsuf silence-with-m1
trivial and output-guarding function funcout [predsuf
trivial ]. The straightforward proofs for these
results are in Appendix A. Note that the same result can also be proved for the IUF security of the
EtS-based scheme. However, proving the same about the OAE security of the EtS-based scheme would
come at the cost of introducing the non-standard assumption that the underlying digital signature scheme
provides unique signatures. We explain the need for this assumption below.

4.1 Sign-then-Encrypt Based Construction

Our StE-based symmetric signcryption scheme StE is shown in Fig. 10. Of it, we prove the following
results.

Construction 1. Let DS be a digital signature scheme. Let NE be a nonce-based encryption scheme with
associated-data space NE.AD = {0, 1}∗ . Then StE = SIGN-THEN-ENCRYPT-SS[DS, NE] is the symmetric
signcryption scheme as defined in Fig. 10, with group-key length StE.gkl = NE.kl, nonce space StE.NS =
{0, 1}NE.nl , message space StE.MS = {0, 1}∗ , and associated-data space StE.AD = {0, 1}∗ .

Theorem 1. Let StE = SIGN-THEN-ENCRYPT-SS[DS, NE] be the symmetric signcryption scheme built
from some DS, NE as specified in Construction 1. Let predsuf trivial be the ciphertext-triviality predicate as
defined in Fig. 8. Let AIUF be any adversary against the IUF security of StE with respect to predsuftrivial . Then
we can build an adversary ASUFCMA against the SUFCMA security of DS such that
AdvIUF SUFCMA
StE,predsuf (AIUF ) ≤ AdvDS (ASUFCMA ).
trivial

15
Let func⊥
out be the output-guarding function as defined in Fig. 9. Let AOAE be any adversary against the
⊥
OAE security of StE with respect to predsuf
trivial and funcout . Then we can build adversary AAEAD against the
AEAD security of NE such that
AdvOAE
StE,predsuf ⊥ (AOAE ) ≤ AdvAEAD
NE (AAEAD ).
trivial ,funcout

4.2 Encrypt-then-Sign Based Construction

We now present the formal definition of our EtS construction. We omit proving the security of this
construction. The IUF security proof for EtS would follow similar steps as the one for StE. The OAE
security proof would require us to introduce an additional assumption about the signature scheme.

EtS.UserKg EtS.VerDec(g, Kg , u, vku , n, c, ad)

(sk, vk) ←$ DS.Kg ; Return (sk, vk) (cNE , s) ← c
EtS.SigEnc(g, Kg , u, sku , n, m, ad) ms ← ⟨g, n, cNE , ad⟩
If ¬DS.Ver(vku , ms , s) then return ⊥
adNE ← ⟨u, ad⟩
adNE ← ⟨u, ad⟩
cNE ← NE.Enc(Kg , n, m, adNE )
m ← NE.Dec(Kg , n, cNE , adNE )
ms ← ⟨g, n, cNE , ad⟩
Return m
s ←$ DS.Sig(sku , ms ) ; Return (cNE , s)

Fig. 11: Symmetric signcryption scheme EtS = ENCRYPT-THEN-SIGN-SS[NE, DS].

Construction 2. Let NE be a nonce-based encryption scheme with associated-data space NE.AD =

{0, 1}∗ . Let DS be a digital signature scheme. Then EtS = ENCRYPT-THEN-SIGN-SS[NE, DS] is the
symmetric signcryption scheme as defined in Fig. 11, with group-key length EtS.gkl = NE.kl, nonce space
EtS.NS = {0, 1}NE.nl , message space EtS.MS = {0, 1}∗ , and associated-data space EtS.AD = {0, 1}∗ .

OAE Security of EtS Requires Unique Signatures. At the beginning of this section, we claimed
that proving the OAE security of EtS with respect to predsuf silence-with-m1
trivial and funcout [predsuf
trivial ] would require
the assumption that the signature scheme produces unique signatures. Here we provide the intuition
for why this assumption is needed. Consider a digital signature scheme that does not produce unique
signatures. Then the adversary could expose an honest user in the OAE security game (or create a corrupt
user with the same signing key as that of another honest user), and use their signing key to produce a new
signature over an existing, honestly generated ciphertext cNE (i.e. one that was produced as a result of a
prior SigEnc query). It could then query the ciphertext cNE along with the new signature to the VerDec
oracle to trivially win the game. This attack can only be mitigated if DS produces unique signatures. As
digital signature schemes standardized in NIST’s FIPS 186-5 standard [CMRR23] (including the RSA
DSA, ECDSA, and EDDSA) do not guarantee unique signatures, we do not analyze the OAE security of
the EtS construction in this work.

5 Modeling Keybase Chat Encryption as Symmetric Signcryption

We analyze the security of the cryptographic algorithm BoxMessage that Keybase uses to encrypt and
authenticate chat messages from a sender to a group. BoxMessage combines multiple cryptographic primi-
tives to offer end-to-end encrypted messaging. In particular it uses XSalsa20-Poly1305, SHA-256, SHA-512,
and Ed25519 as building blocks. Within BoxMessage, the SealPacket subroutine encrypts and authenti-
cates message headers. We show the pseudocode for these algorithms in Fig. 12 and visual depictions of
their data flows in Fig. 13. We omit the decryption algorithms BoxMessage.VerDec and SealPacket.VerDec
from Fig. 12 as Keybase’s implementation of these algorithms follows naturally from the corresponding

16
 BoxMessage.SigEnc(g, Kg , u, sku , n, mbody , ad) // where n = (nbody , nheader )
cbody ← XSalsa20-Poly1305.Enc(Kg , nbody , mbody )
hbody ← SHA-256(nbody ∥ cbody )
mheader ← ⟨ad, u, g, hbody ⟩
cheader ← SealPacket.SigEnc(g, Kg , u, sku , nheader , mheader , ε)
Return (cbody , cheader )
SealPacket.SigEnc(g, Kg , u, sku , n, m, ad) // where ad = ε
h ← SHA-512(m) ; ms ← “Keybase-Chat-2” ∥ ⟨Kg , n, h⟩
s ← Ed25519.Sig(sku , ms ) ; me ← s ∥ m
c ← XSalsa20-Poly1305.Enc(Kg , n, me )
Return c

Fig. 12: The BoxMessage and SealPacket algorithms used in Keybase for encrypting chat messages from
a user to a group. Here g is the group’s identifier, Kg is the symmetric key shared by all group members,
u is the sender’s identifier, and sku is the sender’s signing key.

Fig. 13: The BoxMessage/BM (Left) and SealPacket/SP (Right) algorithms used to encrypt chat messages
and message headers in Keybase. We omit the inputs g, u, and ad from SP as it does not use g or u and
ad = ε always holds.

SigEnc algorithms. We define the VerDec algorithms explicitly in our formalization of BoxMessage and
SealPacket.
To formalize the security of BoxMessage, it is crucial to first identify the formal primitive underlying
this algorithm and the security goals it aims to achieve. None of the existing primitives in literature seem
to aptly model this object, but it is naturally captured by the symmetric signcryption primitive that we
defined in Section 3. Similarly, SealPacket can also be modeled as a symmetric signcryption scheme from
which BoxMessage is built. In this section, we present modular constructions that cast BoxMessage and
SealPacket as symmetric signcryption schemes. We first provide a general overview of the two algorithms.
The BoxMessage Chat-Encryption Algorithm. The BoxMessage.SigEnc algorithm accepts the fol-
lowing inputs – group’s identifier g, symmetric group key Kg , sender identifier u, sender signing key
sku , nonce n = (nbody , nheader ), message mbody , and associated data ad. It performs the following steps.
First it calls XSalsa20-Poly1305.Enc to encrypt mbody using key Kg and nonce nbody , and obtains the
ciphertext cbody . It builds header plaintext mheader as ⟨ad, u, g, hbody ⟩ (a unique encoding of ad, u, g, and
hash hbody = SHA-256(nbody ∥ cbody )). It then invokes SealPacket.SigEnc to encrypt mheader using sku ,
Kg , and nheader , and obtains the ciphertext cheader . Finally, it returns (cbody , cheader ). To decrypt cipher-
text (cbody , cheader ), the algorithm BoxMessage.VerDec (not shown) ensures that cheader decrypts into the
header plaintext mheader that is equal to the unique string ⟨ad, u, g, hbody ⟩ composed from the inputs of
BoxMessage.VerDec. In Keybase, the sender identifier u is their username and the group identifier g is
constructed canonically from the usernames of the group members.

17
The SealPacket Header-Encryption Algorithm. The SealPacket algorithm accepts the same inputs
as BoxMessage, except it does not take associated data ad as input. We set SealPacket.AD = {ε}, meaning
ad = ε is always true When SealPacket.SigEnc is called from BoxMessage.SigEnc, it encrypts chat headers.
To encrypt m with nonce n, it starts by hashing m to obtain h = SHA-512(m). Then it builds an
input ms to the Ed25519 signature scheme by concatenating the prefix string “Keybase-Chat-2” with
the unique encoding ⟨Kg , n, h⟩ of Kg , n, and h. It invokes Ed25519.Sig to produce a signature s over
ms using the signing key sku . Finally it calls XSalsa20-Poly1305.Enc to encrypt me = s ∥ m using the
key Kg and nonce n, and obtains the ciphertext c which is returned To decryption ciphertext c, the
SealPacket.VerDec algorithm (not shown) first recovers me from c and then parses me to obtain s ∥ m.
Note that me can be unambiguously parsed into s ∥ m because Ed25519 produces fixed-length signatures.
Then SealPacket.VerDec reconstructs ms and ensures that s verifies as a valid signature for ms under the
sender’s public key vku . We study the security of SealPacket in the context of the BoxMessage algorithm,
but this is not the only context in which Keybase uses SealPacket. It is also used independently for the
encryption of long strings and attachments. In Appendix E we detail other uses of SealPacket in Keybase.
Analysis Challenges. The descriptions of BoxMessage and SealPacket that we have given so far already
present the following challenges in their analysis.
Key Reuse in BoxMessage. The same symmetric key Kg is used in BoxMessage and SealPacket. This
violates the principle of key separation, which says that one should always use distinct keys for distinct
algorithms and modes of operation. Without context separation, this potentially allows an attacker to
forward ciphertexts produced by one algorithm to another. There is no explicit context separation, so our
analysis will “extract” separation by making assumptions of Ed25519 and using low-level details of how
messages are encoded.
Cyclic Key Dependency in SealPacket. The message ms signed in SealPacket is derived from the
symmetric group key Kg which is also used to encrypt the signature. This produces what is known as an
“encryption cycle”, a generalization of encrypting one’s own key [BRS03]. Standard AEAD security does
not guarantee security when messages being encrypted depend on the key used for encryption. We use
an extension of AEAD security allowing key-dependent messages and prove (in the random oracle model)
that XSalsa20-Poly1305 achieves it for the particular key-dependent messages required.
Lack of Group/User Binding in SealPacket. By looking at the SealPacket algorithm in Fig. 12 we can
see that the inputs u and g are never used by the algorithm. This means that a SealPacket ciphertext
does not, in general, bind to the group’s or user’s identifiers. This could potentially allow a malicious user
to impersonate another group member. When SealPacket is used within BoxMessage, it is always invoked
on a message that contains the group’s and the user’s identifier, so the lack of group/user binding in
SealPacket is not consequential there.
Nonce Repetition in Keybase. XSalsa20-Poly1305 is not secure when nonces repeat so our security
analysis disallows nonce repetition between BoxMessage and/or SealPacket. The Keybase implementa-
tion uses uniformly random nonces, making collisions highly unlikely. Moreover, our results show that
BoxMessage is robust to accidental non-uniformity in randomness as long nonces do not repeat.
We highlight the consequences of repetition across either of nbody or nheader . The XSalsa20-Poly1305 au-
thenticated encryption scheme combines the XSalsa20 stream cipher and the Poly1305 one-time message
authentication code. The XSalsa20 stream cipher XORs plaintexts with a keystream that is determinis-
tically derived from its key and nonce. So nonce repetition allows learning the XOR of the underlying
messages. This is not an issue for twice repetition of nheader the header plaintext mheader is sent in the clear
with ciphertexts in Keybase (a detail omitted from our abstraction), but reveals confidential information
if the repetition involves a nbody . Moreover, the Poly1305 key is extracted from the first 32 keystream
bytes. Nonce repetition results in key reuse, allowing an attacker to create forgeries for this key.

5.1 Message and Header Encryption Schemes BoxMessage and SealPacket

Message Encryption Scheme BM. Our modular symmetric signcryption construction BM models the
BoxMessage chat-encryption algorithm as follows.

18
 BM.UserKg
(sk, vk) ←$ SP.UserKg ; Return (sk, vk)
BM.SigEnc(g, Kg , u, sku , n, mbody , ad) // Kg ∈ {0, 1}256
(nbody , nheader ) ← n // nbody , nheader ∈ {0, 1}192
// Encrypt the message body
cbody ← NE.Enc(Kg , nbody , mbody ) // NE = XSalsa20-Poly1305
// Create and encrypt the message header
hbody ← H(nbody ∥ cbody ) ; mheader ← ⟨ad, u, g, hbody ⟩ // H = SHA-256
cheader ← SP.SigEnc(g, Kg , u, sku , nheader , mheader , ε) // SP = SEAL-PACKET-SS
Return (cbody , cheader )
BM.VerDec(g, Kg , u, vku , n, c, ad)
(nbody , nheader ) ← n ; (cbody , cheader ) ← c
// Recover and verify the message header
mheader ← SP.VerDec(g, Kg , u, vku , nheader , cheader , ε)
hbody ← H(nbody ∥ cbody )
If mheader ̸= ⟨ad, u, g, hbody ⟩ then return ⊥
// Recover and return the message body
mbody ← NE.Dec(Kg , nbody , cbody ) ; Return mbody

Fig. 14: Symmetric signcryption scheme BM = BOX-MESSAGE-SS[M, NE, H, SP]. The right-aligned com-
ments provide a guideline for modeling Keybase.

SP.UserKg
(sk, vk) ←$ DS.Kg ; Return (sk, vk)
SP.SigEnc(g, Kg , u, sku , n, m, ad) // Kg ∈ {0, 1}256 , n ∈ {0, 1}192 , ad = ε
h ← H(m) // H = SHA-512
ms ← “Keybase-Chat-2” ∥ ⟨Kg , n, h⟩
s ← DS.Sig(sku , ms ) ; me ← s ∥ m // DS = Ed25519
c ← NE.Enc(Kg , n, me ) ; Return c // NE = XSalsa20-Poly1305
SP.VerDec(g, Kg , u, vku , n, c, ad) // ad = ε
me ← NE.Dec(Kg , n, c)
If me = ⊥ then return ⊥
s ∥ m ← me // s.t. |s| = DS.sl, |m| ≥ 0
h ← H(m)
ms ← “Keybase-Chat-2” ∥ ⟨Kg , n, h⟩
If ¬DS.Ver(vku , ms , s) then return ⊥ else return m

Fig. 15: Symmetric signcryption scheme SP = SEAL-PACKET-SS[H, DS, NE]. The right-aligned comments
provide a guideline for modeling Keybase.

Construction 3. Let M ⊆ {0, 1}∗ . Let NE be a nonce-based encryption scheme. Let H be a hash function.
Let SP be a deterministic symmetric signcryption scheme. Then BM = BOX-MESSAGE-SS[M, NE, H, SP]
is the deterministic symmetric signcryption scheme as defined in Fig. 14, with message space BM.MS = M
and associated-data space BM.AD = {0, 1}∗ . We require the following. The group key taken by BM is used
as the key for both NE and SP, so BM.gkl = NE.kl = SP.gkl. The nonce taken by BM is a pair containing
a separate nonce for each of NE and SP, so BM.NS = {0, 1}NE.nl × SP.NS.

Header Encryption Scheme SP. Our modular symmetric signcryption construction SP models the
header-encryption algorithm SealPacket as follows.

19
Construction 4. Let H be a hash function. Let DS be a deterministic digital signature scheme. Let
NE be a nonce-based encryption scheme. Then SP = SEAL-PACKET-SS[H, DS, NE] is the deterministic
symmetric signcryption scheme as defined in Fig. 15, with group-key length SP.gkl = NE.kl, nonce space
SP.NS = {0, 1}NE.nl , message space SP.MS = {0, 1}∗ , and associated-data space SP.AD = {ε}.

6 Security Analysis of Keybase Chat Encryption

In this section we analyze the security of the symmetric signcryption schemes BM and SP defined in Sec-
tion 5. In Section 6.1, we show the in-group unforgeability of BM and SP. In Sections 6.2 and 6.3, we
show the out-group AE security of BM and SP. This requires us to introduce two weaker variants of the
OAE security notion, one each for BM and SP, by relaxing the level of nonce-misuse requirements of the
OAE game defined in Fig. 7. The SP analysis requires two new security notions, M-sparsity for digital
signature schemes and authenticated encryption for key-dependent messages for nonce-based encryption
schemes.

6.1 In-Group Unforgeability of BoxMessage and SealPacket

In-Group Unforgeability of BoxMessage. We reduce the in-group unforgeability of the symmetric

signcryption scheme BM = BOX-MESSAGE-SS[M, NE, H, SP] to the security of its underlying primitives.
In particular, we reduce the IUF security of BM = BOX-MESSAGE-SS[M, NE, H, SP] to the IUF security
of SP and the collision resistance of H.
A BM ciphertext is a pair (cbody , cheader ) comprising an NE ciphertext cbody and an SP ciphertext
cheader , which encrypts ⟨ad, u, g, hbody ⟩. The adversary’s objective is to forge a BM ciphertext by either
forging cbody or cheader . The adversary can use a corrupt group key Kg , so cbody ciphertexts are easily
forged. However, this does not suffice to produce a BM forgery because cheader encrypts the hash of cbody .
Therefore, it would need to forge a corresponding cheader ciphertext. The IUF security of SP prevents the
adversary from forging cheader ciphertexts. As a result, the adversary can only reuse honestly generated
cheader from its prior queries to SigEnc in its forgery attempts. Since an honest cheader effectively commits
to ad, u, g, hbody , and nheader , using an old cheader to construct a new BM ciphertext requires finding a
new NE nonce-ciphertext pair that hashes to the same hbody under H. Collision resistance of H prevents
this.

Theorem 2. Let BM = BOX-MESSAGE-SS[M, NE, H, SP] be the symmetric signcryption scheme built
suf-except-group
from some M, NE, H, SP as specified in Construction 3. Let predsuf trivial and predtrivial be the ciphertext-
triviality predicates as defined in Fig. 8. Let AIUF-of-BM be any adversary against the IUF security of BM
with respect to predsuf
trivial . Then we can build adversaries AIUF-of-SP and ACR such that
AdvIUF IUF CR
BM,predsuf (AIUF-of-BM ) ≤ AdvSP,predsuf-except-group (AIUF-of-SP ) + AdvH (ACR ).
trivial trivial

The formal proof of Theorem 2 is in Appendix B.1.

In-Group Unforgeability of SealPacket. In-group unforgeability of the symmetric signcryption scheme
SP = SEAL-PACKET-SS[H, DS, NE] reduces to the security of DS and H. We parameterize the IUF security
of SP to aim for a relaxed version of strong unforgeability because SP ciphertexts do not directly depend
on the group’s identifier g (even though it depends on the group key Kg ).
An SP ciphertext encrypts s ∥ m under Kg . The adversary can use a corrupt Kg , but forging an SP
ciphertext still requires the signature s. So the adversary must either forge a new signature or reuse
an honest signature from a prior SigEnc query. The SUFCMA security of DS prevents the former. An
honest signature s is computed over “Keybase-Chat-2” ∥ ⟨Kg , n, h⟩ where h is the hash of the message m.
Hence reusing an honest signature could use a new SP ciphertext that encrypts s ∥ m with Kg , n, but the
tidiness of NE prevents this. So reusing an honest signature requires finding a new message that hashes
to the same h under H. Collision resistance of H prevents this.

20
Fig. 16: A summary of the reductions that we provide for the wOAE security of SP and the bwOAE security
of BM.

Theorem 3. Let SP = SEAL-PACKET-SS[H, DS, NE] be the symmetric signcryption scheme built from
some H, DS, and NE as specified in Construction 4. Let predsuf-except-group
trivial be the ciphertext-triviality
predicate as defined in Fig. 8. Let AIUF-of-SP be any adversary against the IUF security of SP with respect
to predsuf-except-group
trivial . Then we can build adversaries ASUFCMA and ACR such that
AdvIUF
SP,predsuf-except-group
(AIUF-of-SP ) ≤ AdvSUFCMA
DS (ASUFCMA ) + AdvCR
H (ACR ).
trivial

The formal proof of Theorem 3 is in Appendix B.2.

6.2 Out-Group AE Security of BoxMessage

Out-group AE security of BM = BOX-MESSAGE-SS[M, NE, H, SP] reduces to the security of its underlying
primitives as summarized by the rightmost arrows of Fig. 16. At a high level, we show that BM achieves
a variant of OAE security (bwOAE) if SP achieves another variant of OAE security (wOAE) and H is
collision-resistant. Because NE = XSalsa20-Poly1305 in Keybase (which is not nonce-misuse resistant),
both variants disallow nonce repetition.
Intuition. An BM ciphertext is a pair (cbody , cheader ) consisting of an NE ciphertext cbody and an SP
ciphertext cheader . One way the adversary could learn the challenge bit is by querying its VerDec oracle
on a forged BM ciphertext that decrypts successfully. In order to accomplish that, the adversary must
either forge the underlying SP ciphertext cheader or reuse an honestly generated cheader . The former is
prevented by the out-group AE security of SP. The latter is prevented by the collision resistance of H
because of the following. An honestly generated cheader effectively commits to ad, u, g, hbody , and nheader .
In order to reuse cheader , an adversary must find a new NE nonce-ciphertext pair that hashes to hbody ,
hence producing a collision. It follows that the VerDec oracle is essentially useless to the adversary;
it can only serve to decrypt non-challenge ciphertexts that were previously returned by SigEnc. So it
remains to show that the adversary cannot learn the challenge bit solely based on the BM ciphertexts
that it receives from SigEnc. For any ciphertext (cbody , cheader ) returned by SigEnc, the SP ciphertext
cheader encrypts a hash of cbody but otherwise does not depend on the challenge bit. So the adversary
gains no advantage from observing cheader . Finally, the AEAD security of NE guarantees that cbody does
not reveal the challenge bit.
Because the header encryption scheme SP and the body encryption scheme NE use the same symmetric
key Kg , we require integrity of SP ciphertexts produced using Kg hold even when the adversary can obtain
other NE encryptions under the same key. Similarly, the NE ciphertexts generated using the symmetric
key Kg should be indistinguishable even when the adversary can obtain SP encryptions and decryptions
under the same key. We introduce a variant of the OAE game in Definition 3 to capture these joint
requirements.
Restrictions on Nonce Misuse in BM and SP. We now define new variants of out-group AE secu-
rity for our analysis of Keybase. The BM and SP schemes in Keybase are built from the authenticated
encryption scheme XSalsa20-Poly1305 that is not nonce-misuse resistant so we modify the OAE game to
disallow nonce repetition. We start with wOAE security for SP.

21
Definition 1. Let SS be a symmetric signcryption scheme. Consider the OAE security game for SS
of Fig. 7 (w.r.t. any predsec sec
trivial , funcout ). We define a new variant of this game as follows. The instruction
preventing nonce misuse
require ∀d ∈ {0, 1}, (g, u, n, md , ad) ̸∈ Nd is replaced with require (g, n) ̸∈ N .
In addition, the instructions updating the nonce set
N0 ← N0 ∪ {(g, u, n, m0 , ad)} are replaced with N ← N ∪ {(g, n)}.
N1 ← N1 ∪ {(g, u, n, m1 , ad)}
We denote the resulting game (and security notion) by wOAE. It is a weak variant of OAE that does not
require nonce-misuse resistance. We define an adversary’s advantage in breaking the wOAE security of SS
in the natural way.

Now we define bwOAE security for BM. The nonce of BM is a pair of two separate nonces n =
(nbody , nheader ). The bwOAE security game independently applies the group-nonce uniqueness condition
introduced in Definition 1 to each of (g, nbody ) and (g, nheader ), and it also requires that nbody ̸= nheader .
This is a necessary because BM calls NE.Enc on (g, nbody ), and SP calls NE.Enc on (g, nheader ). In Keybase
both NE schemes are XSalsa20-Poly1305 using the same key.

Definition 2. Let X , Y be any sets. Let SS be a symmetric signcryption scheme with the nonce space
SS.NS = X × Y. Consider the OAE security game for SS of Fig. 7 (w.r.t. any predsec sec
trivial , funcout ). We
define a new variant of this game as follows. The instruction preventing nonce misuse
(nbody , nheader ) ← n
require ∀d, (g, u, n, md , ad) ̸∈ Nd is replaced with If nbody = nheader then return ⊥
If (g, nbody ) ∈ N then return ⊥
If (g, nheader ) ∈ N then return ⊥.
In addition, the instructions updating the nonce set
N0 ← N0 ∪ {(g, u, n, m0 , ad)} are replaced with N ← N ∪ {(g, nheader )}
N1 ← N1 ∪ {(g, u, n, m1 , ad)} N ← N ∪ {(g, nbody )}.
We denote the resulting game (and security notion) by bwOAE. Beyond being defined for SS with a
bipartite nonce space, this variant of OAE is weak in that it does not require nonce-misuse resistance. We
define an adversary’s advantage in breaking the bwOAE security of SS in the natural way.

The Joint Security Required of SP and NE. Here we define the security notion required from SP
when it is used in the presence of arbitrary NE encryptions under the same symmetric group keys that
are used by SP. We call this notion wOAE[Enc[M, NE]]. It is a parameterized version of the wOAE game
defined in Definition 1. We use it for our analysis of the bwOAE security of BM.
At the start of this section, we discussed that the security reduction for BM intuitively requires that
it is hard to forge an SP ciphertext (without knowing the corresponding group key Kg ) in the presence
of NE encryptions. Our definition of wOAE[Enc[M, NE]] captures this by providing the adversary access
to an NE encryption oracle Enc in addition to the SigEnc and VerDec oracles in the out-group AE
security game of SP. We stress that proving the security of BM does not, in principle, require us to provide
the SigEnc oracle to the adversary. We choose to require this stronger level of security from SP because
of the following reasons. On the one hand, in Section 5 we explained why it is beneficial to prove that SP
satisfies a strong security notion, going beyond what is required by BM. On the other hand, this stronger
security notion that we require from SP will not come at the cost of introducing additional assumptions
or achieving looser concrete-security bounds in our analysis of BM.

Definition 3. Let SS be a symmetric signcryption scheme. Let M ⊆ {0, 1}∗ . Let NE be a nonce-based en-
cryption scheme. Consider the wOAE security game for SS as defined in Definition 1 (w.r.t. any predsec
trivial ,
funcsec
out ). We define a variant of this game by adding an oracle that is defined as follows.

22
 Enc[M, NE](g, nbody , mbody,0 , mbody,1 )
require K[g] ̸= ⊥ and |mbody,0 | = |mbody,1 |
require (g, nbody ) ̸∈ N and mbody,0 , mbody,1 ∈ M
If mbody,0 ̸= mbody,1 then
If group is corrupt[g] then return ⊥
chal[g] ← true
cbody ← NE.Enc(K[g], nbody , mbody,b )
N ← N ∪ {(g, nbody )} ; Return cbody
It shares set N , bit b, and the tables K, group is corrupt, chal with the rest of the security game. We denote
the resulting game (and security notion) by wOAE[Enc[M, NE]]. It simultaneously requires out-group AE
security of SS (without nonce repetition) and an IND-style security of NE. We define an adversary’s
advantage in breaking this security notion in the natural way.

Note that we require the messages that the adversary queries to the Enc oracle to be in M. Intuitively,
in our security analysis of BM, an adversary will only be able to obtain NE encryptions of messages in
the message space of BM. So in the security reduction for BM we will use M = BM.MS.
Out-Group AE Security of BoxMessage. We prove bwOAE security of BM.

Theorem 4. Let BM = BOX-MESSAGE-SS[M, NE, H, SP] be the symmetric signcryption scheme built
suf-except-user
from some M, NE, H, SP as specified in Construction 3. Let predsuf trivial and predtrivial be the ciphertext-
triviality predicates as defined in Fig. 8. Let func⊥
out be the output-guarding functions as defined in Fig. 9.
Let wOAE[Enc[M, NE]] be the security notion as defined in Definition 3. Let AbwOAE-of-BM be any adver-
sary against the bwOAE security of BM with respect to predsuf sec
trivial and funcout . Then we build adversaries
AwOAE-of-SP and ACR such that
wOAE[Enc[M,NE]]
AdvbwOAE
BM,predsuf ⊥ (AbwOAE-of-BM ) ≤ Adv (AwOAE-of-SP )
trivial ,funcout
suf-except-user
SP,predtrivial ,func⊥
out

+ AdvCR
H (ACR ).

The formal proof of Theorem 4 is in Appendix C.4.

⊥
Note that we prove the OAE security of BM with respect to predsuf trivial and funcout . As discussed in Sec-
suf
tion 3, predtrivial essentially requires BM to have ciphertext integrity. Our result relies on the security
suf-except-user
of SP with respect to predtrivial and func⊥ suf-except-user
out . Recall that predtrivial basically requires SP to
have ciphertext integrity, except it allows for an honest ciphertext to be successfully decrypted even with
respect to a wrong user identifier; the latter is not considered a “valid” forgery. This does not translate to
an attack against BM because it only uses SP to encrypt header messages mheader = ⟨ad, u, g, hbody ⟩ that
contain u, and the BM.VerDec algorithm verifies that the group identifier it received as input matches
the one that was parsed from mheader .

6.3 Out-Group AE Security of SealPacket

Out-group AE security of SP = SEAL-PACKET-SS[H, DS, NE] reduces to the security NE and DS (see
Fig. 16). In particular, wOAE[Enc[M, NE]] security holds (for any M ⊆ {0, 1}∗ ) if NE provides authenti-
cated encryption for key-dependent messages and DS produces M-sparse signatures. We introduce these
security notions below.
Intuition. Recall that in the wOAE[Enc[M, NE]] security game, the adversary is provided with sign-
cryption and unsigncryption oracles SigEnc and VerDec for SP, and an encryption oracle Enc for NE.
Each of these returns output based on a challenge bit that is shared between them. The adversary can use
three approaches to learn the challenge bit. It can (a) attempt SP forgeries by calling its SP decryption
oracle VerDec; (b) make left-or-right queries to its NE encryption oracle Enc; (c) make left-or-right
queries to its SP encryption oracle SigEnc.
The adversary is allowed to expose users’ signing keys so it could attempt to forge an SP ciphertext
using an exposed DS signing key and its Enc oracle. The adversary would then query the resulting

23
ciphertext to its VerDec oracle in an attempt to trivially win the game. We show that the adversary is
unable to accomplish this. The Enc oracle is defined to only produce encryptions of the messages from
the set M. In the implementation of Keybase, the messages from M have a specific encoding; we will
rely on this property in our proof. In contrast, any ciphertext successfully decrypted by VerDec must
encrypt a message of the form me = s ∥ m where s is a valid DS signature. So the adversary needs to find
a signature s that is consistent with the message encoding that is permitted by Enc. The M-sparseness
of DS signatures, which we formalize below, prevents this. It follows that the VerDec oracle does not
help the adversary to win the game by querying ciphertexts that were previously returned by Enc.3
Now we can reimagine the Enc and SigEnc oracles as producing NE encryptions of key-dependent
messages. The SigEnc oracle requires messages to be derived as a specific function of the symmetric
group key Kg . The Enc oracle can be thought of as allowing messages that are derived from “constant”
functions, meaning the chosen messages do not depend on Kg . We can also view the VerDec oracle as
an NE decryption oracle that prevents the adversary from trivially winning the game by merely querying
the ciphertexts it previously obtained from either Enc or SigEnc. We define the AE security of NE for
key-dependent messages and show that the adversary can only win the wOAE[Enc[M, NE]] game against
SP if it can win the KDMAE game against NE.
The Strength of the Targeted Security Notion. During the analysis of the out-group AE secu-
rity of BM in Section 6.2, we discussed that the left-or-right security of SP is not required for us to prove
the security of BM. Meaning that the requirement (c) listed above arose as a result of us choosing to
define the wOAE[Enc[M, NE]] game in a way that it captures a stronger security notion than strictly
necessary. We note that in our wOAE[Enc[M, NE]] security analysis of SP, case (c) follows from case (b),
and does not need additional assumptions.
Reliance on the Message Encoding in Keybase. We mentioned in the intuition that we rely on
the encoding of messages in M in our proof. We emphasize that avoiding this dependency is non-trivial.
The cyclic key dependency within SP and the key reuse between BM and SP pose significant challenges
when considering the possibility of an alternate proof.
M-sparse Signatures. Consider game G SPARSE of Fig. 17, defined for a digital signature scheme DS,
a set M ⊆ {0, 1}∗ , and an adversary ASPARSE . The advantage of ASPARSE in breaking the M-SPARSE
security of DS is defined as AdvSPARSE SPARSE
DS,M (ASPARSE ) = Pr[GDS,M (ASPARSE )]. Intuitively, this game captures
the inability of an adversary to produce a signature that conforms to the message space M even though
the adversary chooses the public key used to verify the signature. More formally, the adversary wins if it
can return (vk, m, s, γ) such that s verifies as a signature over the message m under the verification key
vk and s ∥ γ ∈ M. We stress that the adversary is allowed to choose an arbitrary – possibly malformed
– verification key. The adversary is not required to know the corresponding signing key, and such a key
may in fact not exist.
We verify our intuition about the M-sparsity of the Ed25519 signature scheme underlying SP in Ap-
pendix C.1. Ed25519 is a deterministic signature scheme introduced by Bernstein, Duif, Lange, Schwabe,
and Yang in [BDL+ 11]. It is obtained by applying the commitment-variant of the Fiat-Shamir transform
to an identification scheme. Therefore a signature produced by Ed25519 consists of the commitment and
response of the identification scheme. The adversary can only win the SPARSE game of Ed25519 if it is
able to produce an accepting conversation transcript for the identification scheme such that the corre-
sponding commitment conforms to M. Commitments in the identification scheme underlying Ed25519
are elements of a prime-order group. We prove that finding such a commitment is only possible if the
adversary can find a group element and its discrete logarithm such that the group element is in M which
we show is hard in the generic group model.
The Message Space M. Keybase uses the MessagePack serialization format [Fur] to encode plaintext
messages. Plaintext messages are represented using a custom data structure in Keybase. So the serialized
MessagePack encoding of a plaintext is a byte sequence that not only stores the plaintext itself but also
some metadata about the data structure that represents it. For messages encrypted by BM, the metadata
3
The wOAE[Enc[M, NE]] game itself also prevents the adversary from trivially winning by querying VerDec
on a ciphertext that was previously returned by SigEnc.

24
 KDMAE
Game GNE,Φ (AKDMAE ) Enc(g, n, ϕ0 , ϕ1 )
′ require K[g] ̸= ⊥ and (g, n) ̸∈ N
b ← {0, 1} ; b ←
$ $ AG,Enc,Dec
KDMAE
Return b = b′ require ϕ0 , ϕ1 ∈ Φ and ∥ϕ0 ∥ = ∥ϕ1 ∥
If ϕ0 ̸= ϕ1 then
Dec(g, n, c)
If group is corrupt[g] then return ⊥
require K[g] ̸= ⊥ and ¬group is corrupt[g] chal[g] ← true
require (g, n, c) ̸∈ C mb ← ϕb (K[g]) ; c ← NE.Enc(K[g], n, mb )
m ← NE.Dec(K[g], n, c) N ← N ∪ {(g, n)} ; C ← C ∪ {(g, n, c)}
If b = 0 then return ⊥ else return m Return c

NewHonGroup(g) ExposeGroup(g) NewCorrGroup(g, K)

require K[g] = ⊥ require K[g] ̸= ⊥ and ¬chal[g] require K[g] = ⊥
K[g] ←$ {0, 1}NE.kl group is corrupt[g] ← true group is corrupt[g] ← true
Return K[g] K[g] ← K

Fig. 18: Game defining authenticated-encryption security of NE for Φ-key-dependent messages, where Φ is
a class of message-deriving functions and G = {NewHonGroup, ExposeGroup, NewCorrGroup}.

about the data structure happens to be located in the first 17 bytes of the encoding. This means that
the encoding of every plaintext encrypted by BM contains a fixed
 17-byte prefix. Let this 17-byte prefix
be pre. Then we define the message space of BM by BM.MS = pre ∥ ν ν ∈ {0, 1}∗ .

Message-Deriving Functions. Let ϕ be any function that

takes a symmetric key K as input and uses it to derive and return
some message m. We call ϕ a message-deriving function and will SPARSE
GDS,M (ASPARSE )
consider some classes (i.e. sets) Φ of message-deriving functions.
For simplicity, we require that the length of an output returned (vk, m, s, γ) ←$ ASPARSE
by ϕ must not depend on its input; we denote the output length win0 ← DS.Ver(vk, m, s)
of ϕ by ∥ϕ∥. win1 ← (s ∥ γ ∈ M)
Return win0 and win1
AE Security of NE for Key-Dependent Messages. Consider
game G KDMAE of Fig. 18, defined for a nonce-based encryption Fig. 17: Game defining M-sparsity of
scheme NE, a class of message-deriving functions Φ, and an adver- a digital signature scheme DS for a
sary AKDMAE . The advantage of AKDMAE in breaking the Φ-KDMAE set M.
security of NE is defined as AdvKDMAE KDMAE
NE,Φ (A) = 2 · Pr[GNE,Φ (A)] − 1.
This game can be thought of as a modification of the AEAD se-
curity game for NE (Fig. 4) which does not require nonce-misuse
resistance. The core difference is that the Enc oracle now takes message-deriving functions ϕ0 , ϕ1 ∈ Φ
as input (rather than challenge messages m0 , m1 ). The challenge message is derived as mb ← ϕb (K[g])
for b ∈ {0, 1}, where K[g] is the symmetric group key associated to g. Trivial attacks are prevented by
requiring that ϕ0 , ϕ1 have the same output length and that ϕ0 = ϕ1 whenever Enc is called for a corrupt
group.
Our definition is based on prior work [BRS03,BPS07,BK11,BMT14]. There are strong impossibility
results [BK11] regarding the existence of schemes that are secure with respect to very large classes of
message-deriving functions Φ. We sidestep these results by considering a very narrow and simple class
ΦSP that we define below.

The Class of Message-Deriving Functions ΦSP . At the beginning of this section we discussed that
in the wOAE[Enc[M, NE]] security game for SP, the SigEnc and Enc oracles can be thought of as
returning an NE ciphertext that encrypts an output of some message-deriving function. For example, the
Enc oracle can be expressed roughly as Enc(g, n, m0 , m1 ) := NE.Enc(K[g], n, ϕmb (K[g])) with respect to
any class Φ that for every m ∈ {0, 1}∗ contains the constant function ϕm (K) := m (i.e. ϕm ignores its

25
input K). We now define the class ΦSP containing all message-deriving functions that are used by either
SigEnc or Enc.

Construction 5. Let NE be a nonce-based encryption scheme. Let H be a hash function. Let DS be a

digital signature scheme. Let SIGENC-DER and ENC-DER be the parameterized message-deriving functions
that are defined as follows, each taking an NE key K ∈ {0, 1}NE.kl as input.
SIGENC-DER[NE, H, DS, m, n, sk](K) ENC-DER[m](K)
h ← H(m) ; ms ← “Keybase-Chat-2” ∥ ⟨K, n, h⟩ Return m
s ← DS.Sig(sk, ms ) ; me ← s ∥ m ; Return me
Then ΦSP = MSG-DER-FUNC[NE, H, DS] is the class of message-deriving functions that is defined as
follows.
ΦSP = SIGENC-DER[NE, H, DS, m, n, sk] m ∈ {0, 1}∗ , n ∈ {0, 1}NE.nl , sk ∈ {0, 1}DS.skl


∪ ENC-DER[m] m ∈ {0, 1}∗ .



Note that SIGENC-DER only uses K as a part of the message ms signed by DS.Sig. Keybase instantiates
DS with Ed25519 which computes two SHA-512 hashes of ms (mixed with other inputs). The resulting
signature does not depend on ms in any other way. Using this observation and an indifferentiability
result of Bellare, Davis, and Di [BDD23] (for SHA-512 with output reduced modulo a prime) we capture
SIGENC-DER as a special class of message-deriving functions for which we can prove security in the
random oracle model.
KDMAE Security for Messages Derived from a Hashed Key. Let H be a hash function. Let Φ be
a class of message-deriving functions such that each ϕ ∈ Φ on input K is only allowed to derive messages
from the hash value H(K), and never directly from K. We will roughly show that every AEAD-secure
nonce-based encryption scheme NE is also Φ-KDMAE-secure, provided that H is modeled as a random
oracle. We formalize this class of functions as follows.
Definition 4. We say Φ derives messages from
 a hashed key if there exists a set Γ and a function H
(modeled as a random oracle) such that Φ = ϕγ ϕγ (·) = γ(H(·)), γ ∈ Γ .
In Appendix C.2 we show how to capture ΦSP as satisfying this definition. Thereby, the following result
will give us ΦSP -KDMAE security.

Proposition 1. Let NE be a nonce-based encryption scheme. Let Φ be a class of message-deriving func-

tions that derives messages from a hash key. Let AKDMAE be an adversary against the Φ-KDMAE security
of NE making qNewHonGroup queries to its NewHonGroup oracle. Then we can build adversaries AKR
and AAEAD such that (in the random oracle model)
2
qNewHonGroup
AdvKDMAE
NE,Φ (A KDMAE ) ≤ 2 · Adv KR
NE (AKR ) + Adv AEAD
NE (AAEAD ) + .
2NE.kl
The constructed adversaries will not repeat (g, n) across Enc queries, so non-nonce-misuse resistant NE
suffices. To prove this, we first assert that a Φ-KDMAE adversary AKDMAE can never directly query the
random oracle on any of the (non-exposed) honest keys; otherwise, we could use AKDMAE to break the
key-recovery security of AEAD. But then AKDMAE cannot distinguish between messages derived from
H(K[g]) or from some H∗ (g). Here H is the actual random oracle and H∗ is a simulated random oracle
whose output depends on a group’s identifier g instead of this group’s key K[g]. We switch from using
H(K[g]) to H∗ (g), thus breaking the dependency of each challenge message on the corresponding NE key.
The AEAD security of NE then guarantees that AKDMAE cannot guess the challenge bit. The formal proof
of Proposition 1 is in Appendix C.3.
Out-group AE Security of SealPacket. We prove wOAE security of SP.

Theorem 5. Let M ⊆ {0, 1}∗ . Let SP = SEAL-PACKET-SS[H, DS, NE] be the symmetric signcryption
scheme built from some H, DS, NE as specified in Construction 4. Let predsuf-except-user
trivial be the ciphertext-
⊥
triviality predicate as defined in Fig. 8. Let funcout be the output-guarding function as defined in Fig. 9. Let

26
wOAE[Enc[M, NE]] be the security notion as defined in Definition 3. Let ΦSP = MSG-DER-FUNC[NE, H,
DS] be the class of message-deriving functions defined in Construction 5. Let AwOAE-of-SP be an adversary
against the wOAE[Enc[M, NE]] security of SP with respect to predsuf-except-user
trivial and func⊥
out . Then we can
build adversaries AKDMAE and ASPARSE such that
wOAE[Enc[M,NE]]
Adv suf-except-user (AwOAE-of-SP ) ≤ AdvKDMAE SPARSE
NE,ΦSP (ANE ) + 2 · AdvDS,M (ASPARSE ).
SP,predtrivial ,func⊥
out

The formal proof of Theorem 5 is in Appendix C.5.

suf-except-user
We prove wOAE[Enc[M, NE]] security of SP with the ciphertext-triviality predicate predtrivial
and the output-guarding function func⊥ suf-except-user
out . The predicate predtrivial requires ciphertext integrity,
except ciphertexts do not bind to the user’s identifier. As pointed out in Section 3 and Section 6.2, the
choice of this predicate follows from the level of ciphertext integrity achieved by SP. The use of func⊥ out
makes the VerDec oracle less informative. We chose func⊥ out despite that fact because proving security
with respect to a stronger parameter like funcsilence-with-m
out
1
[predsuf-except-user
trivial ] comes at the cost of adding
complexity to our reductions.

6.4 Stronger Out-Group AE Security Results

The OAE security results that we showed in Sections 6.2 and 6.3 used the output guarding function
func⊥
out . In this section, we show that for the symmetric signcryption schemes that we consider in this
work, the OAE security of a scheme with respect to func⊥ out implies its OAE security with respect to the
stronger output guarding function funcsecout . This requires us to first introduce a new security notion for
digital signature schemes and symmetric signcryption schemes that we call unique verifiability.
Unique Verifiability. Consider game G UV of Fig. 19, defined for a digital signature scheme DS and
an adversary AUV on the left, and for a symmetric signcryption scheme SS and an adversary AUV on the
right. The advantage of AUV in breaking the UV security of DS (resp. SS) is defined as AdvUV DS (AUV ) =
UV
Pr[GDS (AUV )] (resp. AdvUV UV
SS (Auv ) = Pr[GSS (AUV )]).
Intuitively, for DS, this game captures the inability of an attacker to produce a signature by executing
the underlying signing algorithm with some signing key sk such that the resulting signature verifies
successfully under an attacker-chosen verification key vk ′ that is different from the “honest” verification
key corresponding to sk. Analogously, for SS, the game captures the inability of an attacker to produce
a ciphertext by executing the underlying encryption algorithm with some signing key sk such that the
resulting ciphertext decrypts successfully under an attacker-chosen verification key vk ′ that is different
from the “honest” verification key corresponding to sk.

UV UV
GDS (AUV ) GSS (AUV )
′
(sk, vk , m) ←$ AUV (g, Kg , u, u′ , sku , vku′ , n, m, ad) ←$ AUV
s ←$ DS.Sig(sk, m) c ←$ SS.SigEnc(g, Kg , u, sku , n, m, ad)
win0 ← DS.Ver(vk′ , m, s) win0 ← (SS.VerDec(g, Kg , u′ , vku′ , n, c, ad) ̸= ⊥)
win1 ← ((sk, vk′ ) ̸∈ [DS.Kg]) win1 ← ((sku , vku′ ) ̸∈ [SS.UserKg])
Return win0 and win1 Return win0 and win1

Fig. 19: Left pane: Game defining the unique verifiability of a digital signature scheme DS. Right pane:
Game defining the unique verifiability of a symmetric signcryption scheme DS.

As an intermediate result, we first show that the unique verifiability of the symmetric signcryp-
tion schemes StE = SIGN-THEN-ENCRYPT-SS[DS, NE], EtS = ENCRYPT-THEN-SIGN-SS[NE, DS], and
SP = SEAL-PACKET-SS[H, DS, NE] defined in Sections 4 and 5 is implied by the unique verifiability
of the underlying digital signature scheme DS. In Appendix D.2 we prove that in the random ora-
cle model, the Ed25519 digital signature scheme underlying SP achieves unique verifiability. We omit

27
BM = BOX-MESSAGE-SS[M, NE, H, SP] from Proposition 2 for simplicity, but it is easy to see that the
unique verifiability of BM follows from the unique verifiability of SP.

Proposition 2. Let StE = SIGN-THEN-ENCRYPT-SS[DS, NE], EtS = ENCRYPT-THEN-SIGN-SS[NE, DS],

and SP = SEAL-PACKET-SS[H, DS, NE] be symmetric signcryption schemes built from some DS, NE, H as
specified in Construction 1, Construction 2, and Construction 4 respectively. Let SS ∈ {StE, EtS, SP}. Let
ASS DS
UV be any adversary against the UV security of SS. Then we can build adversary AUV such that
AdvUV SS UV DS
SS (AUV ) ≤ AdvDS (AUV ).

The proof of Proposition 2 for SS = StE is fairly straightforward and is given in Appendix D.1.

Proposition 3. Let DS = Ed25519-DS[k, p, G, Gp , B, H1 , H2 , H3 ] be the digital signature scheme built

from some k, p, G, Gp , B, H1 , H2 , H3 as specified in Construction 6. Let AUV be any adversary against the
UV security of DS. Let H3 be modeled as a random oracle and qH be the number of random oracle queries
that AUV makes. Then
AdvUV 2
Ed25519 (AUV ) ≤ (2 · qH )/p + qH /p.

We now show that OAE security of a symmetric signcryption scheme SS ∈ {StE, EtS, SP, BM} with
⊥
respect to funcsec
out follows from its OAE security with respect to funcout and its UV security.

Scheme SS Security notion OAE∗ Triviality predicate predtrivial

StE = SIGN-THEN-ENCRYPT-SS[DS, NE] OAE predsuf
trivial
EtS = ENCRYPT-THEN-SIGN-SS[NE, DS] OAE predsuf
trivial
BM = BOX-MESSAGE-SS[M, NE, H, SP] bwOAE predsuf
trivial
SP = SEAL-PACKET-SS[H, DS, NE] wOAE[Enc[M, NE]] predsuf-except-user
trivial

Table 1: Table specifying the OAE∗ security notion and the predicate predtrivial for different values of SS.
Here, StE = SIGN-THEN-ENCRYPT-SS[DS, NE] and EtS = ENCRYPT-THEN-SIGN-SS[NE, DS] are the
symmetric signcryption schemes built from some DS, NE as specified in Construction 1 and Construction 2
respectively. The scheme BM = BOX-MESSAGE-SS[M, NE, H, SP] is the symmetric signcryption scheme
built from M = {0, 1}∗ and some NE, H, SP as specified in Construction 3. Finally, the scheme SP =
SEAL-PACKET-SS[H, DS, NE] is the symmetric signcryption scheme built from some H, DS, NE as specified
in Construction 4.

Proposition 4. Let StE, EtS, BM, and SP be the symmetric signcryption schemes defined in Construc-
suf-except-user
tions 1, 2, 3 and 4 respectively. Let predsuf
trivial and predtrivial be the ciphertext-triviality predicates as
⊥ sec silence-with-m1
defined in Fig. 8. Let funcout and funcout := funcout [predtrivial ] be the output-guarding functions
as defined in Fig. 9. Let SS ∈ {StE, EtS, SP, BM}, and OAE∗ and predtrivial be as defined in Table 1. Let
AOAE∗ be any adversary against the OAE∗ security of SS with respect to predtrivial and funcsec out . Then we
can build adversaries AUV and A⊥ OAE∗ such that
∗ ∗
AdvOAE
SS,predtrivial ,funcsec (AOAE∗ ) ≤ AdvUV OAE
SS (AUV ) + AdvSS,pred ⊥ (A⊥
OAE∗ ).
out trivial ,funcout

The proof of Proposition 4 is in Appendix D.3.

6.5 Instantiation and Interpretation

In this section, we summarize the analysis of BoxMessage that we provided in Sections 6.1 to 6.3. For
each of the two core security notions in our paper, we state a separate corollary about what is achieved

28
by BoxMessage. We choose to present our corollaries in a precise and formal way, meaning they do not
simplify or approximate any of the advantage terms from our analysis in the prior sections. However,
instead of using the abstract schemes, we phrase our corollaries with respect to the real-world primitives
that are used to instantiate BoxMessage in Keybase, as described in Section 5.
In the following, we show that our analysis of the in-group unforgeability of BoxMessage in Section 6.1
reduces the IUF security of BoxMessage with respect to the predicate predsuf trivial to the collision resistance
of the SHA-256 and SHA-512 hash functions and the SUFCMA security of the Ed25519 signature scheme.
Recall that in the IUF security game, we use ciphertext triviality predicates to detect ciphertexts that
were trivially forwarded from the SigEnc oracle to the VerDec oracle. In particular, the predicate
predsuf
trivial captures the strong unforgeability of ciphertexts by checking whether z ∈ C. We note here that
the following result holds for any choice of the message space M. Moreover, the SUFCMA security of
Keybase’s implementation of Ed25519 is shown in [BCJZ21].

Corollary 1. Let SHA-256, SHA-512, Ed25519, XSalsa20-Poly1305 be the standard real-world schemes
used in Keybase. Let SP = SEAL-PACKET-SS[SHA-512, Ed25519, XSalsa20-Poly1305] be the symmetric
signcryption scheme as defined in Construction 4. Let BM = BOX-MESSAGE-SS[M, XSalsa20-Poly1305,
SHA-256, SP] be the symmetric signcryption scheme as defined in Construction 3, instantiated for any
message space M. Let predsuftrivial be the ciphertext-triviality predicate as defined in Fig. 8. Let AIUF-of-BM
be any adversary against the IUF security of BM with respect to predsuf trivial . Then we can build adversaries
ASUFCMA , ACR-of-SHA512 , and ACR-of-SHA256 such that
AdvIUF SUFCMA CR
BM,predsuf (AIUF-of-BM ) ≤ AdvEd25519 (ASUFCMA ) + AdvSHA-512 (ACR-of-SHA512 )
trivial

+ AdvCR
SHA-256 (ACR-of-SHA256 ).

Next, we show that our analysis of the out-group AE security of BoxMessage in Sections 6.2 and 6.3
reduces the bwOAE security of BoxMessage with respect to the predicate predsuf
trivial and the output-guarding
function func⊥out to the key-recovery and AEAD security of XSalsa20-Poly1305, the sparsity of Ed25519
with respect to the message space M underlying BoxMessage, and the collision resistance of SHA-256.
Recall that bwOAE is a variant of the OAE security notion that modifies the group-nonce uniqueness
condition of the latter. In the bwOAE game, we use ciphertext triviality predicates to detect ciphertexts
that were trivially forwarded from the SigEnc oracle to the VerDec oracle and the function func⊥ out to
appropriately respond with ⊥ when the VerDec oracle is queried on such forwarded ciphertexts.

Corollary 2. Let SHA-256, SHA-512, Ed25519, XSalsa20-Poly1305 be the standard real-world schemes
used in Keybase. Let SP = SEAL-PACKET-SS[SHA-512, Ed25519, XSalsa20-Poly1305] be the symmetric
signcryption scheme as defined in Construction 4. Let BM = BOX-MESSAGE-SS[M, XSalsa20-Poly1305,
SHA-256, SP] be the symmetric signcryption scheme as defined in Construction 3, instantiated for the mes-
sage space M that contains application-layer messages encoded in the MessagePack format. Let predsuf trivial
be the ciphertext-triviality predicate as defined in Fig. 8. Let func⊥
out be the output-guarding function as
defined in Fig. 9. Let AbwOAE-of-BM be any adversary against the bwOAE security of BM with respect to
predsuf sec
trivial and funcout , making at most qNewHonGroup queries to its NewHonGroup oracle. Then we can
build adversaries AKR , AAEAD , ASPARSE , and ACR-of-SHA256 such that
AdvbwOAE
BM,predsuf ⊥ (AbwOAE-of-BM )
trivial ,funcout
2
qNewHonGroup
≤ 2 · AdvKR AEAD
XSalsa20-Poly1305 (AKR ) + AdvXSalsa20-Poly1305 (AAEAD ) +
2257
+ AdvSPARSE CR
Ed25519,M (ASPARSE ) + AdvSHA-256 (ACR-of-SHA256 ).

We emphasize that for this result, we model the (modularly reduced) instances of SHA-512 within
Ed25519 as a random oracle. We also note from our analysis of the sparsity of Ed25519 with respect to the
message space M in Appendix C.1 that we expect the AdvSPARSE
Ed25519,M (ASPARSE ) term in the bound above
to be very small for the parameters that BoxMessage is instantiated within Keybase.

29
7 Conclusions

Combining Theorem 2 with Theorem 3 and Theorem 4 with Theorem 5 establishes the in-group unforge-
ability and out-group authenticated encryption security of Keybase’s BoxMessage algorithm. These results
rely on some standard security assumptions (unforgeability of Ed25519 and collision resistance of SHA-256)
as well as some non-standard assumptions (key-dependent message security of XSalsa20-Poly1305 and
sparsity of Ed25519). These non-standard assumptions arose, respectively, from the key cycle in SealPacket
and the key reuse without explicit context separation in BoxMessage. While we were able to justify these
assumptions, we consider them brittle as they are not well studied, their justifications required ideal
models, and (in the case of sparsity) they required properties of the specific messaging encoding format
used by Keybase.
The comparative simplicity of our Sign-then-Encrypt construction speaks to the value of formalizing
the syntax and security of symmetric signcryption. Explicit goals allow designing schemes in parallel with
writing proofs to identify precisely what is needed.

References

ACDJ22. Martin R Albrecht, Sofía Celi, Benjamin Dowling, and Daniel Jones. Practically-exploitable cryp-
tographic vulnerabilities in matrix. In 2023 IEEE Symposium on Security and Privacy (SP), pages
1419–1436. IEEE Computer Society, 2022.
ACDT21. Joël Alwen, Sandro Coretti, Yevgeniy Dodis, and Yiannis Tselekounis. Modular design of secure group
messaging protocols and the security of MLS. In Giovanni Vigna and Elaine Shi, editors, ACM CCS
2021, pages 1463–1483. ACM Press, November 2021. doi:10.1145/3460120.3484820.
ADJ23. Martin Albrecht, Benjamin Dowling, and Daniel Jones. Device-oriented group messaging: A formal
cryptographic analysis of matrix’core. In IEEE S&P 2024. 2023.
ADR02. Jee Hea An, Yevgeniy Dodis, and Tal Rabin. On the security of joint signature and encryption.
In Lars R. Knudsen, editor, EUROCRYPT 2002, volume 2332 of LNCS, pages 83–107. Springer,
Heidelberg, April / May 2002. doi:10.1007/3-540-46035-7_6.
AJKL23. Joël Alwen, Jonas Janneck, Eike Kiltz, and Benjamin Lipp. The pre-shared key modes of hpke. In
Advances in Cryptology - ASIACRYPT 2023, Berlin, Heidelberg, 2023. Springer-Verlag. doi:10.1007/
978-981-99-8736-8_11.
BBLW22. Richard Barnes, Karthikeyan Bhargavan, Benjamin Lipp, and Christopher A. Wood. Hybrid Public
Key Encryption. RFC 9180, February 2022. doi:10.17487/RFC9180.
BBR+ 23. Richard Barnes, Benjamin Beurdouche, Raphael Robert, Jon Millican, Emad Omara, and Katriel
Cohn-Gordon. The Messaging Layer Security (MLS) Protocol. RFC 9420, July 2023. doi:10.17487/
RFC9420.
BCG23. David Balbás, Daniel Collins, and Phillip Gajland. Whatsupp with sender keys? analysis, improve-
ments and security proofs. In Advances in Cryptology - ASIACRYPT 2023, pages 307–341, Berlin,
Heidelberg, 2023. Springer-Verlag. doi:10.1007/978-981-99-8733-7_10.
BCJZ21. Jacqueline Brendel, Cas Cremers, Dennis Jackson, and Mang Zhao. The provable security of Ed25519:
Theory and practice. In 2021 IEEE Symposium on Security and Privacy, pages 1659–1676. IEEE
Computer Society Press, May 2021. doi:10.1109/SP40001.2021.00042.
BDD23. Mihir Bellare, Hannah Davis, and Zijing Di. Hardening signature schemes via derive-then-derandomize:
Stronger security proofs for EdDSA. In Alexandra Boldyreva and Vladimir Kolesnikov, editors,
PKC 2023, Part I, volume 13940 of LNCS, pages 223–250. Springer, Heidelberg, May 2023. doi:
10.1007/978-3-031-31368-4_9.
BDJR97. Mihir Bellare, Anand Desai, Eric Jokipii, and Phillip Rogaway. A concrete security treatment of
symmetric encryption. In 38th FOCS, pages 394–403. IEEE Computer Society Press, October 1997.
doi:10.1109/SFCS.1997.646128.
BDL+ 11. Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang. High-speed high-
security signatures. In Bart Preneel and Tsuyoshi Takagi, editors, CHES 2011, volume 6917 of LNCS,
pages 124–142. Springer, Heidelberg, September / October 2011. doi:10.1007/978-3-642-23951-9_9.
BDL+ 12. Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang. High-speed high-
security signatures. Journal of Cryptographic Engineering, 2(2):77–89, September 2012. doi:10.1007/
s13389-012-0027-1.

30
Ber05. Daniel J. Bernstein. The poly1305-AES message-authentication code. In Henri Gilbert and Helena
Handschuh, editors, FSE 2005, volume 3557 of LNCS, pages 32–49. Springer, Heidelberg, February
2005. doi:10.1007/11502760_3.
Ber08. Daniel J Bernstein. The salsa20 family of stream ciphers. In New stream cipher designs: the eSTREAM
finalists, pages 84–97. Springer, 2008.
BK11. Mihir Bellare and Sriram Keelveedhi. Authenticated and misuse-resistant encryption of key-dependent
data. In Phillip Rogaway, editor, CRYPTO 2011, volume 6841 of LNCS, pages 610–629. Springer,
Heidelberg, August 2011. doi:10.1007/978-3-642-22792-9_35.
BMT14. Mihir Bellare, Sarah Meiklejohn, and Susan Thomson. Key-versatile signatures and applications: RKA,
KDM and joint enc/sig. In Phong Q. Nguyen and Elisabeth Oswald, editors, EUROCRYPT 2014,
volume 8441 of LNCS, pages 496–513. Springer, Heidelberg, May 2014. doi:10.1007/978-3-642-55220-
5_28.
BP02. Mihir Bellare and Adriana Palacio. GQ and Schnorr identification schemes: Proofs of security against
impersonation under active and concurrent attacks. In Moti Yung, editor, CRYPTO 2002, volume
2442 of LNCS, pages 162–177. Springer, Heidelberg, August 2002. doi:10.1007/3-540-45708-9_11.
BPS07. Michael Backes, Birgit Pfitzmann, and Andre Scedrov. Key-dependent message security under active
attacks - BRSIM/UC-soundness of symbolic encryption with key cycles. In Andrei Sabelfeld, editor,
CSF 2007 Computer Security Foundations Symposium, pages 112–124. IEEE Computer Society Press,
2007. doi:10.1109/CSF.2007.23.
BR06. Mihir Bellare and Phillip Rogaway. The security of triple encryption and a framework for code-based
game-playing proofs. In Serge Vaudenay, editor, EUROCRYPT 2006, volume 4004 of LNCS, pages
409–426. Springer, Heidelberg, May / June 2006. doi:10.1007/11761679_25.
BRS03. John Black, Phillip Rogaway, and Thomas Shrimpton. Encryption-scheme security in the presence of
key-dependent messages. In Kaisa Nyberg and Howard M. Heys, editors, SAC 2002, volume 2595 of
LNCS, pages 62–75. Springer, Heidelberg, August 2003. doi:10.1007/3-540-36492-7_6.
BS20. Mihir Bellare and Igors Stepanovs. Security under message-derived keys: Signcryption in iMessage. In
Anne Canteaut and Yuval Ishai, editors, EUROCRYPT 2020, Part III, volume 12107 of LNCS, pages
507–537. Springer, Heidelberg, May 2020. doi:10.1007/978-3-030-45727-3_17.
CMRR23. Lily Chen, Dustin Moody, Andrew Regenscheid, and Angela Robinson. Digital signature standard
(dss), 2023-02-02 05:02:00 2023. URL: https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=
935202, doi:https://doi.org/10.6028/NIST.FIPS.186-5.
Fur. Sadayuki Furuhashi. Messagepack. https://msgpack.org/.
Keya. Keybase. Keybase Book. https://book.keybase.io/.
Keyb. Keybase. Keybase Book – Chat – Crypto. https://github.com/keybase/book-content/blob/master/D-
docs/04-chat/01-crypto.md?plain=1#L89-L93.
Keyc. Keybase. Keybase client. https://github.com/keybase/client.
Keyd. Keybase. Keybase client – boxer.go – BoxMessage. https://github.com/keybase/client/blob/v6.2.2/
go/chat/boxer.go/#L1564-L1566.
Keye. Keybase. Keybase client – codec.go – Design Notes. https://github.com/keybase/client/blob/v6.2.2/
go/chat/signencrypt/codec.go/#L95-L110.
Keyf. Keybase. Keybase client – codec.go – sealPacket. https://github.com/keybase/client/blob/v6.2.2/go/
chat/signencrypt/codec.go/#L189-L190.
Keyg. Keybase. Keybase client – codec.go – sealPacket. https://github.com/keybase/client/blob/v6.2.2/go/
chat/signencrypt/codec.go#L548-L549.
Keyh. Keybase. Keybase client – codec.go – sealPacket. https://github.com/keybase/client/blob/v6.2.2/go/
chat/attachments/sender.go#L130-L133.
Keyi. Keybase. Keybase stats. https://web.archive.org/web/20200207065125/https://keybase.io/. Accessed
28 February 2024.
Mar14. Moxie Marlinspike. Private group messaging. https://signal.org/blog/private-groups/, May 2014.
NRS14. Chanathip Namprempre, Phillip Rogaway, and Thomas Shrimpton. Reconsidering generic composi-
tion. In Phong Q. Nguyen and Elisabeth Oswald, editors, EUROCRYPT 2014, volume 8441 of LNCS,
pages 257–274. Springer, Heidelberg, May 2014. doi:10.1007/978-3-642-55220-5_15.
Rog04. Phillip Rogaway. Nonce-based symmetric encryption. In Bimal K. Roy and Willi Meier, editors,
FSE 2004, volume 3017 of LNCS, pages 348–359. Springer, Heidelberg, February 2004. doi:10.1007/
978-3-540-25937-4_22.
Rog06. Phillip Rogaway. Formalizing human ignorance. In Phong Q. Nguyen, editor, Progress in Cryptology
- VIETCRYPT 06, volume 4341 of LNCS, pages 211–228. Springer, Heidelberg, September 2006.

31
RPF19. Keegan Ryan, Thomas Pornin, and Shawn Fitzgerald. Keybase protocol security re-
view. https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018_Public_Report_2019-
02-27_v1.3.pdf, Feb 2019.
RS06. Phillip Rogaway and Thomas Shrimpton. A provable-security treatment of the key-wrap problem. In
Serge Vaudenay, editor, EUROCRYPT 2006, volume 4004 of LNCS, pages 373–390. Springer, Heidel-
berg, May / June 2006. doi:10.1007/11761679_23.
Shr04. Tom Shrimpton. A characterization of authenticated-encryption as a form of chosen-ciphertext security.
Cryptology ePrint Archive, Report 2004/272, 2004. https://eprint.iacr.org/2004/272.
Wha23. WhatsApp. Whatsapp encryption overview: Technical white paper. https://www.whatsapp.com/
security/WhatsApp-Security-Whitepaper.pdf, Sep 2023.
WPBB23. Théophile Wallez, Jonathan Protzenko, Benjamin Beurdouche, and Karthikeyan Bhargavan. TreeSync:
Authenticated group management for messaging layer security. In 32nd USENIX Security Symposium,
pages 1217–1233, Anaheim, CA, August 2023. USENIX Association.
Zhe97. Yuliang Zheng. Digital signcryption or how to achieve cost(signature & encryption) ≪ cost(signature)
+ cost(encryption). In Burton S. Kaliski Jr., editor, CRYPTO’97, volume 1294 of LNCS, pages 165–
179. Springer, Heidelberg, August 1997. doi:10.1007/BFb0052234.
Zoo20. Zoom. Zoom acquires keybase and announces goal of developing the most broadly used enterprise
end-to-end encryption offering. https://blog.zoom.us/zoom-acquires-keybase-and-announces-goal-of-
developing-the-most-broadly-used-enterprise-end-to-end-encryption-offering/, May 2020.

32
A Proofs for Sign-Then-Encrypt Based Symmetric Signcryption

A.1 In-Group Unforgeability of StE (Proof of Theorem 1)

Games G0 –G2 VerDec(g, u, n, c, ad)

AU,G,SigEnc,VerDec
IUF ; Return win require K[g] ̸= ⊥ and vk[u] ̸= ⊥ and u ∈ members[g]
adNE ← ⟨u, ad⟩ ; me ← NE.Dec(K[g], n, c, adNE )
SigEnc(g, u, n, m, ad)
If me = ⊥ then return ⊥
require K[g] ̸= ⊥ and sk[u] ̸= ⊥ and u ∈ members[g] s ∥ m ← me // s.t. |s| = DS.sl, |m| ≥ 0
ms ← ⟨g, n, m, ad⟩ ; s ←$ DS.Sig(sk[u], ms ) ms ← ⟨g, n, m, ad⟩
S ← S ∪ {(u, ms , s)} ; me ← s ∥ m ; adNE ← ⟨u, ad⟩ If ¬DS.Ver(vk[u], ms , s) then return ⊥
c ← NE.Enc(K[g], n, me , adNE ) z ← ((g, u, n, m, ad), c)
C ← C ∪ {((g, u, n, m, ad), c)} ; Return c If z ∈ C then return m
NewHonUser(u) If ¬user is corrupt[u] then
NewHonGroup(g, users) If (u, ms , s) ̸∈ S then
ExposeUser(u) bad0 ← true // ASUFCMA breaks SUFCMA of DS.
ExposeGroup(g) win ← true // G[0,1)
NewCorrUser(u, sk, vk) Else // (u, ms , s) ∈ S
bad1 ← true // Contradicts the tidiness of NE.
NewCorrGroup(g, K, users)
win ← true // G[0,2)
// These oracles are identical to the corresponding
Return m
// oracles in the IUF game for StE as per Fig. 7.

Adversary AU,Sign
SUFCMA SimVerDec(g, u, n, c, ad)
ASimU,SimG,SimSigEnc,SimVerDec
IUF
require K[g] ̸= ⊥ and vk[u] ̸= ⊥ and u ∈ members[g]
adNE ← ⟨u, ad⟩ ; me ← NE.Dec(K[g], n, c, adNE )
SimSigEnc(g, u, n, m, ad)
If me = ⊥ then return ⊥
require K[g] ̸= ⊥ and sk[u] ̸= ⊥ and u ∈ members[g] s ∥ m ← me // s.t. |s| = DS.sl, |m| ≥ 0
ms ← ⟨g, n, m, ad⟩ ; s ← Sign(u, ms ) ms ← ⟨g, n, m, ad⟩
S ← S ∪ {(u, ms , s)} ; me ← s ∥ m ; adNE ← ⟨u, ad⟩ If ¬DS.Ver(vk[u], ms , s) then return ⊥
c ← NE.Enc(K[g], n, me , adNE ) z ← ((g, u, n, m, ad), c)
C ← C ∪ {((g, u, n, m, ad), c)} ; Return c If z ∈ C then return m
SimNewHonGroup(g, users) If ¬user is corrupt[u] then
SimExposeGroup(g) If (u, ms , s) ̸∈ S then
SimNewCorrGroup(g, K, users) z ← (u, ms , s)
// These oracles are identical to the corresponding abort(z)
// oracles in the IUF game for StE as per Fig. 7. Return m

SimNewHonUser(u) SimExposeUser(u) SimNewCorrUser(u, sk, vk)

require sk[u] = vk[u] = ⊥ require sk[u] ̸= ⊥ require sk[u] = vk[u] = ⊥
sk[u] ← “dummy” user is corrupt[u] ← true user is corrupt[u] ← true
vk[u] ← NewHonUser(u) sk[u] ← ExposeUser(u) NewCorrUser(u, sk, vk)
Return vk[u] Return sk[u] sk[u] ← sk ; vk[u] ← vk

Fig. 20: Top pane: Games G0 –G2 for the proof of Theorem 1. The code highlighted in gray was added
by expanding the symmetric signcryption algorithms StE.SigEnc, StE.VerDec and the ciphertext-triviality
predicate predsuf IUF
trivial in game GStE,predsuf (AIUF ). The code added for the transitions between games is high-
trivial
lighted in green. Bottom pane: Adversary ASUFCMA for the proof of Theorem 1. The highlighted in-
structions mark the changes in the code of the simulated game G0 .

Overview. This proof uses games G0 through G2 in Fig. 20. We establish the following claims.

33
 ◦ AdvIUF
StE,predsuf
(AIUF ) = Pr[G0 ] ◦ Pr[G2 ] = 0
trivial
◦ Pr[G0 ] − Pr[G1 ] ≤ Pr[badG00 ] ◦ Pr[badG00 ] ≤ AdvSUFCMA
DS (ASUFCMA )
◦ Pr[G1 ] − Pr[G2 ] ≤ Pr[badG11 ] ◦ Pr[badG11 ] = 0

By combining the above, we have

1
X
AdvIUF
StE,predsuf (AIUF ) = Pr[G0 ] = (Pr[Gi ] − Pr[Gi+1 ]) + Pr[G2 ]
trivial
i=0
G G
≤ Pr[bad00 ] + Pr[bad11 ]
≤ AdvSUFCMA
DS (ASUFCMA ).
We justify our claims in the following paragraphs.
IUF
Game G0 . Game G0 is functionally equivalent to game GStE,pred suf (AIUF ). The former expands multiple
trivial
instructions in the latter; the expanded code is marked in gray. Game G0 also contains newly added code
that is highlighted in green and does not affect its functionality; this code will be used for transitions
between games. In particular, the if-then-else statement that was added in oracle VerDec sets the win
flag in each of its conditional branches. It follows that
AdvIUF
StE,predsuf (AIUF ) = Pr[G0 ].
trivial

Transitions from G0 to G2 . Let i ∈ {0, 1}. Games Gi and Gi+1 are identical until badi is set, therefore
G
Pr[Gi ] − Pr[Gi+1 ] ≤ Pr[badi i ].
Each of these transitions removes an instruction that sets the win flag. The win flag can no longer be set
in game G2 , making it impossible for AIUF to win. We have
Pr[G2 ] = 0.
G
Bounding Pr[bad00 ]. In Fig. 20 we build an adversary ASUFCMA against the SUFCMA security of DS.
It simulates game G0 for adversary AIUF as follows. When adversary AIUF calls the user oracles in the
IUF security game, adversary ASUFCMA responds by using its own user oracles from the SUFCMA security
game. In response to AIUF ’s calls to the group oracles in the IUF security game, we have ASUFCMA respond
by honestly sampling and managing its own NE keys. When AIUF calls the SigEnc oracle, adversary
ASUFCMA can now simulate it by using its Sign oracle. Finally, AIUF ’s calls to the VerDec oracle can be
trivially simulated by ASUFCMA because this oracle does not use DS signing keys. Observe that bad0 can be
set in game G0 only after VerDec confirms the following three statements to be true: DS.Ver(vk[u], ms , s),
¬user is corrupt[u], and (u, ms , s) ̸∈ S. These are exactly the three winning conditions used in the SUFCMA
security game, so ASUFCMA halts with abort(u, ms , s) whenever it detects bad0 being set in the simulated
IUF security game. We have
G SUFCMA
Pr[bad00 ] ≤ Pr[GDS (ASUFCMA )] = AdvSUFCMA
DS (ASUFCMA ).
G
Bounding Pr[bad11 ]. Now consider what conditions need to be met for bad1 to be set in game G1 . This
only happens when z ̸∈ C and (u, ms , s) ∈ S are simultaneously true. We can use the definitions of
the encoding ms and the tuple z in order to expand (u, ms , s) ∈ S into ((u, ⟨g, n, m, ad⟩), s) ∈ S, and
z ̸∈ C into ((g, u, n, m, ad), c) ̸∈ C. The former means that one of the prior calls to the SigEnc oracle
produced the ciphertext c′ = NE.Enc(K[g], n, me , adNE ) for me = s ∥ m and adNE = ⟨u, ad⟩. But the latter
implies that in the current call to the VerDec oracle a distinct ciphertext c ̸= c′ was used to recover
me = NE.Dec(K[g], n, c, adNE ). Together this means that NE.Enc(K[g], n, NE.Dec(K[g], n, c, adNE ), adNE ) ̸=
c, violating the assumed tidiness property of NE. We get a contradiction, and hence
G
Pr[bad11 ] = 0.

A.2 Out-group Authenticated Encryption of StE (Proof of Theorem 1)

Overview. This proof uses games G0 through G2 in Fig. 21. We establish the following claims.

34
Games G0 –G2 VerDec(g, u, n, c, ad)
′ ′
b ←$ {0, 1} ; b ←$ AU,G,SigEnc,VerDec
OAE ; Return b = b require K[g] ̸= ⊥ and ¬group is corrupt[g]
require vk[u] ̸= ⊥ and u ∈ members[g]
SigEnc(g, u, n, m0 , m1 , ad)
If W [g, u, n, c, ad] ̸= ⊥ then return ⊥ // G[1,∞)
require K[g] ̸= ⊥ and |m0 | = |m1 | adNE ← ⟨u, ad⟩ ; me ← NE.Dec(K[g], n, c, adNE )
require sk[u] ̸= ⊥ and u ∈ members[g] If me = ⊥ then return ⊥
require ∀d ∈ {0, 1}, (g, u, n, md , ad) ̸∈ Nd s ∥ m ← me // s.t. |s| = DS.sl, |m| ≥ 0
If m0 ̸= m1 then ms ← ⟨g, n, m, ad⟩
If group is corrupt[g] then return ⊥ else chal[g] ← true If ¬DS.Ver(vk[u], ms , s) then return ⊥
ms ← ⟨g, n, mb , ad⟩ ; s ←$ DS.Sig(sk[u], ms ) z ← ((g, u, n, m, ad), c) // G[0,2)
me ← s ∥ mb ; adNE ← ⟨u, ad⟩ If z ∈ C then return ⊥ // G[0,2)
c ← NE.Enc(K[g], n, me , adNE ) If b = 0 then return ⊥ else return m
N0 ← N0 ∪ {(g, u, n, m0 , ad)}
N1 ← N1 ∪ {(g, u, n, m1 , ad)} NewHonUser(u)
C ← C ∪ {((g, u, n, mb , ad), c)} NewHonGroup(g, users)
Q ← Q ∪ {((g, u, n, m0 , m1 , ad), c)} ExposeUser(u)
W [g, u, n, c, ad] ← m1 ; Return c ExposeGroup(g)
NewCorrUser(u, sk, vk)
NewCorrGroup(g, K, users)
// These oracles are identical to the corresponding
// oracles in the OAE game for StE as per Fig. 7.
Adversary AG,Enc,Dec
AEAD SimVerDec(g, u, n, c, ad)
b′ ←$ ASimU,SimG,SimSigEnc,SimVerDec
OAE ; Return b′ require K[g] ̸= ⊥ and ¬group is corrupt[g]
require vk[u] ̸= ⊥ and u ∈ members[g]
SimSigEnc(g, u, n, m0 , m1 , ad)
If W [g, u, n, c, ad] ̸= ⊥ then return ⊥
require K[g] ̸= ⊥ and |m0 | = |m1 | adNE ← ⟨u, ad⟩ ; me ← Dec(g, n, c, adNE )
require sk[u] ̸= ⊥ and u ∈ members[g] If me = ⊥ then return ⊥
require ∀d ∈ {0, 1}, (g, u, n, md , ad) ̸∈ Nd abort(1) // me ̸= ⊥ possible only when b = 1.
If m0 ̸= m1 then
If group is corrupt[g] then return ⊥ else chal[g] ← true SimNewHonUser(u)
If m0 = m1 then SimExposeUser(u)
ms ← ⟨g, n, m0 , ad⟩ ; s ←$ DS.Sig(sk[u], ms ) SimNewCorrUser(u, sk, vk)
me ← s ∥ m0 ; adNE ← ⟨u, ad⟩ // These oracles are identical to the corresponding
c ← Enc(g, n, me , me , adNE ) // oracles in the OAE game for StE as per Fig. 7.
Else // m0 ̸= m1
ms,0 ← ⟨g, n, m0 , ad⟩ ; s0 ←$ DS.Sig(sk[u], ms,0 )
ms,1 ← ⟨g, n, m1 , ad⟩ ; s1 ←$ DS.Sig(sk[u], ms,1 )
me,0 ← s0 ∥ m0 ; me,1 ← s1 ∥ m1 ; adNE ← ⟨u, ad⟩
c ← Enc(g, n, me,0 , me,1 , adNE )
N0 ← N0 ∪ {(g, u, n, m0 , ad)}
N1 ← N1 ∪ {(g, u, n, m1 , ad)}
W [g, u, n, c, ad] ← m1 ; Return c

SimNewHonGroup(g, users) SimExposeGroup(g) SimNewCorrGroup(g, K, users)

require K[g] = ⊥ require K[g] ̸= ⊥ and ¬chal[g] require K[g] = ⊥
K[g] ← “dummy” group is corrupt[g] ← true group is corrupt[g] ← true
NewHonGroup(g) K[g] ← ExposeGroup(g) NewCorrGroup(g, K)
members[g] ← users Return K[g] K[g] ← K ; members[g] ← users

Fig. 21: Top pane: Games G0 –G2 for the proof of Theorem 1. The code highlighted in gray was added
by expanding the symmetric signcryption algorithms StE.SigEnc, StE.VerDec and the ciphertext-triviality
predicate predsuf OAE
trivial in game GStE,predsuf ,funcsec (AOAE ). The code added for the transitions between games
trivial out
is highlighted in green. Bottom pane: Adversary AAEAD for the proof of Theorem 1. The highlighted
instructions mark the changes in the code of the simulated game G2 .

35
 ◦ AdvOAE
StE,predsuf ,funcsec
(AOAE ) = 2 · Pr[G0 ] − 1 ◦ Pr[G1 ] = Pr[G2 ]
trivial out
◦ Pr[G0 ] = Pr[G1 ] ◦ 2 · Pr[G2 ] − 1 ≤ AdvAEAD
NE (AAEAD )

By combining the above, we have

AdvOAE
StE,predsuf sec (AOAE ) = 2 · Pr[G0 ] − 1
trivial ,funcout

= 2 · Pr[G2 ] − 1 ≤ AdvAEAD
NE (AAEAD ).
We justify our claims in the following paragraphs.
OAE
Game G0 . Game G0 is functionally equivalent to game GStE,pred suf ,funcsec (AOAE ). The former expands mul-
trivial out
tiple instructions in the latter; the expanded code is marked in gray. Game G0 also contains newly added
code that is highlighted in green and does not affect its functionality; this code will be used for transitions
between games. It follows that
AdvOAE
StE,predsuf sec (AOAE ) = 2 · Pr[G0 ] − 1.
trivial ,funcout

Transition from G0 to G1 . We now explain how game G1 differs from game G0 , and will we argue
that these two games are functionally equivalent. Game G1 maintains a record of all ciphertexts that
were previously returned by its SigEnc oracle. When such a ciphertext gets subsequently passed as an
input to the VerDec oracle (with the matching values of g, u, n, ad), game G1 immediately returns ⊥.
To implement this functionality, game G1 uses a table W that maps (g, u, n, c, ad) to m1 . We claim that
Pr[G0 ] = Pr[G1 ].
In order to justify this transition, let us look at what happens in game G0 when an honestly produced
ciphertext is forwarded from the SigEnc oracle to the VerDec oracle. Consider an arbitrary SigEnc
query that took some (g ∗ , u∗ , n∗ , m∗0 , m∗1 , ad∗ ) as input to return a ciphertext c∗ . At the end of this SigEnc
call, the sets N , C, and Q are updated to insert new elements that are created from the SigEnc’s input
(g ∗ , u∗ , n∗ , m∗0 , m∗1 , ad∗ ) and output c∗ ; our analysis below will crucially rely on these sets containing the
newly added elements. Now consider what happens if the VerDec oracle is queried on (g ∗ , u∗ , n∗ , c∗ , ad∗ )
at any point later on. If the condition checking ¬group is corrupt[g] passes, then the decryption correctness
of NE and the correctness of DS jointly guarantee that VerDec builds z = ((g ∗ , u∗ , n∗ , m∗b , ad∗ ), c∗ ). But
exactly the same tuple was inserted into C during the earlier SigEnc call. It follows that z ∈ C is true
and the VerDec oracle returns ⊥. Therefore, the outputs of VerDec are consistent across G0 and G1 .
Transition from G1 to G2 . Note that the condition checking z ∈ C in oracle VerDec of game G1 can
never be reached. In particular, if the set C contains an element z = ((g, u, n, m, ad), c) for any value
of m, then W [g, u, n, c, ad] ̸= ⊥ must be true. The latter causes VerDec to return ⊥ right away. So in
game G2 we remove the two lines of code that build z and check whether it belongs to C. Game G2 is
functionally equivalent to game G1 , so
Pr[G1 ] = Pr[G2 ].

Bounding Pr[G2 ]. In Fig. 21 we build an adversary AAEAD against the AEAD security of NE that simulates
game G2 for adversary AOAE . Adversary AAEAD simulates the group oracles for AOAE by calling its own
group oracles, and it simulates the user oracles for AOAE by sampling its own keys for DS.
Adversary AAEAD simulates the SigEnc oracle for AOAE by evaluating NE.Enc using its encryption
oracle Enc. When SigEnc is queried with m0 = m1 as input, adversary AAEAD ensures that Enc is
likewise called with both of its challenge-message arguments being equal. This maintains consistency of
the challenge maps chal[·] between the simulated game G2 and the AEAD security game of AAEAD . When
SigEnc is queried with m0 ̸= m1 as input, note that |me,0 | = |me,1 | is guaranteed to hold whenever
|m0 | = |m1 | does, because in Section 2.1 we require DS to produce signatures of a fixed length DS.sl.
Finally, the nonce-misuse condition in oracle SigEnc that checks (g, n, m∗ , ad) ̸∈ N is equivalent to the
corresponding condition in oracle Enc that checks (g, u, n, m∗ , ad) ̸∈ N , because AAEAD queries Enc on
an ad field that uniquely encodes the u, ad fields of SigEnc.
Adversary AAEAD simulates the VerDec oracle for AOAE by evaluating NE.Dec using its decryption
AEAD
oracle Dec. If Dec returns me ̸= ⊥ then the challenge bit in game GNE (AAEAD ) is b = 1 and hence

36
AAEAD immediately calls abort(1) in order to halt and return 1 as output. Otherwise (i.e. me = ⊥)
adversary AAEAD returns ⊥ as the output of the simulated VerDec oracle. Note that the AEAD security
game defines Dec to return ⊥ in response to the NE ciphertexts that were previously produced by its
Enc oracle. This is equivalent to the case where a ciphertext is forwarded from SigEnc to VerDec; the
use of the W map at the start of the simulated VerDec oracle ensures that Dec is never called on a
replayed NE ciphertext.
AEAD
Let d denote the challenge bit in game GNE (AAEAD ), and let d′ denote the corresponding output of
adversary AAEAD . If d = 0 then AAEAD perfectly simulates game G2 with challenge bit b = 0 for adversary
AOAE , and returns d′ = 1 iff AOAE returns b′ = 1. In particular, adversary AAEAD perfectly simulates
the VerDec oracle because  in game
 G2 this oracle always returns ⊥ if W [g, u, n, c, ad] = ⊥ and b = 0.
We write Pr d′ = 1 d = 0 = Pr b′ = 1 b = 0 . If d = 1 then AAEAD perfectly simulates game G2 with


challenge bit b = 1 for adversary AOAE until the first time NE.Dec produces non-⊥ in oracle VerDec
′
of game G2 . When the latter happens, AAEAD halts ′with d = 1 regardless of whether AOAE would have
′ ′
returned b = 1. We write Pr d = 1 d = 1 ≥ Pr b = 1 b = 1 . It follows that
AdvAEAD (AAEAD ) = Pr d′ = 1 d = 1 − Pr d′ = 1 d = 0
   
NE
≥ Pr b′ = 1 b = 1 − Pr b′ = 1 b = 0
   

= 2 · Pr[G2 ] − 1.
The latter equality relies on the standard fact that AOAE ’s advantage in game G2 can be expressed in two
alternative ways that are equivalent.

B Proofs for the In-Group Unforgeability of Keybase

B.1 In-Group Unforgeability of BoxMessage (Proof of Theorem 2)

Overview. This proof uses games G0 through G2 in Fig. 22. We establish the following claims.

◦ AdvIUF
BM,predsuf
(AIUF-of-BM ) = Pr[G0 ] ◦ Pr[G2 ] = 0
trivial
◦ Pr[G0 ] − Pr[G1 ] ≤ Pr[badG00 ] ◦ Pr[badG00 ] ≤ AdvIUF
SP,pred
suf-except-group (AIUF-of-SP )
trivial
◦ Pr[G1 ] − Pr[G2 ] ≤ Pr[badG11 ] ◦ Pr[badG11 ] ≤ AdvCR
H (ACR )

By combining the above, we have

1
X
AdvIUF
BM,predsuf (AIUF-of-BM ) = Pr[G0 ] = (Pr[Gi ] − Pr[Gi+1 ]) + Pr[G2 ]
trivial
i=0
G G
≤ Pr[bad00 ] + Pr[bad11 ]
≤ AdvIUF
SP,predsuf-except-group
(AIUF-of-SP ) + AdvCR
H (ACR ).
trivial

We justify our claims in the following paragraphs.

IUF
Game G0 . Game G0 is functionally equivalent to game GBM,pred suf . The former expands multiple instruc-
trivial
tions in the latter; the expanded code is marked in gray. Game G0 also contains newly added code that
is highlighted in green and does not affect its functionality; this code will be used for transitions between
games. In particular, the if-then-else statement that was added in oracle VerDec sets the win flag in
each of its conditional branches. It follows that
AdvIUF
BM,predsuf (AIUF-of-BM ) = Pr[G0 ].
trivial

Transitions from G0 to G2 . Let i ∈ {0, 1}. Games Gi and Gi+1 are identical until badi is set, therefore
G
Pr[Gi ] − Pr[Gi+1 ] ≤ Pr[badi i ].
Each of these transitions removes an instruction that sets the win flag. In game G2 the win flag is only set
when the conditions ∃g ′ : ((g ′ , u, nheader , mheader , ε), cheader ) ∈ CSP and nbody ∥ cbody = T [u, nheader , cheader ,
ad, g, hbody ] are satisfied. Since mheader = ⟨ad, u, g, hbody ⟩, the former condition is necessarily true for

37
Games G0 –G2 VerDec(g, u, n, c, ad)
AU,G,SigEnc,VerDec
IUF-of-BM ; Return win require K[g] ̸= ⊥ and vk[u] ̸= ⊥ and u ∈ members[g]
(nbody , nheader ) ← n ; (cbody , cheader ) ← c
SigEnc(g, u, n, mbody , ad)
mheader ← SP.VerDec(g, K[g], u, vk[u], nheader , cheader , ε)
require K[g] ̸= ⊥ and sk[u] ̸= ⊥ and u ∈ members[g] h
body ← H(nbody ∥ cbody )
(nbody , nheader ) ← n If mheader ̸= ⟨ad, u, g, hbody ⟩ then return ⊥
cbody ← NE.Enc(K[g], nbody , mbody ) mbody ← NE.Dec(K[g], nbody , cbody )
hbody ← H(nbody ∥ cbody ) ; mheader ← ⟨ad, u, g, hbody ⟩ If m
body = ⊥ then return ⊥
cheader ← SP.SigEnc(g, K[g], u, sk[u], nheader , mheader , ε) z ← ((g, u, n, m
body , ad), c) ; If z ∈ C then return mbody
c ← (cbody , cheader ) If ¬user is corrupt[u] then
CSP ← CSP ∪ {((g, u, nheader , mheader , ε), cheader )} If ̸ ∃g ′ : ((g ′ , u, nheader , mheader , ε), cheader ) ∈ CSP then
T [u, nheader , cheader , ad, g, hbody ] ← nbody ∥ cbody bad0 ← true // AIUF-of-SP breaks IUF of SP.
C ← C ∪ {((g, u, n, mbody , ad), c)} ; Return c win ← true // G[0,1)
NewHonUser(u) Else if nbody ∥ cbody ̸= T [u, nheader , cheader , ad, g, hbody ] then
NewHonGroup(g, users) bad1 ← true // ACR breaks CR of H.
ExposeUser(u) win ← true // G[0,2)
ExposeGroup(g) Else // Unreachable in G2 .
NewCorrUser(u, sk, vk) win ← true
Return mbody
NewCorrGroup(g, K, users)
// These oracles are identical to the corresponding
// oracles in the IUF game for BM as per Fig. 7.
Adversary AU,G,SigEnc,VerDec
IUF-of-SP SimVerDec(g, u, n, c, ad)
ASimU,SimG,SimSigEnc,SimVerDec
IUF-of-BM
require K[g] ̸= ⊥ and vk[u] ̸= ⊥ and u ∈ members[g]
(nbody , nheader ) ← n ; (cbody , cheader ) ← c
SimSigEnc(g, u, n, mbody , ad)
mheader ← VerDec(g, u, nheader , cheader , ε)
require K[g] ̸= ⊥ and sk[u] ̸= ⊥ and u ∈ members[g] h
body ← H(nbody ∥ cbody )
(nbody , nheader ) ← n If mheader ̸= ⟨ad, u, g, hbody ⟩ then return ⊥
cbody ← NE.Enc(K[g], nbody , mbody ) mbody ← NE.Dec(K[g], nbody , cbody )
hbody ← H(nbody ∥ cbody ) ; mheader ← ⟨ad, u, g, hbody ⟩ If m
body = ⊥ then return ⊥
cheader ← SigEnc(g, u, nheader , mheader , ε) z ← ((g, u, n, mbody , ad), c) ; If z ∈ C then return mbody
c ← (cbody , cheader ) If ¬user is corrupt[u] then
CSP ← CSP ∪ {((g, u, nheader , mheader , ε), cheader )} If ̸ ∃g ′ : ((g ′ , u, nheader , mheader , ε), cheader ) ∈ CSP then
C ← C ∪ {((g, u, n, mbody , ad), c)} ; Return c bad0 ← true // AIUF-of-SP breaks IUF of SP.
Return mbody

SimNewHonUser(u) SimExposeUser(u) SimNewCorrUser(u, sk, vk)

require sk[u] = vk[u] = ⊥ require sk[u] ̸= ⊥ require sk[u] = vk[u] = ⊥
sk[u] ← “dummy” user is corrupt[u] ← true user is corrupt[u] ← true
vk[u] ← NewHonUser(u) sk[u] ← ExposeUser(u) NewCorrUser(u, sk, vk)
Return vk[u] Return sk[u] sk[u] ← sk ; vk[u] ← vk
SimNewHonGroup(g, users) SimExposeGroup(g) SimNewCorrGroup(g, K, users)
require K[g] = ⊥ require K[g] ̸= ⊥ require K[g] = ⊥
NewHonGroup(g, users) Return K[g] NewCorrGroup(g, K, users)
K[g] ← ExposeGroup(g) K[g] ← K ; members[g] ← users
members[g] ← users

Fig. 22: Top pane: Games G0 –G2 for the proof of Theorem 2. The code highlighted in gray was added
by expanding the symmetric signcryption algorithms BM.SigEnc, BM.VerDec and the ciphertext-triviality
predicate predsuf IUF
trivial in game GBM,predsuf (AIUF-of-BM ). The code added for the transitions between games is
trivial
highlighted in green. Bottom pane: Adversary AIUF-of-SP for the proof of Theorem 2. The highlighted
instructions mark the changes in the code of the simulated game G1 .

38
g ′ = g, i.e. ((g, u, nheader , mheader , ε), cheader ) ∈ CSP . The two conditions combined with the correctness
of NE guarantee that ((g, u, n, mbody , ad), c) ∈ C. This means that the ciphertext-triviality predicate
predsuf
trivial would have triggered for such a query prior to reaching the if-then-else statement. Hence, it
is impossible to set the win flag in G2 and we have
Pr[G2 ] = 0.

G
Bounding Pr[bad00 ]. In Fig. 22 we build an adversary AIUF-of-SP against the IUF security of SP with re-
spect to the ciphertext-triviality predicate predsuf-except-group
trivial . It perfectly simulates game G0 for adversary
AIUF-of-BM . In particular, it simulates the responses to the user and group oracles using the corresponding
oracles from its own IUF security game. Note that the IUF security game allows to expose all group keys, so
every time an honest group key is created in the simulated game G0 , adversary AIUF-of-SP immediately ex-
poses it. While simulating the SigEnc oracle for AIUF-of-BM , it replaces calls to SP.SigEnc with its SigEnc
oracle. Analogously, while simulating VerDec, it substitutes calls to SP.VerDec with its VerDec oracle.
Finally, when the bad0 flag is set in the simulated game G0 , adversary AIUF-of-SP wins by setting the win
flag in the IUF security game it plays in. Note that the bad0 flag is only set in G0 when ¬user is corrupt[u],
and cheader successfully decrypts under SP.VerDec and ̸ ∃g ′ : ((g ′ , u, nheader , mheader , ε), cheader ) ∈ CSP . These
are the same as the winning conditions in the IUF security game of SP and so
G
Pr[bad00 ] ≤ AdvIUF
SP,predsuf-except-group
(AIUF-of-SP ).
trivial

G G
Bounding Pr[bad11 ]. In order to upper-bound Pr[bad11 ], consider an adversary ACR against the colli-
sion resistance of H that is defined as follows. Adversary ACR perfectly simulates game G1 for AIUF-of-BM
until the bad1 flag is set. To simulate the user oracles U and the group oracles G, adversary ACR itself
samples and maintains all user keys and group keys. Whenever the bad1 flag is set in VerDec, ad-
versary ACR returns a pair of strings (nbody ∥ cbody , T [u, nheader , cheader , ad, g, hbody ]). Note that the table
entry T [u, nheader , cheader , ad, g, hbody ] is not empty because bad1 could only be set once the following two
conditions were satisfied in the current VerDec call: ∃g ′ : ((g ′ , u, nheader , mheader , ε), cheader ) ∈ CSP and
mheader = ⟨ad, u, g, hbody ⟩. This means there was a prior SigEnc call where all of the values indexing
the table T (as per the current VerDec call) were simultaneously in use. The two strings returned by
ACR are distinct because a conditional statement in game G1 verifies this immediately before setting the
bad1 flag. We now show that these strings also produce the same hash value. First, observe that the
table entry T [u, nheader , cheader , ad, g, hbody ] was filled during a prior call to oracle SigEnc, with a value
for which hbody = H(T [u, nheader , cheader , ad, g, hbody ]) is true. But the same hash was obtained in the cur-
rent VerDec call upon evaluating hbody ← H(nbody ∥ cbody ). So the strings returned by ACR produce a
collision. It follows that
G
Pr[bad11 ] ≤ AdvCR
H (ACR ).

B.2 In-Group Unforgeability of SealPacket (Proof of Theorem 3)

Overview. This proof uses games G0 through G3 in Fig. 23. We establish the following claims.

◦ AdvIUF
SP,pred
suf-except-group (AIUF-of-SP ) = Pr[G0 ] ◦ Pr[G3 ] = 0
Pr[badG00 ] ≤ AdvSUFCMA
trivial
◦ Pr[G0 ] − Pr[G1 ] ≤ Pr[badG00 ] ◦ DS (ASUFCMA )
◦ Pr[G1 ] − Pr[G2 ] ≤ Pr[badG11 ] ◦ Pr[badG11 ] ≤ AdvCR
H (ACR )

◦ Pr[G2 ] − Pr[G3 ] ≤ Pr[badG22 ] ◦ Pr[badG22 ] = 0

39
 Games G0 –G3 VerDec(g, u, n, c, ad) // ad = ε
U,G,SigEnc,VerDec
AIUF-of-SP ; Return win require K[g] ̸= ⊥ and vk[u] ̸= ⊥ and u ∈ members[g]
me ← NE.Dec(K[g], n, c)
SigEnc(g, u, n, m, ad) // ad = ε
If me = ⊥ then return ⊥
require K[g] ̸= ⊥ and sk[u] ̸= ⊥ and u ∈ members[g] s ∥ m ← m // s.t. |s| = DS.sl, |m| ≥ 0
e
h ← H(m) ; ms ← “Keybase-Chat-2” ∥ ⟨K[g], n, h⟩ h ← H(m) ; ms ← “Keybase-Chat-2” ∥ ⟨K[g], n, h⟩
s ← DS.Sig(sk[u], ms ) ; T [u, ms , s] ← m If ¬DS.Ver(vk[u], ms , s) then return ⊥
me ← s ∥ m ; c ← NE.Enc(K[g], n, me ) If ∃g ′ : ((g ′ , u, n, m, ad), c) ∈ C then return m
C ← C ∪ {((g, u, n, m, ad), c)} ; Return c If ¬user is corrupt[u] then
NewHonUser(u) If T [u, ms , s] = ⊥ then
NewHonGroup(g, users) bad0 ← true // ASUFCMA breaks SUFCMA of DS.
ExposeUser(u) win ← true // G[0,1)
ExposeGroup(g) Else
NewCorrUser(u, sk, vk) If T [u, ms , s] ̸= m then
bad1 ← true // ACR breaks CR of H.
NewCorrGroup(g, K, users)
win ← true // G[0,2)
// These oracles are identical to the corresponding
Else // T [u, ms , s] = m
// oracles in the IUF game for SP as per Fig. 7.
bad2 ← true // Contradicts the tidiness of NE.
win ← true // G[0,3)
Return m
Adversary AU,Sign
SUFCMA SimVerDec(g, u, n, c, ad) // ad = ε
ASimU,SimG,SimSigEnc,SimVerDec
IUF-of-SP
require K[g] ̸= ⊥ and vk[u] ̸= ⊥ and u ∈ members[g]
me ← NE.Dec(K[g], n, c)
SimSigEnc(g, u, n, m, ad) // ad = ε
If me = ⊥ then return ⊥
require K[g] ̸= ⊥ and sk[u] ̸= ⊥ and u ∈ members[g] s ∥ m ← me // s.t. |s| = DS.sl, |m| ≥ 0
h ← H(m) ; ms ← “Keybase-Chat-2” ∥ ⟨K[g], n, h⟩ h ← H(m) ; ms ← “Keybase-Chat-2” ∥ ⟨K[g], n, h⟩
s ← Sign(u, ms ) ; T [u, ms , s] ← m If ¬DS.Ver(vk[u], ms , s) then return ⊥
me ← s ∥ m ; c ← NE.Enc(K[g], n, me ) If ∃g ′ : ((g ′ , u, n, m, ad), c) ∈ C then return m
C ← C ∪ {((g, u, n, m, ad), c)} ; Return c If ¬user is corrupt[u] then
SimNewHonGroup(g, users) If T [u, ms , s] = ⊥ then
SimExposeGroup(g) z ← (u, ms , s)
SimNewCorrGroup(g, K, users) abort(z)
// These oracles are identical to the corresponding Return m
// oracles in the IUF game for SP as per Fig. 7.

SimNewHonUser(u) SimExposeUser(u) SimNewCorrUser(u, sk, vk)

require sk[u] = vk[u] = ⊥ require sk[u] ̸= ⊥ require sk[u] = vk[u] = ⊥
sk[u] ← “dummy” user is corrupt[u] ← true user is corrupt[u] ← true
vk[u] ← NewHonUser(u) sk[u] ← ExposeUser(u) NewCorrUser(u, sk, vk)
Return vk[u] Return sk[u] sk[u] ← sk ; vk[u] ← vk

Fig. 23: Top pane: Games G0 –G3 for the proof of Theorem 3. The code highlighted in gray was added
by expanding the symmetric signcryption algorithms SP.SigEnc, SP.VerDec and the ciphertext-triviality
predicate predsuf-except-group
trivial
IUF
in game GSP,pred suf-except-group (AIUF-of-SP ). The code added for the transitions be-
trivial
tween games is highlighted in green. Bottom pane: Adversary ASUFCMA for the proof of Theorem 3. The
highlighted instructions mark the changes in the code of the simulated game G0 .

By combining the above, we have

2
X
AdvIUF
SP,predsuf-except-group
(AIUF-of-SP ) = Pr[G0 ] = (Pr[Gi ] − Pr[Gi+1 ]) + Pr[G3 ]
trivial
i=0
2
X G
≤ Pr[badi i ] + Pr[G3 ]
i=0

≤ AdvSUFCMA
DS (ASUFCMA ) + AdvCR
H (ACR ).

40
We justify our claims in the following paragraphs.
IUF
Game G0 . Game G0 is functionally equivalent to game GSP,predsuf-except-group . The former expands multiple
trivial
instructions in the latter; the expanded code is marked in gray. Game G0 also contains newly added code
that is highlighted in green and does not affect its functionality; this code will be used for transitions
between games. In particular, the if-then-else statement that was added in oracle VerDec sets the win
flag in each of its conditional branches. It follows that
AdvIUF
SP,predsuf-except-group
(AIUF-of-SP ) = Pr[G0 ].
trivial

Transitions from G0 to G3 . Let i ∈ {0, 1, 2}. Games Gi and Gi+1 are identical until badi is set, therefore
G
Pr[Gi ] − Pr[Gi+1 ] ≤ Pr[badi i ].
Each of these transitions removes an instruction that sets the win flag. The win flag can no longer be set
in game G3 , making it impossible for AIUF-of-SP to win. We have
Pr[G3 ] = 0.

G
Bounding Pr[bad00 ]. In Fig. 23 we build an adversary ASUFCMA against the SUFCMA security of DS.
It perfectly simulates game G0 for adversary AIUF-of-SP until the bad0 flag is set. Adversary ASUFCMA
responds to AIUF-of-SP ’s user-oracle queries using its own user oracles, and it simulates group oracles by
sampling and maintaining group keys locally. While simulating the SigEnc oracle, it substitutes calls
to the signing algorithm DS.Sig with its signing oracle Sign. Whenever bad0 is set, adversary ASUFCMA
halts the simulation and returns (u, ms , s) as the forgery in its own game. Note that in any VerDec
query that sets bad0 , the following conditions must be satisfied: DS.Ver(vk[u], ms , s), ¬user is corrupt[u],
and T [u, ms , s] = ⊥. These are equivalent to the three conditions that are necessary to win in the
unforgeability game against DS. We have
G
Pr[bad00 ] ≤ AdvSUFCMA
DS (ASUFCMA ).

G G
Bounding Pr[bad11 ]. In order to upper-bound Pr[bad11 ], consider an adversary ACR against the collision
resistance of H that is defined as follows. Adversary ACR perfectly simulates game G1 for AIUF-of-SP until
the bad1 flag is set. To simulate the user oracles U and the group oracles G, adversary ACR itself samples
and maintains all user keys and group keys. Whenever the bad1 flag is set in VerDec, adversary ACR
returns a pair of strings (T [u, ms , s], m). Note that immediately before setting bad1 , game G1 verifies that
the table entry T [u, ms , s] is not empty and that the two strings are distinct. We now show that these
strings also produce the same hash value. First, observe that the table T is filled by oracle SigEnc. For
any string assigned to the table entry T [u, ms , s], we know that h = H(T [u, ms , s]) is true for the hash
value h that is encoded in ms . But while reconstructing the value of ms in the current VerDec call, the
same hash must have been obtained upon evaluating h ← H(m). So the strings returned by ACR produce
a collision. It follows that
G
Pr[bad11 ] ≤ AdvCR
H (ACR ).

G
Bounding Pr[bad22 ]. Consider a VerDec query (g, u, n, c, ε) that sets bad2 in game G2 . Immediately
prior to setting bad2 , game G2 verifies that T [u, ms , s] = m for ms = “Keybase-Chat-2” ∥ ⟨K[g], n, h⟩ that
was obtained during the current VerDec call. Since the table T is only populated inside SigEnc, it
follows that the SigEnc oracle was previously queried with (g ′ , u, n, m, ε) as input, for some g ′ satisfying
K[g ′ ] = K[g]. In that SigEnc query, let the output of NE.Enc be c′ . Then ((g ′ , u, n, m, ε), c′ ) ∈ C. However,
the VerDec oracle in game G2 also requires that ̸ ∃g ′ : ((g ′ , u, n, m, ε), c) ∈ C before the bad2 flag could
be set. This is only possible if adversary AIUF-of-SP was able to find a distinct NE ciphertext c ̸= c′
that decrypts to the same value as c′ . By combining the information we deduced about the SigEnc
and VerDec queries above, we have NE.Enc(K[g], n, NE.Dec(K[g], n, c, ε), ε) ̸= c′ . This contradicts the
assumed tidiness property of NE, therefore
G
Pr[bad22 ] = 0.

41
C Analysis and Proofs for the Out-Group AE Security of Keybase

C.1 M-sparsity of Ed25519

In Section 6.3 we defined the M-SPARSE security of a digital signature scheme for an arbitrary set
M ⊆ {0, 1}∗ . In this section, we reduce the M-SPARSE security of Ed25519 for any sufficiently small
M. To do so, we first introduce and analyze two definitions. The first is Discrete Logarithm with Prefix
Matching (DL-PM), which is a variant of the Discrete Logarithm (DL) assumption. We verify the DL-PM
assumption in the generic group model. The second is Impersonation with Prefix Matching (IMP-PM),
which is a new security definition for identification schemes. Intuitively, IMP-PM captures an adversary’s
inability to generate a conversation transcript in which the commitment contains a predefined prefix
such that an honest verifier would accept the transcript even if the adversary is allowed to choose the
verification key used by the verifier. We prove that the IMP-PM security of the identification scheme
underlying Ed25519 is implied by the hardness of the DL-PM assumption in the underlying prime-order
group. We then use this result to prove that Ed25519 achieves SPARSE security. We introduce these
definitions with a particular focus on their relevance to our analysis of Keybase. Our primary intention
is not to present these definitions as stand-alone concepts of independent interest but rather to use them
as tools essential for our examination of Keybase’s SEAL-PACKET-SS scheme.
Notation and Conventions. For any positive integer n ∈ N \ {0}, we let [n] = {1, 2, . . . , n}. We use
G to denote a group. We use the additive notation to write group operations and use 0G to denote the
identity element of G. We assume that the membership test is efficiently computable in G for all groups
we consider. Wherever specified, we let the elements of G be represented as k-bit strings where k is a
positive integer. For a cyclic group Gp of order p with a generator B, the discrete logarithm of an element
X ∈ Gp is the value x ∈ Zp such that xB = X.

Game GGDL-PM
p ,M
IMP-PM
(ADL-PM ) Game GID,M (AIMP-PM )
(r, R, γ) ←$ ADL-PM (vk, com, st) ←$ AIMP-PM
win0 ← (R = rB) ch ←$ ID.V1
win1 ← (R ∥ γ ∈ M) (rsp, γ) ←$ AIMP-PM (ch, st)
Return win0 and win1 win0 ← ID.V2 (vk, com, ch, rsp)
win1 ← (com ∥ γ ∈ M)
Return win0 and win1

Fig. 24: Left pane: Game defining the discrete logarithm with prefix matching security of a group Gp
with respect to a message space M. Right pane: Game defining the impersonation with prefix matching
security of an identification scheme ID with respect to a message space M.

The DL-PM Assumption for Gp . Let Gp be a cyclic group of order p, and let B ∈ Gp be its generator.
Consider game G DL-PM of Fig. 24, defined for Gp , a set M ⊆ {0, 1}∗ , and an adversary ADL-PM . The ad-
vantage of ADL-PM against the DL-PM security of Gp with respect to M is defined as AdvDL-PM Gp ,M (ADL-PM ) =
Pr[GGDL-PM
p ,M
(ADL-PM )]. The adversary wins if it finds a tuple (r, R, γ) such that r is the discrete logarithm
of R and R ∥ γ ∈ M. We prove the hardness of DL-PM in the generic group model for sufficiently small
M.
Identification Schemes. An identification scheme ID is an interactive protocol involving two parties,
the prover and the verifier. The prover is instantiated with a secret key sk that it uses to send the
first message called a commitment. The verifier, instantiated with a public key vk, then samples and
sends a random challenge. Lastly, the prover sends a response to the verifier’s challenge. The verifier
uses vk and the conversation transcript to accept or reject the conversation. Formally, ID specifies three
algorithms ID.Kg, ID.P = (P1 , P2 ), and ID.V = (V1 , V2 ). Associated to every instance of ID is a challenge
set ChalSet. The key generation algorithm ID.Kg returns a secret key sk and a public verification key vk.

42
The prover ID.P is a pair of algorithms ID.P1 and ID.P2 . The commitment algorithm ID.P1 takes sk as
input and returns a commitment com and some state st. The deterministic response algorithm ID.P2 takes
a challenge ch ∈ ChalSet sent by the verifier ID.V1 and a state st, and returns a response rsp to send to
the verifier ID.V2 . The verifier ID.V is a pair of algorithms ID.V1 and ID.V2 . The algorithm ID.V1 samples
and returns a random challenge ch ∈ ChalSet. The deterministic verification algorithm ID.V2 takes the
tuple (vk, com, ch, rsp) as input and returns true if it accepts the conversation, and false otherwise.
IMP-PM
The IMP-PM Security of ID. The IMP-PM game GID,M for an identification scheme ID, a message
space M, and an adversary AIMP-PM is shown in Fig. 24. The advantage of AIMP-PM against the IMP-PM
security of ID is given by AdvIMP-PM IMP-PM
ID,M (AIMP-PM ) = Pr[GID,M (AIMP-PM )]. The adversary AIMP-PM is run
twice over the course of the game. Its first execution is at the beginning of the game after which it returns
the tuple (vk, com, st). The game then proceeds to sample the challenge ch using ID.V1 . Subsequently,
the adversary is run once again on input (ch, st). Its final output is (rsp, γ). The adversary wins if
ID.V2 (vk, com, ch, rsp) = true and com ∥ γ ∈ M.
SPARSE Security of the Ed25519 Signature Scheme.
Construction 6. Let k = 256 and prime p ≈ 2252 . Let G be a group whose elements are encoded as k-bit
strings. Let Gp be the cyclic subgroup of G whose order is p and generator is B. Let H1 = H2 = H3 =
SHA-512. Then Ed25519-DS[k, p, G, Gp , B, H1 , H2 , H3 ] is the signature scheme as defined in Fig. 25 with
Ed25519-DS.skl = 256 and Ed25519-DS.sl = 512.

Ed25519.Kg Ed25519.Sig(sk, m) Ed25519.Ver(vk, m, s)

sk ←$ {0, 1}k // k = 256 e1 ∥ e2 ← H1 (sk) R ∥ z ← s // |R| = |z| = 256
Pk−3 i
e1 ∥ e2 ← H1 (sk) // H1 = SHA-512 t ← 2k−2 + i=3 2 · e1 [i] A ← vk
// |e1 | = |e2 | = 256 a ← t mod p If z ≥ p then return false
t ← 2k−2 + k−3 i
If R ̸∈ Gp or A ̸∈ G then return false
P
i=3 2 · e1 [i] r ← H2 (e2 , m) // H2 = SHA-512
a ← t mod p // p ≈ 2252 R ← rB ; A ← aB ch ← H3 (R, A, m)
vk ← aB ch ← H3 (R, A, m) // H3 = SHA-512 Return z · B = R + ch · A
Return (sk, vk) z ← (r + ch · a) mod p
s ← R∥z
Return s

Fig. 25: The Ed25519 signature scheme.

Proposition 5 (IMP-PMEdID ⇒ SPARSEEd25519 ). Let Ed25519 = Ed25519-DS[k, p, G, Gp , B, H1 , H2 , H3 ]

be the digital signature scheme built from k, p, G, Gp , B, H1 , H2 , H3 as specified in Construction 6. Let
M be a message space that does not depend on H3 . Let ASPARSE be any adversary against the M-SPARSE
security of Ed25519. Let H3 be modeled as a random oracle and qH be the number of random oracle queries
that ASPARSE makes. Then we build an adversary AIMP-PM such that
AdvSPARSE IMP-PM
Ed25519,M (ASPARSE ) ≤ (qH + 1) · AdvEdID,M (AIMP-PM ).

SPARSE
Proof. We begin with the game GEd25519,M in Fig. 26. The hash function H3 in Fig. 27 is implicitly used
as H3 (·) mod p. So we use the indifferentiability results of Bellare, Davis, and Di [BDD23] to model H3
as a random oracle. We have
SPARSE
Pr[GEd25519,M (ASPARSE )] = AdvSPARSE
Ed25519,M (ASPARSE ).
In Fig. 26 we build an adversary AIMP-PM against the IMP-PM security of EdID that perfectly simulates
SPARSE
the game GEd25519,M for ASPARSE . The adversary AIMP-PM guesses the random oracle query i for which
ASPARSE will ultimately attempt a forgery. Note that ASPARSE may attempt a forgery on values that it
never queried to the random oracle. So AIMP-PM makes a call to the random oracle after ASPARSE has
attempted to forge a signature. Therefore i ∈ [qH + 1]. For every query j ∈ [qH + 1] such that j ̸= i,

43
 SPARSE
GEd25519,M H(x) AIMP-PM SimH(x)
(vk, m, s, γ)←$ AH
SPARSE If H[x] = ⊥ then i ←$ [qH + 1] ; j ← 0 If H[x] ̸= ⊥ then return H[x]
R ∥ z ← s ; A ← vk X ←$ Zp (vk, m, s, γ) ←$ ASimH
SPARSE j =j+1
If z ≥ p then return ⊥ H[x] ← X (R ∥ z) ← s If j = i then
If R ̸∈ Gp or A ̸∈ G then return false Return H[x] x ← (R, vk, m) (R, A, m) ← x
ch ← H(R, A, m) SimH(x) R∗ ← R ; A∗ ← A
If z · B = R + ch · A then Return (R, z ∥ γ) ch∗ ← output(A∗ , R∗ )
win0 ← true H[x] ← ch∗
win1 ← (s ∥ γ ∈ M) Return ch∗
Return win0 and win1 X ←$ Zp
H[x] ← X
Return H[x]

Fig. 26: Left pane: The game used in the proof of Proposition 5. Right pane: The adversary AIMP-PM
used in the proof of Proposition 5. The function output is described in the text below.

AIMP-PM lazily simulates the output of H. For the j = i case, we introduce a new instruction output
which is to be interpreted as follows. When AIMP-PM encounters this instruction during the ith random
oracle query (R∗ , A∗ , m∗ ), it returns the values A∗ , R∗ , and its current state st to its own game. It is then
run on the inputs (ch, st). It uses the state st to resume executing in the context of SimH, assigning ch to
the variable ch∗ . Finally AIMP-PM returns ch as the output of the ith H query. Recall that the challenge
ch in AIMP-PM ’s game is sampled uniformly at random from Zp . Also, note that output is guaranteed to
execute exactly once. So, this change is undetectable for ASPARSE .
At some point, ASPARSE returns the forgery (vk, m, s, γ) where s is of the form R ∥ z. Adversary
AIMP-PM returns (R, z ∥ γ) and wins whenever (vk, R) = (A∗ , R∗ ) and ASPARSE wins. We know that
Pr[(vk, R) = (A∗ , R∗ )] ≥ 1/(qH + 1)
Consider the winning conditions for ASPARSE . We have A∗ ∈ G, R∗ ∈ Gp , z · B = R∗ + ch∗ · A∗ and
s ∥ γ ∈ M all hold. The last condition simplifies to R ∥ (z ∥ γ) ∈ M. These are exactly the same as the
winning conditions for AIMP-PM . Hence,
AdvIMP-PM SPARSE
EdID,M (AIMP-PM ) ≥ 1/(qH + 1) · AdvEd25519,M (ASPARSE )
This concludes the proof.

IMP-PM Security of the ID Scheme Underlying Ed25519.

Construction 7. Let k = 256 and prime p ≈ 2252 . Let G be a group whose elements are encoded as k-bit
strings. Let Gp be the cyclic subgroup of G whose order is p and generator is B. Let H = SHA-512. Then
Ed25519-ID[k, p, G, Gp , B, H] is the identification scheme defined in Fig. 27 with Ed25519-ID.ChalSet = Zp .

Proposition 6 (DL-PMGp ⇒ IMP-PMEdID ). Let EdID = Ed25519-ID[k, p, G, Gp , B, H] be the identifica-

tion protocol built from k, p, G, Gp , B, H as specified in Construction 7. Let AIMP-PM be any adversary
against the IMP-PM security of EdID with respect to the message space M. Then, we build an adversary
ADL-PM such that
q
AdvIMP-PM
EdID,M (AIMP-PM ) ≤ AdvDL-PM
Gp ,M (ADL-PM ) + 1/p.

IMP-PM
Proof. We start with the game GEdID,M in Fig. 28. We have
Pr[G (AIMP-PM )] = AdvIMP-PM
EdID,M (AIMP-PM ).
IMP-PM
Adversary ADL-PM runs AIMP-PM and simulates the game GEdID,M . At some point, AIMP-PM returns the
tuple (vk, com, st). Then ADL-PM samples a challenge ch0 uniformly at random from Zp and runs AIMP-PM
on the inputs (ch0 , st). Finally, AIMP-PM terminates with output (z0 , γ0 ). Subsequently, ADL-PM resets

44
 EdID.Kg EdID.P1 (sk) EdID.P2 (ch, st)
k
sk ← {0, 1}
$ // k = 256 e1 ∥ e2 ← H(sk) (r, a) ← st
Pk−3 i
e1 ∥ e2 ← H(sk) // H = SHA-512 t ← 2k−2 + i=3 2 · e1 [i] z ← (r + ch · a) mod p
// |e1 | = |e2 | = 256 a ← t mod p ; r ←$ Zp rsp ← z ; Return rsp
t ← 2k−2 + k−3 i
P
i=3 2 · e1 [i] st ← (r, a) EdID.V2 (vk, com, ch, rsp)
a ← t mod p // p ≈ 2252 R ← rB ; com ← R
If com ̸∈ Gp or vk ̸∈ G then return false
vk ← aB Return (com, st)
R ← com ; A ← vk ; z ← rsp
Return (sk, vk) EdID.V1 () Return z · B = R + ch · A
ch ←$ Zp
Return ch

Fig. 27: The identification protocol EdID for the proof of Proposition 6.

IMP-PM
GEdID,M Adversary ADL-PM
(vk, com, st) ← AIMP-PM
$ (vk, com, st) ←$ AIMP-PM
ch ←$ Zp If com ̸∈ Gp or vk ̸∈ G then
(rsp, γ) ←$ AIMP-PM (ch, st) Return (1, B, ε)
If com ̸∈ Gp or vk ̸∈ G then return false ch0 ←$ Zp
R ← com ; A ← vk ; z ← rsp (z0 , γ0 ) ←$ AIMP-PM (ch0 , st)
Return z · B = R + ch · A and R ∥ γ ∈ M ch1 ←$ Zp
(z1 , γ1 ) ←$ AIMP-PM (ch1 , st)
(Q + T ) ← vk // Q ∈ Gp ; T ∈ Gt
R ← com
If ch0 ̸= ch1 then
If z0 · B = R + ch0 · Q and z1 · B = R + ch1 · Q then
If R ∥ γ0 ∈ M and R ∥ γ1 ∈ M then
r ← z0 − ch0 · (z0 − z1 )(ch0 − ch1 )−1 mod p
Return (r, R, γ0 )
Return (1, B, ε)

Fig. 28: Left pane: The security game used in the proof of Proposition 6. We use gray highlighting to show
code from EdID. Right pane: Adversary ADL-PM used in the proof of Proposition 6. The interpretation
of the line highlighted green is explained in the text below.

AIMP-PM ’s state back to the point just after when it had returned (vk, com, st), chooses a new random
challenge ch1 and sends it to AIMP-PM . The adversary AIMP-PM returns another response (z1 , γ1 ).
To explain the step (Q + T ) ← vk, we present some details about the group G underlying EdID. The
group G satisfies n = 8 · p = 23 · p where n is the order of G. Using Kronecker’s decomposition theorem
we have that in addition to the prime order subgroup Gp , the group G contains another subgroup Gt
of order 8 such that the group G is the direct product of Gp and Gt , i.e., G = Gp × Gt . This means
that every element X ∈ G can be uniquely written as Q + T for Q ∈ Gp and T ∈ Gt . We call Gt the
torsion subgroup of G, and T the torsion component of X. Consider the check z · B = R + ch · A. This is
equivalent to z · B − R = ch · A which is in turn equivalent to z · B − R = ch(Q + T ). By the time this
check is performed by ADL-PM , we know that z · B − R ∈ Gp . For equality to hold, ch(Q + T ) ∈ Gp must
be true. This can only happen if T = 0G . Therefore, z · B − R = ch · A =⇒ z · B − R = ch · Q.
Let E be the event that all three conditional statements in Fig. 28 evaluate to true i.e. ch0 ̸= ch1 ,
z0 ·B = R+ch0 ·Q, z1 ·B = R+ch1 ·Q, and R ∥ γi ∈ M for i ∈ {0, 1} all hold simultaneously. Whenever the
event E occurs, ADL-PM computes the discrete log r of R by solving the system of equations z0 = r +ch0 ·q
and z1 = r + ch1 · q, returns (r, R, γ0 ) and wins its game. It follows that
AdvDL-PM
Gp ,M (ADL-PM ) ≥ Pr[E].
We use the Reset Lemma [BP02] to bound Pr[E]. The Reset Lemma upper-bounds the advantage
of a dishonest prover (AIMP-PM ) as a function of the probability that the prover produces two accepting

45
responses in an experiment that resets it as
p
AdvIMP-PM
EdID,M (AIMP-PM ) ≤ 1/ |ChalSet| + Pr[E]
where ChalSet is the set from which the verifier samples challenges. In our case ChalSet = Zp . Combining
the probabilities above we get
q
AdvIMP-PM
EdID,M (AIMP-PM ) ≤ AdvDL-PM
Gp ,M (ADL-PM ) + 1/p.

This concludes the proof.

Shoup’s Generic Group Model. We analyze the DL-PM security of Gp in Shoup’s generic group model
which uses a random injective map σ : Zp → S for some set of strings S and thinks of the string σ(x) as
the representation of the group element xB. It gives the adversary access to two oracles, the generator
exponentiation oracle Exp and the group operation oracle Op. On input x, the Exp oracle returns σ(x)
which is the representation of xB. On input (a, b, X, Y ), the Op oracle returns the representation of
aX + bY if X and Y are valid string representations of group elements and returns ⊥ otherwise.
DL-PM in Shoup’s Generic Group Model.
ν ∈ {0, 1}∗ where pre is the 17-byte prefix defined

Proposition 7. Let S = {0, 1}k . Let M = pre ∥ ν
in Section 6.3. Let ADL-PM be any adversary against the DL-PM security of Gp with respect to M, making
at most qExp and qOp queries to its Exp and Op oracles respectively. Then we show that
AdvDL-PM
Gp ,M (ADL-PM ) ≤ ((qExp + qOp + 2) · (2
k−|pre|
+ qExp + 2 · qOp + 2))/2k + (qExp + qOp + 2)2 /p.

Overview. This proof uses games G0 through G4 in Fig. 29 and Fig. 30. We establish the following claims.

◦ AdvDL-PM
Gp ,pre (ADL-PM ) = Pr[G0 ] ◦ Pr[G2 ] = Pr[G3 ]
◦ Pr[G0 ] = Pr[G1 ] ◦ Pr[G3 ] − Pr[G4 ] ≤ Pr[badG13 ]
◦ Pr[G1 ] − Pr[G2 ] ≤ Pr[badG01 ] ◦ Pr[badG13 ] ≤ (qExp + qOp + 2)2 /p
◦ Pr[badG01 ] ≤ ((qExp + qOp + 2) · (2k−|pre| + qExp + 2 · qOp + 2))/2k ◦ Pr[G4 ] = 0

By combining the above, we have

DL-PM
AdvGp ,pre
(ADL-PM ) = Pr[G0 ] = Pr[G1 ] = (Pr[G1 ] − Pr[G2 ]) + Pr[G2 ]
G G
≤ Pr[bad01 ] + Pr[G3 ] ≤ Pr[bad01 ] + (Pr[G3 ] − Pr[G4 ]) + Pr[G4 ]
G G
≤ Pr[bad01 ] + Pr[bad14 ]
≤ ((qExp + qOp ) · (2k−|pre| + qExp + 2 · qOp ))/2k + (qExp + qOp + 2)2 /p.
We justify our claims in the following paragraphs.
Game G0 . We start with the game G0 in Fig. 29. The game G0 is a modified version of the game GGDL-PM
p ,M
shown in Fig. 24. We use the notation Φ(Zp , S) to denote the set of all injections with domain Zp and
range S. The game G0 replaces the check R ∥ γ ∈ M of GGDL-PM
p ,M
with the check R ∈ M. Recall that the
length of the prefix pre used to define M is 136 bits long and that group elements are represented as
256-bit strings. Thus R ∥ γ ∈ M is only possible is R ∈ M. It follows that
M
AdvDL-PM
Gp ,M (ADL-PM ) = Pr[G0 ].

Transition from G0 to G1 . The game G1 performs a lazy simulation of the random injection σ. To do
this the game uses the table T , initially empty, that partially represents σ. Every time the adversary
makes an Exp query on a value x, the oracle lazily samples the output and returns it. Now the adversary
may query Op on inputs (a, b, X, Y ) such that either X or Y is not in Rng(T ). For such queries, the
oracle Op needs to probabilistically decide if they are in Rng(σ). Whenever the oracle decides that a
point X ∈ S does not have a preimage, it remembers that decision by maintaining a set Sreject of rejected
points. The oracle assigns a preimage to X with probability (p − Rng(T ))/(|S| − |Rng(T )| − |Sreject |) by
sampling j ←$ [|S| − Rng(T ) − |Sreject |] and checking if j ≤ p − Rng(T ). We compute this probability as
follows. There are p points in Rng(σ). This means that when a query (a, b, X, Y ) is made to Op such that
X ̸∈ Rng(T ) there are at most p − |Rng(T )| points that the oracle can decide to assign a preimage for.

46
 Game G0 Exp(x)
σ ←$ Φ(Zp , S) Return σ(x)
B ← Exp(1)
Op(a, b, X, Y )
(r, R) ←$ AOp,Exp
DL-PM (B)
win0 ← (R = Exp(r)) If σ −1 (X) ̸= ⊥ and σ −1 (Y ) ̸= ⊥ then
win1 ← (R[1.. |pre|] = pre) Return σ(a · σ −1 (X) + b · σ −1 (Y ))
Return win0 and win1

Fig. 29: Game G0 used in the proof of Proposition 7. We use the notation Φ(Zp , S) to denote the set of
all injections with domain Zp and range S.

The codomain of σ contains |S| points of which |Rng(T )| already have a preimage and |Sreject | have been
rejected. This leaves a total of |S| − |Rng(T )| − |Sreject | points in the codomain. Therefore the probability
that a point X ̸∈ Rng(T ) belongs in Rng(σ) is (p − Rng(T ))/(|S| − |Rng(T ) − |Sreject ||). The table T
perfectly simulates the injection σ. Therefore,
Pr[G0 ] = Pr[G1 ].

Games G1−4 Exp(x) Op(a, b, X, Y )

i←0 If T [x] = ⊥ then For Z ∈ {X, Y } do
B ← Exp(1) If ∃P ∈ Dom(T ) : P(z) = x(z) then // G[3,∞) If Z ̸∈ (Rng(T ) ∪ Sreject ) then
(r, R) ←$ AOp,Exp
DL-PM (B) bad 1 ← true // G [3,∞) j ←$ [|S| − Rng(T ) − |Sreject |]
win0 ← (R = Exp(r)) T [x] ← T [P] // G[3,4) If j ≤ p − Rng(T ) then
win1 ← (R[1.. |pre|] = pre) Return T [x] // G[3,4) i←i+1
Return win0 and win1 T [x] ←$ S \ (Rng(T ) ∪ Sreject ) zi ←$ Zp \ Dom(T ) // G[1,3)
If T [x][1.. |pre|] = pre then T [zi ] ← Z // G[1,3)
bad0 ← true z#»i ←$ Zp \ Dom(T )[ #»
z ] // G[3,∞)
T [x] ←$ S \ (Rng(T ) ∪ Sreject ∪ Spre ) // G[2,∞) T [Zi ] ← Z // G[3,∞)
Return T [x] Else Sreject ← Sreject ∪ {Z}
If ∃x, y : T [x] = X and T [y] = Y then
Return Exp(ax + by)
Return ⊥

Fig. 30: Games G1−4 used in the proof of Proposition 7. We use Spre to denote the set of strings in S that
contain the prefix pre.

Transition from G1 to G2 . Games G1 and G2 are identical until bad0 is set, therefore
G
Pr[G1 ] − Pr[G2 ] ≤ Pr[bad01 ].

G
Bounding Pr[bad01 ]. The bad0 flag is set in G1 if the Exp oracle samples a string containing the prefix
pre from S \ (Rng(T ) ∪ Sreject ). Game G2 adds an instruction that reassigns T [x] to a value that does
G
not contain the prefix pre. We use a counting argument to bound Pr[bad01 ]. Strings in S are k bits long.
We use Spre to denote the set of strings in S that contain the prefix pre. We have |Spre | = 2k−|pre| . Of
these, |(Rng(T ) ∪ Sreject ) ∩ Spre | have either already been added to Rng(T ) or to Sreject during prior Op
queries. The probability that Exp picked one of the remaining 2k−|pre| − |(Rng(T ) ∪ |Sreject |) ∩ Spre | values
is (2k−|pre| − |(Rng(T ) ∪ |Sreject |) ∩ Spre |)/(|S| − |Rng(T )| − |Sreject |). Hence, the probability that a query

47
to Exp set bad0 is bounded by
2k−|pre| − |(Rng(T ) ∪ |Sreject |) ∩ Spre | 2k−|pre|
≤
|S| − |Rng(T )| − |Sreject | |S| − |Rng(T )| − |Sreject |
2k−|pre| + |Rng(T )| + |Sreject | 2k−|pre| + (qExp + qOp + 2) + qOp
≤ k
≤ .
2 2k
Applying a union bound over all Exp queries, we have
G (qExp + qOp + 2) · (2k−|pre| + qExp + 2 · qOp + 2)
Pr[bad01 ] ≤ .
2k
Transition G2 to G3 . In game G2 we update the table T such that it performs a “symbolic” simulation of
the injection σ. Specifically, we introduce indeterminates Zi so the table T is of the form T : Zp [Zi ] → S,
i.e., the domain of T now consists of (linear) polynomials of the form P(Zi ) = αZi + β for α, β ∈ Zp .
Note that the adversary can only make constant polynomial queries directly to Exp. However, it may
indirectly query Exp on a non-constant polynomial via an Op query. Whenever a query Exp(x) is made
in G3 , the oracle checks if ∃P ∈ Dom(T ) : P(z) = x(z) where z is the vector of all zi ∈ Zp sampled so
far. If the conditional evaluates to true, the oracle sets the bad1 flag and sets T [x] to T [P]. This ensures
that games G2 and G3 are identical. It follows that
Pr[G2 ] = Pr[G3 ].

Transition G3 to G4 . Games G3 and G4 are identical until bad1 is set, therefore

G
Pr[G3 ] − Pr[G4 ] ≤ Pr[bad14 ].
Game G3 removes the instruction that assigns T [P] to T [x].
G G
Bounding Pr[bad14 ]. We use the Schwartz-Zippel lemma to bound Pr[bad13 ]. Note that bad1 is only set if
T [x] = ⊥ and ∃P ∈ Dom(T ) : P(z) = x(z). This implies that x ̸= P and x(z) = P(z) or (P − x)(z) = 0.
As P −x is a linear polynomial and z is sampled uniformly at random from Zp , we use the Schwartz-Zippel
lemma to bound the probability that a particular Exp query sets bad1 as Rng(T )/p ≤ (qExp + qOp )/p.
Applying a union bound over all Exp queries, we have
G
Pr[bad14 ] ≤ (qExp + qOp + 2)2 /p.

Bounding Pr[G4 ]. The adversary cannot win G4 . To win, ADL-PM must return a constant polynomial r
and a bitstring R such that R begins with pre and T [r] = R holds at the end of the execution of the
game. This is impossible because values written into T by Exp never begin with pre and Op only writes
to T for non-constant polynomials. Hence,
Pr[G4 ] = 0.

C.2 ΦSP Derives Messages from Hashed NE Keys

In this section, we justify our claim that the key cycle in SealPacket can be viewed as an instance of
deriving the message from a hashed key. Let ΦSP = SIGENC-DER[NE, H, DS, m, n, sk] ∪ ENC-DER[m]
be the message deriving function defined in Construction 5. Then we build functions γ and H for
ΦSP that satisfy Definition 4. The case of ENC-DER[m] is trivial: the corresponding γ is the constant
function that always returns m (regardless of its input H). So we focus on the other case now. Let
ϕ = SIGENC-DER[NE, H, DS, m, n, sk] for any m ∈ {0, 1}∗ , n ∈ {0, 1}NE.nl , and sk ∈ {0, 1}DS.skl . In Key-
base, NE = XSalsa20-Poly1305, H = SHA-512, and DS = Ed25519. We provide the expanded definition of
ϕ in Fig. 31 wherein Gp be the cyclic group underlying the Ed25519 scheme as specified in Construction 6.
In particular, the order of Gp is p, the generator of Gp is B, and the elements of Gp are encoded as 256-bit
strings.
Note that the only lines within the message deriving function ϕ that use the input key K are the ones
that are indicated with a box . Additionaly, we define r and ch to be the outputs of the SHA-512 calls
modulo p. These values were likewise used only modulo p in the function ϕ; we merely made this explicit
in Fig. 31.

48
 We define the function H corresponding to ϕ in Fig. 31. It encapsulates the two SHA-512 mod p
instances within ϕ. In recent work [BDD23] formalized and showed the indifferentiability of SHA-512
reduced modulo a sufficiently large prime p as a part of the broader analysis of the Ed25519 scheme.
If we show that the two SHA-512 mod p instances in ϕ (namely H0 and H1 ) can be modeled as two
independent random oracles, then we can directly apply the result of [BDD23] to prove that H can be
reasonably treated as a random oracle. For this, it would suffice to show that (a) each SHA-512 call takes
inputs of a fixed length, and (b) the input lengths of these SHA-512 calls are distinct. These properties
follow from K, n, h, e2 , R, and A being fixed-length. With this definition of H, we can straightforwardly
build γ such that ϕ = γ(H(K)), where H can be modeled as a random oracle.

ϕ[XSalsa20-Poly1305, SHA-512, Ed25519, m, n, sk](K) H(K, n, h, X)

h ← SHA-512(m) ; ms ← “Keybase-Chat-2” ∥ ⟨K, n, h⟩ require |n| = XSalsa20-Poly1305.nl
e1 ∥ e2 ← SHA-512(sk) // s.t. |e1 | = |e2 | = 256 require |h| = SHA-512.ol
t ← 2k−2 + k−3
P i require |K| = XSalsa20-Poly1305.kl
i=3 2 · e1 [i]
a ← t mod p require |X| ∈ {256, 512}
ms ← “Keybase-Chat-2” ∥ ⟨K, n, h⟩
r ← SHA-512(e2 , ms ) mod p
If |X| = 256 then
R ← rB ; A ← aB
Return H0 (X, ms ) // H0 (·) = SHA-512(·) mod p
ch ← SHA-512(R, A, ms ) mod p Return H1 (X, ms ) // H1 (·) = SHA-512(·) mod p
z ← (r + ch · a) mod p
s ← R∥z
me ← s ∥ m ; Return me

Fig. 31: The function ϕ = SIGENC-DER[NE, H, Ed25519, m, n, sk]. The code highlighted in gray was added
by expanding the signing algorithm Ed25519.Sig (according to its definition in Fig. 25 of Appendix C.1).

Challenges in Modelling H as a Random Oracle. Here we enumerate the subtle issues with claim-
ing that the function H defined above satisfies Definition 4.
First of all, according to Definition 4, the domain of the function H should be {0, 1}XSalsa20-Poly1305.kl
where XSalsa20-Poly1305.kl = 256. However, the functions H0 and H1 in Fig. 31 take inputs of the form
(e2 , ms ) and (R, A, ms ) where |e2 | = |R| = |A| = 256 and |ms | = 1072. This means that the domain D of
H is {0, 1}256 × ({0, 1}1072 ∪ {0, 1}256+1072 ) and its range R is Zp . We fix this in the next subsection by
defining a function F : {0, 1}XSalsa20-Poly1305 → {f |f : D′ → R} where D′ = {0, 1}704 ×({0, 1}256 ∪{0, 1}512 )
such that F (K)(x) = H(K, x). Then we define γ0 corresponding to F such that ϕ = γ0 (F (K)). Since F
is the composition of an injection and a function that can be modeled as a random oracle, F can also be
modeled as a random oracle.
Secondly, we have thus far omitted discussing the two other SHA-512 (not mod p) calls within ϕ.
If we tried to formally reduce security to the indifferentiability result of [BDD23] these extra uses of
SHA-512 require small tweaks to the approach to handle. We provide an overview of these tweaks in the
last subsection of this appendix.
Per-Key Random Oracles. Let D′ = {0, 1}704 × ({0, 1}256 ∪ {0, 1}512 ) and R = Zp . Then we define
the functions F and γ0 as discussed above in Fig. 32. The function F takes an XSalsa20-Poly1305 key
K ∈ {0, 1}XSalsa20-Poly1305.kl as input, and it returns the description of another function f [K] : D′ → R. We
emphasize that the output of F (K) specifies the function f [K] that can itself be evaluated on arbitrary
input tuples (n, h, X). Note that there is domain separation. For K ̸= K ′ , f [K] and f [K ′ ] will never call
SHA-512 mod p on the same inputs. Consequently, (modeling SHA-512 mod p as a random oracle) each
f [K] is independent and random, so F can be viewed as a random oracle. We also define γ0 [m, n, sk]
corresponding to ϕ in Fig. 32. It is straightforward to see that ϕ = SIGENC-DER[NE, H, DS, m, n, sk]
can be expressed as γ0 (F (K)). Except for the nuance we discuss in the next subsection, we have built
the functions H = F and γ = γ0 corresponding to the message deriving function ϕ such that they
satisfy Definition 4.

49
 F (K) // |K| = ℓ γ0 [m, n, sk](f )
Return f [K] h ← SHA-512(m)
Function f [K](n, h, X) e1 ∥ e2 ← SHA-512(sk)
Pk−3 i
t ← 2k−2 + i=3 2 · e1 [i]
require |n| = XSalsa20-Poly1305.nl and |h| = SHA-512.ol
a ← t mod p
ms ← “Keybase-Chat-2” ∥ ⟨K, n, h⟩
r ← f (n, h, e2 )
o ← SHA-512(X, ms ) mod p
R ← rB ; A ← aB
Return o
ch ← f (n, h, (R, A))
z ← (r + ch · a) mod p
s ← R∥z
me ← s ∥ m ; Return me

Fig. 32: Left pane: The function F corresponding to ϕ. Right pane: The function γ0 [m, n, sk] corre-
sponding to ϕ.

Proof Flow from Indifferentiability. As we mentioned earlier, the presence of the two plain (i.e.
not reduced modulo p) SHA-512 calls in ϕ introduces subtleties that require us to tweak our steps so far.
Recall that we want to show that ϕ derives messages from a hashed key and use this property to prove the
KDMAE security of XSalsa20-Poly1305 with respect to ϕ. We now give an overview of the required tweaks
and the overall proof flow that would be required to leverage the indifferentiability results of [BDD23].
In the following game transitions, we start with the game G0 that captures the KDMAE security of
NE = XSalsa20-Poly1305 with respect to the message deriving function ϕ. We sketch intermediate game
transitions to ultimately reach G6 that captures the KDMAE security of XSalsa20-Poly1305 with respect
to the function γ1 (F (.)) where we define γ1 along the way and F is a random oracle.

1. Game G0 . In G0 , AKDMAE internally calls the standard model function SHA-512 and picks ϕ =
SIGENC-DER[XSalsa20-Poly1305, SHA-512, Ed25519, m, n, sk] which runs the standard model calls to
both plain SHA-512 (of the form h ← SHA-512(m) and e1 ||e2 ← SHA-512(sk)) and SHA-512 mod p.
2. Game G1 . In G1 , we replace the function ϕ with its modified version ϕ̃. Unlike the former, the latter
does not invoke plain SHA-512 but instead takes the values h and e1 ||e2 as part of its input. We then
have AKDMAE compute the values h and e1 ||e2 locally by running SHA-512 before its calls to ϕ̃. As
this transition only involves reorganization of logic, G1 is equivalent to G0 .
3. Game G2 . In game G2 , we note that SHA-512 is an MD-based hash function, computed by repeatedly
invoking the compression function sha. We replace all calls to SHA-512 mod p with the MD con-
struction mod p that using the compression function sha inside of adversary and the function ϕ. We
replace all calls to plain SHA-512 with the MD construction using the compression function sha inside
of adversary. So this step does not change the view of the adversary and hence G2 is equivalent to G1 .
4. Game G3 . Now we switch from the standard model to the ideal model and replace all instances
of the compression function sha with the ideal function h. Here we assume that the compression
function sha can be modeled as an idealized compression function. This heuristic step sets us for the
indifferentiability analysis.
5. Game G4 . In game G4 , we use the indifferentiabilty results of [BDD23] to replace the MD mod p
construction (with access to h) used by ϕ̃ with the random oracle H. This changes all other queries
to h (particularly, those internal to AKDMAE that arose from the calls to plain SHA-512) to instead
use a stateful simulator with access to H to simulate h.
6. Game G5 . In this game we embed the code for the simulator from the previous step inside AKDMAE .
So instead of having direct access to the simulator, the adversary runs it as part of its own code.4
This step only constitutes syntactic changes and hence G5 is equivalent to G4 .
4
Incorporating the plain SHA-512 calls into the adversary AKDMAE ’s code in G1 was done as a set up for this
step, where it is important that the simulator is only ever run internally to AKDMAE and not in the message
derivation function. Otherwise we would have issues as the simulator is stateful.

50
 7. Game G6 In our final transition, we replace H and ϕ̃ with F and γ1 (F (·)) respectively. Here F is as
defined in Fig. 32 except SHA-512 mod p is replaced with H and γ1 is the same as γ0 except it does
not make calls to plain SHA-512 and is parameterized by [h, n, e1 ||e2 ]. Thus we have shown that the
message deriving function ϕ derives messages from a hashed key.

C.3 KDMAE for Messages Derived from a Hashed Key (Proof of Proposition 1)

Overview. This proof uses games G0 through G4 in Fig. 33. We establish the following claims.

◦ AdvKDMAE
NE,Φ (AKDMAE ) = 2 · Pr[G0 ] − 1 ◦ Pr[G2 ] ≤ Pr[G3 ]
◦ Pr[G0 ] − Pr[G1 ] ≤ Pr[badG00 ] ◦ Pr[G3 ] ≤ Pr[G4 ] + Pr[badG14 ]
◦ Pr[badG00 ] ≤ qNewHonGroup
2
/2NE.kl+1 ◦ Pr[badG14 ] ≤ AdvKR
NE (AKR )
◦ Pr[G1 ] = Pr[G2 ] ◦ 2 · Pr[G4 ] − 1 ≤ AdvAEAD
NE (AAEAD )

By combining the above, we have

3
!
X
AdvKDMAE
NE,Φ (AKDMAE ) = 2 · Pr[G0 ] − 1 = 2 · (Pr[Gi ] − Pr[Gi+1 ]) + Pr[G4 ] −1
i=0
G G
≤ 2 · (Pr[bad00 ] + Pr[bad14 ] + Pr[G4 ]) − 1
≤ 2
qNewHonGroup /2 NE.kl
+ 2 · AdvKR AEAD
NE (AKR ) + AdvNE (AAEAD ).
We justify our claims in the following paragraphs.
KDMAE
Game G0 . As per Proposition 1, consider game GNE,Φ where Φ derives messages from a hashed key so
every message-deriving function is of the form ϕγ (K[g]) = γ(H(K[g])), where H is modeled as a random
oracle H. We let R denote the random oracle’s range. We rewrite this game in a functionally equivalent
way, obtaining game G0 as our starting point in this proof. The highlighted code in G0 marks the changes
KDMAE
that we introduced while rewriting GNE,Φ . The code highlighted in green is only used for transitions
between games G0 through G4 ; we will explain this code later. The code highlighted in gray introduces the
following changes: (1) it writes ϕb (K[g]) as γb (H(K[g])), (2) it populates and updates the sets Shonest , Sreused
that contain “honest” and “reused” NE keys, and (3) it adds a simulated random oracle Hkey secret that is
meant to be called only on inputs that are keys of honest groups.
We will now explain the meaning of these sets, and justify that they do not alter the functionality of
the initial game. It will follow that
AdvKDMAE
NE,Φ (AKDMAE ) = 2 · Pr[G0 ] − 1.
First, we introduce the set Shonest that contains all honest symmetric keys at any point in time.
Whenever the adversary creates an honest group, the newly sampled key is added to Shonest and whenever
it exposes a group key, the exposed key is removed from Shonest . If the NewHonGroup oracle ever samples
the same symmetric key for two different groups, we set the bad0 flag. Next, we rewrite the random oracle
H such that if it is queried on a (currently) honest key K, it delegates the lazy sampling of the response
to the simulated oracle Hkey secret . Otherwise, it responds by lazily sampling the output itself. Note that H
and Hkey
secret use different tables T0 and T1 for responding to queries. Whenever an honest key is exposed,
on top of removing it from the set Shonest , the game updates the table T0 to be consistent with the table
T1 by setting T0 [K[g]] to Hkey secret (K[g]). Note that a key K is exposed iff T0 [K] ̸= ⊥. If H is called on an
exposed key K, it returns T0 [K]. If AKDMAE queries its NewCorrGroup oracle on inputs (g, K) such
that K[g] = ⊥ and K ∈ Shonest , we call the key K a “reused” key. We maintain a set Sreused of reused keys
and set the bad1 flag whenever a reused key is queried to NewCorrGroup. We require that H answer
a query on a reused key on its own rather than delegating it to the simulated random oracle Hkey secret .
We assume, without loss of generality, that the adversary makes all of its NewHonGroup queries before
making any other queries. Lastly, we add conditional statements in the Enc oracle that result in three
branches. All three branches execute the same line of code that assigns to z the output of H(K[g]). None
KDMAE
of these changes affect the functionality of GNE,Φ .

51
 Games G0 –G4 Enc(g, n, ϕ0 , ϕ1 ) // s.t. ϕb (K[g]) = γb (H(K[g]))
′
b ←$ {0, 1} ; b ←$ AG,Enc,Dec,H
KDMAE
require K[g] ̸= ⊥ and (g, n) ̸∈ N
Return b = b′ require ϕ0 , ϕ1 ∈ Φ and ∥ϕ0 ∥ = ∥ϕ1 ∥
If ϕ0 ̸= ϕ1 then
H(K)
If group is corrupt[g] then return ⊥ else chal[g] ← true
If K ∈ Shonest and K ̸∈ Sreused then If K[g] ∈ Sreused then
bad1 ← true // AKR breaks KR of NE. z ← H(K[g]) // Unreachable in G4 .
Return Hkey
secret (K) // G[0,2) Else
Return Hgroup
secret (group[K]) // G[2,4) If K[g] ∈ Shonest then
If T0 [K] = ⊥ then T0 [K] ←$ R // Only reachable if ¬group is corrupt[g].
Return T0 [K] z ← H(K[g]) // G[0,2)
Hkey
secret (K) z ← Hgroup
secret (g) // G[2,∞)
Else z ← H(K[g]) // Only reachable if group is corrupt[g].
If T1 [K] = ⊥ then T1 [K] ←$ R
mb ← γb (z) ; c ← NE.Enc(K[g], n, mb )
Return T1 [K]
N ← N ∪ {(g, n)} ; C ← C ∪ {(g, n, c)} ; Return c
Hgroup
secret (g) // G[2,∞]
Dec(g, n, c)
If T1 [g] = ⊥ then T1 [g] ←$ R // G[2,∞]
// This oracle is identical to the corresponding
Return T1 [g] // G[2,∞]
// oracle in the KDMAE game for NE as per Fig. 18.

NewHonGroup(g) ExposeGroup(g) NewCorrGroup(g, K)

require K[g] = ⊥ require K[g] ̸= ⊥ and ¬chal[g] require K[g] = ⊥
K[g] ←$ {0, 1}NE.kl group is corrupt[g] ← true group is corrupt[g] ← true
Shonest ← Shonest ∪ {K[g]} Shonest ← Shonest \ {K[g]} If K ∈ Shonest and K ̸∈ Sreused then
If group[K[g]] ̸= ⊥ then If K ̸∈ Sreused then bad1 ← true // AKR breaks KR of NE.
// Birthday bound. T0 [K[g]] ← Hkey
secret (K[g])// G[0,2) Sreused ← Sreused ∪ {K} // G[0,4)
bad0 ← true T0 [K[g]] ← Hgroup
secret (g) // G[2,∞) T0 [K] ← Hkey
secret (K) // G[0,2)
stop(false) // G[1,3) Return K[g] T0 [K] ← Hgroup
secret (group[K]) // G[2,4)
group[K[g]] ← g K[g] ← K
Adversary AG,Enc,Dec,Guess
KR SimEnc(g, n, ϕ0 , ϕ1 ) // s.t. ϕb (K[g]) = γb (H(K[g]))
b ←$ {0, 1} require K[g] ̸= ⊥ and (g, n) ̸∈ N
b′ ←$ ASimG,SimEnc,SimDec,SimH
KDMAE
require ϕ0 , ϕ1 ∈ Φ and ∥ϕ0 ∥ = ∥ϕ1 ∥
If ϕ0 ̸= ϕ1 then
SimH(K)
If group is corrupt[g] then return ⊥ else chal[g] ← true
Guess(K) If ¬group is corrupt[g] then z ← Hgroup
secret (g) else z ← SimH(K[g])
If T0 [K] = ⊥ then T0 [K] ←$ R mb ← γb (z) ; c ← Enc(g, n, mb )
Return T0 [K] N ← N ∪ {(g, n)} ; C ← C ∪ {(g, n, c)} ; Return c
Hgroup
secret (g) SimDec(g, n, c)
If T1 [g] = ⊥ then T1 [g] ←$ R require K[g] ̸= ⊥ and ¬group is corrupt[g] and (g, n, c) ̸∈ C
Return T1 [g] m ← Dec(g, n, c) ; If b = 0 then return ⊥ else return m

SimNewHonGroup(g) SimExposeGroup(g) SimNewCorrGroup(g, K)

require K[g] = ⊥ require K[g] ̸= ⊥ and ¬chal[g] require K[g] = ⊥
K[g] ← “dummy” group is corrupt[g] ← true group is corrupt[g] ← true
NewHonGroup(g) K[g] ← ExposeGroup(g) Guess(K)
T0 [K[g]] ← Hgroup
secret (g) NewCorrGroup(g, K)
Return K[g] K[g] ← K

Fig. 33: Top pane: Games G0 –G4 for the proof of Proposition 1. The code highlighted in gray rewrites
KDMAE
parts of game GNE,Φ (AKDMAE ) in an equivalent way. The code added for the transitions between games
is highlighted in green. Bottom pane: Adversary AKR for the proof of Proposition 1. The highlighted
instructions mark the changes in the code of the simulated game G4 .

52
Transition from G0 to G1 . In game G1 , the NewHonGroup oracle executes the stop(false) instruc-
tion whenever bad0 is set. This instruction immediately halts the game and returns false as its final
output. As the games G0 and G1 are identical-until-bad, we have
G
Pr[G0 ] − Pr[G1 ] ≤ Pr[bad00 ].
G
Bounding Pr[bad00 ]. The probability that bad0 is set in G0 is bounded by the probability that the
NewHonGroup oracle assigns the same key K to two different groups. As keys are sampled uniformly
at random from {0, 1}NE.kl , we can use the birthday bound to get
G 2
Pr[bad00 ] ≤ qNewHonGroup /(2 · 2NE.kl ).

Transition from G1 to G2 . We note that the change introduced in the previous game transition ensures
that ∀K ∈ Shonest \ Sreused , there is a unique mapping between K and the corresponding group identifier
g. Moreover, for every query H(K) for which K ∈ Shonest \ Sreused , the query is relayed to Hkey secret . Now in
G2 we use a new simulated oracle Hgroup secret to respond to all H queries satisfying K ∈ Shonest \ Sreused . In
essence we switch from using Hkey group
secret to using Hsecret . The unique mapping between group identifiers and
keys enables us to make this switch without changing the functionality of G1 . Hence,
Pr[G1 ] = Pr[G2 ].

Transition from G2 to G3 . In game G3 the game no longer aborts when bad0 is set. Note that this
only increases the chances that the adversary wins the game. It follows that
Pr[G2 ] ≤ Pr[G3 ].

Transition from G3 to G4 . In game G4 , the oracles H and NewCorrGroup do not execute any other
instructions in the conditional branches that set the bad1 flag. As games G3 and G4 are identical until
bad1 is set in G4 , we have
G
Pr[G3 ] − Pr[G4 ] ≤ Pr[bad14 ].
G G
Bounding Pr[bad14 ]. To bound Pr[bad14 ], we build an adversary AKR in Fig. 33 that simulates G4 for
AKDMAE . The adversary AKR uses its group oracles G to respond to group oracle queries made by AKDMAE .
The set Sreused is always empty in G4 . So AKR can ignore the conditional that checks if K[g] ∈ Sreused while
simulating the Enc oracle. To simulate the other two conditional branches, AKR uses the group is corrupt
table. Note that K[g] ∈ Shonest iff ¬group is corrupt[g]. It replaces calls to NE.Enc with its Enc oracle and
calls to NE.Dec with its Dec oracle. Finally, AKR guesses every key queried to the random oracle H or
the NewCorrGroup oracle. The bad1 flag is only set in G4 if the adversary queried an honest key to
either the random oracle H or to the NewCorrGroup oracle. By guessing such a key, AKR wins its
game. Thus,
G
Pr[bad14 ] ≤ AdvKR
NE (AKR ).

Bounding Pr[G4 ]. We build an adversary AAEAD in Fig. 34 that perfectly simulates game G4 for AKDMAE
and wins whenever AKDMAE does. It uses its group oracles G to simulate responses to group oracle queries
made by AKDMAE and its oracles Enc and Dec to simulate the corresponding oracles in G4 . Therefore,
2 · Pr[G4 ] − 1 ≤ AdvAEAD
NE (AAEAD ).

C.4 Out-Group AE Security of BoxMessage (Proof of Theorem 4)

Overview. This proof uses games G0 through G3 in Fig. 35. We establish the following claims.

◦ AdvOAE
BM,predsuf ,funcsec
(AbwOAE-of-BM ) = 2 · Pr[G0 ] − 1 ◦ Pr[G2 ] − Pr[G3 ] ≤ Pr[badG12 ]
trivial out
◦ Pr[G0 ] = Pr[G1 ] ◦ Pr[badG12 ] = 0
◦ Pr[G1 ] − Pr[G2 ] ≤ Pr[badG01 ] ◦ 2 · Pr[G3 ] − 1 ≤ AdvOAE
SP,pred
suf-except-user
,func⊥
(AwOAE-of-SP )
trivial out
◦ Pr[badG01 ] ≤ AdvCR
H (ACR )

53
 Adversary AG,Enc,Dec
AEAD SimEnc(g, n, ϕ0 , ϕ1 ) // s.t. ϕb (K[g]) = γb (H(K[g]))
′
b ← $ ASimG,SimEnc,SimDec,SimH
KDMAE
require K[g] ̸= ⊥ and (g, n) ̸∈ N
′
Return b require ϕ0 , ϕ1 ∈ Φ and ∥ϕ0 ∥ = ∥ϕ1 ∥
If ϕ0 ̸= ϕ1 then
SimH(K)
If group is corrupt[g] then return ⊥ else chal[g] ← true
If T0 [K] = ⊥ then T0 [K] ←$ R If ¬group is corrupt[g] then z ← Hgroup (g) else z ← SimH(K[g])
secret
Return T0 [K] If ϕ0 ̸= ϕ1 then
Hgroup
secret (g) m0 ← γ0 (z) ; m1 ← γ1 (z) ; c ← Enc(g, n, m0 , m1 )
If T1 [g] = ⊥ then T1 [g] ←$ R Else
Return T1 [g] m ← γ0 (z) ; c ← Enc(g, n, m, m)
N ← N ∪ {(g, n)} ; C ← C ∪ {(g, n, c)} ; Return c
SimDec(g, n, c)
require K[g] ̸= ⊥ and ¬group is corrupt[g] and (g, n, c) ̸∈ C
m ← Dec(g, n, c) ; If b = 0 then return ⊥ else return m

SimNewHonGroup(g) SimExposeGroup(g) SimNewCorrGroup(g, K)

require K[g] = ⊥ require K[g] ̸= ⊥ and ¬chal[g] require K[g] = ⊥
K[g] ← “dummy” group is corrupt[g] ← true group is corrupt[g] ← true
NewHonGroup(g) K[g] ← ExposeGroup(g) NewCorrGroup(g, K)
T0 [K[g]] ← Hgroup
secret (g) K[g] ← K
Return K[g]

Fig. 34: Adversary AAEAD for the proof of Proposition 1. The highlighted instructions mark the changes
in the code of the simulated game G4 .

54
Games G0 –G3 VerDec(g, u, n, c, ad)
′ ′
b ←$ {0, 1} ; b ←$ AU,G,SigEnc,VerDec
bwOAE-of-BM ; Return b = b require K[g] ̸= ⊥ and ¬group is corrupt[g]
require vk[u] ̸= ⊥ and u ∈ members[g]
SigEnc(g, u, n, mbody,0 , mbody,1 , ad)
If W [g, u, n, c, ad] ̸= ⊥ then return ⊥ // G[1,∞)
require K[g] ̸= ⊥ and |mbody,0 | = |mbody,1 | (nbody , nheader ) ← n ; (cbody , cheader ) ← c
require sk[u] ̸= ⊥ and u ∈ members[g] mheader ← SP.VerDec(g, K[g], u, vk[u], nheader , cheader , ε)
(nbody , nheader ) ← n ; If nbody = nheader then return ⊥ hbody ← H(nbody ∥ cbody )
If (g, nbody ) ∈ N or (g, nheader ) ∈ N then return ⊥ If mheader ̸= ⟨ad, u, g, hbody ⟩ then return ⊥
If mbody,0 ̸= mbody,1 then mbody ← NE.Dec(K[g], nbody , cbody )
If group is corrupt[g] then return ⊥ else chal[g] ← true If m
body = ⊥ then return ⊥
cbody ← NE.Enc(K[g], nbody , mbody,b ) z ← ((g, u, n, mbody , ad), c) // G[0,1)
hbody ← H(nbody ∥ cbody ) ; mheader ← ⟨ad, u, g, hbody ⟩ If z ∈ C then return ⊥ // G[0,1)
cheader ← SP.SigEnc(g, K[g], u, sk[u], nheader , mheader , ε) If b = 0 then return ⊥
CSP ← CSP ∪ {((g, u, nheader , mheader , ε), cheader )} If ∃u′ : ((g, u′ , nheader , mheader , ε), cheader ) ∈ CSP then
c ← (cbody , cheader ) ; N ← N ∪ {(g, nheader ), (g, nbody )} If (nbody , cbody ) ̸= T [g, nheader ] then
C ← C ∪ {((g, u, n, mbody,b , ad), c)} bad0 ← true // ACR breaks CR of H.
W [g, u, n, c, ad] ← mbody,1 ; T [g, nheader ] ← (nbody , cbody ) Return mbody // G[0,2)
Q ← Q ∪ {((g, u, n, mbody,0 , mbody,1 , ad), c)} ; Return c Return ⊥ // G[2,∞)
NewHonUser(u) Else // (nbody , cbody ) = T [g, nheader ]
NewHonGroup(g, users) bad1 ← true // Unreachable in G2 .
ExposeUser(u) Return mbody // G[0,3)
ExposeGroup(g) Return ⊥ // G[3,∞)
NewCorrUser(u, sk, vk) Else // ̸ ∃u′ : ((g, u′ , nheader , mheader , ε), cheader ) ∈ CSP
bad2 ← true // AwOAE-of-SP breaks OAE[Enc] of SP.
NewCorrGroup(g, K, users)
Return mbody
// These oracles are identical to the corresponding
// oracles in the OAE game for BM as per Fig. 7.
Adversary AU,G,SigEnc,VerDec,Enc
wOAE-of-SP SimVerDec(g, u, n, c, ad)
b′ ←$ ASimU,SimG,SimSigEnc,SimVerDec
bwOAE-of-BM ; Return b′ require K[g] ̸= ⊥ and ¬group is corrupt[g]
require vk[u] ̸= ⊥ and u ∈ members[g]
SimSigEnc(g, u, n, mbody,0 , mbody,1 , ad)
If W [g, u, n, c, ad] ̸= ⊥ then return ⊥
require K[g] ̸= ⊥ and |mbody,0 | = |mbody,1 | (nbody , nheader ) ← n ; (cbody , cheader ) ← c
require sk[u] ̸= ⊥ and u ∈ members[g] mheader ← VerDec(g, u, nheader , cheader , ε)
(nbody , nheader ) ← n ; If nbody = nheader then return ⊥ If mheader ̸= ⊥ then abort(1)
If (g, nbody ) ∈ N or (g, nheader ) ∈ N then return ⊥ Return ⊥
If mbody,0 ̸= mbody,1 then
If group is corrupt[g] then return ⊥ else chal[g] ← true
cbody ← Enc(g, nbody , mbody,0 , mbody,1 )
hbody ← H(nbody ∥ cbody ) ; mheader ← ⟨ad, u, g, hbody ⟩
cheader ← SigEnc(g, u, nheader , mheader , mheader , ε)
c ← (cbody , cheader ) ; N ← N ∪ {(g, nheader ), (g, nbody )}
W [g, u, n, c, ad] ← mbody,1 ; Return c

SimNewHonGroup(g, users) SimExposeGroup(g) SimNewCorrGroup(g, K, users)

require K[g] = ⊥ require K[g] ̸= ⊥ and ¬chal[g] require K[g] = ⊥
K[g] ← “dummy” group is corrupt[g] ← true group is corrupt[g] ← true
NewHonGroup(g) K[g] ← ExposeGroup(g) NewCorrGroup(g, K)
members[g] ← users Return K[g] K[g] ← K ; members[g] ← users
SimNewHonUser(u) SimExposeUser(u) SimNewCorrUser(u, sk, vk)
require sk[u] = vk[u] = ⊥ require sk[u] ̸= ⊥ require sk[u] = vk[u] = ⊥
vk[u] ← NewHonUser(u) Return sk[u] NewCorrUser(u, sk, vk)
sk[u] ← ExposeUser(u) ; Return vk[u] sk[u] ← sk ; vk[u] ← vk

Fig. 35: Top pane: Games G0 –G3 for the proof of Theorem 4. The code highlighted in gray was added by
expanding the symmetric signcryption algorithms BM.SigEnc, BM.VerDec, and the ciphertext-triviality
predicate predsuf OAE
trivial in game GBM,predsuf ,funcsec (AbwOAE-of-BM ). The code added for the transitions between
trivial out
games is highlighted in green. Bottom pane: Adversary AwOAE-of-SP for the proof of Theorem 4. The
highlighted instructions mark the changes in the code of the simulated game G3 .
55
By combining the above, we have
AdvOAE
BM,predsuf sec (AbwOAE-of-BM ) = 2 · Pr[G0 ] − 1 = 2 · Pr[G1 ] − 1
trivial ,funcout
1
!
X
=2· (Pr[Gi+1 ] − Pr[Gi+2 ]) + Pr[G3 ] − 1
i=0
1
!
X Gi+1
=2· (Pr[badi ]) + Pr[G3 ] − 1
i=0

≤2· AdvCR
H (AH ) + AdvOAE
SP,predsuf-except-user ,func⊥
(AwOAE-of-SP ).
trivial out

We justify our claims in the following paragraphs.

OAE
Game G0 . The game G0 is functionally equivalent to GBM,pred suf ,funcsec . Additionally, the former includes
trivial out
code lines highlighted in green that we use for transitions between games. Note that the if-then-else
statement that was added in oracle VerDec returns mbody under all conditional branches. These changes
do not affect the functionality of G0 and we have
AdvOAE
BM,predsuf sec (AbwOAE-of-BM ) = 2 · Pr[G0 ] − 1.
trivial ,funcout

Transition from G0 to G1 . In the game G0 if the adversary forwards an honestly generated ciphertext
from SigEnc to VerDec, then the condition z ∈ C holds and VerDec will always return ⊥. In game
G1 we remove the conditional that checks if z ∈ C from G1 and use the table W instead to achieve
the same behavior without actually having to decrypt forwarded ciphertexts. For every SigEnc query,
the table W indexed by the tuple (g, u, n, c, ad) stores the challenge message mbody,1 where c is the
ciphertext returned for that query. This table W is then used to respond to VerDec queries on trivially
forwarded ciphertexts. Note that the decryption correctness of NE and SP gives W [g, u, n, c, ad] ̸= ⊥ ⇐⇒
((g, u, n, mbody , ad), c) ∈ C i.e. W [g, u, n, c, ad] ̸= ⊥ ⇐⇒ z ∈ C holds in G0 . However, if the condition
W [g, u, n, c, ad] ̸= ⊥ evaluates to true in G0 , the VerDec oracle immediately returns ⊥. This means that
the conditional checking whether z ∈ C is unreachable in G0 , and removing it in G1 does not change the
output of VerDec. It follows that
Pr[G0 ] = Pr[G1 ].

Transitions from game G1 to G3 . Let i ∈ {0, 1}. Games Gi+1 and Gi+2 are identical until badi is set.
Each of these transitions removes an instruction returning mbody and returns ⊥ instead. Therefore
G
Pr[Gi+1 ] − Pr[Gi+2 ] ≤ Pr[badi i+1 ].
G
Bounding Pr[bad01 ]. We describe adversary ACR against the collision resistance of H that simulates game
G1 for AbwOAE-of-BM . Adversary ACR runs the code of G1 by sampling and maintaining all user and group
keys locally. Consider a VerDec query that sets the bad0 flag. During this query VerDec computed
hbody = H(nbody ∥ cbody ). Now, the bad1 flag is only set when ∃u′ : ((g, u′ , nheader , mheader , ε), cheader ) ∈ CSP
and (nbody , cbody ) ̸= T [g, nheader ]. The former implies that there was a prior call to SigEnc during
which SP.SigEnc was invoked on inputs (g, u′ , nheader , mheader , ε) and produced output cheader . Let the
body ciphertext for this query be c′body . We know that for the current VerDec query z ̸∈ C. There-
fore cbody ̸= c′body . Note that the message mheader uniquely encodes hbody = H(nbody ∥ c′body ). By the
uniqueness of (g, nheader ) we know that T [g, nheader ] uniquely maps to the pair (nbody ∥ c′body ). Then we
get hbody = H(nbody ∥ cbody ) = H(nbody ∥ cbody )′ and (nbody , cbody ) ̸= (nbody , c′body ). Therefore, by returning
(nbody ∥ cbody , nbody ∥ c′body ), adversary ACR wins the collision-resistance game of H whenever bad0 is set.
This gives
G
Pr[bad01 ] ≤ AdvCR
H (ACR ).

G
Bounding Pr[bad12 ]. The conditions that set bad1 in G2 are ∃u′ : ((g, u′ , nheader , mheader , ε), cheader ) ∈ CSP
and (nbody , cbody ) = T [g, nheader ]. Since mheader encodes u, we get u′ = u. Then we can infer that
((g, u, nheader , mheader , ε), cheader ) ∈ CSP . This means that there was a prior call to SigEnc during which

56
SP.SigEnc was invoked on inputs (g, u, nheader , mheader , ε) and produced output cheader . By the construction
of m, we know that the values ad and hbody were the same across a prior SigEnc query and the current
VerDec query. The condition (nbody , cbody ) = T [g, nheader ] implies that (nbody , cbody ) were also repeated
across the two queries. Combining the above, we get that the values g, u, n, c, and ad were repeated, and
hence W [g, u, n, c, ad] ̸= ⊥. Therefore it is impossible to set bad1 in G2 and
G
Pr[bad12 ] = 0

Bounding Pr[G3 ]. In Fig. 35 we show adversary AwOAE-of-SP against the OAE security of SP that simulates
the game G3 for adversary AOAE until bad2 is set and wins whenever AOAE does. It simulates the user
oracles using the corresponding oracles from its OAE security game and simulates responses to the group
oracles using its group oracles. While simulating the SigEnc oracle for AOAE , it replaces calls to SP.SigEnc
with its SigEnc oracle and analogously, while simulating VerDec, it substitutes calls to SP.VerDec with
its VerDec oracle. To simulate calls to NE.Enc, adversary AwOAE-of-SP uses its Enc oracle. Finally, if the
bad2 flag is never set and AOAE returns b′ , adversary AwOAE-of-SP also returns b′ . Now consider the case that
bad2 is set in the simulated game. It must be the case that ̸ ∃u′ : ((g, u′ , nheader , mheader , ε), cheader ) ∈ CSP
and mheader ̸= ⊥. This is only possible when AwOAE-of-SP has successfully forged a ciphertext and the bit b
in its game is 1. Therefore AwOAE-of-SP executes abort(1) and wins its game whenever bad2 is set, giving
2 · Pr[G1 ] − 1 ≤ AdvOAE
SP,predsuf-except-user ,func⊥
(AwOAE-of-SP ).
trivial out

C.5 Out-group AE Security of SealPacket (Proof of Theorem 5)

Overview. This proof uses games G0 through G3 in Fig. 36. We establish the following claims.
OAE[Enc]
◦ Adv suf-except-user (AwOAE-of-SP ) = 2 · Pr[G0 ] − 1 ◦ Pr[badG01 ] ≤ AdvSPARSE
DS,M (ASPARSE )
SP,predtrivial ,func⊥
out
◦ Pr[G0 ] = Pr[G1 ] ◦ Pr[G2 ] = Pr[G3 ]
◦ Pr[G1 ] − Pr[G2 ] ≤ Pr[badG01 ] ◦ 2 · Pr[G3 ] − 1 ≤ AdvKDMAE
NE,ΦSP (AAEAD )

By combining the above, we have

wOAE[Enc[M,NE]]
Adv (AwOAE-of-SP ) = 2 · ((Pr[G1 ] − Pr[G2 ]) + Pr[G2 ]) − 1
SP,predsuf-except-user
trivial ,func⊥
out
G
≤ 2 · (Pr[bad01 ] + Pr[G3 ]) − 1
≤ 2 · AdvSPARSE KDMAE
DS,M (ASPARSE ) + AdvNE,ΦSP (AAEAD ).
We justify our claims in the following paragraphs.
Game G0 . We claim that the view of adversary AwOAE-of-SP in game G0 is identical to its view in game
OAE[Enc]
G suf-except-user . We use green highlighting to show code that was added for transitions between
SP,predtrivial ,func⊥
out
games. In particular, we add the set CNE in SigEnc and the set L in Enc. The set CNE stores the tuple
(g, n, c) for every SigEnc query where c is the output of NE.Enc for that query. The set L stores the tuple
(g, nbody , cbody ) for every valid Enc query where cbody is the output of Enc for that query. The latter set
is then used in VerDec to check whether the adversary forwarded a ciphertext returned by Enc. If that
is the case then the bad0 flag is set. This does not affect the functionality of the game. Therefore,
OAE[Enc]
Adv suf-except-user (AwOAE-of-SP ) = 2 · Pr[G0 ] − 1.
SP,predtrivial ,func⊥
out

Transition from G0 to G1 . In game G1 , we use the set CNE in VerDec to check if (g, n, c) ∈ CNE
for a query (g, u, n, c, ad). If the condition is true, the oracle returns ⊥. Now, (g, n, c) ∈ CNE ⇐⇒
∃u′ : ((g, u′ , n, m, ad), c) ∈ C where m is the unsigncryption of c. This implies that (g, n, c) ∈ CNE ⇐⇒
suf-except-user
predtrivial (z, C) = true. By definition of the output-guarding function func⊥ out , the game G0 returns
⊥ whenever predsuf-except-user
trivial (z, C) = true. The game G 1 returns ⊥ whenever (g, n, c) ∈ CNE . Therefore the
outputs of games G0 and G1 are consistent and we have
Pr[G0 ] = Pr[G1 ].

57
Games G0 –G3 VerDec(g, u, n, c, ad) // ad = ε
′ ′
b ←$ {0, 1} ; b ←$ AU,G,SigEnc,VerDec,Enc
wOAE-of-SP ; Return b = b require K[g] ̸= ⊥ and ¬group is corrupt[g]
require vk[u] ̸= ⊥ and u ∈ members[g]
SigEnc(g, u, n, m0 , m1 , ad) // ad = ε
If (g, n, c) ∈ CNE then return ⊥ // G[1,∞)
require K[g] ̸= ⊥ and |m0 | = |m1 | If (g, n, c) ∈ L then return ⊥ // G[3,∞)
require sk[u] ̸= ⊥ and u ∈ members[g] and (g, n) ̸∈ N me ← NE.Dec(K[g], n, c) ; If me = ⊥ then return ⊥
If m0 ̸= m1 then s ∥ m ← me // s.t. |s| = DS.sl, |m| ≥ 0
If group is corrupt[g] then return ⊥ else chal[g] ← true h ← H(m) ; ms ← “Keybase-Chat-2” ∥ ⟨K[g], n, h⟩
h ← H(mb ) ; ms ← “Keybase-Chat-2” ∥ ⟨K[g], n, h⟩ If ¬DS.Ver(vk[u], ms , s) then return ⊥
s ← DS.Sig(sk[u], ms ) ; me ← s ∥ mb z ← ((g, u, n, m, ad), c)
c ← NE.Enc(K[g], n, me ) If ∃u′ : ((g, u′ , n, m, ad), c) ∈ C then return ⊥
CNE ← CNE ∪ {(g, n, c)} ; N ← N ∪ {(g, n)} If (g, n, c) ∈ L then
C ← C ∪ {((g, u, n, mb , ad), c)} ; Return c bad0 ← true // ASPARSE breaks SPARSE of DS.
Enc(g, nbody , mbody,0 , mbody,1 ) Return ⊥ // G[2,∞)
require K[g] ̸= ⊥ and |mbody,0 | = |mbody,1 | If b = 0 then return ⊥ else return m
require (g, nbody ) ̸∈ N and mbody,0 , mbody,1 ∈ M NewHonUser(u)
If mbody,0 ̸= mbody,1 then NewHonGroup(g, users)
If group is corrupt[g] then return ⊥ else chal[g] ← true ExposeUser(u)
cbody ← NE.Enc(K[g], nbody , mbody,b ) ExposeGroup(g)
L ← L ∪ {(g, nbody , cbody )} NewCorrUser(u, sk, vk)
N ← N ∪ {(g, nbody )} ; Return cbody
NewCorrGroup(g, K, users)
// These oracles are identical to the corresponding
// oracles in the OAE game for SP as per Fig. 7.
Adversary AG,Enc,Dec
KDMAE SimVerDec(g, u, n, c, ad) // ad = ε
′ ′
b ←$ ASimU,SimG,SimSigEnc,SimVerDec,SimEnc
wOAE-of-SP ; Return b require K[g] ̸= ⊥ and ¬group is corrupt[g]
require vk[u] ̸= ⊥ and u ∈ members[g]
SimSigEnc(g, u, n, m0 , m1 , ad) // ad = ε
me ← Dec(g, n, c) ; If me = ⊥ then return ⊥
require K[g] ̸= ⊥ and |m0 | = |m1 | abort(1)
require sk[u] ̸= ⊥ and u ∈ members[g] and (g, n) ̸∈ N
If m0 ̸= m1 then SIGENC-DER[NE, H, DS, m, n, sk](K)
If group is corrupt[g] then return ⊥ else chal[g] ← true h ← H(m) ; ms ← “Keybase-Chat-2” ∥ ⟨K, n, h⟩
f0 ← SIGENC-DER[NE, H, DS, m0 , n, sk[u]] s ← DS.Sig(sk, ms ) ; me ← s ∥ m ; Return me
f1 ← SIGENC-DER[NE, H, DS, m1 , n, sk[u]] ENC-DER[m](K)
c ← Enc(g, n, f0 , f1 ) ; N ← N ∪ {(g, n)} ; Return c
Return m
SimEnc(g, nbody , mbody,0 , mbody,1 )
SimNewHonUser(u)
require K[g] ̸= ⊥ and |mbody,0 | = |mbody,1 | SimExposeUser(u)
require (g, nbody ) ̸∈ N and mbody,0 , mbody,1 ∈ M
SimNewCorrUser(u, sk, vk)
If mbody,0 ̸= mbody,1 then
// These oracles are identical to the corresponding
If group is corrupt[g] then return ⊥ else chal[g] ← true
// oracles in the OAE game for SP as per Fig. 7.
f0 ← ENC-DER[mbody,0 ]
f1 ← ENC-DER[mbody,1 ] ; cbody ← Enc(g, nbody , f0 , f1 )
N ← N ∪ {(g, nbody )} ; Return cbody

SimNewHonGroup(g, users) SimExposeGroup(g) SimNewCorrGroup(g, K, users)

require K[g] = ⊥ require K[g] ̸= ⊥ and ¬chal[g] require K[g] = ⊥
K[g] ← “dummy” group is corrupt[g] ← true group is corrupt[g] ← true
NewHonGroup(g) K[g] ← ExposeGroup(g) NewCorrGroup(g, K)
members[g] ← users Return K[g] K[g] ← K ; members[g] ← users

Fig. 36: Top pane: Games G0 –G3 for the proof of Theorem 5. The code highlighted in gray was added by
expanding the symmetric signcryption algorithms SP.SigEnc, SP.VerDec, the ciphertext-triviality predi-
OAE[Enc]
suf-except-user
cate predtrivial , and the output-guarding function func⊥
out in game G suf-except-user ⊥
(AIUF-of-SP ).
SP,predtrivial ,funcout
The code added for the transitions between games is highlighted in green. Bottom pane: Adversary
AKDMAE for the proof of Theorem 5. The highlighted instructions mark the changes in the code of the
simulated game G3 .

58
Transition from G1 to G2 . In game G2 we modify VerDec to return ⊥ whenever bad0 is set. As the
G
games G1 and G2 are identical-until-bad, Pr[G1 ] ≤ Pr[G2 ] + Pr[bad01 ].
G
Bounding Pr[bad01 ]. We bound the probability that bad0 is set in G1 by describing adversary ASPARSE
that perfectly simulates G1 for AwOAE-of-SP . Adversary ASPARSE plays in the SPARSE security game against
DS with respect to the message set M. It simply runs the code for the game G1 by sampling and
maintaining the user and group keys. Whenever the flag bad0 is set on a VerDec query, adversary
ASPARSE returns the corresponding (vk[u], ms , s) and wins its game. Note that the bad0 flag is set when
the output c of a prior Enc query is successfully unsigncrypted by VerDec. The correctness of NE
guarantees that me = NE.Dec(K[g], n, c) is the same as the message previously encrypted by Enc. As
Enc requires that me ∈ M, we have DS.Ver(vk[u], ms , s) = true and s ∥ me ∈ M. These are the same as
the winning conditions in the SPARSE game of DS. Thus
G
Pr[bad01 ] ≤ AdvSPARSE
DS,M (ASPARSE ).

Transition from G2 to G3 . In game G3 , we modify the VerDec oracle. We move the instruction that
checks if (g, n, c) ∈ L to the top of the oracle. This does not change the output of the oracle and we have
Pr[G2 ] = Pr[G3 ].

Bounding Pr[G3 ]. In Fig. 36, we define the adversary AKDMAE that simulates G3 for AwOAE-of-SP . The
reduction simulates responses to group oracle queries by using its own group oracles and simulates the
user oracles by sampling and maintaining keys locally. While simulating the SigEnc oracle, it replaces
calls to NE.Enc with its oracle Enc using the function SIGENC-DER. The function SIGENC-DER executes
exactly the same lines of code that computed me from these parameters in G3 . This means that

Enc(g, n, SIGENC-DER[NE, H, DS, m0 ,n, sk[u]](K), SIGENC-DER[NE, H, DS, m1 , n, sk[u]](K))

=NE.Enc(K, n, me ).

To simulate the encryption oracle Enc, the adversary AKDMAE uses its oracle Enc with the function
ENC-DER. The function ENC-DER is parameterized by a message m and returns m. Note that the output
of Enc(g, nbody , ENC-DER[mbody,0 ](K), ENC-DER[mbody,1 ](K)) is the same as NE.Enc(K, nbody , mbody,b ).
While simulating the VerDec oracle, the reduction replaces calls to NE.Dec with its Dec oracle. Adver-
sary AAEAD wins whenever AwOAE-of-SP does. Therefore,
Pr[G3 ] ≤ AdvKDMAE
NE,ΦSP (AAEAD ).

D Proofs for the Stronger Out-Group AE Security Results

D.1 Proof for the UV Security of StE (Proof of Proposition 2)

Proof. This proof uses the game G in Fig. 37. We establish that AdvUV StE UV DS
StE (AUV ) ≤ AdvDS (AUV ). Game G0 is
UV
equivalent to the game GStE . The former expands multiple instructions in the latter; the expanded code
is marked in gray. Therefore, AdvUV StE
StE (AUV ) = Pr[G0 ].
In Fig. 37 we show adversary ADS UV against the UV security of DS that simulates the game G0 for AUV
StE
′
and wins whenever AStEUV does. Once A StE
UV returns (g, K, u , u, sk u′ , vku , n, m, ad), the reduction constructs
ms = ⟨g, n, m, ad⟩, and returns (sku′ , vku′ , ms ). Note that whenever AStE UV wins, it must be the case
that SS.VerDec(g, K, u′ , vku′ , n, c, ad) ̸= ⊥ and ((sku , vku′ ) ̸∈ [SS.UserKg]). By the correctness of NE
and the construction of StE, this implies that DS.Ver(vku′ , ms , s) and ((sku , vku′ ) ̸∈ [SS.UserKg]) where
ms = ⟨g, n, m, ad⟩. These two are exactly the winning conditions of the UV security game of DS. Therefore,
UV
ADS StE DS
UV wins whenever AUV does and it follows that AdvDS (AUV ) ≥ Pr[G0 ].
For simplicity, we only give the proof of Proposition 2 for SS = StE. However, the adversary ADS UV
of Fig. 37 remains the same for all SS ∈ {StE, EtS, SP} except for the line in the box that constructs the
value ms . For other choices of SS, this line would be replaced as per the construction of the scheme.

59
 G (AStE
UV ) ADS
UV

(g, K, u, u′ , sku , vku′ , n, m, ad) ←$ AU,G,SigEnc,VerDec

UV (g, K, u, u′ , sku , vku′ , n, m, ad) ←$ AU,G,SigEnc,VerDec
UV
// c ← StE.SigEnc(g, K, u, sku , n, m, ad) ms ← ⟨g, n, m, ad⟩
ms ← ⟨g, n, m, ad⟩ Return (sku , vku′ , ms )
s ← DS.Sig(sku , ms )
me ← s ∥ m ; adNE ← ⟨u, ad⟩
c ← NE.Enc(Kg , n, me , adNE )
// win0 ← (StE.VerDec(g, K, u′ , vku′ , n, c, ad) ̸= ⊥)
adNE ← ⟨u′ , ad⟩
me ← NE.Dec(Kg , n, c, adNE )
If me = ⊥ then return win0 ← false
Else
s ∥ m ← me // s.t. |s| = DS.sl, |m| ≥ 0
ms ← ⟨g, n, m, ad⟩
If ¬DS.Ver(vku′ , ms , s) then win0 ← false
Else win0 ← true
win1 ← ((sku , vku′ ) ̸∈ [SS.UserKg])
Return win0 and win1

Fig. 37: The game G and the adversary ADS

UV used in the proof of Proposition 2.

Games G0 –G2 H(x)

′
(sk, vk , m) ←$ AH
UV If H[x] = ⊥ then
s ← Ed25519.Sig(sk, m) X ←$ Zp
R ∥ z ← s ; A′ ← vk′ H[x] ← X
If z ≥ p then return ⊥ (R, A, m) ← x ; ch ← H[x]
If R ̸∈ Gp or A′ ̸∈ G then If ch = 0 then
Return false bad0 ← true
ch′ ← H(R, A′ , m) ch ←$ Zp \ {0} // G[1,∞)
If z · B = R + ch′ · A′ then H[x] ← ch // G[1,∞)
win0 ← true If ∃A′ : T [(R, A′ , m)] = ch · A and A ̸= A′ then // ch′ · A′ = ch · A
win1 ← ((sk, vk′ ) ̸∈ [DS.Kg]) bad1 ← true
Return win0 and win1 While (∃A′ : T [(R, A′ , m)] = ch · A and A ̸= A′ ) or ch · A = 0 do // G[2,∞)
ch ←$ Zp // G[2,∞)
H[x] ← ch // G[2,∞)
T [(R, A, m)] = ch · A
Return H[x]

Fig. 38: Games G0 –G2 used in the proof of Proposition 3.

D.2 Proof for the UV Security of Ed25519 (Proof of Proposition 3)

Proof. Overview. This proof uses games G0 through G2 in Fig. 38. We establish the following claims.
◦ AdvUV
Ed25519 (AUV ) = Pr[G0 ] ◦ Pr[G1 ] − Pr[G2 ] ≤ Pr[badG11 ]
◦ Pr[G0 ] − Pr[G1 ] ≤ Pr[badG00 ] ◦ Pr[G2 ] = 0
◦ Pr[badG00 ] ≤ 2 · qH /p

By combining the above, we have

AdvUV
Ed25519 (AUV ) = Pr[G0 ] = Pr[G0 ] = (Pr[G0 ] − Pr[G1 ]) + Pr[G1 ]
G G
≤ Pr[bad00 ] + Pr[G1 ] ≤ Pr[bad00 ] + (Pr[G1 ] − Pr[G2 ]) + Pr[G2 ]
G G 2
≤ Pr[bad00 ] + Pr[bad11 ] ≤ (2 · qH )/p + qH /p.

60
We justify our claims in the following paragraphs.
UV
Game G0 . The game G0 is functionally equivalent to GEd25519 . We use gray highlighting to show code from
Ed25519. Additionally, G0 includes code lines highlighted in green that we use for transitions between
games. In particular, the random oracle H sets the bad0 flag if the challenge ch sampled for a query
x = (R, A, m) satisfies ch · A = 0. The random oracle H also maintains a dictionary T that stores the
value ch · A corresponding to every query (R, A, m) where ch is the output for that query. It sets the bad1
flag if the booleans ∃A′ : T [(R, A′ , m)] = ch · A and A ̸= A′ evaluate to true for a query (R, A, m). These
changes do not affect the functionality of G0 . It follows that
Pr[G0 ] = AdvUV
Ed25519 (AUV ).

Transitions from G0 to G2 . Let i ∈ {0, 1}. Games Gi and Gi+1 are identical until badi is set, therefore
G
Pr[Gi ] − Pr[Gi+1 ] ≤ Pr[badi i ].

Bounding Pr[bad00 ]. We now compute Pr[bad00 ]. Consider the condition ch · A = 0 that sets the bad0 flag
for an input (R, A, m) in game G0 . Recall that ch is sampled uniformly at random from Zp . Now for a
given A = a · B there are exactly two values for ch – 0B and a−1 mod p – that satisfy ch · A = 0. Therefore
the probability that a particular random oracle query sets the bad0 flag in G0 is 2/p. Applying a union
bound over all H queries we have
Pr[bad00 ] = qH · 2/p.

Bounding Pr[bad11 ]. Consider the condition that sets bad1 in G1 . We have T (R, A′ , m) = ch · A and
A′ ̸= A. Let ch′ be the response returned for the query (R, A′ , m). Then we have ch′ · A′ = ch · A. At
the time bad1 is set, ch′ , A′ , and A are fixed. The probability that for a particular random oracle query
ch = (ch′ · A′ ) · A−1 is bounded by qH /p. Applying a union bound over all random oracle queries we have
Pr[bad11 ] = qH
2
/(p − 1).

Game G2 . Consider the winning conditions in G2 . The adversary AUV wins the game G2 if it returns
(sk, vk ′ , m) such that (z · B = R + ch′ · vk ′ ) and ((sk, vk ′ ) ̸∈ [DS.Kg]) where (R ∥ z) = Ed25519.Sig(sk, m)
and ch′ . Let vk be the verification key that satisfies (sk, vk) ∈ [DS.Kg]. Then we have from the correctness
of DS that z · B = R + ch′ · vk. We also know that vk ̸= vk ′ . So we have z · B = R + ch′ · vk ′
and z · B = R + ch′ · vk. These two conditions can simultaneously hold only if one of ch · A = 0 or
ch′ · A′ = ch · A is true. In our transitions from G0 to G2 , we precluded either of these conditions from
being true. Therefore, it is impossible for AUV to win G2 . It follows that
Pr[G0 ] = 0.

D.3 Stronger Out-Group AE Security Results (Proof of Proposition 4)

Overview. This proof uses games G0 through G2 in Fig. 39. We establish the following claims.

◦ AdvOAE
SS,predtrivial ,funcsec
out
(AOAE ) = 2 · Pr[G0 ] − 1 ◦ Pr[G1 ] = Pr[G2 ]
◦ Pr[G0 ] − Pr[G1 ] ≤ Pr[badG00 ] ◦ 2 · Pr[G2 ] − 1 ≤ AdvOAE
SS,predtrivial ,funcout ⊥ (AOAE⊥ )
◦ Pr[badG00 ] ≤ AdvUV SS (AUV )

By combining the above, we have

AdvOAE
SS,predtrivial ,funcsec
out
(AOAE ) = 2 · Pr[G0 ] − 1 = 2 · ((Pr[G0 ] − Pr[G1 ]) + Pr[G1 ]) − 1
G
≤ 2 · (Pr[bad00 ] + Pr[G1 ]) − 1
≤ AdvUV OAE
SS (AUV ) + AdvSS,predtrivial ,funcout ⊥ (AOAE⊥ ).
We justify our claims in the following paragraphs.

61
 Games G0 –G2 SigEnc(g, u, n, m0 , m1 , ad)
′
b ←$ {0, 1} ; b ←$ AU,G,SigEnc,VerDec
OAE
require K[g] ̸= ⊥ and |m0 | = |m1 |
Return b = b′ require sk[u] ̸= ⊥ and u ∈ members[g]
// Nonce reuse check
NewHonUser(u)
If m0 ̸= m1 then
NewHonGroup(g, users)
If group is corrupt[g] then return ⊥
ExposeUser(u)
Else chal[g] ← true
ExposeGroup(g) c ← SS.SigEnc(g, K[g], u, sk[u], n, m, ad)
NewCorrUser(u, sk, vk) // Update nonce set
NewCorrGroup(g, K, users) C ← C ∪ {((g, u, n, mb , ad), c)}
// These oracles are identical to the corresponding Q ← Q ∪ {((g, u, n, m0 , m1 , ad), c)}
// oracles in the OAE game for StE as per Fig. 7. W [g, u, n, c, ad] ← m1 ; Return c
Nonce reuse checks Update nonce set
require ∀d ∈ {0, 1}, (g, u, n, md , ad) ̸∈ Nd // SS ∈ {EtS, StE} N0 ← N0 ∪ {(g, u, n, m0 , ad)} // SS ∈ {EtS, StE}
require (g, n) ̸∈ N // SS = SP N1 ← N1 ∪ {(g, u, n, m1 , ad)} // SS ∈ {EtS, StE}
(nbody , nheader ) ← n // SS = BM N ← N ∪ {(g, n)} // SS = SP
If nbody = nheader then return ⊥ // SS = BM N ← N ∪ {(g, nheader ), (g, nbody )} // SS = BM
If (g, nbody ) ∈ N then return ⊥ // SS = BM
If (g, nheader ) ∈ N then return ⊥ // SS = BM

VerDec(g, u, n, c, ad) VerDec(g, u, n, c, ad)

require K[g] ̸= ⊥ and ¬group is corrupt[g] require K[g] ̸= ⊥ and ¬group is corrupt[g]
require vk[u] ̸= ⊥ and u ∈ members[g] require vk[u] ̸= ⊥ and u ∈ members[g]
If W [g, u, n, c, ad] ̸= ⊥ then // G[2,∞) If ∃u′ : W [g, u′ , n, c, ad] ̸= ⊥ then // G[2,∞)
If (vk[u], sk[u]) ̸∈ [SS.UserKg] then // G[2,∞) If (vk[u], sk[u′ ]) ̸∈ [SS.UserKg] then // G[2,∞)
Return ⊥ // G[2,∞) Return ⊥ // G[2,∞)
Return W [g, u, n, c, ad] // G[2,∞) Return W [g, u′ , n, c, ad] // G[2,∞)
m ← SS.VerDec(g, K[g], u, sk[u], n, c, ad) m ← SS.VerDec(g, K[g], u, sk[u], n, c, ad)
If m = ⊥ then return ⊥ If m = ⊥ then return ⊥
z ← ((g, u, n, m, ad), c) z ← ((g, u, n, m, ad), c)
If z ∈ C then If ∃u′ : ((g, u′ , n, m, ad), c) ∈ C then
If (vk[u], sk[u]) ̸∈ [SS.UserKg] then If (vk[u], sk[u′ ]) ̸∈ [SS.UserKg] then
bad0 ← true bad0 ← true
Return ⊥ // G[1,2) Return ⊥ // G[1,2)
Return funcsec out (z, Q) Return funcsec out (z, Q)
If b = 0 then return ⊥ else return m If b = 0 then return ⊥ else return m

Fig. 39: Games G0 –G2 used in the proof of Proposition 4 for predtrivial = predsuf trivial and predtrivial =
suf-except-user suf
predtrivial . The VerDec oracle correspodning to predtrivial is shown on the right and the VerDec
oracle corresponding to predsuf-except-user
trivial is shown on the right.

OAE
Game G0 . The game G0 is functionally equivalent to GSS,pred sec . Additionally, the former includes
trivial ,funcout
code lines highlighted in green that we use for transitions between games. The VerDec oracle correspond-
suf-except-user
ing to predsuf
trivial is shown at the bottom-left of Fig. 39 and that corresponding to predtrivial is shown
at the bottom-right of Fig. 39. The Derive vk function defined in ?? derives the verification key vk corre-
sponding to the input signing key sk. The conditional statement that was added in VerDec oracle sets
the bad0 flag whenever the boolean (vk[u], sk[u]) ̸∈ [SS.UserKg] evaluates to true for predtrivial = predsuf trivial
and whenever the boolean (vk[u], sk[u]) ̸∈ [SS.UserKg] evaluates to true for predtrivial = predsuf-except-user
trivial .
These changes do not affect the functionality of G0 and we have
AdvOAE
SS,predtrivial ,funcsec
out
(AOAE ) = 2 · Pr[G0 ] − 1.

62
Transition from G0 to G1 . In game G1 we modify the VerDec oracle such that it returns ⊥ whenever
bad0 is set. As the games G0 and G1 are identical-until-bad, we have
G
Pr[G0 ] ≤ Pr[G1 ] + Pr[bad00 ].

Bounding Pr[bad00 ]. In order to bound Pr[bad00 ], consider an adversary AUV against the UV security of
SS that is defined as follows. It perfectly simulates the game G0 for adversary AOAE until the bad00 flag is
set. To simulate the user oracles U and the group oracles G, adversary AUV itself samples and maintains
all user keys and group keys.
Let us first define AUV for the case predtrivial = predsuf
trivial . Whenever the bad0 flag is set in the simulated
game during a VerDec query, adversary AUV returns the corresponding (g, K[g], u, u, sk[u], vk[u], n, m, ad).
Consider a VerDec query (g, u, n, c, ad) that sets the bad0 flag in G0 . During this query, the verification
key vk[u] successfully verifies and decrypts the ciphertext c, i.e., SS.VerDec(g, K[g], u, vk[u], n, c, ad) ̸= ⊥.
Moreover, we have z = (g, u, n, m, ad) ∈ C. Therefore, c = SS.SigEnc(g, K[g], u, sk[u], n, c, ad). Note that
immediately before the bad0 flag is set, game G0 verifies that (vk[u], sk[u]) ̸∈ [SS.UserKg] holds. This
implies that (sk[u], vk[u]) ̸∈ [DS.Kg]. So the bad0 flag is set when the following conditions are true –
SS.VerDec(g, K[g], u, vk[u], n, c, ad) ̸= ⊥ where c = SS.SigEnc(g, K[g], u′ , sk[u′ ], n, c, ad) and (sk[u], vk[u]) ̸∈
[DS.Kg].
We now define AUV for the case predtrivial = predsuf trivial . Whenever the bad0 flag is set in the simulated
game during a VerDec query, adversary AUV returns the corresponding (g, K[g], u′ , usk[u′ ], vk[u], n, m, ad).
Consider a VerDec query (g, u, n, c, ad) that sets the bad0 flag in G0 . During this query, the verification
key vk[u] successfully verifies and decrypts the ciphertext c, i.e., SS.VerDec(g, K[g], u, vk[u], n, c, ad) ̸= ⊥.
Moreover we have ∃u′ : ((g, u′ , n, c, ad), c) ∈ C. Therefore, c = SS.SigEnc(g, K[g], u′ , sk[u′ ], n, c, ad).
Note that immediately before the bad0 flag is set, game G0 verifies that (vk[u], sk[u′ ]) ̸∈ [SS.UserKg]
holds. This implies that (sk[u′ ], vk[u]) ̸∈ [DS.Kg]. So the bad0 flag is set when the following conditions
are true – SS.VerDec(g, K[g], u, vk[u], n, c, ad) ̸= ⊥ where c = SS.SigEnc(g, K[g], u′ , sk[u′ ], n, c, ad) and
(sk[u′ ], vk[u]) ̸∈ [DS.Kg].
In both cases, the conditions under which bad0 is set in G0 are exactly the winning conditions in the
UV game of SS. Therefore, by returning the corresponding values, AUV wins its game and we have
Pr[bad00 ] ≤ AdvUV
SS (AUV ).

Transition from G1 to G2 . First, we address this transition for the case predtrivial = predsuf trivial . In the
game G1 , if the adversary forwards an honestly generated ciphertext from SigEnc to VerDec, then
z ∈ C evaluates to true in VerDec and VerDec returns the corresponding challenge message m1
if (vk[u], sk[u]) ∈ [SS.UserKg] and ⊥ otherwise. In game G2 we remove the conditional that checks if
predtrivial (z, C) is true from VerDec and instead use the table W to achieve the same behavior without
actually having to decrypt forwarded ciphertexts. For every SigEnc query, the table W indexed by
g, u, n, c, and ad stores the challenge message m1 where c is the ciphertext returned for that query.
This table W is then used to respond to VerDec queries on trivially forwarded ciphertexts. Note that
the decryption correctness of SS gives W [g, u, n, c, ad] ̸= ⊥ evaluates to true in G2 iff predtrivial (z, C) for
z = ((g, u, n, m, ad), c). Therefore the outputs of VerDec are consistent between the two games.
Now we analyze the case predtrivial = predsuf-except-user
trivial analogously. In the game G1 , if the adversary for-
wards an honestly generated ciphertext from SigEnc to VerDec, then ∃u′ : ((g, u′ , n, m, ad), c) ∈ C eval-
uates to true in VerDec and VerDec returns the corresponding challenge message m1 if (vk[u], sk[u′ ]) ∈
[SS.UserKg] and ⊥ otherwise. Again we use the table W to replace the conditional that checks the trivi-
ality predicate. The decryption correctness of SS gives ∃u′ : W [g, u′ , n, c, ad] ̸= ⊥ evaluates to true in G2
iff ∃u′ : ((g, u′ , n, m, ad), c) ∈ C. So the outputs of VerDec are consistent between the two games.
In both cases, the outputs of VerDec remain unchanged between G1 and G2 . It follows that
Pr[G1 ] = Pr[G2 ].

Bounding Pr[G2 ]. In Fig. 40, we define the adversary AOAE⊥ against the OAE security of SS with respect
to the predicate predtrivial and the output guarding function func⊥
out . It perfectly simulates the game G2
for adversary AOAE . In particular, it simulates the responses to the user and group oracles using the

63
 Adversary AU,G,SigEnc,VerDec,Enc
OAE⊥ SimSigEnc(g, u, n, m0 , m1 , ad)
b′ ←$ ASimU,SimG,SimSigEnc,SimVerDec
OAE require K[g] ̸= ⊥ and |mbody,0 | = |mbody,1 |
Return b′ require sk[u] ̸= ⊥ and u ∈ members[g] and (g, nbody ) ̸∈ N
If m0 ̸= m1 then
If group is corrupt[g] then return ⊥ else chal[g] ← true
c ← SigEnc(g, u, n, m0 , m1 , ad)
N ← N ∪ {(g, n)} ; W [g, u, n, c, ad] ← m1 ; Return c

SimNewHonGroup(g, users) SimExposeGroup(g) SimNewCorrGroup(g, K, users)

require K[g] = ⊥ require K[g] ̸= ⊥ and ¬chal[g] require K[g] = ⊥
K[g] ← “dummy” group is corrupt[g] ← true group is corrupt[g] ← true
NewHonGroup(g) K[g] ← ExposeGroup(g) NewCorrGroup(g, K)
members[g] ← users Return K[g] K[g] ← K ; members[g] ← users
SimNewHonUser(u) SimExposeUser(u) SimNewCorrUser(u, sk, vk)
require sk[u] = vk[u] = ⊥ require sk[u] ̸= ⊥ require sk[u] = vk[u] = ⊥
vk[u] ← NewHonUser(u) Return sk[u] NewCorrUser(u, sk, vk)
sk[u] ← ExposeUser(u) ; Return vk[u] sk[u] ← sk ; vk[u] ← vk
SimVerDec(g, u, n, c, ad) SimVerDec(g, u, n, c, ad)
require K[g] ̸= ⊥ and ¬group is corrupt[g] require K[g] ̸= ⊥ and ¬group is corrupt[g]
require vk[u] ̸= ⊥ and u ∈ members[g] require vk[u] ̸= ⊥ and u ∈ members[g]
If W [g, u, n, c, ad] ̸= ⊥ then If ∃u′ : W [g, u′ , n, c, ad] ̸= ⊥ then
If (vk[u], sk[u]) ̸∈ [SS.UserKg] then return ⊥ If (vk[u], sk[u′ ]) ̸∈ [SS.UserKg] then return ⊥
Else return W [g, u, n, c, ad] Else return W [g, u′ , n, c, ad]
m ← VerDec(g, u, n, c, ad) m ← VerDec(g, u, n, c, ad)
If m ̸= ⊥ then abort(1) If m ̸= ⊥ then abort(1)
Return ⊥ Return ⊥

Fig. 40: Adversary AOAE⊥ used in the proof of Proposition 4. The SimVerDec oracle for predsuf
trivial is
shown on the left and the SimVerDec oracle for predsuf-except-user
trivial is shown on the right.

64
corresponding oracles from its own OAE security game. Note that the OAE security game allows to
expose all user keys, so every time an honest user key-pair is created in the simulated game G2 , adversary
AOAE⊥ immediately exposes it. It simulates the SigEnc oracle using the corresponding oracle from its
security game and simulates the VerDec oracle using the corresponding oracle from its security game
and the table W . The simulated VerDec oracle corresponding to predtrivial = predsuf trivial and predtrivial =
suf-except-user
predtrivial are shown at the bottom-left and bottom-right respectively of Fig. 40. Finally, if the
m ̸= ⊥ condition is never true in the simulated VerDec and AOAE returns b′ , adversary AOAE⊥ also
returns b′ . Now consider the case that m ̸= ⊥ evaluates to true in the simulated game. It must be the
case that predtrivial (z, C) = false and m ̸= ⊥. This is only possible when AOAE has successfully forged a
ciphertext and the bit b is 1. Therefore AOAE⊥ executes abort(1) and wins its game. We have
2 · Pr[G1 ] − 1 ≤ AdvOAE
SS,pred ⊥ AOAE⊥ .
trivial ,funcout

E Other Uses of Symmetric Signcryption in Keybase

In this appendix, we briefly touch upon other uses of the SealPacket and BoxMessage algorithms in
Keybase. We present three such instances – SealPacket as a standalone scheme, the algorithm SealWhole
that is used to encrypt long strings, and the algorithm PostFileAttachment that is used to encrypt and
upload file attachments to a third-party storage.

E.1 Security of SealPacket as a Standalone Encryption Scheme

In Keybase, the SealPacket subroutine is not only used within the BoxMessage construction to signencrypt
the header but also as a standalone scheme. For example, it is used in isolation to signencrypt small chat
attachments. Here we prove the wOAE security of SealPacket as a standalone scheme with respect to the
suf-except-user
predicate predtrivial and the output guarding function funcsec out .
Recall that we analyzed the security of SealPacket when used within BoxMessage in Theorem 5. In
particular, we had reduced the wOAE[Enc[M, NE]] security of SealPacket with respect to the predicate
suf-except-user
predtrivial and the output guarding function func⊥ out to the M-sparsity of the underlying digital
signature scheme DS and the KDMAE security of the underlying nonce based encryption scheme NE.
One could capture the wOAE security of the standalone SealPacket scheme with respect to the predicate
suf-except-user
predtrivial and the function func⊥ out as a special case of this result by restricting the adversary from
making any calls to its Enc oracle. By doing so, the reduction to the SPARSE security of the digital
signature scheme is no longer required. Moreover, the class of message-deriving functions considered
during the reduction to the KDMAE security of the nonce-based encryption scheme would be smaller.
This is because in the proof of Theorem 5 the function ENC-DER was only required to simulate the Enc
oracle, which is never used when treating SealPacket as a standalone scheme, allowing its omition from
the class of message-deriving functions considered.
In the following, we show that the wOAE security of the standalone SealPacket scheme with respect
to the predicate predtrivialsuf-except-user
and the output guarding function func⊥ out implies its wOAE security with
respect to the stronger output-guarding function funcsec out .

Proposition 8. Let DS = Ed25519-DS[k, p, G, Gp , B, H1 , H2 , H3 ] be the digital signature scheme built

from some k, p, G, Gp , B, H1 , H2 , H3 as specified in Construction 6. Let SP = SEAL-PACKET-SS[H, DS,
NE] be the symmetric signcryption scheme built from some H, NE, and DS. Let predsuf-except-usertrivial be the
ciphertext-triviality predicate defined in Fig. 8. Let func⊥
out and funcsec
out := funcsilence-with-m1
out [pred suf-except-user
trivial ]
be the output-guarding functions as defined in Fig. 9. Let wOAE be the security notion as defined in Defi-
nition 1. Let AwOAE-of-SP be any adversary against the wOAE security of SP with respect to predsuf-except-user
trivial
and funcsec
out . Then we can build adversaries AUV and BwOAE-of-SP such that
AdvwOAE
SP,predsuf-except-user ,funcsec
(AwOAE-of-SP ) ≤ AdvUV wOAE
DS (AUV ) + AdvSP,predsuf-except-user ,func⊥ (BwOAE-of-SP ).
trivial out trivial out

Proof. This proof is analogous to the proof of Proposition 4.

65
E.2 Multi-purpose Scheme SealWhole for Encrypting Long Strings

Basic Notation. For any x ∈ {0, 1}∗ and ℓ ∈ N such that |x| ≤ ℓ, we write ⟨x⟩ℓ to denote the bit-string
of length ℓ that is built by padding x with leading zeros.
Symmetric Signcryption Syntax. In this section, we augment the definition of SS from Section 3
with a ciphertext-length function SS.cl : N → N that is associated with every instance of SS. We then
require that the signcryption algorithm SS.SigEnc encrypts any message m ∈ SS.MS into a ciphertext c
of the corresponding (fixed) length |c| = SS.cl(|m|).
The SealWhole algorithm [Keyg] is a wrapper around the standalone SealPacket algorithm and is
used in Keybase to encrypt large strings and attachments. We present the pseudocode for the SealWhole
algorithm in Fig. 41 and give a high-level description of the algorithm. The SealWhole algorithm accepts
the same inputs as the SealPacket algorithm. To encrypt a message m with a nonce n, the SealWhole.SigEnc
algorithm first parses the message m into chunks mi of length 1 MB. It then encrypts each mi by
calling the SealPacket algorithm with nonce ni = n ∥ ⟨i mod 264 ⟩64 to obtain ciphertext ci . The SealWhole
algorithm returns the concatenation of all ci obtained above.

SealWhole.SigEnc(g, Kg , u, sku , n, m, ad) // where n ∈ {0, 1}128 , ad = ε

m0 ∥ m1 ∥ ... ∥ ml ← m // |mi | = 1 MB for all i < l and 0 ≤ |ml | < 1 MB.
For i = 0 to l do
ni ← n ∥ ⟨i mod 264 ⟩64
ci ← SealPacket.SigEnc(g, Kg , u, sku , ni , mi , ad)
Return c0 ∥ c1 ∥ ... ∥ cl
SealPacket.SigEnc(g, Kg , u, sku , nchunk , mchunk , ad) // nchunk ∈ {0, 1}192 , ad = ε
hchunk ← SHA-512(mchunk )
schunk ← Ed25519.Sig(sku , “Keybase-Chat-2” ∥ ⟨Kg , nchunk , hchunk ⟩)
cchunk ← XSalsa20-Poly1305.Enc(Kg , nchunk , schunk ∥ mchunk )
Return cchunk

Fig. 41: The SealWhole algorithm used in Keybase for encrypting long strings. We reproduce the SealPacket
algorithm from Section 5 for convenience.

E.3 Encryption of Attachments with PostFileAttachment

The PostFileAttachment [Keyh] algorithm is used to encrypt and upload files in private Keybase folders. We
present the pseudocode for the PostFileAttachment algorithm in Fig. 42 and give a high-level description of
the algorithm. The PostFileAttachment algorithm accepts the same inputs as the BoxMessage algorithm,
except the message mattach is a file that a sender wants to upload to a third-party storage, and the
associated data ad is a pair (adattach , adwrap ). To encrypt the file attachment mattach , the PostFileAttachment
algorithm first samples a 256-bit attachment encryption key kattach and generates an ephemeral signing
key pair (skattach , vkattach ) by calling SealWhole.UserKg. It then computes the nonce nattach as the first 128
bits of SHA-256(adattach ). Next it calls the SealWhole.SigEnc algorithm to encrypt mattach using the key
kattach , nonce nattach , and signing key sku to obtain the ciphertext cattach . Subsequently it calls SHA-256
on mattach and cattach to produce the hashes hm and hc . It then builds the wrapper message mwrap =
(kattach , vkattach , nattach , hm , hc ). Finally PostFileAttachment.SigEnc invokes BoxMessage on mwrap , Kg , sku ,
nwrap , and adwrap to obtain the ciphertext cwrap . The algorithm returns (cwrap , cattach , nattach ).
We do not further analyze the SealWhole and PostFileAttachment algorithms in this work.

66
PostFileAttachment.SigEnc(g, Kg , u, sku , nwrap , mattach , ad) // Kg ∈ {0, 1}256
// nwrap = (nwrap-body , nwrap-header ) ; nwrap-body , nwrap-header ∈ {0, 1}192
(adattach , adwrap ) ← ad
kattach ←$ {0, 1}256
(skattach , vkattach ) ←$ SealWhole.UserKg // SealWhole = SEAL-WHOLE-SS
nattach ← H(adattach )[1..128] // H = SHA-256 ; nattach is assigned the first 128 bits of the H output
cattach ←$ SealWhole.SigEnc(g, kattach , u, skattach , nattach , mattach , ε)
hm ← H(mattach )
hc ← H(cattach )
mwrap ← (kattach , vkattach , nattach , hm , hc )
cwrap ←$ BM.SigEnc(g, Kg , u, sku , nwrap , mwrap , adwrap )
c ← (cwrap , cattach , nattach )
Return c

Fig. 42: The PostFileAttachment algorithm used in Keybase to encrypt and upload file attachments to a
third-party storage.

67