Skip outer layer authentication, file encryption containers create hidden volumes directly

[风之暇想]

1. The first part of the file is a recognizable file for camouflage (e.g. mp4 can play the first part)
   2, using the end of the file can be loaded container
   3, can be disguised as a download incomplete file (file corruption is reasonable)
   Adding a skip outer validation option would do it.

[Enigma2Illusion]

I disagree with this request since this removes the primary header and the user only has one valid header to mount the volume which would now be the embedded backup header.

MOD NOTE: Moving to Feature Requests.

[风之暇想]

Solution, automatically create the backup header when creating the container; currently I use other tools to split the file and splice it again, which accomplishes the goal;
@idrassi what do you think?

[Enigma2Illusion]

Steganography encryption would require extensive code changes to the VeraCrypt software to perform steganography encryption while allowing VeraCrypt to maintain its core purpose of being a disk encryption software and virtual disk encryption (file containers).

For users that never heard of steganography encryption, here is explanation by the Kaspersky company.

https://www.kaspersky.com/resource-center/definitions/what-is-steganography

Of course, the developer of VeraCrypt will decide if he wants to undertake steganography encryption in addition to the current functionality of VeraCrypt's disk encryption.

[风之暇想]

1. It's not steganography, it's masquerading as a corrupted file (the header of the file looks normal)
   2、No need to redesign steganography, just disguise, based on the original functionality

[Enigma2Illusion]

Your proposal is absolutely steganography encryption. Trying to make it appear as a corrupted file is still steganography.

From the Kaspersky link I posted:

What is steganography?

Steganography is the practice of concealing information within another message or physical object to avoid detection.

I also have doubts of your example using a media file will pass a forensic examination since clearly the media section of the file is a valid media file using the mp4 file format specifications even with the additional data extension of the VeraCrypt file container at the end of the file.

it's masquerading as a corrupted file (the header of the file looks normal)

Also, the difference between the media file data patterns and the VeraCrypt file container data patterns should appear obvious to a forensic examination.

Too obvious to a forensic examination that the corruption (VeraCrypt file container) occurs after the complete media file data section.

As an example of data pattern occurred in the hidden volume's headers that led to recognition issue in TrueCrypt/VeraCrypt can be found in the Release Notes at the top of the page:

Note to users who created volumes with 1.17 version of VeraCrypt or earlier:
To avoid hinting whether your volumes contain a hidden volume or not, or if you depend on plausible deniability when using hidden volumes/OS, then you must recreate both the outer and hidden volumes including system encryption and hidden OS, discarding existing volumes created prior to 1.18a version of VeraCrypt.

[风之暇想]

1. The file volume does not have a recognizable header that matches the suffix, which is suspicious in itself
2. Hide the volume and write it to normal files, which is easier to deceive detection
3. Disguise as downloading an incomplete file, which is more reasonable (with a recognizable header)
   For these reasons, I recommend adding this feature (although I can do it with other tools) @idrassi

MOD NOTE: I removed your post "Disguise Microsoft Edge browser incomplete files" with RAR download file.

[Enigma2Illusion]

Again, your proposal does not address the issue of passing a forensic examination due to data patterns being different within the "corrupt" media file which will give VeraCrypt users a false sense of being able to avoid detection of their file container as I stated in my post.

Also I provided a real world example that involved the VeraCrypt hidden headers that was fixed in 1.18 version that required recreating all forms of VeraCrypt volumes if plausible deniability is important to you.

[风之暇想]

1, after embedding the hidden volume, I viewed the hexadecimal data and did not find any obvious anomalies in the data pattern (I'm using VeraCrypt 1.26.12)
2, download the file, is directly access to the disk, so it will overwrite the data left in the disk (hidden volume can be plausibly denied, even if the data pattern is abnormal)
3, if you find a suitable encrypted file extension, such as encrypted zip, encrypted gho backup, etc. (embedded hidden volume will be more reasonable?)

[Enigma2Illusion]

You are not a computer forensic specialist nor are you using computer forensic specialty tools.

The point of my objection to your request is simple.

• You want VeraCrypt to implement a feature that you manually perform thinking that computer forensic examination cannot detect the file container.
• Your proposal may prevent detection from lower tier law enforcement depending on the specialist and tools. Or they can send your PC to an government agency that has the specialists and the proper computer forensic specialty tools.
• If this feature is added to VeraCrypt, the users will assume that the new feature has been properly vetted by specialists, audits and therefore is safe to use. This will damage VeraCrypt's security reputation.
• The code changes needed to add steganography is not trivial as you make appear in your posts which would impact the Volume Tools and the developer has very limited free time to work on the VeraCrypt project.
• An audit may prove that the steganography feature should be removed. This happened with the GOST89 encryption algorithm that was requested by a user.

.
In my opinion, the VeraCrypt roadmap should not include steganography due to the extra coding, testing, maintenance efforts along with the associated risks of including steganography.

[风之暇想]

It looks like it will have to be combined with other steganography tools, the embedding method is only good for simply avoiding detection. @jertzukka

[Jertzukka]

It is very difficult to hide completely random data within other filetypes that are not random. This will pass the cursory glance, but any serious analysis will reveal that your corrupted file or video file contains completely random data. You don't even need to get into video format specifications to see what the stream end sequence looks like, just measuring entropy in the file is enough. Attached is an example of the entropy on a 360MB video file which actually is a 255MB video with a 105MB container appended to it.

Only way this would have a chance to work is to use a filetype which also looks like random data, such as encrypted archives (7zip, rar) though I haven't tried what it looks like. That would bring its own problems as the archive header probably has its own metadata which wouldn't necessarily match with the decoy filesize.