If you want to learn about cryptanalysis, the most effective and efficient way that I found is to lookup how old schemes were broken.
For example, once you know how linear cryptanalysis works, it's like you have a new eye which constantly looks out for signs of linear equations that you can simply reverse. It's a lot like learning something new and then wanting to apply it to absolutely everything.
In cryptanalysis, that's actually a good thing: as an attacker, you often only need to find a single weakness which you can leverage to exploit more and more weaknesses if the first weakness not already completely breaks the scheme. As the defender, you need to be constantly on the lookout to not miss security patches and for unknown unknowns which is by definition impossible.
I believe this asymmetry is why it's so hard to secure systems. Oh and did you notice how I wrote an attacker and the defender? Right, you're basically alone against the whole internet, as far as you can tell. Unless you run audits on your infrastructure. Then you're a little less alone.
Little details like this (that become obvious once explained) broke AWS signature version 1. You could easily generate two messages with the same signature:
AWS signature version 1 signs an HTTP query string as follows:
- Split the query string based on '&' and '=' characters into a series of key-value pairs.
- Sort the pairs based on the keys.
- Append the keys and values together, in order, to construct one big string (key1 + value1 + key2 + value2 + ... ).
- Sign that string using HMAC-SHA1 and your secret access key.
When Amazon invented this signature scheme, they forgot about one of the foremost design principles relating to cryptographic signatures: Collisions are BAD! In a well-designed signature system, it should be computationally infeasible to construct two different messages which have the same signature; this prevents substitution attacks where an attacker convinces the key holder to sign a "harmless" message, and then attaches that signature to a different message. Looking at how AWS signature version 1 is computed, it's easy to see how to construct collisions: Because there are no delimiters between the keys and values, the signature for "foo=bar" is identical to the signature for "foob=ar"; moreover, the signature for "foo=bar&fooble=baz" is the same as the signature for "foo=barfooblebaz".
This means you could use the same signature for two different payloads which can be catastrophic.
People inevitably make mistakes from time to time. Security problems happen. But when they do happen, Amazon's response is a good example to follow.