Is there an issue with AES-Twofish-Serpent that fails whereas Serpent-Twofish-AES works ?

[Graham]

I'm sorry this post will be long but there's no other way of explaining it:

Veracrypt 1.22 64 bit (Both Windows 7 & Windows 10)
As I now need a larger container file I decided it's time to upgrade from Truecrypt to Veracrypt:
The process I followed was;

1. Open my working 256Mbyte Truecrypt container using Truecrypt (Serpent-Twofish-AES) as disk "Q" (normally "P")

2. Open Veracrypt and create a 512Mbyte container (AES-Twofish-Serpent) and open the new volume as disk "P". (Note the change from (Serpent-Twofish-AES) to (AES-Twofish-Serpent); not for any particular reason.

3. Copy all files from the Truecrypt disk "Q" to the Veracrypt disk "P" so that they are in the same folder structure. (Note disk "P" is the disk letter required by the INI file for my ancient (XP - but still working) Quicken program.)

4. Test Quicken: (it runs from the PC only the data is in the container)
   I have two Quicken Accounting files; "COTTAGE" and "G&D ACCOUNTS".
   The COTTAGE file opens correctly.
   The G&D ACCOUNTS file consistently fails to open.
   All other Excel & Word files etc. on the new container work.

The solution I found by accident:
5. Close the failing Veracrypt disk "P" and reopen as disk "S".

1. Create a Veracrypt 512Mbyte container (Serpent-Twofish-AES - note this) and open the new volume as disk "P".

2. Copy all files from the Veracrypt disk "S" (the container that failed as disk "P" AES-Twofish-Serpent) to the new Veracrypt Disk "P" so that they are in the same folder structure.

3. Test Quicken and both accounting files now open correctly with the new 512Mbyte container using Serpent-Twofish-AES.

The difference seems:
Serpent-Twofish-AES works
AES-Twofish-Serpent fails
I have tried this several times and the failure to open the Quicken file is consistent.

Using AES-Twofish-Serpent doesn't corrupt the files it just seems to stop Quicken from working. This is proven as in step (7) I coped the Quicken data from the failing AES-Twofish-Serpent version of the container.

This issue also appears in Windows 10.
The issue does not occur in Truecrypt.
I used the same complex password and keyfiles throughout.

I know that it's unlikely that this "feature" can be easily replicated as the Quicken program is no longer available but I do have screenshots.

I find this worrying as the accounting files date back a long time and I need to be confident that they are safe & secure (I keep many back-ups).
Any other thoughts/ideas on what could be causing this would be gratefully received.
Thank you.

[Enigma2Illusion]

One idea I have is to create a checksum on the Quicken files on the new VeraCrypt volume using AES-Twofish-Serpent (P drive) from the TrueCrypt Serpent-Twofish-AES (Q drive).

The following commands work on Windows 10 Pro.

• Mount the TrueCrypt volume on the Q drive and mount the VeraCrypt volume that fails to open the Quicken file on the P drive letter.
• Again, copy the Quicken file from the Q drive to the P drive.
• Open command line.
• Change directory to your Documents.

cd Documents
OR
cd C:\Users\<Your Account Name>\Documents

• Issue the following commands to create the checksum of the Quicken file on the Q and P drives. Each command should be on one line.

CertUtil -hashfile "Q:\<Directory path to file>\Filename.FileExtension" SHA512 > checkhash_Q.txt

CertUtil -hashfile "P:\<Directory path to file>\Filename.FileExtension" SHA512 > checkhash_P.txt

• Open both text files in Notepad located in your Documents.
• The hash values should be exactly the same if the file was not modified during the copy.

Do the two hash values between checkhash_Q.txt and checkhash_P.txt files match?

If the hash values match, then attempt to open the Quicken file on the P drive without making changes and close the program.

Repeat creating a hash file called checkhash_P_Opened.txt.

Does the hash values in checkhash_P_Opened.txt still match either checkhash_Q.txt or checkhash_P.txt files?

[Graham]

Thankyou for the great idea, Enigma2Illusion; appreciated:
The results are;
TrueCrypt Serpent-Twofish-AES (Q drive)
VeraCrypt volume using AES-Twofish-Serpent (P drive)

Checkhash Q & P are the same.

After Quicken fails to open the G&D_ACCOUNTS file.
I closed Quicken and took the hash: VeraCrypt volume using AES-Twofish-Serpent (P drive)

Checkhash P2 is the same.

So the G&D_ACCOUNTS file isn't altered (good news).

But I enclose:
"w10_veracrypt_test2.jpg" showing that Quicken fails to open the G&D_ACCOUNTS file using AES-Twofish-Serpent (P drive).
&
"w10_truecrypt_test2.jpg" showing that Quicken does open the G&D_ACCOUNTS file with Truecrypt using Serpent-Twofish-AES (P drive)

I'll be pleased to try anything else that may help to solve this problem.
Thank you for your interest in it.

[Enigma2Illusion]

Thanks for reporting your results. We now know the file is not being modified from the original file and it is not a VeraCrypt issue.

The next idea I have is to take ownership of the P drive Quicken file and try to open with the application. If that fails, take ownership of the directory and keep working your way up from the child directory.

https://www.windowscentral.com/how-take-ownership-files-and-folders-windows-10

Different folders can have different permissions and ownership permissions for user accounts in Windows that are inherited when you place a file in that folder.

[Graham]

Thanks again for your suggestion Enigma2Illusion, regarding permissions.
Apologies this response has taken so long but it has been the result of much time-consuming analysis.

I'm sorry that I omitted to mention that I did initially consider that permissions were a potential issue and checked the permissions & ownership between both the TC & VC containers and content and, as I had the "Take Ownership" shell extension on my Windows 7 PC, I did try that as it usually solves such issues; it didn't and that's why I tried exploring other possibilities, until desperation caused me to bother you all with my new topic based on the only seeming issue at the time (now clearly false).

However, since my previous posts I have been getting more and conflicting errors and realised that the Quicken .INI file contains the path to the Quicken program (so that the Quicken program can restart itself and store reminder configs etc.) that it seems to do when deselecting one file and selecting another. This defaulted correctly in W7 but differs in W10; so I've had to cure that issue before further testing by maintaining separate .INI files in each container's Quicken folder and replacing the .INI file at its hard-coded location with a .SYMLINK; this has solved the perceived differences/issues between TC & VC. And I've now proven that both Serpent-Twofish-AES and AES-Twofish-Serpent work or fail depending on whatever is the ultimate cause of the remaining problem (see below) so my initial query (the headline topic) is invalid.

The situation now is as follows:
1. With Windows 7; both TrueCrypt & VeraCrypt work correctly.
2. With Windows 10; TrueCrypt works but VeraCrypt has the issue that the Quicken COTTAGE file opens and the G&D_ACCOUNTS file doesn't.
Copying all Quicken files from the VeraCrypt container to an open disk and then accessing with the Quicken program both accounts files work.

Perhaps this could be:
a) Permissions/ownership; though I have checked these and don't think I've missed anything.

b) The Quicken program; but it works correctly with TrueCrypt (W7&10) & VeraCrypt (W7) and outside of a container file.
Apart from the .INI file there are no registry entries to consider.

c) A VeraCrypt issue; but it works correctly with Windows 7.
With Windows 10 & VeraCrypt the Quicken program can successfully validate the G&D_ACCOUNTS file!

d) A Windows 10 issue; but TrueCrypt works.
I temporarily disabled UAC but that didn't help.

I have, on occasion, had to force-close VeraCrypt as it would not dismount normally; this resulted in a Windows 10 stop error.

At this time I have little choice but to continue using TrueCrypt which isn't ideal.

If there are any other ideas or anything else I can try I'll be pleased to do so.
Meanwhile I will keep exploring a solution empirically; and if I find the answer I'll be sure to post it here.

Thanks to all readers for your interest; it is very much appreciated.

[Enigma2Illusion]

What happens if you rename the G&D_ACCOUNTS file to another name and using Quicken to open the file on the Windows 10 running VeraCrypt?

If there is something with Quicken "remembering" the wrong path or location in a configuration file or the registry, this should allow you to open the renamed G&D_ACCOUNTS file since there is no history of that renamed file being used before.

EDIT: You did take ownership of the dismounted file container. Correct?

[Graham]

The problem is solved!

Thank you so much for your last comment Enigma2Illusion, as it made me think about filenames & legacy programs that I hadn't considered at all; although I did change the filename during an earlier test. If you hadn't have suggested what you did, I think I would have been going around in ever increasing circles. What's important to me now is that I've proven why the issue exists that gives me the confidence in never losing access to these vitally important files.

The reason for the problem is actually quite simple; the solution is even more so: Shorten the filename!!!

I have proven that the hidden 8.3 filenames, designed for compatibility with legacy systems, are neither generated nor preserved by VeraCrypt in NTFS-formatted HC-containers under Windows 10. NTFS doesn't mandate 8.3 filename preservation and I suspect that VeraCrypt actually disables the feature on its containers for efficiency.

But VeraCrypt does NOT disable 8.3 filenames in Windows 7; nor for non-NTFS (FAT/FAT32 etc.) containers in Windows 10; though it DOES preserve the existing 8.3 filenames within NTFS TrueCrypt containers in TrueCrypt mode; however, it doesn't display them (i.e. they don't show by using DIR /X on the folder in a command window).

In my particular case this is why only one scenario was problematic:
[Windows 10 - VeraCrypt - HC container - NTFS - Legacy Program]
So as the G&D_ACCOUNTS.qdf file name is >8 characters and there was no accompanying 8.3 filename Quicken couldn't find it!

I need the container to be NTFS as I use NTFS Junctions etc. within the container (you can make junctions from NTFS to FAT/FAT32 but not vice versa); and NTFS does have the robustness of journaling; but also the legacy Quicken program needs the 8.3 legacy filenames to function that is incompatible with VeraCrypt Windows 10 NTFS containers.

Thus the easy solution to all of this is simply change the filename to: G&D_ACCS.qdf (8.3) and all is well.
It would be nice if there could be a parameter to NOT disable 8.3 legacy filenames in NTFS but legacy systems are dwindling fast so there's no real future need.

To sum up, the golden rule for LEGACY systems with VeraCrypt is clearly:
1. Do not use NTFS.
OR
2. If you must use NTFS; keep the filenames for the legacy systems as 8.3 (no long filenames).

Sorted! And thank you once again; I really appreciate your interest & help.