<div dir="ltr"><div class="gmail_default" style="font-size:small">OK, so I know what we normally mean when we talk about zero knowledge and the bit about the cave. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If we are using DH/ECDH, we can do the same thing in a much better way.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div></div>