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.
(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?