0

I need to distribute a shared 256 bit key to 100's or 1000's of nodes (I have the public key of each node).

There's no networking involved - this will all be done by loading a single file on to each node. That file is generated by a "master".

In some cases, the nodes use 2048-bit RSA keys, and others it is a p521 Elliptic Curve key.

The idea is to create a line for each node in the distributed file encrypting the shared key.

If the node uses EC, then the node's public EC and the master's private EC keys are used to generate a symmetric key which is used to encrypt the shared key . The encrypted shared key and signature generated by the master are stored on a line in the file. The node would then loop through each line in the file, use the master's public EC key and its own private EC key to generate the same symmetric key, decrypt the data, then check the signature. If correct, then that is the shared key.

If the node uses RSA, then the shared key would be encrypted with the node's public RSA key, and a signature generated by the master and both stored on a line in the file. The node would then loop through each line in the file, use its private RSA key to decrypt the data, then check the signature. If correct, then that is the shared key.

My worry is that does knowing that a single piece of data being encrypted with 1000 different keys give an attacker a significant advantage for deriving a private key?

Improve this question
2
  • I think your main issue will be someone taking the device and extracting the shared symmetric key. Is there a reason why you can't have unique keys per node?
    – user
    Dec 18, 2019 at 19:17
  • Securing the physical device is taken care of. They all need the same symmetric key because they are all decrypting a very large data file encrypted with that key, impractical to encrypt uniquely per node. So we need to distribute the key to the white-listed devices for which we have the public key. The question is if there is sufficient information in that distributed key file, knowing that it is the same key encrypted with 1000 different public keys, to derive anything that could compromise any nodes private key.
    – jo phul
    Dec 18, 2019 at 23:13

2 Answers 2

Reset to default
1

Depending on the used implementation, using RSA with the same input and different keys could be a problem. If all your keys have the same exponent e, a variant of the coppersmith attack (Håstad's broadcast attack) is applicable: https://en.wikipedia.org/wiki/Coppersmith%27s_attack

Improve this answer
3
  • Ah thank you. I just checked and the e is 65537. Also read on that wiki page that randomized padding will help. So I can add random padding to the key prior to encryption.
    – jo phul
    Dec 19, 2019 at 0:15
  • You can avoid this problem by generating a separate symmetric key for each node (randomly, not based on any other key). Then the plaintexts you're encrypting with the nodes' public keys are all unrelated.
    – Gordon Davisson
    Dec 19, 2019 at 2:24
  • That's great, thanks. So the strategy is to generate a random AES key, encrypt the plaintext and write that to the file. Then encrypt the AES key using 1) In the case of RSA, the node's RSA Private key or 2) in the case of EC, an AES key derived from the node's public EC key and the master's private EC key and write that to the file. Then on the receiving end, the node decrypts the AES key in order to decrypt the cipher text.
    – jo phul
    Dec 19, 2019 at 3:42
0

More broadly speaking, it is (as seen in the other answer) a potential attack vector - even if no feasible vector is currently know, one might be discovered in the future. Of course you can try to foil this with random padding and the like, but the problem with such "protocols" is that it is very is easy to overlook something.

If your goal is just to distribute some piece of data, you could easily use GPG or at least the same approach: Encrypt your "key" with a randomly chosen symmetric key (e.g. using AES) and then encrypt the random key using public-key cryptography.

Of course this then begs the question why you would not just encrypt the actual payload in this way, as opposed to a shared key. I can see very few applications where your proposed method (sharing a key with thousands of systems) would make sense in the first place.

If you used the shared "key" for actual encryption, you would have another host of problems to consider: Using it cannot guarantee authenticity (even if the initial public key exchange was signed), any system can impersonate any other system and if only one node is compromised, everything is.

Improve this answer

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.