<div dir="ltr">Hi everyone,<br><div class="gmail_quote"><div dir="ltr"><br>Join us next tomorrow for the first busec seminar of the year. Ranjit will tell us about privacy-preserving smart contracts and their relationship to Bitcoin. As usual, lunch follows seminar.  <br><br>The following week, our own Omer Paneth defends his PhD thesis on code obfuscation, and the week after that, Leo Reyzin will tell us about his new work on memory-hard hash functions. Hope to see you all!<br><br>Sharon<br><br>BUsec Calendar:  <a href="http://www.bu.edu/cs/busec/" target="_blank">http://www.bu.edu/cs/busec/</a><br><br>The busec seminar gratefully acknowledges the support of BU&#39;s Center for Reliable Information Systems and Cyber Security (RISCS). <br><br>******<br><br>Privacy-Preserving Smart Contracts<br>Speaker: Ranjit Kumaresan, MIT<br>Time: September 21, 2016, 10-11:30am<br>Place: Hariri Seminar Room at 111 Cummington St, Boston MA<br><br>Abstract:<br>Cryptographic technologies such as encryption and authentication provide stability to modern electronic commerce. Recent technologies such as Bitcoin  have the potential to further enhance the way we conduct electronic commerce. In this talk, I will describe my work in developing a robust theory of privacy-preserving contracts that are self-enforcing and do not require third-party intervention. Starting from Bitcoin-inspired abstractions, the theory enables building provably secure and scalable applications on top of cryptocurrencies. <br>
</div>
</div><br>*****<br clear="all"><br>PhD Thesis Defense! (Code Obfuscation)<br>Speaker: Omer Paneth, BU<br>Time: September 28, 2016, 10-11:30am<br>Place: Hariri Seminar Room at 111 Cummington St, Boston MA<br><br>Abstract:Code is said to be obfuscated if it is intentionally difficult for humans to understand. Obfuscation is often used to conceal sensitive implementation details such as proprietary algorithms or licensing mechanisms.<br><br>A general-purpose obfuscator is a compiler that obfuscates arbitrary code (in some particular language) without altering the code&#39;s functionality.  Ideally, the obfuscated code would hide any information about the original code that cannot be obtained by simply executing it.<br><br>The potential applications of general-purpose obfuscators extend beyond software protection. For example, in computational complexity theory, obfuscation is used to establish the intractability of a range of computational problems. Obfuscation is also a powerful tool in cryptography, enabling a variety of advanced applications.<br><br>The possibility of general-purpose obfuscation was put into question by Barak et al. [CRYPTO 01], who proved that such obfuscation cannot have ideal security. Nevertheless, they leave open the possibility of obfuscation with weaker security properties, which may be sufficient for many applications. Recently, Garg et al. [FOCS~13] suggested a candidate construction for general-purpose obfuscation conjectured to satisfy these security properties.<br><br>In this thesis we study the feasibility and applicability of different notions of secure obfuscation.<br><br>In terms of applicability, we prove that finding a Nash equilibrium of a game is intractable, based on a weak notion of obfuscation known as indistinguishability obfuscation.<br><br>In terms of feasibility, we focus on a variant of the Garg at el. obfuscator that is based on a recent construction of cryptographic multilinear maps [Garg et al. EUROCRYPT 13]. We reduce the security of the obfuscator to that of the underlying multilinear maps. Our first reduction considers obfuscation and multilinear maps with ideal security.<br><br>We then study a useful strengthening of indistinguishability obfuscation known as virtual-grey-box obfuscation. We identify security properties of multilinear maps that are necessary and sufficient for this notion.<br><br>Finally, we explore the possibility of basing obfuscation on weaker primitives. We show that obfuscation is impossible even based on ideal random oracles.<br><br>*****<br clear="all">On the Memory-Hardness of scrypt<br>Speaker: Leonid Reyzin, BU<br>Time: October 5, 2016, 10-11:30am<br>Place: Hariri Seminar Room at 111 Cummington St, Boston MA<br><br>The key derivation function scrypt (Percival, 2009) is defined as the result of n steps, where each step consists of selecting one or two previously computed values (the selection depends on the values themselves) and hashing them. It is conjectured that this function is memory-hard.<br><br>We show that indeed scrypt is maximally memory-hard in the parallel random oracle model. Specifically, we show that the product of memory and time used during the computation of scrypt must be Theta(n^2). Moreover, even if the amount of memory used fluctuates during the computation, we show that the sum of memory usage over time (a.k.a. &quot;cumulative memory complexity&quot; introduced by Alwen and Serbinenko in 2015) is Theta(n^2). This suggests that computation of multiple instances of scrypt cannot be improved via amortization. Our result holds even if the adversary is allowed to make an unlimited number of parallel random oracle queries at each step.<br><br>Previous work (Alwen, Chen, Kamath, Kolmogorov, Pietrzak, Tessaro 2016) showed a lower bound of Omega( n^2 / log^2 n) on the memory complexity of scrypt in more restricted models, where the adversary was assumed to store only random oracle outputs or specific functions of them. Our result improves the bound quantitatively by eliminating the log^2 n factor and qualitatively by allowing arbitrary storage by the adversary.<br><br>Joint work with Joel Alwen, Binyi Chen, Krzysztof Pietrzak, and Stefano Tessaro.<br><br></div>