Cryptographic Protocols

Markus Jakobsson

Graduate Division

Computer Science



Most commercial transactions involve two or more parties with different objectives, some of which may try to take advantage of others. For most “real-world” applications, many possible dishonest strategies are evident, and the transactions are designed with these in mind. Imagine, for example, a teller machine where you swipe your ATM card, enter the amount to withdraw, and then take the corresponding amount of money from a stack of bills. Imagine further anonymous credentials in the shape of drivers licenses that do not divulge any identifying information, but where the right to drive a vehicle would be associated with the ownership of such a license. It is clear that while both of these “implementations” work well in an environment where nobody cheats, it would also be highly questionable to employ them in an imperfect society.


Cryptographic protocol design strives to identify and protect against abusive strategies in applications where standard ``real-world'' defenses fail.


To properly defend against attacks, we must first practice ourselves to become aware of the nature of potential threats. These may be unauthorized access to resources or rights, as in the examples involving teller machines and drivers licenses. Examples of other types of unauthorized access are piracy (namely dishonest access to a service or product); unauthorized sharing of information; unauthorized attempts at forging or modifying contracts, and similar. Another type of threat is the violation of other users' privacy, whether this relates to their actions, location, memberships and associations, and more. Yet another type threat is inappropriate use of system features -- such as the use of encryption by drug dealers and the use of steganographically hidden communication by terrorists. (In these examples, the user may simply use available applications in a way that technically corresponds to their intended use, but for purposes that are not endorsed by society.)


Thus, the design of a system requires not only an understanding of its wanted behavior (e.g., to allow people to withdraw money resp. give evidence that they belong to a certain group of people, such as “people who may drive a car”.) It is also crucial to understand the unwanted types of behavior, whether these constitute attacks on the system itself, or simply stray from the intended use. Moreover, it is important to understand the available tools and how these can be employed to reach a set of goals. This course will address these issues by the discussion of various applications, abuses, and cryptographic techniques.


The course will have one technical component, and one component relating to understanding and removing protocol flaws. To understand the nature of the second component, consider the following non-technical example: Most realtors do not request identification from apartment owners picking up or replacing keys of apartments they are listing. How could this be abused?


Full course description (ps, pdf).


Powerpoint slides corresponding to the lectures will be made available on my corporate homepage as soon as the course starts. A preliminary schedule is already available.