20

I have a stream that I want to encrypt for broadcast to 10,000 subscribers. I know I should encrypt this data using a symmetric key; and also intend that this symmetric key will be rotated every 30 days.

Assuming that I already have a Public key for each subscriber (private key only known to them), how should I encrypt the symmetric key and send it to the subscribers?

Or is this just obvious; I just encrypt the symmetric key with each public key? Are there any special considerations I need to take?

For example, how does the length of the symmetric key factor in to the solution? I am considering wrapping the symmetric key in a SOAP or JSON message which may alter the length of the final string to be encrypted.

AviD
  • 72,138
  • 22
  • 136
  • 218
makerofthings7
  • 50,090
  • 54
  • 250
  • 536

2 Answers2

17

You just encrypt the symmetric with the public key of each recipient. There is some research on how to do better than that (so that the size overhead is less than, say, a hundred bytes per recipient) but there is nothing directly applicable right now.

If you use RSA (that's the most probable), then here are the sizes: an encrypted message always has the same size than the modulus; for a 1024-bit RSA key, this means 128 bytes. The encryption process includes some padding, which adds an internal overhead of at least 11 bytes. Thus, the maximum size of a data blob which is to be encrypted with a 1024-bit RSA key is 128-11 = 117 bytes.

I am not sure why you would want to wrap the symmetric key in a SOAP or JSON message. If it is encrypted then the receiver must decrypt it; since an encrypted RSA message really looks like a bunch of random bytes with no visible structure, this means that the receiver already knows what to expect. What would SOAP or JSON add at that point ? Maybe you would like to do it the other way round, i.e. encrypt (with RSA) the symmetric key, and then wrap the result (the 128-byte encrypted message) into a SOAP or JSON message ?

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Thank you.. I inverted my thinking and wrapping the results in JSON to provide metadata makes sense. How would you suggest I generate the symmetric key? Any algorithm? – makerofthings7 Mar 25 '11 at 17:45
  • 2
    @makerofthings: a symmetric key is a bunch of arbitrary bits. To generate such a key, you need a cryptographically strong RNG (Random Number Generator), which is seeded with "true alea" from hardware sources. This is a job for the operating system, who has direct access to hardware. On Linux, FreeBSD and other unix-like systems, use `/dev/urandom`. On Windows, call `CryptGenRandom()`. With Java, use `java.security.SecureRandom`. – Thomas Pornin Mar 25 '11 at 19:47
  • Is it correct that for a 1024 bit RSA key, the maximum size of a symmetric key I can use is 117 bytes? – makerofthings7 Mar 18 '14 at 17:00
  • With RSA PKCS#1 v1.5 encryption, the maximum size of that which is encrypted will be 11 bytes less than the modulus size. This does not depend on whether that which is encrypted is part of a "key" or something else; a byte is a byte. With RSA PKCS#1 "OAEP" (new in v2.0), the limit is actually even lower. Of course, most protocols which do "asymmetric encryption" only encrypt with RSA a random symmetric key (16 bytes are enough for most decent security), and then use that symmetric key to encrypt gigabytes of data; so the limit is not a true limitation. – Thomas Pornin Mar 18 '14 at 20:48
4

There are several usable Broadcast Encryption(BE) schemes. The most popular of them is the Subset Difference(SD) scheme by Naor-Naor-Lotspiech(NNL) that was proposed back in 2001. Here is a link to the full version of the paper describing the scheme: http://eccc.hpi-web.de/report/2002/043/. It was suggested for use by the AACS standard for digital rights management in optical discs.

The two most important parameters (in terms of cost) of any BE scheme are (a) the amount of storage required to store the private keys of each user, (b) the amount of additional information (communication overhead) that has to be sent with each block of data that is encrypted for broadcast.

Several improvements to the NNL-SD scheme have been proposed that intend to reduce the device key storage requirement as well as the communication overhead. Here are a few of them.

  1. Reducing storage: (a) Layered SD schemes by Halevy and Shamir, Crypto 2002. (b) Minimal storage and other optimizations of the SD scheme: http://www.computer.org/csdl/trans/tc/preprint/06484060-abs.html
  2. Reducing communication overhead: (a) k-ary tree SD schemes: IACR ePrint archive number: 2013/786 (b) Augmented Binary Tree SD schemes: IACR ePrint archive number: 2014/577

All these schemes have the following features: A. They are stateless - and hence the user keys need not be updated from time to time. B. These schemes also allow any number of users to be revoked at any point of time. C. They also allow "black-box traitor tracing". This is a mechanism by which the decryption capability of a "pirate decryption box" can be tested to find the user keys that have been used in it. It may be noted that this does not require opening of the pirate box. Testing its decryption capabilities by treating it as a black box suffices.

They however have the following disadvantages: A. All broadcasts happen from one center that has all information about the secret keys of the users - as per the standard definition of BE. B. Users can not be added dynamically to the system. Hence, the maximum number of users in the system have to be estimated and hence fixed during the initialization of the scheme.

Tabole Buro
  • 41
  • 1