GENERAL DESCRIPTION: The project consists of two parts: a written paper of 6-10 pages (single spaced), and a 20-minute presentation, with 5 minutes for questions.
PAPER: The paper should be clearly written and comprehensible by the other students in the class. The final version will be due the last day of class; a good first draft is due on 6 April 2010. I will read this and suggest revisions for you to implement in the final version. The paper must be typeset, and I encourage you to try using LaTeX (or plain TeX if you're a real hacker) to typeset it.
A good paper will include: motivating background information, clear definitions, interesting examples, one or two main results, and some nontrivial proofs. Pictures and diagrams are welcome, as is historical information, but not to the exclusion of some serious math.
SCHEDULE:
TOPICS: There are many interesting and accessible topics in cryptography. Here is a (still short) list of possibilities. If you find one interesting, first see what you can find out on the web about it, including pointers to books and math papers. I'll also be happy to guide you to accessible places, but would like to see what you're able to find on your own. (I expect to learn quite a bit!)
PRESENTATION: The presentation should last 20 minutes (which is both shorter and longer than it first seems). Rather than reading your paper, you need to think about how to present the material most effectively in an oral presentation. Technical details and detailed proofs should be avoided in favor of giving listeners a feel for the subject and why they should find it interesting. This is not a license for sloppy statements, but if you need to be vague about something too technical to present in a short amount of time, 'fess up.
You should probably use some sort of projector, either overhead transparencies or from a laptop, although writing on the blackboard might be appropriate instead. Examples and visuals are great, as are props (if appropriate). Handouts can be helpful to many, and can give you a place to put technical details or long-winded statements that you don't want to take the time to write down.
Everyone must practice their presentation in front of other students (not necessarily from Math 3094) and get feedback from them. The presenter should keep track of this feedback and forward it to me afterwards. Afterwards, the presentor will practice it again for me in my office and get feedback from me. This will make your final presentation to the entire class much more polished than if it were your first time.
Since giving and receiving feedback is a skill that benefits from explicit teaching, here is a handout on feedback that everyone should read before giving (or receiving) a practice presentation.
Back to the Math 3094 home page.
Back to my home page.