@tedm : VeraCrypt is intended to be cross-platform and as noted by humdinger a Linux version has been released and a MacOSX one is on its way.
I agree with your idea of submitting a patch for TrueCrypt 7.1a. The only point is the choice of the iterations count : we choose values that gives the maximum security in our opinion while add delays on volumes openings that are acceptable to us. This may not be acceptable to people who don't want to wait a lot after entering their password. Anyway, I'll try to prepare a patch for TrueCrypt and make it public as soon as possible. Other forks can start from this to define their own iterations count values.
For those who are not familiar with TrueCrypt internals (there was a message asking about this here but it was removed), the key derivation functions along with their corresponding iterations count are not stored in the volume hearder. Instead, TrueCrypt/VeraCrypt tries all available functions on a sequential way (RIPEMD160 -> SHA 512 -> Whirlpool) till it finds the correct one.
By using secure values for iterations count, each key derivation function will take a substantial time to complete and if for example if you choose Whirlpool as your derivation function, volume opening time may be very long.
In order to keep the same level of security, we should keep this way of working but there is a solution that can speed up the volume opening without loosing security : offering the user the possibility to select his key derivation function.
I already exposed this idea in a post on CodePlex : https://veracrypt.codeplex.com/discussions/549728
This approach needs a lot of code rewriting, especially in the Windows Device Driver part.
Any thoughts about this?
Concerning the licensing issue raised by @Phaelon, this is a recurring question. Since VeraCrypt is derived from TrueCrypt so it must retain the same license. At the same time, we decided to go for a dual-licensing mode where the second license would be the Ms-PL. We are not layers but we think Ms-PL is the most compatible one with the TrueCrypt license. We would have liked to be able to choose a GNU compatible license but the terms of the TrueCrypt license make this impossible.
Anyway, other forks will have to deal with the same licensing issue and we'll see what choices they will make.
One last point about compatibility : one idea is to develop a tool that can convert TrueCrypt volumes to any other fork format. We'll just have to keep the master keys and change the other volume header part to be compatible with the new fork. Unfortunately, there are difficulties because TrueCrypt format has changed a lot across version (5.x, 6.x and 7.x) and if we are going to do this, than the fork in question must handle all possible version combinations.
The only viable solution I see is to limit the scope of such conversion tool to the 7.x version of TrueCrypt volumes (released on July 19th 2010). So, volumes created more that 4 years ago should copied manually.