Why is 128bit AES considered very strong but 160bit SHA 'insufficiently secure'? Google/chrome/browsers seems to drop support for SHA1 SSL certificates. I assume it's more simple to calculate SHA than a round of AES but there are a lot more bits in SHA. I understand MD5 was depreciated bc the algorithm was broken enough that it was not difficult to create a collision but I don't think that comes into play with SHA?
For hash functions (like SHA-1) being used to sign SSL certificates, the security is completely undermined if you have successful collision attacks. Due to the birthday paradox, a N-bit hash function effectively provides about N/2 bits of security against collision attacks. That is a brute-forcer can create collisions for a N-bit hash function after generating about 2N/2 potential strings to hash. Hence an 160-bit hash function provides about 80-bits of security against collisions (meaning it takes about 280 effort to generate a collision via brute-force).
For a block cipher (like AES), you use a N-bit key that maps a block of text (128 bits in the case of AES) into a block of ciphertext in a reversible way if you possess the N-bit key. Hence, to brute force a block cipher with an N-bit key (and no other vulnerabilities), you need to try about 2N possible keys until you find a key that transforms the ciphertext into the original message.
Thus (without looking at any specific flaws in the two algorithms), a block cipher with a 128-bit key is much stronger (which takes 2128 effort to brute force) than using an SSL certificate signed with a 160-bit hash function (which takes 280 effort to find a collision and completely undermine the security). In fact it is roughly 248 ~ 281 trillion (1012) times more secure.
Explanation of why collisions break SSL certificates
Basically, an SSL certificate consists of some plaintext information
p and a signature
S provided by a certificate authority. This plaintext typically includes the name of your organization and your domain name and similar information. If you want a new certificate, you then submit this information to a certificate authority (CA) that popular web browsers intrinsically trust. The CA checks your information (e.g., they verify you own the domain, by say emailing a code to the email address listed in the DNS records for that domain, OR you pay for an extended validation certificate and the CA does more checks that you are the organization you say you are). If the information checks out, the certificate authority will agree to sign it and issue you the signature to complete the certificate. The signature consists of hashing the plaintext information
H(p) in the certificate and then using the CA's private key (
K_priv) to encrypt that hash (
S = E(K_priv, H(p)). Then anyone can use the corresponding public key of the CA (
K_public) (and your operating system and/or web browser typically comes with a list of public keys of trusted certificate authorities) to decrypt the signature to find
H(p) = D(K_public, S) and verify that the signature matches the hash of the plaintext information in the SSL certificate.
Thus if you generate roughly 280 different plaintext messages
p (some in the form needed to be a certificate for a domain, some in the form of certificates for intermediate certificate authority), it could be possible to find a pair of two messages
p2 that collide. If say
p1 identifies a randomly changed domain (
sgnjnjrafaftjhyqsv.com) that you can easily buy (or you vary subdomains of domains you already own like
sgnjnjrafaftjhyqsv.blah.com), then you can verify ownership of
p1 to a CA and you can get a CA's signature of
p1. Since the hashes match
H(p1)==H(p2), you can take the signature from
p1's certificate and use it with p2 to generate a valid certificate. If
p2 for example was an intermediate certificate authority that allows you to sign other certificates, you could then use that intermediate certificate authority to sign any certificate you want (and could for example spoof any website you want -- at least ignoring other protections like certificate pinning).
For reference, this attack was successfully used to create fake intermediate certificate authorities against MD5 (128-bit hash) signed certificates around 2008. Note, ignoring specific flaws in the relevant hashes finding a SHA-1 collision is only about 65,000 times more difficult than finding one in an MD5 hash. With the cost of computation decreasing, it is believed to be feasible for sophisticated attackers to collision attack SHA-1 and undermine SSL security. Using a 256 bit hash (like SHA-256) is about 18 billion billion (18 x 1018) times more secure than a 128 bit hash (like MD5) against collision attacks (again ignoring specific flaws in the hash functions).
AES is a symmetric encryption algorithm. SHA-1 is a hashing function. They are completely different beasts.
The issue is not the number of bits but the functions themselves. As an example you can take MD5. It also has 128 bits, yet creating two colliding strings is now trivial.
The issue is not being able to bruteforce the 128-bit possibilities, but (ab)using the properties of the md5 operations for forcing the collision.