You could read about Shor's algorithm and Grover's algorithm. Wikipedia is generally a great source for basic knowledge about cryptography, it is extremely superficial but it is great for giving you an idea of things to look up. Grover's algorithm is a quantum based direct attack on symmetric encryption keys, not on their corresponding passwords. The strength of a symmetric algorithm is hard limited by the key space of the algorithm. Grover's algorithm cuts key strength in half, the quality of the password or PBKDF will have no effect on it. Truecrypt almost certainly is using something called a password based key derivation function, commonly referred to as a PBKDF. PBKDF's are used for turning a users password into a symmetric encryption key. When you encrypt a file with an algorithm like AES-256, you must provide a key that is of the appropriate length. That is to say that you cannot directly use the password 'password' with AES-256, you need to convert the password into a 256 bit key. This could naively be done by using a hash algorithm, perhaps you take the SHA256 value of 'password', which is '6b3a55e0261b0304143f805a24924d0c1c44524821305f31d9277843b8a10f4e' (in hex), and which consists of 256 bits. PBKDF's do use hashing as their primitives, but they add at least two important features. The first feature they add is called salting. Salting adds some fixed randomness to your password prior to hashing it. You see, if your password is 'password', then you are weak to rainbow table attacks. A rainbow table attack involves the attacker taking sometimes terabytes worth of dictionary words / leaked passwords / common phrases / etc, and hashing all of them with a specific algorithm (generally with many algorithms, which is I believe where it gets its name from, it stores the SHA256 of the password, the MD5 of the password, the SHA512 of the password, etc). This takes a lot of computational power, but after it is done once the attacker no longer needs to compute the hash values again, now they can attempt to directly use the stored hash data as the symmetric encryption key until they find the correct one. Any half decent rainbow table will have the SHA256 value of 'password' stored in it. To protect from rainbow tables, the encryption program will generate a few random bytes of data, let's say 'j82opdl29e' , and then it concatenates it to your password prior to hashing your password. Therefor your password is now really 'j82opdl29epassword' , but you only need to remember password because the salt is handled by the encryption program (and generally stored in plaintext with the encrypted data, salts do not need to be secret). This means that your password now produces the key '718e7e73155913d6ab75a6d4a3a0e515f0c2056c25c98103f9d4f2dd8e661172' , which will not likely be part of the attackers rainbow table. Since everybody who uses the program has a different salt generated, the input password 'password' can now produce a wide variety of different output keys (for example, since Truecrypt uses a 512 bit salt, a rainbow table effective against it will be 2^512 times as large, and take 2^512 as many operations to compute, as a rainbow table effective against an application that doesn't use any salt at all. Essentially this means that Truecrypt is immune to rainbow table attacks). Another thing that PBKDF's do is iteratively hash a password. This is what protects from brute force attacks. If the attacker obtains your salt (which they can easily do since the salt isn't itself encrypted) then they can start the brute force attack with 'j82opdl29e' and start adding characters to it, perhaps starting at 'j82opdl29ea' and then going to 'j82opdl29eb' etc. Additionally they can try computational dictionary attacks directly (although the salt protects from rainbow table based attacks). Now it takes a very small amount of time to take the hash value of 'j82opdl29ea', and a very small amount of time to take the hash value of 'j82opdl29eb' etc. So instead the PBKDF will have a set number of iterations, probably in the thousands or tens of thousands. Without iterations the key corresponding to the password ''j82opdl29ea' is '19798b674de3fa0111d46315048a5b33893b347249af9dc9ba106af3eea9a824', assuming that SHA256 is used. With 10,000 iterations of hashing, as specified by the PBKDF, the hash is that hashed out 10,000 additional times. For example 19798b674de3fa0111d46315048a5b33893b347249af9dc9ba106af3eea9a824 SHA256 = 68529cb832e34720b8be405233bca6d231a95766dacf36a66acc769bbab71daf SHA256 = 31a065cb81ba09fa9831b0700a904fad25b5e39d88160764c6b325dc61df614c etc.... This obviously will take ten thousand times longer for an attacker to compute. Usually this will work out to about a second or two to convert a password to a key (although it is entirely computationally bound), an amount of time that is not noticeable to a user with the correct password, but which adds up to a lot of time for an attacker who needs to repeatedly guess incorrect passwords. If it takes two seconds to do that many iterations, it takes you two seconds to obtain your key after correctly entering your password, but an attacker who attempts 100,000,000 different passwords before they get the correct one ends up spending over six years with an equal amount of computational power. So in summary PBKDF's can protect you but they don't protect the encryption algorithm itself, and they don't protect the actual symmetric key from being brute force (only the password used to derive the key). So against the quantum attack called Grover's algorithm, PBKDF's have absolutely no effect at all. The reason for this is that you can always try to obtain the encryption key without the password at all, although generally it is vastly more efficient to guess the password than it is to break the encryption key. For example, with AES-256 we know the encryption key is 256 bits. Nothing stops you from starting at 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 and working your way up to 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 and everything in between. Of course this leaves you with 2^256 permutations of bits to try in order to exhaust the key space. It is much more likely that the bit pattern will map to a specific input password that is much easier to guess or brute force. PBKDF's try to strengthen the password, but they don't come anywhere near to giving most passwords 256 bit equivalent security. Grover's algorithm is not concerned with breaking the password to obtain the correct key, it is concerned with breaking the symmetric key directly. I don't really understand how it works in detail, but it works such that the number of bits you need to guess in order to form the correct encryption key is cut in half. So instead of going from 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 to 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 and everything in between, you only need to go from 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 to 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 and everything in between. In such an attack the attacker doesn't even care if they can map the bit sequence that the symmetric key consists of to a human readable password, because the only reason somebody tries to figure out the human readable password is so that they can derive the correct bit sequence from it. Grover's algorithm goes straight to brute forcing the correct bit sequence, it doesn't start at the password. Thankfully even going from 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 to 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 and everything in between is not realistic. This means that 256 bit algorithms are not broken by Grover's algorithm. On the other hand, against 128 bit algorithms it turns into 0000000000000000000000000000000000000000000000000000000000000000 to 1111111111111111111111111111111111111111111111111111111111111111 and everything in between which is possible to brute force. Therefor 128 bit symmetric algorithms are broken by Grover's algorithm.