I agree with both Ptacek and Percival, with one caveat: the Ptacek statement should be "If you're not learning how to use crypto by coding attacks, you might no

I agree with both Ptacek and Percival, with one caveat: the Ptacek statement should be "If you're not learning how to use crypto by coding attacks, you might not actually be learning how to use crypto". Even within the academic community there has been recent upheaval over the value of proofs. Ostensibly, proofs are good in the sense that they restrict the focus of cryptanalysis. Without a security proof of a mode (say CTR or HAIFA), cryptanalysis wouldn't be able to focus on distinguishing the core function from random in some sense, but on everything. Note that coding attacks does not help much here. It also seems that the role of proofs is often misunderstood, and assumed to mean much more than it does. Then there are the practical aspects of the trade: cryptographic engineering. This involves avoiding information leaks (timing, power, etc), knowing what to do with IVs and keys and nonces, and the list goes on. This is a much more hands-on task, and often much less documented ("the implementation is left as an exercise to the reader"). Experience on building and attacking these is often the best way to learn how to do it, and not by reading a book about it.