All handouts in the course will be available here. The information given below may be updated during the course, in which case we will ping students with a post.

General Information

• Course description (170117)
• Rules for solving problems and handing in solutions UPDATED FOR 2017.

• Example of compiled solution set and the corresponding LaTeX source. Note that this is an example that should not be used to typeset any real set of solutions. It is only used to illustrate what is expected from students. There will be a separate template for each homework.

Latex and Running Ubuntu in a Virtual Machine on Windows

• The Not So Short Introduction to LaTeX (see also the template above).
• VM Ware Player (free for non-commercial use)
• Download Ubuntu ISO-file

To install Ubuntu in your VM Ware player, start the player, create a new virtual machine, and browse for the ISO-file. All you need to do is enter your name and password, the rest is taken care of by VM Ware player. When this is done you open a browser inside your Ubuntu and download ubuntu.tar.gz from this page. Look inside the scripts and comment out the things you do not want, the script is reasonably well documented.

Group Project

The goal of the project is give you a full stack experience of real-world cryptography. The results can serve as great work samples when you apply for a job.

• Part I (20P). Consider how a voter can authenticate itself in an electronic voting system. Write down descriptions of a few methods in about 4 pages (with reasonable margins and font size). Use your own judgement to determine how many schemes you describe, but it is more fun if you choose systems that are as diverse as possible, i.e., simply looking at Google login and Yahoo login is not a good solution.
  

  We will discuss everybody's solutions in class. Then you will pick one (not necessarily one of those you described) and go into more detail.
  

• Part II (20P). Choose an authentication scheme that allows both theoretical study and practical implementation. Unfortunately this reduces the set of possible choices. Kerberos and most likely biometrical schemes can not be used. BankID is somewhat special. The protocol is not available so it can not be used in this part, but it is perhaps too tempting as a real life example, so when you implement you can switch to it if you like.

  Then motivate your choice, and describe the scheme at an abstract level and argue as rigorously as you can that it is secure. This means: describing a security goal/definition, stating assumptions explicitly, stating security parameters, defining computations and messages sent, and argue that the system satisfies the security goal given the assumptions. Express this as precisely as you can. It is a good idea to play devil's advocate with yourself here. Try to break it in every way you can think of and understand why you fail.

  It does not mean describing things at a byte level. Use a mathematical style of writing and no pseudo-code that resembles real code. It is perfectly fine to simplify things you do not think are essential in your exposition and argument. The focus in this part of the project is to understand the key ideas of the scheme. Feel free to draw pictures, but if you do it by hand, then please use clear hand writing for any symbols.

• Part III and Part IV (20P+20P=40P). Choose an authentication scheme, implement a demo, describe how it works, demo it, and witness a demo. More precisely:
  
  1. You have considered several systems in Part I and Part II. Choose a system that is feasible for you to implement a mock-up client and possibly a server. Make sure that you read about the system at a technical level before you start coding. Ask yourself what libraries and APIs are available for a programming language that you like?
  2. Implement a demo client and if needed a server. The technical details differ depending on if you use a third party for authentication (e.g., BankID and Facebook), if the system is token based or signature based, if you use a browser or a stand-alone client etc. Any programming language can be used, but it is often a good idea to use one that is "native" to the APIs. Demo means demo, so don't try to implement everything from scratch.
  3. Describe the system at a technical level, e.g., what flags, options, configuration, packaging schemes are used. Determine if it is a faithful refinement of a sound abstract scheme. Are they "cheating" somewhere? Is the "cheating" sound? Security parameters? Try to identify weak points! Give also a brief assessment of APIs, documentation, unintuitive or dangerous ambiguities, and difficulties encountered, i.e., summarize your experience.
  4. Prepare a demo session targeting fellow students, and then explain and demo your system to another project group. Your session should take 20 min and involve use, browsing code, and a summary of your findings.
     
  5. Every group should give a demo to one other group (or one more on a volunteer basis if needed). Write a half-page about the demo you were given by the other group. Note if the group takes significantly more or less than 20 min.

Homework

• Homework I 
  • LaTeX solution template
  • Note that you can work in groups of at most three students as discussed in class for theoretical problems, but not for the implementation problems. Read the updated rules above.
  • Ciphertext-only attack on d × d Hill in O(d13^d). (there will be a homework problem based on this paper)
  • CORRECTION: In 6c) you can consider S to be padded with zeros to fix the mismatch between the support of S and the domain of RO, i.e., you can think of S a random variable of the form S'|0000....0 where S' is randomly distributed in {0,1}^128.
• Homework II

Slides From Lectures

Lecture slides for all lectures are available below. They will be updated regularly to reflect changes in the course and what is said and covered on the blackboard during lectures. Slides may be added or removed, but slides from given lectures will at most be corrected. It gives a good idea of the course content.

• Lecture slides 170117 (compiled for presentation with step-wise disclosure of items)
• Lecture slides 170117 (compiled to be printed)

About recording lectures

On KTH campus it is illegal to record audio or video of any lectures without the lecturer's explicit permission. This applies to all recordings, even those for your own use.

Why is this important?

The most important reason is that there are students with hidden identity at KTH. Leaking the identity of these students may jeopardize their safety. Examples include: political refugees, court witnesses, and people escaping domestic violence or threats. Due to personal experience with one of these examples, I take this very seriously.

Only a chosen few (not me) know who they are, so we have to behave as if they are in every class. If I allow recording, then I am responsible for making sure that recordings are done in such a way that no other students appear in the recording, and I simply do not have the time to do that.

Lectures are also structured differently depending on the audience, and if KTH lectures appear online we obviously want the audio and video to be of high quality.

Last year I had to "save" students from the involvement by the legal department by hunting down a bunch of copies and getting written statements from every student that had those that they were deleted and had not spread further.

Let us take pictures of the blackboard for everybody instead!

I do understand that you want to take pictures of the blackboard, so I suggest that:

1. before each lecture somebody volunteers to sit in the front and take pictures,
2. you send those pictures to me,
3. you delete them when I have acknowledged that I have them, and
4. I check them and post them on the handouts page for everybody.

I hope that you find this to be a reasonable solution!

....and I am going to assume that nobody recorded anything during the first two lectures unless you posted it online.