2

Is there a common scheme for broadcast encryption that doesn't involve an exchange of a shared key? I'm aware that traditionally a common symmetrical key would be given to all parties and exchanged securely using the recipients' public keys.

I'm building an application on the Ethereum blockchain where I want to use one message to transmit information to all recipients involved securely. Unfortunately, this means revoking keys becomes an expensive process due to Ethereum transaction costs, as I would have to redistribute a new symmetric key to all recipients again.

Is there any way to encrypt a message using a set of public keys that could be decrypted by any of their respective private keys so that revocation is not so expensive? I would not include the revoked public key the next time I send an update. The message is quite a small amount of text, so size should also not be a problem.

Patriot
  • 3,162
  • 3
  • 20
  • 66
Alex Godwin
  • 21
  • 1

3 Answers3

1

Asynchronous Ratcheting Tree (ART) is an n-way Diffie-Hellman key exchange. The group initiator selects members and instantiates the tree, revealing only public information such that each other member may recompute the group shared key. Users may update their key-share as a measure to implement forward secrecy of a later compromise of their long-term static identity key.

As you're interested in at least revocation, you'll want to extend ART with dynamic groups which introduce the operations: join, leave, partition and merge.

Leaving is done willingly, however, partitioning and merging can enable selective revocation, computing partial tree updates without recomputing a whole new tree (which is not too expensive anyway).

With the group key you now use symmetric authenticated encryption.

Edit: You may additionally use the group key to derive a shared asymmetric identity such that anyone may encrypt messages to the group; but only group members (1-of-n) may decrypt the messages. As the group membership changes, the encrypting user is responsible for using the latest identity to encrypt for.

cypherfox
  • 1,442
  • 8
  • 16
0

There are a number of PKC based broadcast encryption schemes. The original was the Franklin-Boneh scheme, google it. These more recent ones seem to promise improvements.

Identity-based broadcast encryption with constant size ciphertexts and private keys by C Delerablée, Asiacrypt 2007

The broadcaster encrypts messages and transmits these to the group of users via the broadcast channel. In a (public-key) IBBE encryption scheme, the broadcaster does not hold any private information and encryption is performed with the help of a public key PK.

Cited by 299 [PDF] academia.edu

Public Key Broadcast Encryption Schemes With Shorter Transmissions, JH Park et. al., IEEE Transactions on Broadcasting, 2008.

Abstract: Broadcast encryption allows a sender to securely distribute messages to a dynamically changing set of users over an insecure channel. In a public key broadcast encryption (PKBE) scheme, this encryption is performed in the public key setting, where the public key is stored in a user's device, or directly transmitted to the receivers along with ciphertexts. In this paper, we propose two PKBE schemes for stateless receivers which are transmission-efficient. A distinctive feature in our first construction is that, different than existing schemes in the literature, only a fraction of the public key related to the set of intended receivers is required in the decryption process. This feature results in the first PKBE scheme with O(r) transmission cost and O(1) user storage cost for r revoked users.. By combining the two proposed schemes, we suggest a PKBE scheme that achieves further shortened transmissions, while still maintaining O(1) user storage cost. The proposed schemes are secure against any number of colluders and do not require costly re-keying procedures followed by revocation of users.

kodlu
  • 25,146
  • 2
  • 30
  • 63
0

| what if we use this method? Is it secure?

  • when Group is created, it creates a Unique Group Key ${K_G}$, derived from it a few keys- may be used for various purpose. broadcast common messages${K_{c1}}$, authorize/deauthorize user for various actions..
  • Now when a user joins group, it will be assigned an unique ID, ${K_{U1}}$ and Group Key along with the other secret keys that are derived from group key.
  • The encryption of broadcast msg can be derived key ${K_{d1}}$ from${K_{c1}}$, hence ${E_{K_{G}}(Header||E_{K_{d1}}(m))}$
  • The header will have info about deriving ${K_{d1}}$
SSA
  • 670
  • 5
  • 12