[Busec] BUsec upcoming talks: (Cynthia Dwork, Nir Bitanski, Robert Lychev )

Sharon Goldberg goldbe at cs.bu.edu
Mon Apr 22 14:36:25 EDT 2013


Another reminder for Nir Bitanski from Tel Aviv University's reading group
talk on "On the Impossibility of Approximate Obfuscation and Applications
to Resettable Cryptography" at MIT (abstract below and full paper at *
https://eprint.iacr.org/2012/729*). Please come and enjoy. Breakfast will
be provided.

At the following week's seminar, Robert Lychev (GATech/BU) will give a talk
on routing security, and on the Wednesday of that week, we are very excited
to host a distinguished lecture by Cynthia Dwork on her new research area,
"Fairness Through Awareness". Abstract below.  Hope to see you
all there.


BUsec Calendar:  http://www.bu.edu/cs/busec/
BUsec Mailing list:  http://cs-mailman.bu.edu/mailman/listinfo/busec
How to get to BU from MIT:  Try the CT2 bus or MIT's "Boston Daytime


> Speaker: Nir Bitansky
> Venue: MIT, 32-D463 (Star)
> Time: Apr. 23rd, 9:00am --11:00am
> ==============================================
> On the Impossibility of Approximate Obfuscation
> and Applications to Resettable Cryptography
> -----------------------------------------------------------------
> The traditional notion of program obfuscation requires that an obfuscation
> P' of a program P computes the exact same function as P, but beyond that,
> the code of P' should not leak any information about P. This strong notion
> of virtual black-box security was shown by Barak et al. (CRYPTO 2001) to be
> impossible to achieve, for certain unobfuscatable function families. The
> same work raised the question of approximate obfuscation, where the
> obfuscated P' is only required to approximate P; that is, P' only agrees
> with P with high enough probability on some input distribution.
> We show that, assuming trapdoor permutations, there exist families of
> robust unobfuscatable functions for which even approximate obfuscation is
> impossible. Specifically, obfuscation is impossible even if the obfuscated
> P' is only required to agree with P with probability slightly more than
> 1/2, on a uniformly sampled input (below 1/2-agreement, the function
> obfuscated by P, is not uniquely defined). Additionally, assuming only
> one-way functions, we rule out approximate obfuscation where P' may output
> \bot with probability close to 1 but otherwise must agree with P.
> We demonstrate the power of robust unobfuscatable functions by exhibiting
> new implications to resettable protocols. Concretely, we reduce the
> assumptions required for resettably-sound zero-knowledge to one-way
> functions, as well as reduce round-complexity. We also present a new
> simplified construction of a simultaneously-resettable zero-knowledge
> protocol, based on one-way functions, and any simultaneously-resettable
> witness-indistinguishable protocol. Finally, we construct a three-message
> simultaneously-resettable witness-indistinguishable argument of knowledge
> (with a non-black-box knowledge extractor). Our constructions use a new
> non-black-box simulation technique that is based on a special kind of
> “resettable slots”. These slots are useful for a non-black-box simulator,
> but not for a resetting prover.
> Joint work with Omer Paneth.
> ================================================

Is the Juice Worth the Squeeze?  BGP Security in Partial Deployment
Speaker: Robert Lychev, GATech & BU
Date: Monday April 29, 2013 10AM
MCS137, 111 Cummington St, Boston


The Border Gateway Protocol (BGP) sets up routes between the smaller
networks that make up the Internet. However, BGP is vulnerable to such
serious problems as the propagation of bogus routing information due to
attacks or misconfigurations. The S*BGP protocols (Secure BGP, secure
origin BGP, BGPsec, etc) were proposed to address these issues, but the
transition to S*BGP is expected to be long and slow, with S*BGP coexisting
in “partial deployment” alongside BGP for possibly a very long time. We use
theoretical and  experimental analyses to study the security benefits
provided by partially-deployed S*BGP and show how the complex interactions
between S*BGP and insecure BGP can introduce new vulnerabilities and
instabilities into the interdomain routing system.

Fairness Through Awareness
Speaker: Cynthia Dwork, Microsoft Research, SVC
Date:  Wednesday May 1, 2013, 11AM
Hariri Institute, 111 Cummington St, Boston

"Why was I not shown this advertisement? Why was my loan application
denied? Why was I rejected from this university?"

This talk will address fairness in classification, where the goal is
to prevent discrimination against protected population subgroups in
classification systems while simultaneously preserving utility for the
party carrying out the classification, for example, the advertiser,
bank, or admissions committee. We argue that a classification is fair
only when individuals who are similar with respect to the
classification task at hand are treated similarly, and this in turn
requires understanding of sub cultures of the population. Similarity
metrics are applied in many contexts, but these are often hidden. Our
work explicitly exposes the metric, opening it to public debate.
(Joint work with Moritz Hardt, Toniann Pitassi, Omer Reingold, and
Richard Zemel.)

Our approach provides a (theoretical) method by which an on-line
advertising network can prevent discrimination against protected
groups, even when the advertisers are unknown and untrusted. We
briefly discuss the role of fairness in consumer objections to
behavioral targeting and explain how traditional notions of privacy
miss the mark and fail to address these. (Joint work with Deirdre

Finally, we discuss a machine learning instantiation of our approach,
in which the distance metric need not be given but can instead be
learned.  (Joint work with Toniann Pitassi, Yu Wu, and Richard Zemel.)

Sharon Goldberg
Computer Science, Boston University

Sharon Goldberg
Computer Science, Boston University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs-mailman.bu.edu/pipermail/busec/attachments/20130422/ff5eaaae/attachment.html>

More information about the Busec mailing list