I already started working on the CryptAcquireContext issue: the modification will not tackle only this function but will also add more specific error handling for random generator initialization. In practice, this will almost never manifest itself (the only
case I can think of is a user with no profile on disk) but the code should be made more robust anyway.
Concerning the cache-timing attack, this is a deep issue found in several implementations not only TrueCrypt/VeraCrypt and implementing a counter-measure is not obvious nor simple. From the attack point of view, this is very a very complex attack to mount.
Moreover, it requires the attacker to run code the victim's machine...
Cache-timing attacks are realistic on multi-user server environment where a malicious user can recover sensitive keys from the CPU. This type of shared environment is clearly not recommended for TrueCrypt/VeraCrypt because of other security risks so this is
not a realistic scenario in our context.
the best know attack requires between 2x10^9 and 4x10^9 samples...this requires a lot of time (between one week and one month) and it will most certainly be detected or interrupted before it gets any results.
Nevertheless, it should be taken into account since attacks get only better. The problem is, as expressed by Daniel Bernstein in his famous paper about cache timing attacks, it is extremely difficult to write constant-time high-speed AEs software for common
general-purpose computers. The other problem is that there patented way to modify AES implementation in order to protect against these attacks which make them impossible to use without written consent.
Anyway, since this applies to all cryptographic libraries, we should seek external help/advice from other open source projects to look for available general purpose implementations that brings some level of protection without loosing too much performance.
As noted by the audit report itself, the keyfile mixing issue has been know of years. Moreover, a user has already opened an ticket for this on VeraCrypt issue tracker two weeks ago:
This is no a critical issue but it definitely needs to be enhanced. This will take some time to define the best implementation that is secure but also practical (for example, keyfile processing should remain quick and preferably the order of the key files should
The last point concerning unauthenticated plain text in the decrypted header is not a realistic attack at all. Since the attacker doesn't know the encryption key, he will have to find a way to force VeraCrypt on the target machine to mount specially crafted
times, hoping to be able to forge the "VERA" ASCII string. Moreover, because of the checks done by TrueCrypt/VeraCrypt on the validity of various fields (sector size, header version, Required program version), the attack
needs also to uncover valid values for these fields at the same time. Thus the real number of crafted volumes needed is at roughly around
2^32 x 2^16 x 2^16 x 2^16
if we take into account the ASCII field and the three numeric fields. This is
attempts, which is completely unrealistic...
These are my first thoughts about the report. Overall, no real vulnerability despite the high rating given by the report and the keyfile mixing issue is the more realistic issue among them all but it has been known for years.