How To Bob and Alice and Carol Add Their Encryption Keys To Data?

How Do Bob and Alice and Carol Add Their Encryption Keys To Data?

When I worked as an electrical engineer, we had a hasp to isolate the electric power on a device we were working on:

With this, each person who was working on the equipment, would put on their own padlock, and where we could not put the power back on, until all the padlocks had been taken off. The padlocks could be put on in any order, and taken off in any order, but there was no way to putting the power back on, until everyone had taken their padlock off.

So how could we do this with data. Let’s say that Bob, Alice and Carol want to apply their “data hasp”, so that the data cannot be revealed until they have all taken off their padlock. Well, with symmetric key block ciphers, such as AES, we cannot do this, as we must decrypt in the reverse order of they keys being applied:

To encrypt: Bob → Alice → Carol … and then to decrypt: Carol → Alice →Bob

There are ways to do it with RSA, such as with SRA [here], but these methods significantly reduce the security of the process. The solution is to use a stream cipher, as we basically just X-OR the data when we are encrypting, and then X-OR again with the same key when we decrypt. We can apply multiple keys to the data, and in any order and it will always decrypt properly once we have applied all the keys.

Commutative encryption using ChaCha20

ChaCha20 is wiping the floor with AES just now, and showing how out-of-date block ciphers look in a world focused on the speed of processing of data.

With commutative encryption, we can decrypt with the keys in any order. Normally we would encrypt with Bob’s key and then encrypt with Alice’s key, and then we must decrypt with Alice’s key and then Bob’s. In commutative encryption, we can decrypt in any order.

With a stream cipher, we can automatically apply commutative as we basically just EX-OR with the key stream. In the following we use Go code, and where Bob encrypts, Alice encrypts, Bob decrypts, and then Alice decrypts [here]:

And a sample run [here]:

Input text: Hello
Bob passphrase: qwerty
Alice passphrase: 123456

Input text: Hello
Bob keygen: 65e84be33532fb784c48129675f9eff3a682b27168c0ea744b2cf58ee02337c5
Alice keygen: 8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92

Cipher after Bob encrypt: d9eef8ecdc
Cipher after Alice encrypt: 7a5dcd0f43
Cipher after Bob decrypt: ebd6598ff0
Cipher after Alice decrypt: 48656c6c6f
Decrypted text: Hello

We can easily extend the method to Carol, Trent, and so on. In my simple example I have used the same nonce for Bob and Alice, but in real life they would use different values, and these would be random for every transaction.

Conclusions

We need to move away from just integrated rights management with encryption, and actually embed rights into the data. Commutative encryption allows for a hasp method that we saw in isolating electrical equipment.