Re: [Trans] Privacy-preserving proof of sct exclusion

Hi George,

Thanks for reading the paper!

Yes, the signatures we use in our scheme are completely unrelated to the normal operation of the log and only come into play in the event of log misbehavior. Ordinary log behavior can continue to use standard signatures.

The important property of the signatures we use in our scheme is the "proof of knowledge of a signature." The idea is to use this proof to show that we have committed values that actually correspond to objects on the log. We then use range proofs and other simpler zero knowledge proofs on commitments to show that they fulfill the relationships required to complete the proof.

thanks and let me know if you have any more questions,

~saba

________________________________
From: George Tankersley <gtank@cloudflare.com>
Sent: Monday, April 10, 2017 4:34:37 PM
To: Saba Eskandarian
Cc: Ben Laurie; trans@ietf.org
Subject: Re: [Trans] Privacy-preserving proof of sct exclusion

Hey Saba,

Read this paper with interest. Thanks for sharing!

Am I correct that the range proof signatures are completely unrelated to normal log operation? That is, the ordinary log behavior continue to use commonly supported algorithms (RSA-PKCS1v15 or ECDSA) with only the intermediate range values being signed to admit proofs of signatures under commitment?

On Wed, Apr 5, 2017 at 12:27 PM, Saba Eskandarian <sabae@stanford.edu<mailto:sabae@stanford.edu>> wrote:
Since there wasn't time to present these privacy preserving proofs at the meeting last week, I thought it might be of interest to the list that I'll be presenting the idea at Stanford's annual security workshop next Monday. I believe it will be streamed on youtube, and you may find the other presentations interesting as well (http://forum.stanford.edu/events/2017security.php). The workshop is aimed at a non-specialist audience, but I still hope to get to much of the content I meant to present at ietf.

thanks,
~saba
________________________________
From: Ben Laurie <benl@google.com<mailto:benl@google.com>>
Sent: Monday, March 27, 2017 2:48:11 AM

To: Saba Eskandarian
Cc: trans@ietf.org<mailto:trans@ietf.org>
Subject: Re: [Trans] Privacy-preserving proof of sct exclusion

On 27 March 2017 at 05:16, Saba Eskandarian <sabae@stanford.edu<mailto:sabae@stanford.edu>> wrote:

Thanks for the prompt feedback! I'll make sure to address these comments in my talk, and I'm looking forward to discussing design options in person. I suspect that the flexibility of the tools and techniques we use as well as the associated engineering and privacy tradeoffs will make for an interesting discussion.

Afraid I won't be there, but looking forward to hearing more.

Thanks,

~saba

________________________________
From: Ben Laurie <benl@google.com<mailto:benl@google.com>>
Sent: Sunday, March 26, 2017 9:46:21 AM
To: Saba Eskandarian
Cc: trans@ietf.org<mailto:trans@ietf.org>
Subject: Re: [Trans] Privacy-preserving proof of sct exclusion

On 25 March 2017 at 22:39, Saba Eskandarian <sabae@stanford.edu<mailto:sabae@stanford.edu>> wrote:

Hello,

I'm on the agenda for Tuesday's meeting to share a privacy-preserving proof of sct exclusion from a log (I think Eran alluded to this work in a message a while ago).

My posted slides will not include many words, so I wanted to share a link to the preprint of our academic paper on the subject in case anyone wants to read the details there. The paper is targeted at a somewhat different audience, but it can be found here: https://arxiv.org/abs/1703.02209

Thanks and looking forward to meeting you all next week!

Cool, but I immediately see a problem - you require logs to be in timestamp order, but they aren't. I can't immediately think of a way to get that property without also considerably increasing time to inclusion in the log.

That seems undesirable - in fact, we're trying to go the other way, i.e. reduce time to inclusion, in general.

Also, engineering reality doesn't change, so increasing time to inclusion is also likely to increase MMD.

Secondly, its interesting, but doesn't seem particularly useful: when an SCT corresponds to a cert that has not been included, you want to reveal the cert, not hide it. What you want to hide is who is revealing it.

~saba

_______________________________________________
Trans mailing list
Trans@ietf.org<mailto:Trans@ietf.org>
https://www.ietf.org/mailman/listinfo/trans

_______________________________________________
Trans mailing list
Trans@ietf.org<mailto:Trans@ietf.org>
https://www.ietf.org/mailman/listinfo/trans