Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5C3127871 for ; Mon, 10 Apr 2017 16:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaHUCkU2PjNt for ; Mon, 10 Apr 2017 16:34:40 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98FD127011 for ; Mon, 10 Apr 2017 16:34:39 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id h125so78493471lfe.0 for ; Mon, 10 Apr 2017 16:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KeQ0X1DIPFqgZkMgchNCOZZnIQz3zunJCdlJ6JFBf+8=; b=dJ0f8hR5IccjoFWOTh295xmWkujnSd5cJMH2GbICQtCPJ4OQ+MCbh/ixlG6BlZciBn CYgTJmSYx1B2JWPUilKzYprSXnCjvn80f0tn8LcjLo5Fy/ha84BF/yUvjOrw60+psgZe qRxJRdQWCh+y5JV5pk8ViQyWBfIpthrckWmDA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KeQ0X1DIPFqgZkMgchNCOZZnIQz3zunJCdlJ6JFBf+8=; b=SXasiHfSOloKfLNmZGtM7XrhY7O1Am+YAJLb95irZPHuOFUPiqDnnjZ3XIbUIWS7Gp nSrYDAAC5klNZCeZ1R/0RVGiNPB+ay/Trod+RwxrePdPsZyYfnu53EG5nK8WYRdkbnfX 5G0Ccedpq5t5szDVBaIpp+wI6Qxl4vhM4XP9snpy/fJNhN1ESgTe/Z9ADjyJ0oIBFKg9 CVM17YMUsfEvVoWEbt2JRJ7fWiCZvRXd6NLfAkX3ZuDbGCXccKlN2tVNU41/ASsgfWRV YSe4uRGFMdGUDhrGuu0L6kBg+M7icvPWbVdYlzWWrUE9Fn0IlWD+V0KYKElpoHA/s9Uz KbMA== X-Gm-Message-State: AFeK/H1y+huDP3GcbgPSfXCrulxoO9ndXiJyl+SaFJ0gBYFwJrJ0LjSfcpAUD+MZPlWpAtr0mNfvImebD4ggdBiH X-Received: by 10.25.43.205 with SMTP id r196mr16248578lfr.116.1491867277721; Mon, 10 Apr 2017 16:34:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.9 with HTTP; Mon, 10 Apr 2017 16:34:37 -0700 (PDT) In-Reply-To: References: From: George Tankersley Date: Mon, 10 Apr 2017 19:34:37 -0400 Message-ID: To: Saba Eskandarian Cc: Ben Laurie , "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a11410dd4241cb9054cd86bd9 Archived-At: Subject: Re: [Trans] Privacy-preserving proof of sct exclusion X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 23:34:42 -0000 --001a11410dd4241cb9054cd86bd9 Content-Type: text/plain; charset=UTF-8 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 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 > *Sent:* Monday, March 27, 2017 2:48:11 AM > > *To:* Saba Eskandarian > *Cc:* trans@ietf.org > *Subject:* Re: [Trans] Privacy-preserving proof of sct exclusion > > > > On 27 March 2017 at 05:16, Saba Eskandarian 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 >> *Sent:* Sunday, March 26, 2017 9:46:21 AM >> *To:* Saba Eskandarian >> *Cc:* trans@ietf.org >> *Subject:* Re: [Trans] Privacy-preserving proof of sct exclusion >> >> >> >> On 25 March 2017 at 22:39, Saba Eskandarian 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 >>> https://www.ietf.org/mailman/listinfo/trans >>> >>> >> > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --001a11410dd4241cb9054cd86bd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 (R= SA-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> wrote:
Since there wasn't time to present these privacy preserving proofs a= t 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 a= s well (http://forum.stanford.edu/events/2017security= .php). The workshop is aimed at a non-specialist audience, but I still hope to ge= t to much of the content I meant to present at ietf.=C2=A0

thanks,
~saba
From: = Ben Laurie <benl@go= ogle.com>
Sent: Monday, March 27, 2017 2:48:11 AM

To: Saba Eskandarian
Cc: trans@ietf.o= rg
Subject: Re: [Trans] Privacy-preserving proof of sct exclusion
=
=C2=A0


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

Thanks for the prompt=C2=A0feedback!=C2=A0I'll make sure to address these comments in my talk, and I'm looki= ng forward to discussing design options in person. I suspect that the flexi= bility of the=C2=A0tools and techniques we use as well as the=C2=A0associated engineering and privacy tradeoffs=C2=A0will make for a= n interesting discussion.


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


Thanks,

~saba

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


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

Hello,

I'm on the agenda for Tuesday's meeting to share a privacy-preservi= ng 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 t= o 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 audi= ence, but it can be found here: https://arxi= v.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 time= stamp order, but they aren't. I can't immediately think of a way to= get that property without also considerably increasing time to inclusion i= n 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 in= clusion is also likely to increase MMD.

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

~saba


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




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


--001a11410dd4241cb9054cd86bd9--