[Cryptography] Recryption API

[Phillip Hallam-Baker]

I have been working on an end to end encrypted Web site using Proxy
Re-Encryption 'recryption'. The basic idea is that Alice is the
administrator, she creates a keypair for 'Group W' and published the public
part. Anyone who wants to can publish material encrypted under this key.

For each person Alice adds to the group, she creates a recryption keypair
[recrypt, decrypt], the first key is sent to the online recryption service
chosen by Alice. The second is encrypted under Bob's public key and
uploaded to the recryption service.

The net effect is that it is impossible for any party to decrypt the
content on the site unless they have either:

* The private key held by Alice
* The private key of one of the group members and at least an oracle that
will preform the recryption step.

This is true end to end encryption. An attacker can breach both the cloud
services and the material is still confidential.


So to implement this I need an API. OK so first off, I need an API for DH
key agreement:

            var AliceKeyPair = new DiffeHellmanPrivate();
            var BobKeyPair = new DiffeHellmanPrivate();

            var AlicePublic = AliceKeyPair.DiffeHellmanPublic;
            var BobPublic = BobKeyPair.DiffeHellmanPublic;

            var AliceAgree = AliceKeyPair.Agreement(BobPublic);
            var BobAgree = BobKeyPair.Agreement(AlicePublic);

            if (AliceAgree!=BobAgree) {
                Console.WriteLine("Fail");
                }

[This is of course eliding all the code that would move the data between
Alice and Bob]

This looks nice and symmetric. AliceAgree  is currently returned as a
BigInteger. This should obviously be fed into a hash function in some
fashion to derive a key. But that would be part of DH-SHA2-512 or the like
which would wrap this class.

OK so what does a recryption scheme look like?

            var GroupKeyPair = new DiffeHellmanPrivate();
            var GroupKeyPublic = GroupKeyPair.DiffeHellmanPublic;

            var BobSplit = GroupKeyPair.MakeRecryption(2);
            var BobRecryption = BobSplit[0];
            var BobDecryption = BobSplit[1];

            var AliceAgreeW = AliceKeyPair.Agreement(GroupKeyPublic);

            var ServerAgreeW = BobRecryption.Agreement(AlicePublic);
            var BobAgreeW = BobDecryption.Agreement(AlicePublic,
ServerAgreeW);


            if (AliceAgreeW != BobAgreeW) {
                Console.WriteLine("Fail");
                }

This is pretty similar to the previous verison. The only changes are making
the recryption set (MakeRecryption) and there are now two agreement
operations instead of one. The first is exactly the same as before and the
second requires the output of the first as a 'carry'.

One thing I don't much like about this approach is that it enforces
sequential processing. That is pretty much inevitable with two parties. But
with more parties you might well want to perform the agreement steps in one
place and then the combination elsewhere.

            var ServerRecrypt = BobRecryption.Agreement(AlicePublic);
            var BobRecrypt = BobDecryption.Agreement(AlicePublic);

            var Recrypts = new BigInteger[] { ServerRecrypt, BobRecrypt };
            var BobAgreeW = BobDecryption.Agreement(Recrypts);

Does this make sense?

Here is the code that implements the methods:

        public BigInteger Agreement(DiffeHellmanPublic Public) {
            Verify(Public);
            return BigInteger.ModPow(Public.Public, Private, Modulus);
            }

        public BigInteger Agreement(DiffeHellmanPublic Public, BigInteger
Carry) {
            Verify(Public);
            var Partial = Agreement(Public);
            return (Partial * Carry) % Modulus;
            }

If the basic framework is right, it should be possible to implement this
for the curve-x algorithms. If I can work out what the functions
corresponding to ModPow and * are from DJB's code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161205/ce397ae0/attachment.html>