[Cryptography] Precise definition of zero knowledge?

Phillip Hallam-Baker phill at hallambaker.com
Fri Aug 31 12:53:42 EDT 2018


OK, so I know what we normally mean when we talk about zero knowledge and
the bit about the cave.

It suddenly occurred to me that the approaches I am using to generate
keypairs for cogeneration and proxy re-encryption could be seen as 'zero
knowledge' but the approach is direct, there is no proof.

Now as with everything 'Meshy', the way I see things, my approach is simply
a logical extension of the approaches of Torben Pedersen and Matt Blaze.
Others are saying that I am actually doing something different. And that is
quite possible given how much I am bending stuff to meet my requirements.


For example, when an administration device is provisioning a new
application keypair to a connected device, the conventional way to do that
is to generate the new keypair, encrypt it under the device encryption
public key and publish the result to the device in some fashion.

If we are using DH/ECDH, we can do the same thing in a much better way.

Let the device keypair be {y, e^y}. The administrator generates a new
keypair {x, e^x) and sends it to the device via some encrypted channel. The
device then calculates the application private key a= x+y. The public key
e^a = e^x. e^y.

The administrator has no knowledge of the application private key. All they
have done is to choose a random number. The device gives no reply to the
administrator so the administrator has learned absolutely nothing. I would
say 'zero' but it is not a zero knowledge proof, it is proof that the
administrator learns nothing.


The same is true of the construction of recryption key sets only this time
we start from a public key pair and split it into two.

Let the group recryption key be {g, e^g}. To add a new member to the group,
the administrator generates a new random value r which is smaller than the
order of the DH group (the prime minus one for DH, different for ECDH).

The administrator then generates the decryption key d = (g-r+o) mod o and
sends this to the user via some encrypted channel. This then allows the
recryption service and the group member to perform private key operations
but only if they both participate. Neither can do decryption on their own.

This time we do not actually achieve zero knowledge but we are very close.
The recryption service only has a random number, it does not have any
information that requires knowledge of the key. Unfortunately, decryption
key has to be communicated to the group member at some point. So we do
create additional information that an attacker could exploit.

This is not a concern for my application as the encryption of the
decryption key blob is at least as strong as the encryption of any message
under the encryption blob. So maybe its blob-complete or something.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180831/221177d2/attachment.html>


More information about the cryptography mailing list