Is that called a 'round' every time you move your mouse when creating a new volume? I'm talking about the screen with the random numbers during the volume creation process. What is the purpose of doing the random movement?
I saw Lastpass is now doing '100,000 rounds', I'm not sure what that means exactly.
Brand new to the world of encryption here :)
You are creating something called "entropy". Random number generators within computers can, if implemented within software, only be at best pseudo-random. Pseudo-random number generators (PRNG) start with a seed. If the seed is well-known, then anyone with knowledge of the PRNG algorithm can derive the same values you derived (this is actually really good for things like simulations and the like where you need an element of reproducability -- it is not good for crypto). So you need to start with a non-well-known seed. Traditionally (not for crypto!) this seed was the computer's time of day. However, for crypto, you need much stronger randomness than this.
In many commercial environments, there is often the requirement that random number generators (RNGs) are based off of a hardware-based "noise source". This could be things like random network packet data, the number of photons hitting a detector, the speed of air across a sensor, or any combination of things that might be considered TRULY random.
Unfortunately, these hardware-based noise sources don't usually find themselves in widespread use in consumer environments. So the next best thing is to pull hardware-based noise from something else. Many encryption systems use a human moving a mouse to acquire this. Even if the human moves the mouse in circles or back and forth, there is usually still enough actual real-world randomness in the mouse path deviation to provide a reasonable level of entropy to seed the PRNG.
For real-world examples of entropy from the environment, look no further than the air-splayed balls spinning around in a lottery cage.
"Rounds" are not related to entropy gathering and are related to the number of times that a specific algorithm is run through. There is almost always (?) a feedback mechanism allowing one round to affect later rounds. Increasing the number of rounds increases the amount of time it takes to encrypt/decrypt data. This is important as it can seriously de-scale any brute force decryption efforts. Of course, it also slows down the ENCRYPTION efforts as well.
The point is to provide entropy. Truecrypt must generate a secret key for the volume. It does so by generating a bunch of random bits. Here (as often in cryptography), what is important is not really that the bits that make up the key are random in a statistical sense, but rather than the key cannot be predicted or reproduced by an attacker. A computer is a deterministic machine¹: if the attacker knows in what state it was in when you started to generate the key, he can run Truecrypt and generate the same key.
By moving the mouse, you are providing input that the attacker cannot reproduce. The more input you provide, the harder the key will be to reproduce. For example, if the computer only recorded a single motion as left or right, then there would only be two possible keys, and the attacker could try them both; the key would only have 1 bit of entropy (no matter how long the key is). Ideally, the key must be completely random; if the key is, say, a 128-bit key, the random number generator must have 128 bits of entropy available. Human movements are somewhat predictable (you aren't going to move the mouse two meters left), but the more you move, the more entropy you feed into the pool.
The mouse motion is not related to the 100,000 rounds. The rounds are a different issue, related to how hard it is for the attacker to reproduce your password. Humans are notoriously poor at choosing and remembering complex passwords, so the attacker can try all plausible passwords by brute force. For this reason, cryptographic systems that use passwords don't use them as-is, but perform some computation (a cryptographic hash, say; PBKDF2 is generally recommended these days) on the password many times over. This computation is expensive; its running time is proportional to the number of rounds. The system must perform this iterated computation once per password attempt; the attacker must also perform it once per password attempt. If it takes 1 second for your system to process your password when you mount the volume instead of 10 microseconds, it's not a big deal, because password processing is only a tiny fraction of what you use your CPU for anyway. But for the attacker, who's spending all his CPU time brute-forcing passwords, being able to perform only 1 cracking attempt per second and not 100,000 per CPU is a big hit.
¹ Some computers have a hardware random number generator, which derives its randomness from physically impossible to predict (or at least hidden and extremely hard to predict) sources. Nuclear decay is good for this but impractical. On mobile devices, camera white noise works fairly well. But many computers lack such a hardware random generator.
Truecrypt makes a CRC32 of the MOUSEHOOKSTRUCT structure, which is populated by Windows and passed to the callback function defined by Truecrypt when you move your mouse. Take a look at the definition:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644968%28v=vs.85%29.aspx
The entire struct is used, including members such as hwnd that don't change between calls. Due to the hit testing feature, you arguably get better entropy if you move the mouse over and around the window boundaries. Or maybe you weaken it. You can ponder that one.
If the CRC of the struct is different from last time Truecrypt's callback was executed then it will make a CRC32 of the 32bit tick count returned by GetTickCount(). The CRC of the struct and the tick count are added together and hashed with RIPEMD160 by default. The resulting hash is then used to modify the random pool with an XOR operation.
Looking at it makes me wonder how much randomness this process really adds. There isn't a huge range of possible values in the y,x coordinates. The window handle will be random for the particular key generation, but will remain unchanged each time the mouse is sampled. The hit testing can return a small number of enumerated values. Certain behaviors with the mouse will cause this to return a single value at all times. There's a pointer to further information. I'm not sure when this is set.
Generation of random numbers using a pseudo-random generator may be treated suspiciously by the ultra-paranoid, so linking some of the randomness to a user-defined input provides some confidence that you are 'safe'
