Several things. The instructor, David Evans of the University of Virginia, has a really infections goofy enthusiasm that keeps your interest. He covered a good range of topics, with a nice mix of practical, historical, and theoretical. Here's very short summary from the syllabus:
Unit 1: Perfect Ciphers. What makes certain ciphers perfect, how the Lorenz Cipher was broken
Unit 2: Symmetric Encryption. Sending messages when two people share a secret
Unit 3: Key Exchange. Technics to establish a shared secret
Unit 4: Asymmetric Encryption. Exchanging information using public key cryptosystems
Unit 5: Public Key Protocols. Encrypted key exchange, certificates, secure commerce
Unit 6: Using Cryptographic Primitives. How cryptography can be useful for anonymizing communication, voting, and digital cash
Unit 7: Secure Computation. Computing without exposing data
In a little more detail:
Unit 1 introduced the subject, covering OTP and giving an interesting historical account of the Lorenz cipher and the development of Colossus.
Unit 2 talked about Kolmogorov complexity, randomness, PRNGs, block cipher modes, hash function, password storage.
Unit 3 was about key exchange, mostly Diffie Hellman.
Unit 4 covered asymmetric systems, concentrating on RSA.
Unit 5 covered EKE, ssh, TLS, and certificates.
Unit 6 covered traffic analysis, onion routing, TOR, voting (Mixnet), centralized digital cash (based on blind signatures and an identity list scheme to deanonymize double spenders), decentralized digital cash (Bitcoin).
Unit 7 covered secure computation. In particular the garbled circuit protocol to let Alice and Bob evaluate a logic circuit together without revealing their inputs to each other.
Each unit had around 5 or 6 homework problems. Most were multiple choice, but there were several that involved programming.
There were also several optional challenge problems. These were instructive and a lot of fun. Here is a description of the challenge problems:
From unit 1: We were given two bit strings of the same length, about 700 bits each, and told they were the result of running two messages encoded as 7-bit ASCII through a one time pad, where the operator goofed and used the same pad for both messages. Figure out the messages.
From unit 2: we were given a list of 126 32-bit numbers, and asked to figure out the next number. Based on the material in unit 2, it was obvious this was supposed to be a weak PRNG. It turned out to be weaker then they intended--it was periodic with period 64, making it easy to solve the challenge by inspection.
From unit 3: we were given the public information from a Diffie-Hellman key exchange between Alice and Bob, AND we were told the number of multiplications that were required when Alice computed the shared key from the her secret and the data from Bob. Our task was to decrypt the message that Alice and Bob then exchanged.
From unit 4: we were given 16 separate public RSA keys, and for each we were given the cipher text of a message encrypted with that key. Our challenge was to find the plain text. This was a particularly fun challenge. I'll describe it in more detail later.
From unit 5: this was a simplified version of the BEAST attack from last year against SSL. They set up a server that operated as follows:
* It contained a secret message, M.
* We could open a session, and receive a session token.
* We could then send the server a message. The server takes our message, appends its secret message, encrypts the result with AES in CBC mode, and sends the cipher text back to us. For a given session, the server uses a fixed key, and the IV each time is the last block of the cipher text from the previous exchange.
Our task: find out M.
The final challenge was released with the final exam. Alice and Bob wish to communicate, but need our help. They each have a server. There are four commands we can do via CGI on their server:
* Open a session. That gets us a token and half of a Diffie-Hellman exchange to establish a key for that session.
That sounds really fun. We build an internal application (which I was going to release publicly but instead keep rewriting and rewriting because I don't trust my code enough) that does a lot of this, but at much more nitty-gritty level (ie, use inference techniques to figure out block cipher modes, that sort of thing). If you're ever interested in more challenges like this, drop me a line; I have 'em.
(I watched some of the video stuff last night, and I agree, he's really engaging; moreso than Dan Boneh was for the Stanford crypto course).
How good was the block cipher coverage? Did you end up understanding what you might look for if you had to break someone else's (say) CTR mode stream encryptor, that kind of stuff?
There was not a lot of low level stuff on block ciphers. In an early unit, he said that while it is interesting to go into how block ciphers work at the low level, he was going to omit that to get on to application of cryptography (I believe the official title of the course is "Applied Cryptograph"). He emphasized that very very few people should be designing their own block ciphers or doing their own implementation of existing designs--almost everyone should be using a library implementation that has been well tested by experts.
I haven't taken the Stanford course (I'd like to--but my schedule has just not worked out to allow it yet), but I did go look at the slides from a few of the lectures there and it appeared that they go into more detail at the lower level on ciphers and hashes. I got the impression that the Stanford course and the Udacity course would compliment each other quite a bit.
As far as breaking someone's encryptor goes, there would be some mention of how things could be exploited if the thing you were attacking had certain flaws, usually as motivation to explain why things were done a certain way. E.g., if you don't have a random nonce here, someone will be able to do this and that will reveal something about your plaintext...that kind of thing.
For the specific example of trying to break someone's system that is using a block cipher in CTR mode to make a stream encryptor, I think a student finished the Udacity course and did well would know enough to:
(1) recognize that CTR mode is essentially using the block cipher to generate the key for a OTP, so flipping bits in the ciphertext flips the corresponding bits in the decrypted plaintext. Hence, if the attacker can find out through some means enough information about the structure of the messages so as to predict what is in the plaintext (account number to receive the deposit, for instance) he can make meaningful changes (assuming the system does not include some kind of check on the message integrity).
(2) recognize that if the key and counter sequence are ever reused the consequences are essentially the same as reusing a OTP key, and so focus on how the keys and counters are being initialized.
6 comments
[ 2.8 ms ] story [ 36.2 ms ] threadhttp://www.youtube.com/watch?v=CdsS8jFVv2c
http://www.youtube.com/watch?v=zJxVXyvccgI
http://www.youtube.com/watch?v=4UF9zYU0jZI
http://www.youtube.com/watch?v=JRPu-vUdJU0
They range from under two minutes to a bit over 3 minutes.
PS: that course is excellent. If you are at all interested in cryptography, I highly recommend it.
Unit 1: Perfect Ciphers. What makes certain ciphers perfect, how the Lorenz Cipher was broken
Unit 2: Symmetric Encryption. Sending messages when two people share a secret
Unit 3: Key Exchange. Technics to establish a shared secret
Unit 4: Asymmetric Encryption. Exchanging information using public key cryptosystems
Unit 5: Public Key Protocols. Encrypted key exchange, certificates, secure commerce
Unit 6: Using Cryptographic Primitives. How cryptography can be useful for anonymizing communication, voting, and digital cash
Unit 7: Secure Computation. Computing without exposing data
In a little more detail:
Unit 1 introduced the subject, covering OTP and giving an interesting historical account of the Lorenz cipher and the development of Colossus.
Unit 2 talked about Kolmogorov complexity, randomness, PRNGs, block cipher modes, hash function, password storage.
Unit 3 was about key exchange, mostly Diffie Hellman.
Unit 4 covered asymmetric systems, concentrating on RSA.
Unit 5 covered EKE, ssh, TLS, and certificates.
Unit 6 covered traffic analysis, onion routing, TOR, voting (Mixnet), centralized digital cash (based on blind signatures and an identity list scheme to deanonymize double spenders), decentralized digital cash (Bitcoin).
Unit 7 covered secure computation. In particular the garbled circuit protocol to let Alice and Bob evaluate a logic circuit together without revealing their inputs to each other.
Each unit had around 5 or 6 homework problems. Most were multiple choice, but there were several that involved programming.
There were also several optional challenge problems. These were instructive and a lot of fun. Here is a description of the challenge problems:
From unit 1: We were given two bit strings of the same length, about 700 bits each, and told they were the result of running two messages encoded as 7-bit ASCII through a one time pad, where the operator goofed and used the same pad for both messages. Figure out the messages.
From unit 2: we were given a list of 126 32-bit numbers, and asked to figure out the next number. Based on the material in unit 2, it was obvious this was supposed to be a weak PRNG. It turned out to be weaker then they intended--it was periodic with period 64, making it easy to solve the challenge by inspection.
From unit 3: we were given the public information from a Diffie-Hellman key exchange between Alice and Bob, AND we were told the number of multiplications that were required when Alice computed the shared key from the her secret and the data from Bob. Our task was to decrypt the message that Alice and Bob then exchanged.
From unit 4: we were given 16 separate public RSA keys, and for each we were given the cipher text of a message encrypted with that key. Our challenge was to find the plain text. This was a particularly fun challenge. I'll describe it in more detail later.
From unit 5: this was a simplified version of the BEAST attack from last year against SSL. They set up a server that operated as follows:
* It contained a secret message, M.
* We could open a session, and receive a session token.
* We could then send the server a message. The server takes our message, appends its secret message, encrypts the result with AES in CBC mode, and sends the cipher text back to us. For a given session, the server uses a fixed key, and the IV each time is the last block of the cipher text from the previous exchange.
Our task: find out M.
The final challenge was released with the final exam. Alice and Bob wish to communicate, but need our help. They each have a server. There are four commands we can do via CGI on their server:
* Open a session. That gets us a token and half of a Diffie-Hellman exchange to establish a key for that session.
* Send hal...
(I watched some of the video stuff last night, and I agree, he's really engaging; moreso than Dan Boneh was for the Stanford crypto course).
How good was the block cipher coverage? Did you end up understanding what you might look for if you had to break someone else's (say) CTR mode stream encryptor, that kind of stuff?
I haven't taken the Stanford course (I'd like to--but my schedule has just not worked out to allow it yet), but I did go look at the slides from a few of the lectures there and it appeared that they go into more detail at the lower level on ciphers and hashes. I got the impression that the Stanford course and the Udacity course would compliment each other quite a bit.
As far as breaking someone's encryptor goes, there would be some mention of how things could be exploited if the thing you were attacking had certain flaws, usually as motivation to explain why things were done a certain way. E.g., if you don't have a random nonce here, someone will be able to do this and that will reveal something about your plaintext...that kind of thing.
For the specific example of trying to break someone's system that is using a block cipher in CTR mode to make a stream encryptor, I think a student finished the Udacity course and did well would know enough to:
(1) recognize that CTR mode is essentially using the block cipher to generate the key for a OTP, so flipping bits in the ciphertext flips the corresponding bits in the decrypted plaintext. Hence, if the attacker can find out through some means enough information about the structure of the messages so as to predict what is in the plaintext (account number to receive the deposit, for instance) he can make meaningful changes (assuming the system does not include some kind of check on the message integrity).
(2) recognize that if the key and counter sequence are ever reused the consequences are essentially the same as reusing a OTP key, and so focus on how the keys and counters are being initialized.