VeraCrypt
aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--doc/html/Encryption Scheme.html2
1 files changed, 1 insertions, 1 deletions
diff --git a/doc/html/Encryption Scheme.html b/doc/html/Encryption Scheme.html
index 67d669a2..e159c7e8 100644
--- a/doc/html/Encryption Scheme.html
+++ b/doc/html/Encryption Scheme.html
@@ -49,41 +49,41 @@ Hidden Operating System</a>). If there is a hidden volume within this volume (or
it has to be determined by attempting to decrypt this data; for more information see the section
<a href="Hidden%20Volume.html"><em>Hidden Volume</em></a>).
</li><li>Now VeraCrypt attempts to decrypt the standard volume header read in (1). All data used and generated in the course of the process of decryption are kept in RAM (VeraCrypt never saves them to disk). The following parameters are unknown&dagger; and have
to be determined through the process of trial and error (i.e., by testing all possible combinations of the following):
<ol type="a">
<li>PRF used by the header key derivation function (as specified in PKCS #5 v2.0; see the section
<a href="Header%20Key%20Derivation.html">
<em>Header Key Derivation, Salt, and Iteration Count</em></a>), which can be one of the following:
<p>HMAC-SHA-512, HMAC-SHA-256, HMAC-RIPEMD-160, HMAC-Whirlpool. If a PRF is explicitly specified by the user, it will be used directly without trying the other possibilities.</p>
<p>A password entered by the user (to which one or more keyfiles may have been applied &ndash; see the section
<a href="Keyfiles%20in%20VeraCrypt.html">
<em>Keyfiles</em></a>), a PIM value (if specified) and the salt read in (1) are passed to the header key derivation function, which produces a sequence of values (see the section
<a href="Header%20Key%20Derivation.html">
<em>Header Key Derivation, Salt, and Iteration Count</em></a>) from which the header encryption key and secondary header key (XTS mode) are formed. (These keys are used to decrypt the volume header.)</p>
</li><li>Encryption algorithm: AES-256, Serpent, Twofish, AES-Serpent, AES-Twofish- Serpent, etc.
</li><li>Mode of operation: only XTS is supported </li><li>Key size(s) </li></ol>
</li><li>Decryption is considered successful if the first 4 bytes of the decrypted data contain the ASCII string &ldquo;VERA&rdquo;, and if the CRC-32 checksum of the last 256 bytes of the decrypted data (volume header) matches the value located at byte #8 of the
decrypted data (this value is unknown to an adversary because it is encrypted &ndash; see the section
<a href="VeraCrypt%20Volume%20Format%20Specification.html">
<em>VeraCrypt Volume Format Specification</em></a>). If these conditions are not met, the process continues from (3) again, but this time, instead of the data read in (1), the data read in (2) are used (i.e., possible hidden volume header). If the conditions
are not met again, mounting is terminated (wrong password, corrupted volume, or not a VeraCrypt volume).
</li><li>Now we know (or assume with very high probability) that we have the correct password, the correct encryption algorithm, mode, key size, and the correct header key derivation algorithm. If we successfully decrypted the data read in (2), we also know that
we are mounting a hidden volume and its size is retrieved from data read in (2) decrypted in (3).
</li><li>The encryption routine is reinitialized with the primary master key** and the secondary master key (XTS mode &ndash; see the section
<a href="Modes%20of%20Operation.html"><em>Modes of Operation</em></a>), which are retrieved from the decrypted volume header (see the section
<a href="VeraCrypt%20Volume%20Format%20Specification.html">
<em>VeraCrypt Volume Format Specification</em></a>). These keys can be used to decrypt any sector of the volume, except the volume header area (or the key data area, for system encryption), which has been encrypted using the header keys. The volume is mounted.
</li></ol>
<p>See also section <a href="Modes%20of%20Operation.html">
<em>Modes of Operation</em></a> and section <a href="Header%20Key%20Derivation.html">
<em>Header Key Derivation, Salt, and Iteration Count</em></a> and also the chapter
<a href="Security%20Model.html"><em>Security Model</em></a>.</p>
<p>* If the size of the active partition is less than 256 MB, then the data is read from the
<em>second</em> partition behind the active one (Windows 7 and later, by default, do not boot from the partition on which they are installed).</p>
<p>&dagger; These parameters are kept secret <em>not</em> in order to increase the complexity of an attack, but primarily to make VeraCrypt volumes unidentifiable (indistinguishable from random data), which would be difficult to achieve if these parameters
- were stored unencrypted within the volume header. Also note that if a non-cascaded encryption algorithm is used for system encryption, the algorithm
+ were stored unencrypted within the volume header. Also note that in the case of legacy MBR boot mode, if a non-cascaded encryption algorithm is used for system encryption, the algorithm
<em>is</em> known (it can be determined by analyzing the contents of the unencrypted VeraCrypt Boot Loader stored in the first logical drive track or on the VeraCrypt Rescue Disk).</p>
<p>** The master keys were generated during the volume creation and cannot be changed later. Volume password change is accomplished by re-encrypting the volume header using a new header key (derived from a new password).</p>
<p>&nbsp;</p>
<p><a href="Modes%20of%20Operation.html" style="text-align:left; color:#0080c0; text-decoration:none; font-weight:bold.html">Next Section &gt;&gt;</a></p>
</div><div class="ClearBoth"></div></body></html>