Security concern re: group message wrapping (invisible salamanders attack)

1

Bringing Soatok’s Fediverse post here so it doesn’t get buried.

Soatok wrote:

Following up on a query from @tris this week:

The cryptography you’re using makes it possible for anyone to send messages to a group even if they cannot see message history.

core/src/e2ee.rs at 47b9bfc8bf807ad099d2211a59d6ba80290b0c95 · chatmail/core · GitHub

core/src/pgp.rs at 47b9bfc8bf807ad099d2211a59d6ba80290b0c95 · chatmail/core · GitHub

rpgp/src/composed/message/types.rs at ac6c0f8066c0db48270f5c9e41dd64d13b0813fe · rpgp/rpgp · GitHub

rpgp/src/packet/public_key_encrypted_session_key.rs at 500c52e2838d31ed0f4f67c616ae1540984c2fe4 · rpgp/rpgp · GitHub

rpgp/src/packet/key/public.rs at 500c52e2838d31ed0f4f67c616ae1540984c2fe4 · rpgp/rpgp · GitHub

A modern group key agreement protocol (MLS, etc.) avoids this behavior. I thought you should be made aware of it, if you weren’t otherwise.

The root cause for this behavior is that you’re wrapping a symmetric key to multiple public keys, naively.

In addition to the behavior @tris observed, this also lets you partition the recipients:

Imagine a group of Alice, Bob, Carol, and Dave.

Alice sends k_1 to {Bob, Carol}

Alice sends k_2 to {Dave}

Alice uses AES-GCM to encrypt the underlying message, and uses an exploit such as https://github.com/soatok/gcm-exploit to create a ciphertext that decrypts to two valid plaintexts

In this trivial setup, Alice can abuse Invisible Salamanders to sew disagreement among the other participants.

Read more: https://soatok.blog/2024/09/10/invisible-salamanders-are-not-what-you-think/

To mitigate this: I recommend adding an intermediary key derivation step like so:

Sort, then concatenate, the public keys of the recipients.

Derive the encryption key as follows: HKDF-SHA512(inputKey, “ENC_KEY_” + step1, null, 32) // ikm, label, salt, len (bytes)

Derive a key commitment as follows: HKDF-SHA512(inputKey, “COMMIT_” + step1, null, 32) // ikm, label, salt, len (bytes)

This will prevent the invisible salamanders issue (and binds the encryption key to the recipients’ public keys).

I would recommend also always require the ciphertext be signed by a public key that is a member of the group to be accepted, to prevent the sort of behavior that @tris observed.

1 Like
2

We have already responded this in that thread:

While it may be interesting to raise the issue of the lack of key commitment in OpenPGP circles and it may be useful for some applications, in case of Delta Chat usage for messaging there is no need to do this attack because there is no transcript consistency in the first place - you can simply create two different messages with the same Message-ID and send different message to different group members. Providing transcript consistency would require more than adding key commitment.

AEAD (SEIPDv2) is already supported, enabling it in backwards-compatible way is on the “roadmap”: Generate Features subpacket on the new keys · Issue #6673 · chatmail/core · GitHub

As for key commitment without transcript consistency, even if it existed in OpenPGP, I don’t see the value of it. Original “Invisible Salamanders” paper is about the “abuse reporting” usecase where Alice discloses messages sent by Bob to Facebook.

1 Like
3

As for requiring that messages are signed by the group member, this is already checked and non-member messages are marked with “~” in the name. But we don’t drop such messages because usually this happens normally due to reordering or missed messages.

1 Like
4

To conclude on this, I have double-checked the current state of OpenPGP. When RFC 9580: OpenPGP was standardized, key-committing AEAD modes were not considered. RFC 9580 standardizes EAX Mode, OCB Mode and GCM Mode. Delta Chat is supporting whatever rPGP supports and will use OCB Mode for sending. Delta Chat is not using GCM for sending, but accepts it for compatibility.

“Full commitment” and “key commitment” properties are defined in RFC 9771 - Properties of Authenticated Encryption with Associated Data (AEAD) Algorithms If some key committing mode gets standardized and added to OpenPGP, we might use it, but currently there is none and we are not going to build our own non-standard key commitment construction on top of OpenPGP.

2 Likes
5

It is also not clear that this exploit is relevant in a scenario where Alice is somehow prevented from simply sending two different OpenPGP messages to different sets of recipients. Message key is not directly created by Alice, but is derived using HKDF that is based on SHA-256:

1 Like