Conference madness, part III: IdeaLab 2013

A photo of the whole group on the last day of the workshop. Photo courtesy of ICERM.

After Sage Days (technically, though, I left a day early), I headed to Providence for the IdeaLab 2013 workshop. This was the first workshop of its kind at ICERM. Modeled after a similar program in France, the IdeaLab invited about 20 early career mathematicians to work on two relevant applied math problems, in the areas of climate change modeling and cryptography. I think the idea was to invite many people and then have them pick which problem they would rather work on (and this might be the spirit of it in the future, from what I heard there). But given that the two problems were so different, I think the organizers knew that they were inviting people so that roughly half would go to each problem. It was pretty clear that for me, as a number theorist, the cryptography project made a lot more sense.

 I arrived late on the first day, because I took the red-eye from Seattle to Boston and I still had to get to Providence. Again, even though I did this to be able to stay at Sage Days as long as possible, this seemed like a bad idea once I got to ICERM completely exhausted (not the best way to start a workshop). The first day was pretty mild, though, since we essentially only did introductions. First, every participant (in alphabetical order, which worked out well for me), gave a 3-slide, 6-minute talk about their research. This was more challenging to prepare than I expected, but actually quite fun. How do you summarize your research so that it fits into three slides, and so that it makes sense to everyone else? All of us did a decent job, although I think this makes people more inclined towards the technical rather than expository. It seemed like what happened to a lot of people is that they would “tune out” the people who were talking about unfamiliar things. So, for example, the applied mathematicians would tune out my talk about number theory, and some number theorists would tune out the applied math stuff. I am generally of the opinion that you shouldn’t tune anything out, even if you don’t understand most of it. I always find that paying attention to talks gives me good ideas later on for teaching, research, and suggesting problems to students, to name a few examples. I was however, unintentionally tuning most things out, because I was just so tired.

Monday afternoon and the morning of Tuesday were devoted to introductory talks for the two projects. In my project’s case, which focused on working “Towards Efficient Homomorphic Encryption”, the talks were given by the project leaders, Henry Cohn (Microsoft Research), Jeff Hoffstein, and Joe Silverman (both at Brown University). I thought all of their talks were great and gave a good idea of what the problem was, what had been done so far, and how crazy difficult it is. I thought it was funny that we were told repeatedly that we should keep our expectations low (that is, don’t think you’ll solve this problem in a week).

My working group. From left to right, Ekin Ozman, me, David Lowry, Peter Jaehyun Cho, and Jean-Francois Biasse. Photo courtesy of ICERM.

The first day of us “working” on this problem was simultaneously terrifying and exciting. I mean, the nice thing of working on a very difficult problem that you have never thought about before, and that you have been told you have almost no hope of solving in a week, is that it frees your mind completely from any sort of pressure. It’s weird, but it is so great to work on a problem without thinking that you have to solve the problem. You just do what you can, and work really hard, but the fact that no one is expecting you to get it right helps you focus more completely on it. I hope that makes sense. I’m not sure my group mates all thought about it the same way, and it may just be because they’re more used to getting things right than I am. I always feel confused, so I’m happy when someone just tells me “it’s OK to be confused, you’re supposed to be confused”.

In a nutshell, most cryptosystems are developed from hard problems in mathematics, like the factorization problem (i.e. it’s hard to factor big numbers) and the discrete log problem (e.g. finding “logs mod p”). The homomorphic encryption problem also asks that the encryption function be a ring homomorphism. Why do we want that? Imagine that you have a bunch of data, and you want to do some computations, like multiply and add, but you can’t do it in your own computer, so you want to send it to “the cloud”. The idea is, maybe there is some way to encrypt the data, and send it to the cloud, and get the cloud to do those computations without ever being able to see the actual data. Then it sends you the encrypted computation, and you (and only you) can decrypt it. It’s a clever idea, but it’s very hard to do! Most cryptosystems that end up being sort of homomorphic are only so for one operation. The only known homomorphic encryption systems at the moment are too inefficient to really use (you can encrypt one bit in two days!). So our goal was to find new hard problems that may have a chance to be homomorphic with respect to two operations. You can see why this was very hard, right?

Things got more focused after the second day. We had many ideas for how to attack the problem, in fact, maybe we had too many ideas. We also had slightly different backgrounds, so it was cool to see what other people were coming up with. Once we all had a hard problem or something we wanted to think about, we got to work and we worked hard. Pretty much until Thursday night we were still bouncing ideas off each other and coming up with new examples. One thing that was terrifying at first, but later on turned out to be good for us, was that our mentors pretty much left everything in our hands. They didn’t want to influence our ideas too much, but they did come around every once in a while to give us feedback and to hear us out. I think that was a perfect balance of mentoring and letting people work on their own.

On Friday each group presented their work, and I thought everyone did an impressive amount of work and thinking in such a short time. I also thought the presentations were really good. There were special guests in the audience, from NSF and other funding agencies, which added a bit more pressure but I think that just made people do a better job. Their questions during the presentations were also very good and I think helped people with their ideas. After the group presentations, there was a panel of the special guests, where they talked about funding opportunities for projects of this type.

All in all, I’m really happy I had the opportunity to participate in this workshop. It was literally a week spent coming up with ideas for solutions to hard problems, rather than actual solutions to these problems. So, the IdeaLab really lived up to its name! I’m not sure the idea I was working on will end up being that fruitful (but I’m certainly going to keep thinking about it), but I do think working on this has opened my mind to finding solutions to the homomorphic encryption problem. Now that I’m aware of this problem, and how to think about it, I think I’m going to be more likely to find or discover a hard problem that could be good for homomorphic encryption. And even if nothing else comes out of this, it was still a really fun experience to have.

So how about you, dear readers? Would you consider attending a workshop like this? Have you? Please share any thoughts or comments in the comments section below.