boot times

Topics: Technical Issues
Jan 10, 2015 at 8:17 AM
Ok so I installed VC yesterday and encrypted the system partition.
With TC, the OS would start to load pretty much instantly.
With VC, there is a delay each time of 65 seconds after entering my password and hitting the return key before the OS starts loading.
I appreciate that this may be due to the security improvements with VC but still, 65 seconds seems quite long. Is this normal?
My PC is a couple of years old but still a fast quad core set up.
Coordinator
Jan 10, 2015 at 8:36 AM
Hi,

This delay is caused by the increased strength of key derivation but also the use of SHA-256 instead of RIPEMD-160. It is still possible to use RIPEMD-160 which devides the boot time by two.

Instead of weakening the default security, VeraCrypt is focus on two new features that will boost the boot performance:

1. Rewrite the bootloader to be 32bit instead of the current 16bit implementation inherited from TrueCrypt
2. Define a dynamic mode of encryption parameters choice in order to be able to correlate iteration count with password length. This would make it possible for those using strong passsords (20+ characters) to be able to set relatively lower iteration (not below a certain limit) thus leading to faster mounting and boot.



Jan 10, 2015 at 9:09 AM
Ok thanks for the info. The new developments sound promising.
Jan 10, 2015 at 12:27 PM
CorumUK

Can I just ask something please ?

Do you use VeraCrypt for VERY sensitive data or just your personal files etc ?
Jan 10, 2015 at 12:54 PM
Nothing of national security importance. Just a PC enthusiast that likes to try out different stuff.
I use an encrypted container for my passwords spreadsheet which I can then access on mobile devices via dropbox and an app callled EDS lite (unfortunately it doesn't seem to work with a VC container) and have been using FDE on the system partition of my home PC just as a general safeguard for personal data in case of burglary or similar.

I've disabled the FDE for the minute though as the boot times were a bit long on VC but will continue to use VC for containers.
Jan 10, 2015 at 1:28 PM
Edited Jan 10, 2015 at 1:34 PM
Thank you very much for your reply CorumUK.

If you have the time can you provide some more user feedback please ?

If you did have some important / valuable data to protect, would you be prepared to wait a little when booting to provide good, genuine security ?

Would you think that a delay in booting was a price worth paying for securing your data to a high degree ?

Are you aware of hash cracking speeds achievable to even the most humble hacker when utilising GPU processors ?

On our forum it seems we have some users who have little need for real encryption / security but still wish to use VeraCrypt. Can I ask why you want to use VeraCrypt and not TrueCrypt / ChipherShed / Bitlocker etc ?

If it is because you believe VeraCrypt is more secure, can I ask if you would deliberately weaken it if you could achieve faster boot times or would you think that was counter productive ?

Last question :)

What is the longest totally random password you are able to remember ? Not written down, just from memory.

Thank you.
Jan 10, 2015 at 2:37 PM
I'll give these L0ck questions a try...

Wait while booting? YES
Delay worth paying? YES
Hash cracking speeds? AWARE (seen ArsTechnica.com articles)
Why VeraCrypt?
a) FBI unable to crack TrueCrypt (https://www.eff.org/document/opinion - see pages 8 and 9 of the 11th Circuit Court's opinion)
b) NSA has major problems when trying to crack TrueCrypt ( http://www.spiegel.de/media/media-35535.pdf page 20; see also http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html and see also http://www.techworld.com/news/security/fbi-hackers-fail-to-crack-truecrypt-3228701/ )
c) VeraCrypt has implemented security improvements to the TrueCrypt code
Would weaken VC for faster boot times? NO NO NO NO NO NO NO NO
Longest password? Nobody can remember a reasonably long totally random password. However, I can easily remember 30+ characters of a very strong password by using memorization shortcuts based on things that only I know which have never been written down. I do have one password complaint - TrueCrypt was based on ASCII and security could be greatly improved by moving to Unicode instead. This presents attackers with an enormously enlarged character set to deal with. If the attackers decide to assume only the ASCII subset will be used, then the simple inclusion of a Chinese or Arabic character would suffice to lock them out completely.

P.S. Please vote for my newly created issue "UniCode 8.0 basis for VeraCrypt" here: https://veracrypt.codeplex.com/workitem/62
       Thank you for your upvoting support!  :)
Jan 10, 2015 at 3:34 PM
L0ck wrote:
Thank you very much for your reply CorumUK.

If you have the time can you provide some more user feedback please ?

If you did have some important / valuable data to protect, would you be prepared to wait a little when booting to provide good, genuine security ?
Depends on_how important/valuable the data was and the length of the wait. 65 seconds seems quite long unless its securing the launch codes for a nuclear weapon strike on xyz._

Would you think that a delay in booting was a price worth paying for securing your data to a high degree ?
A delay of a few seconds would be acceptable for general use as far as FDE is concerned. For encrypted containers/volumes, a slightly longer wait would be acceptable. For me personally, a delay at boot time of anything more than a few seconds becomes inconvenient, especially on days when I might be trying out a few software programs/troubleshooting graphic card drivers etc that may require several reboots in short succession.

Are you aware of hash cracking speeds achievable to even the most humble hacker when utilising GPU processors ?
Not really.

On our forum it seems we have some users who have little need for real encryption / security but still wish to use VeraCrypt. Can I ask why you want to use VeraCrypt and not TrueCrypt / ChipherShed / Bitlocker etc ?
I like the idea of open source as it is more transparent and community based, not to mention free! My use of encryption is just from a general user point of view to secure documents and passwords etc. I was quite happy with Truecrypt but its lack of ongoing development is catching up with it. VC seems the best alternative currently.

If it is because you believe VeraCrypt is more secure, can I ask if you would deliberately weaken it if you could achieve faster boot times or would you think that was counter productive ?
Perhaps the best option is to provide a solution that has strongly recommended default settings but is more configurable by the end user, on the understanding that they have been made aware of the risks. Both of my work laptops (provided by the Local Authorities I work for in the UK) came with FDE, Becrypt on one and McAfee Endpoint on the other. These boot almost instantly after entering the password. That said, I think they do lock the user our after so many failed attempts.

Last question :)

What is the longest totally random password you are able to remember ? Not written down, just from memory.
Probably quite short, but as I don't use them i'm not 100% sure. I normally use a dictionary word with a capital thrown in and a couple of numbers either at the start or end.
Thank you.
Welcome.
Jan 10, 2015 at 4:23 PM
commenter8

Thank you for your reply commenter8

I am starting to think we were separated at birth or something :LOL :)

It's nice to have someone else here who is 100% security.

I will vote for your request, however I believe there is a technical reason it hasn't been implemented before. I'm not sure though.

As you are clearly security aware, all your answers are predictable and welcome.
Jan 10, 2015 at 4:24 PM
Edited Jan 10, 2015 at 4:24 PM
CorumUK

Thank you once again for your help.

I would like to start with an apology and an explanation.

Please don't take this the wrong way, it is not critical of you personally but my questions and your answers were to demonstrate a point I wanted to make on another thread.

You seem to be a regular guy just wanting to protect personal ( not critical ) files from burglars and perhaps domestic hackers, if you left your laptop somewhere for example.

My questions were asked in an unfair way to expose my point, not against you personally.

As you have been so kind to take time to reply I guess I owe an explanation.
If you did have some important / valuable data to protect, would you be prepared to wait a little when booting to provide good, genuine security ?

Depends on_how important/valuable the data was and the length of the wait. 65 seconds seems quite long unless its securing the launch codes for a nuclear weapon strike on xyz._
Here you demonstrate you have no real need for "strong" encryption. You do at least agree that serious data would justify a longer wait.

.
Are you aware of hash cracking speeds achievable to even the most humble hacker when utilising GPU processors ?

Not really.
This was asked to see if you understood the threat model correctly, I guess you don't. This is nothing to be ashamed of, most normal everyday users don't.

I believe if you did know this figure and taking in to account your answer about password memorisation, you would be prepared to wait a little to boot your computer :)


.
On our forum it seems we have some users who have little need for real encryption / security but still wish to use VeraCrypt. Can I ask why you want to use VeraCrypt and not TrueCrypt / ChipherShed / Bitlocker etc ?

I like the idea of open source as it is more transparent and community based, not to mention free! My use of encryption is just from a general user point of view to secure documents and passwords etc. I was quite happy with Truecrypt but its lack of ongoing development is catching up with it. VC seems the best alternative currently.
So it seems you have not chosen VeraCrypt because of it's strength but because it is maintained. I want people to choose VeraCrypt for it's strength.

.
If it is because you believe VeraCrypt is more secure, can I ask if you would deliberately weaken it if you could achieve faster boot times or would you think that was counter productive ?

Perhaps the best option is to provide a solution that has strongly recommended default settings but is more configurable by the end user, on the understanding that they have been made aware of the risks. Both of my work laptops (provided by the Local Authorities I work for in the UK) came with FDE, Becrypt on one and McAfee Endpoint on the other. These boot almost instantly after entering the password. That said, I think they do lock the user our after so many failed attempts.
By your previous answers you already admit you have no idea of the threat model and no serious files to protect, but you believe VeraCrypt should have an option to weaken the brute force protection.

.
What is the longest totally random password you are able to remember ? Not written down, just from memory.

Probably quite short, but as I don't use them i'm not 100% sure. I normally use a dictionary word with a capital thrown in and a couple of numbers either at the start or end.
You don't use long random passwords but you also wish to reduce the iteration count to speed up booting.

Also your password padding is very common. Any domestic hacker would already know these common padding techniques.

This is not fair of me to exploit your replies like I have, but as I said this is not against you personally. I asked you because you were a new and seemed to be a typical user.

You also seem representative of others who ask for faster boot times etc for VeraCrypt and I wanted to demonstrate my point to Mounir.



Mounir

Admittedly I was unfair to this new member and I have already apologised to him. However I hope you see the problem I was trying to get across before.

This "typical" user....

Has no idea about hash cracking speeds for domestic hackers, let alone governments.

Has no need for very strong encryption.

Has chosen VeraCrypt simply because it was being maintained, not for real security.

Uses weak, short dictionary passwords with basic padding.

After reading the above, any user with this background has an equal vote as to the future of VeraCrypt. Are you 100% certain you want to take VeraCrypt in this direction ?

Unless I am asked or quoted I won't bother you directly with this problem any more Mounir.

I know you personally wouldn't like to lower the iteration count, or even make it an option. I understand you must be sick of the requests by the public to reduce boot times etc.

No problems either way, I just wanted to prove it to you with a real world example. VeraCrypt has become very important to me recently and I care deeply about it's future.
Jan 10, 2015 at 4:59 PM
Some recommended reading for people who use weak passwords...

Why passwords have never been weaker—and crackers have never been stronger

http://arstechnica.com/security/2012/08/passwords-under-assault/

How I became a password cracker

http://arstechnica.com/security/2013/03/how-i-became-a-password-cracker/

Turbo-charged cracking comes to long passwords

http://arstechnica.com/security/2013/08/thereisnofatebutwhatwemake-turbo-charged-cracking-comes-to-long-passwords/
Jan 10, 2015 at 5:24 PM
More reading material about attacks on TrueCrypt:

TrueCrack is a brute-force password cracker for TrueCrypt. TrueCrack is an Open Source Software under GNU Public License version 3.

The execution time of TrueCrack for a dictionary attack is (average word length 10 characters):

CPU 3.00GHz GTX650 GTX680
1000 0m 12.031s 0m 3.771s 0m 2.693s
10000 2m 0.421s 0m 15.893s 0m 5.628s
100000 20 m3.811s 2m 20.379s 0m 37.610s

https://code.google.com/p/truecrack/

What is unprotect.info software?

unprotect.info is the password recovery software for Windows that you can use to recover a lost password for an encrypted volume that you’ve previously created with the TrueCrypt software.

Do I have to pay for using this software?

No, this software is free for both personal and commercial use. However, some additional features, such as the password mask require a payment of a license fee to use them.

http://unprotect.info/

A while back I've encrypted a few files with Truecrypt 7.1, didn't write down the password and stored it in my head. That was a big mistake. After some time, when I needed access to those files the password wasn't working. I'm sure most of the password was right, but I was off by two or four digits, while the whole password was 25 characters long. After a number of failures I've decided to look for a software that allows to brute force the encrypted container with a certain keywords or regular expressions. I've found the software that handles both - OTFBrutusGUI.

OTFBrutusGUI can be helpful when you do not remember only a part of the password or your password is really small and simple, like 4-6 characters. In other case brute force can take months or years.

To get started just download the latest version and unpack it anywhere. Then run the x64 or x86 version .exe file

http://www.kuhtinsky.eu/index.php/blog/item/15-recover-forgotten-truecrypt-password

Passware Kit Enterprise and Passware Kit Forensic decrypt hard disks encrypted with BitLocker, TrueCrypt, FileVault2, or PGP.

BitLocker is a data protection feature available in Windows systems starting from Vista. TrueCrypt is a software application that creates virtual hard disks with real-time encryption.

Passware Kit scans the physical memory image file (acquired while the encrypted disk was mounted, even if the target computer was locked), extracts all the encryption keys, and decrypts the given volume. Such memory images can be acquired using Passware FireWire Memory Imager (included in Passware Kit Forensic), or third-party tools, such as ManTech Physical Memory Dump Utility or win32dd.

If the target computer with the encrypted volume is powered off, encryption keys are not stored in its memory, but they could be possibly recovered from the hiberfil.sys file, which is automatically created when a system hibernates.

NOTE: If the target computer is turned off and the encrypted volume was dismounted during the last hibernation, neither the memory image nor the hiberfil.sys file will contain the encryption keys. Therefore, instant decryption of the volume is impossible. In this case, Passware Kit assigns brute-force attacks to recover the original password for the volume.

http://www.lostpassword.com/hdd-decryption.htm

Recover passwords to TrueCrypt volumes

Passcovery Suite recovers lost passwords to any TrueCrypt volumes. The software supports all hash algorithms and data encryption algorithms. Passcovery Suite runs at accelerated speeds on AMD/NVIDIA graphics cards.

http://gpupasswordrecovery.net/password-recovery-software/truecrypt-password.htm

TrueCrypt Master Key Extraction And Volume Identification

One of the disclosed pitfalls of TrueCrypt disk encryption is that the master keys must remain in RAM in order to provide fully transparent encryption. In other words, if master keys were allowed to be flushed to disk, the design would suffer in terms of security (writing plain-text keys to more permanent storage) and performance. This is a risk that suspects have to live with, and one that law enforcement and government investigators can capitalize on.

The default encryption scheme is AES in XTS mode. In XTS mode, primary and secondary 256-bit keys are concatenated together to form one 512-bit (64 bytes) master key. An advantage you gain right off the bat is that patterns in AES keys can be distinguished from other seemingly random blocks of data. This is how tools like aeskeyfind and bulk_extractor locate the keys in memory dumps, packet captures, etc. In most cases, extracting the keys from RAM is as easy as this: ...

Several keys were identified, but only the two final ones in red are 256-bits (the others are 128-bit keys). Thus, you can bet by combining the two 256-bit keys, you'll have your 512-bit master AES key. That's all pretty straightforward and has been documented in quite a few places - one of my favorites being Michael Weissbacher's blog.

The problem is - what if suspects change the default AES encryption scheme? TrueCrypt also supports Twofish, Serpent, and combinations thereof (AES-Twofish, AES-Twofish-Serpent). Furthermore, it supports modes other than XTS, such as LWR, CBC, outer CBC, and Inner CBC (though many of the CBCs are either deprecated or not recommended).

What do you do if a suspect uses non-default encryption schemes or modes? You can't find Twofish or Serpent keys with tools designed to scan for AES keys -- that just doesn't work. As pointed out by one of our Twitter followers (@brnocrist), a tool by Carsten Maartmann-Moe named Interrogate could be of use here (as could several commercial implementations from Elcomsoft or Passware).

Another challenge that investigators face, in the case of file-based containers, is figuring out which file on the suspect's hard disk serves as the container. If you don't know that, then having the master keys is only as useful as finding the key to a house but having no idea where the house is.

To address these issues, I wrote several new Volatility plugins. The truecryptsummary plugin gives you a detailed description of all TrueCrypt related artifacts in a given memory dump. Here's how it appears on a test system running 64-bit Windows 2012. ...

Among other things, you can see that the TrueCrypt volume was mounted on the suspect system on October 11th 2013. Furthermore, the path to the container is \Device\Harddisk1\Partition1, because in this case, the container was an entire partition (a USB thumb drive). If we were dealing with a file-based container as previously mentioned, the output would show the full path on disk to the file.

Perhaps even more exciting than all that is the fact that, despite the partition being fully encrypted, once its mounted, any files accessed on the volume become cached by the Windows Cache Manager per normal -- which means the dumpfiles plugin can help you recover them in plain text. Yes, this includes the $Mft, $MftMirr, $Directory, and other NTFS meta-data files, which are decrypted immediately when mounting the volume. In fact, even if values that lead us to the master keys are swapped to disk, or if TrueCrypt (or other disk encryption suites like PGP or BitLocker) begin using algorithms without predictable/detectable keys, you can still recover all or part of any files accessed while the volume was mounted based on the fact that the Windows OS itself will cache the file contents (remember, the encryption is transparent to the OS, so it caches files from encrypted volumes in the same way as it always does).

After running a plugin such as truecryptsummary, you should have no doubts as to whether TrueCrypt was installed and in use, and which files or partitions are your targets. You can then run the truecryptmaster plugin which performs nothing short of magic. ...

You now have a 512-byte Serpent master key, which you can use to decrypt the roughly 8 GB USB drive. It tells you the encryption mode that the suspect used, the full path to the file or container, and some additional properties such as whether the volume is read-only or hidden. As you may suspect, the plugin works regardless of the encryption algorithm, mode, key length, and various other factors which may complicate the procedure of finding keys. This is because it doesn't rely on the key or key schedule patterns -- it finds them in the exact same way the TrueCrypt driver itself finds the keys in RAM before it needs to encrypt or decrypt a block of data. ...

http://volatility-labs.blogspot.com/2014/01/truecrypt-master-key-extraction-and.html
Jan 11, 2015 at 11:58 AM
Excellent post commenter8

It's so good I think you should have your own thread listing attacks :)
Jan 12, 2015 at 3:05 PM
@ L0ck:

I am a retired software developer (nothing to do with encryption) with an interest in VeraCrypt as a replacement for TrueCrypt. I like the helpful and open nature of this community and would like to offer my thoughts on your impromptu questionnaire.

Background:

I started using TrueCrypt around 2009 to encrypt portable hard drives when I was working at home. I found it easy to use and reliable with no performance issues. Later, thinking about data security on my own computers (Win 7 PC & laptop), I realised that with online banking and shopping, plus my own family records, I probably couldn't be sure of the locations of all the personal data on these machines. I encrypted the system and data disks in both machines and TrueCrypt has performed well ever since.

If you did have some important / valuable data to protect, would you be prepared to wait a little when booting to provide good, genuine security ?

Yes. I don't usually reboot very often during a session, but I can understand that other folks might have reasons to object.

Would you think that a delay in booting was a price worth paying for securing your data to a high degree ?

Yes. I believe that full data and system encryption is worth it. I could probably live with 10 minutes. I'd go and make a nice cup of tea!

Are you aware of hash cracking speeds achievable to even the most humble hacker when utilising GPU processors ?

I'm sure it's much faster than I might guess.

On our forum it seems we have some users who have little need for real encryption / security but still wish to use VeraCrypt. Can I ask why you want to use VeraCrypt and not TrueCrypt / ChipherShed / Bitlocker etc ?

For me, the fact that TrueCrypt now appears to be dead, and that VeraCrypt is based on TrueCrypt code, seems to make it an obvious choice. I probably would use Bitlocker, but I have Win 7 Pro which does not include it.

If it is because you believe VeraCrypt is more secure, can I ask if you would deliberately weaken it if you could achieve faster boot times or would you think that was counter productive ?

I agree with CorumUK that the ability to select a weaker encryption scheme in cases where boot time is important would be a useful option. However, I sense that you feel this could be an unwanted deviation from your main goal. I understand that, but I suspect that there will be a large number of TrueCrypt users who will be attracted to VeraCrypt as an alternative. I guess you should decide ASAP which route to take.

What is the longest totally random password you are able to remember ? Not written down, just from memory.

Painfully short is the honest answer! My usual approach is to choose some memorable life event and build a password based on names, places and dates associated with that event with the usual mix of upper/lower case, numbers and symbols. Then I think of a much shorter mnemonic that can be written down to help me remember the actual password. It's not exactly 21st century, but it works for me.

I shall follow this project with interest and wish you all well.
Jan 12, 2015 at 4:33 PM
algypug wrote:
I am a retired software developer
.
Software developers never retire, they just wait :)

.
I like the helpful and open nature of this community
.
Thank you, although we do have our robust moments here :)
I agree with CorumUK that the ability to select a weaker encryption scheme in cases where boot time is important would be a useful option.
.
I just want to clarify something, the option would not weaken the encryption, but it would weaken the hashing of the password, to then access the encryption key. It amounts to the same risk, but they are different problems :)

.
I sense that you feel this could be an unwanted deviation from your main goal.
It certainly would. It is also the opinion of Mounir, who is at the current time agonising over going against his principles for VeraCrypt or pleasing the users who requires less security than VeraCrypt currently offers.

To me personally it requires no further thought, there are weaker programs available to those who require speed over security. VeraCrypt has a good name to maintain, I don't see the gain in risking it. If 30 seconds waiting is too much to ask then I don't believe they deserve VeraCrypt.

.
I guess you should decide ASAP which route to take.
.
There will be a new feature to make the boot loader perform 32bit calculations, this should about halve the boot time, hopefully this will please all but the most impatient.

Thank you for taking the time to answer those questions. Your answers were mixed, you were predictably smart on the understanding why a delay was necessary, not surprising with your programming background :)

However I think you know where you let yourself down LOL Short password are bad, even when using high iterations, have you considered using a password and a keyfile ?

Hey, you don't want to come out of retirement for a few weeks do you ??? Mounir would welcome any help.

Thanks for your reply and welcome to the forum.
Jan 12, 2015 at 4:55 PM
Edited Jan 12, 2015 at 4:56 PM
"What is the longest totally random password you are able to remember ? Not written down, just from memory. "

Well I am using a total random 30+ passwords with numbers upper and lower case letters and symbols. (Good luck bruteforcing that :D)

And then I guess I am not normal, because I dont use the same password twice.. (Security resons, bruteforcing one don't give you access to everything..)

So it is possible :)
Jan 12, 2015 at 5:34 PM
Well done destrukt, you are very exceptional :)

However going on your other comments on the forum you clearly place a high value on security.

I am pleased you have made the effort to protect yourself, your password combined with high iterations should make you secure.

As I have previously said, you are a honorary crypto geek :)
Jan 14, 2015 at 4:28 PM
Veracrypt should stay the way it is. It's very very worth waiting the extra boot time when you have HIGHLY confidential documents.

I agree with your posts on the different threads (looking around the discussions): security should NOT be traded in for convenience when a person is serious about it.
Jan 14, 2015 at 4:29 PM
Edited Jan 14, 2015 at 4:30 PM
idrassi wrote:
Hi, This delay is caused by the increased strength of key derivation but also the use of SHA-256 instead of RIPEMD-160. It is still possible to use RIPEMD-160 which devides the boot time by two. Instead of weakening the default security, VeraCrypt is focus on two new features that will boost the boot performance: 1. Rewrite the bootloader to be 32bit instead of the current 16bit implementation inherited from TrueCrypt 2. Define a dynamic mode of encryption parameters choice in order to be able to correlate iteration count with password length. This would make it possible for those using strong passsords (20+ characters) to be able to set relatively lower iteration (not below a certain limit) thus leading to faster mounting and boot.
Will will still be able to have a choice to use the older, 16-bit boot loader when the new 32-bit boot loader does hit release?

That extra time from the 16-bit bootloader being limited to doing operations at a slower pace definitely helps prevent bruteforcing attempts from being quick.

Thank you thank you thank you for putting security first, by the way! Veracrypt is working great!
Jan 15, 2015 at 7:27 PM
Thanks commenter8 for the info copied and pasted previously and the hyperlinks to various nuggets of info. I've had a quick read through some of it and it is most interesting and educational. Anyone seeing the long list of articles might well be alarmed.

A couple of points I thought i'd mention.

The ars technica articles are quite entertaining but do not in the main seem to relate to cracking of cryptographic algorithms. I note that in the second article on his crash couse in cracking this was based on unsalted md5 hash's which, it seems, bears no real resemblance to algorithms used in any real cryptography program, even TC.

From scanning through the ars tehnica articles I got the impression that one of the most important things that a user can do is ensure sufficient password length as time for brute force attacks rises exponentially. So for chiefs of staff with any of the aforementioned nuclear launch codes a password of 25 random characters may definitely be advisable. That said if they were using the current version of veracrypt like us by the time their system had hashed the password they would probably have been nuked by the enemy before they could even hit the big red button ;-)

As for 99% of the rest of the world a ten character password would seem sufficient even for say political activists in somwhere like NK, as long as they avoided simple passwords and were using a proper cryptography application.

Moving on, I don't use linux and CLI is a little taxing for my simple brain so I skipped TrueCrack and downloaded Unprotect.info instead, helpfully telling it the length and character composition of my TC volume password. Once it had got going it said it would be finished in 68 to 464 years, although admittedly that isn't using any kind of dictionary or RockYou database.

Anyway those are just a couple of observations so far that I pulled from the links you provided. Lots more for me to read i'm sure and its all interesting stuff. If future versions of veracrypt can, as suggested by the developer, reduce the boot time by half (without compromising security) then I think a 30 second wait each boot time wouldn't be too bad for most users. To finish with a quote from ars technica "more iterations alone won't stop table lookup attacks. Though the tables will take much longer to generate, once they're generated, attacks that use them will proceed at the same speed as with any other table lookup attack."
Jan 16, 2015 at 12:49 AM
Edited Jan 16, 2015 at 12:50 AM
CorumUK wrote:
To finish with a quote from ars technica "more iterations alone won't stop table lookup attacks. Though the tables will take much longer to generate, once they're generated, attacks that use them will proceed at the same speed as with any other table lookup attack."
veracrypt adds salt, rainbow tables are useless.
Jan 16, 2015 at 11:27 AM
Good point, I had read that in one of the articles but I think it was a case of information overload!
Jan 23, 2015 at 10:44 AM
This is a user interface issue. It is unreasonable to keep users guessing as to what is occurring inside Veracrypt at boot. If you cannot provide immediate feedback, Veracrypt users are faced with the unpleasant dilemma: "Did I type in the correct password?", "Did the system crash?". Veracrypt trust/acceptance would be much improved across a broader spectrum of users if at the very least there was an immediate confirmation of good/bad password, and a countdown clock to boot up.
Jan 25, 2015 at 1:17 PM
L0ck wrote:
Software developers never retire, they just wait :)
I didn't wait long. I have an 8 year old grandson whose world is much more fun than the one I've inhabited for the last 64 years. I'm keeping my skills sharp by devising ways of keeping up with him in Minecraft - and occasionally succeeding.
Thank you, although we do have our robust moments here :)
I'm glad to hear it.
I just want to clarify something, the option would not weaken the encryption, but it would weaken the hashing of the password, to then access the encryption key. It amounts to the same risk, but they are different problems :)
Cool. As I implied, I know little about current encryption technology.
It certainly would. It is also the opinion of Mounir, who is at the current time agonising over going against his principles for VeraCrypt or pleasing the users who requires less security than VeraCrypt currently offers.
As I read earlier discussions and learn more about the group and its aims, I realise that it would certainly be wrong to compromise the founding principles of VeraCrypt in deference to potential users who may have no real need for its differentiating features. However, I do feel that the potential downsides to the use of enhanced encryption, e.g. boot times, should be discussed in the introductory documentation. This would not deter the intended users, but it may prevent possible unjustified adverse comments and publicity. Incidentally, I must praise you all on the quality of the documentation!
There will be a new feature to make the boot loader perform 32bit calculations, this should about halve the boot time, hopefully this will please all but the most impatient.
Having now come round to your point of view, I wonder if even this is a step in the wrong direction. Shucks, now I'm getting paranoid!
However I think you know where you let yourself down LOL Short password are bad, even when using high iterations, have you considered using a password and a keyfile ?
Ha! I know you're right. Yes, I have started using keyfiles, and have also considered randomly generated passwords. If nothing else, I now realise that I need to seriously reconsider my approach.
Hey, you don't want to come out of retirement for a few weeks do you ??? Mounir would welcome any help.
Ask my wife! ...on second thoughts, don't!!!