2
$\begingroup$

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

I'm building an application on the Ethereum blockchain where I want to securely transmit information to all recipients involved using one message. Unfortunately this means key revoking 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 I could 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 simply just not include the revoked public key next time I send an update. The message is quite a small amount of text, so size should also not be a problem.

Apologies if this is a noob question, this is my first fore into this type of encryption. Thanks!

$\endgroup$
1
$\begingroup$

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.

$\endgroup$
0
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ This requires pairing-friendly curves which I doubt are available under Ethereum. Edit: It appears to have BN-curves. Interesting. $\endgroup$ – cypherfox Mar 15 '18 at 2:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.