Would it make sense to use default PIM value 485 for Argon2 too (instead of 12)? Suppose somebody uses PIM 750 for extra security on PBKDF2 based disk and enters wrong password. VeraCrypt will try all PRF's with PIM 750 so Argon2 will be tested with very high parameters (60x the default) compared to other PRF's. Why introduce the difference? Could be as simple as dividing by 40 and feeding that into the existing formula.
Currently, there is no method to directly derive other segments, but using HKDF for derivation can achieve maximal separation, leaving attackers with no means to break it. Even if one of the encryption algorithms (such as AES) is completely compromised, only the subkeys will be exposed, while the master key remains secure.
@Mounir: Gemini and ChatGPt firmly and stiffly claim that there is a secondary key that decrypts the master key. This secondary key is stored in the encrypted RAM in plain font. With a CBA, the RAM is copied and the secondary key is located with the elcomsoft app and thus the master key can be decrypted. Is that the danger you mentioned? We are now in 2025. Or has something changed? @Mounir: Gemini und ChatGPt behaupten fest und steif, dass es einen sekundär-Schlüssel gibt, welcher den Hauptschlüssel...
Could you elaborate on this part: once one segment leaks, the remaining two segments are completely determined Focussing on PBKDF2, each generated block T_i is independent of other blocks, e.g. you can calculate T_64 without knowing T_0...T_63. In what sense does leaking the first segment determine the other segments? Assuming of course the password is not leaked.
I resized a VeraCrypt encrypted partition D: so VC doesn't mount any more. To restore partition size exactly I should know first and last sector number of the partition, then I can restore exact partition size using testdisk.exe. Firts sector number is no problem to find out because it should be last sector number of C: plus 1, and C: is still ok. But how can I determine the last sector of an encrypted partition??? Some info I got said VC would hold the first <n> bytes containing a header as a backup...
Hi, On Win10x64 I deleted the partition on an external usb stick, which was confirmed by Diskpart. However, Veracrypt's device list still shows the deleted partition, which means I can't encrypt the disk. Why does Veracrypt show phantom partitions? EDIT - This gets stranger, I also just tried a sd card, but same thing. I've uploaded 2 images showing the disconnect between VC and DM. I also tried diskpart clean, but nothing seems to fix it. FinalEDIT - Tried a removable ssd and it worked. So it looks...
@Mounir: Gemini und ChatGPt behaupten fest und steif, dass es einen sekundär-Schlüssel gibt, welcher den Hauptschlüssel entschlüsselt. Dieser sekundärschlüssel ist im verschlüsselten RAM in Klar Schrift gespeichert. Bei einem CBA wird der RAM kopiert und der sekundärschlüssel mit der elcomsoft app lokalisiert und somit kann der Hauptschlüssel entschlüsselt werden. Ist das die von dir erwähnte Gefahr? Wir haben jetzt 2025. Oder hat sich da etwas geändert?
@Mounir: Gemini und ChatGPt behaupten fest und steif, dass es einen sekundär-Schlüssel gibt, welcher den Hauptschlüssel entschlüsselt. Dieser sekundärschlüssel ist im verschlüsselten RAM in Klar Schrift gespeichert. Bei einem CBA wird der RAM kopiert und der sekundärschlüssel mit der elcomsoft app lokalisiert und somit den Hauptschlüssel entschlüsselt. Ist das die von dir erwähnte Gefahr? Wir haben jetzt 2025. Oder hat sich da etwas geändert?
Hi, On Win10x64 I deleted the partition on an external usb stick, which was confirmed by Diskpart. However, Veracrypt's device list still shows the deleted partition, which means I can't encrypt the disk. Why does Veracrypt show phantom partitions? EDIT - This gets stranger, I also just tried a sd card, but same thing. I've uploaded 2 images showing the disconnect between VC and DM. I also tried diskpart clean, but nothing seems to fix it.
Hi, On Win10x64 I deleted the partition on an external usb stick, which was confirmed by Diskpart. However, Veracrypt's device list still shows the deleted partition, which means I can't encrypt the disk. Why does Veracrypt show phantom partitions? EDIT - This gets stranger, I also just tried a sd card, but same thing. I've uploaded 2 images showing the disconnect between VC and DM. I also tried diskpart clean, but nothing seems to fix it.
Hi, On Win10x64 I deleted the partition on an external usb stick, which was confirmed by Diskpart. However, Veracrypt's device list still shows the deleted partition, which means I can't encrypt the disk. Why does Veracrypt show phantom partitions?
Hi, On Win10x64 I deleted the partition on an external usb stick, which was confirmed by Diskpart. However, Veracrypt's device list still shows the deleted partition, which means I can't encrypt the disk. I get this might be as simple as a reboot, but thought the behaviour strange.
Hi, just wanted some feedback on what is rhe best option for: is it advisable to keep container on usb drive or mac laptop for most security? I only view on the mac laptop but had orginally thoight if someone puts malware on the mac thats why its better on usb Is it more safe to use password manager like lastpass or store passwords on word file inwide VC container? Or is there a bettwr way? Just out of curiousity is brute force practically possible on VC wihtout PIM even for shorter passwords? I...
Adding to this thread since I'm not sure where else to put it, and this one deals with Seagate EXOS disks. I've recently purchased 8Tb Seagate 7E10 model st8000nm017b. Its' SMART attributes say it's been unused before me, and it has latest SB10 firmware (at least SG program doesn't find anything fresher for this disk). Testing it with Victoria program didn't show any glaring issues except write speeds were lower then expected - 70 to 50Mb/sec. But it wasn't a big enough issue for the shop to accept...
Adding to this thread since I'm not sure where else to put it, and this one deals with Seagate EXOS disks. I've recently purchased 8Tb Seagate 7E10 model st8000nm017b. Its' SMART attributes say it's been unused before me, and it has latest SB10 firmware (at least SG program doesn't find anything fresher for this disk). Testing it with Victoria program didn't show any glaring issues except write speeds were lower then expected - 70 to 50Mb/sec. But it wasn't a big enough issue for the shop to accept...
Hi, VC version 1.26: Angeblich soll der sekundäre Schlüssel (RAM-Entschlüsselungsschlüssel) im Speicher gespeichert sein bei Vollverschlüsselung und laufendem Windows Betrieb im Sperrbildschirm. Der Hauptschlüssel ist verschlüsselt. Mit dem sekundären Schlüssel könnte ein Fornesiker per cold boot Attak zweite Generation diese auslesen und den Hauptschlüssel bzw die Festplatte entschlüsseln. Ist das so richtig?
Hi, VC version 1.26: Angeblich soll der sekundäre Schlüssel (RAM-Entschlüsselungsschlüssel) im Speicher gespeichert sein bei Vollverschlüsselung und laufendem Windows Betrieb im Sperrbildschirm. Der Hauptschlüssel ist verschlüsselt. Mit dem sekundären Schlüssel könnte ein Fornesiker per cold boot Attak diese auslesen und den Hauptschlüssel bzw die Festplatte entschlüsseln. Ist das so richtig?
Hi, VC version 1.26: Angeblich sollen die sekundären Schlüssel (RAM-Entschlüsselungsschlüssel) im Speicher gespeichert sein bei Vollverschlüsselung und laufendem Windows Betrieb im Sperrbildschirm. Die Hauptschlüssel sind verschlüsselt. Mit den sekundären Schlüssel könnte ein Fornesiker per cold boot Attak diese auslesen und den Hauptschlüssel bzw die Festplatte entschlüsseln. Ist das so richtig?
ist das Forum noch aktiv? Oder weiß niemand eine Antwort?
ist das Froum noch aktiv? Oder weiß niemand eine Antwort?
It should check if FUSE-T is installed - and it is installed on my machine.
Veracrypt 1.26.24 on both OS's. I should mention I work with this config for the last 2 years, maybe more. And no problem till now. I guess I havent worked on my Windows session for the last 10 weeks... maybe something broken the last time I mounted this volume on my Windows session.
@ra0 Using exFAT avoids the issue of NTFS file permissions and security permissions. Please post the exact version of Linux version and the VeraCrypt versions you are using on both OS platforms so hopefully someone using Linux in the VeraCrypt community can provide insight to your issue. The only idea I have is either a Windows and/or Linux update changed the exFAT compatibility which is controlled by the OS and not VeraCrypt.
exFAT
@ra0 Which type of filesystem format did you use for the file container? (FAT, NTFS, exFAT, etc)
Hi Adrian, I really mean missing files, not hidden. And it it s every type of files, even folders, small or large size. Actually, based on the date on files, it seems that any file or folder created for the last 8 or maybe 10 past weeks, when the volume was mounted in Linux, are not present when this same volume is mounted in Windows.
Is the drive on which the files are stored an external portable drive? Is the drive formatted NTFS, and was NTFS used when setting up the encryption?
You don't say what type and size of files are 'missing' in Windows, but do you have Linux set up to show 'hidden' files, but Windows to hide them?
Thank you for your thoughtful response Kurt. I completely understand your point that the security benefits of a 512-bit hash like BLAKE2b-512 are minimal in PBKDF2-HMAC for deriving 256-bit keys, where iteration count (via PIM) and password entropy are the real bottlenecks. With VeraCrypt introducing Argon2id as a KDF option, the pfuture-proofing advantages I was aiming for with BLAKE2b-512 in PBKDF2 have largely lost their relevance. Argon2id’s memory-hard design, built on BLAKE2b, offers superior...
Did you see the footer? Updated on 22 September 2025 If Trump hadn't been there, the site wouldn't have existed.
https://www.truecrypt.org Their site used to warn that using TrueCrypt was not secure and they hosted TC version 7.2 which could only decrypt. Now the website is back with the last fully functional version 7.1 and no warnings whatsoever. The site may have been abandoned and re-registered by a new owner but that's just speculation. I would not download there as you cannot know if the downloads are and will remain legit. But the digital signature of the TrueCrypt 7.1 installer is valid and original....
What did you actually do? a. Encrypt your E: drive (a whole drive, or a partition on a drive)? b. Create a file container (with the .hc extension)? On what drive? c. Or both, ie encrpyt your E: drive, then mount it and create a file container on that? Can't possibly begin to assist you until you clarify this. It's also necessary to provided a relevant screenshot, ie of Windows Disk Manager, showing your drive configration.
Hello, I am using dual boot on my machine with Windows 11 and Ubuntu 20.04. On this same local disk, I also have a 3rd partition for my data, totally encrypted with VC. I usually work in Linux environment and only goes to W11 every now and then. But I have just noticed that when I mount this encrypted volume in W11, I don't see all the last files and folders created on this same volume mounted when I run Linux !! How is this possible ? Also, note that, since it is a dual boot machine, it is always...
Hi, VC version 1.26: Angeblich sollen die sekundären Schlüssel im Speicher gespeichert sein bei Vollverschlüsselung und laufendem Windows Betrieb im Sperrbildschirm. Die Hauptschlüssel sind verschlüsselt. Mit den sekundären Schlüssel könnte ein Fornesiker per cold boot Attak diese auslesen und den Hauptschlüssel bzw die Festplatte entschlüsseln. Ist das so richtig?
@Aarni K - Thank you for the suggestion, unfortunately, these drivers do not contain the PCKS#11 library. I think what is needed is something like: ASECardCryptoToolkit425x64En I cannot download it from the Wayback.
I noticed your post on Stack Overflow before it got deleted (I happen to have enough reputation to be able to view deleted posts still). Archive.org's Wayback Machine actually still has Athena's page https://web.archive.org/web/20120314114311/http://www.athena-scs.com/support/software-driver-downloads and from there you can find these direct download links: x86 (32-bit): https://web.archive.org/web/20120510235545/http://athena-scs.com/docs/reader-drivers/asedrv4003x86-en.exe x64 (64-bit): https://web.archive.org/web/20120510235216/http://athena-scs.com/docs/reader-drivers/asedrv4003x64-en.exe...
Hello VeraCrypt Support team, I’m writing because I am unable to mount my encrypted E: drive after creating it with VeraCrypt 1.26.24. Summary of the issue I installed VeraCrypt 1.26.24 and encrypted/locked my E: drive. At that time a .hc type container file was generated. My PC now shows only drives C: and E:. When I attempt to mount the E: drive, mounting fails and I receive error messages (I have attached screenshots of the exact messages). I cannot find the .hc container file on my PC. I think...
New problem in MacOS
Do I need to replace my SSD?
Hi, A short time ago my pc blew and I need to get the Veracrypt keys on the new computer (Win10x64). Unfortunately, it seems impossible to get hold of the official Athena middleware which would install the PKCS#11 library. I did find this: 32-bit asepkcs.dll v6.5.0.5 from https://www.pconlife.com/download/otherfile/86668/514faa8ad10855eba25cd61010030f4e/ The dll looks legit, at least it is signed by Athena Smartcard Solutions. Any advice would be greatly appreciated, since if the smartcard got bricked...
Hello, I just had the same issue on Fedora42. You can check the fingerprint using sudo rpmkeys --list | grep vera In my instance, the fingerprint did not match
In the middle of looking through files on a mounted drive, the files stopped being able to be opened and Windows prompted an error that states: "Location is not available; X is not accessible; the device is not ready" When I attempted to dismount the drive to restart my computer, VeraCrypt sent a warning message stating applications were still in use. After looking through task manager and attempting to end as many tasks as possible, VeraCrypt repeatedly sent the same warning message. I scanned the...
The concept of a single "PIM" is, I think, not truly compatible with Argon2id. Not without handicapping the best features of argon2id. Your typical key derivation will add about 20-bits of effective strength to a password. After that, for every added bit of effective strength you want to add, costs you double the processing time. One of the strengths of argon2id is the ability to add parallelism to this process. You get a free bit of effective password strength ever time you double the cores. Throwing...
The concept of a single "PIM" is, I think, truly compatible with Argon2id. Not without handicapping the best feature of argon2id. Your typical key derivation will add about 20-bits of effective strength to a password. After that, for every added bit of effective strength you want to add, costs you double the processing time. One of the strengths of argon2id is the ability to add parallelism to this process. You get a free bit of effective password strength ever time you double the cores. PIM formulas...
Contribution Request: Software Integration for VeraCrypt
Just tried out the beta. Following bugs still exist: 1) Preboot-authentication overwrites password with a single * to obfuscate the length, but it does not replace the PIM with a single * - this is a very long standing bug, having existed since the beginning of EFI. 2) Booting from the rescue disk does not read DcsProp from the rescue disk - it reads from the system drive's EFI folder. I also note that EFI bootloader is byte-for-byte identical with previous version. I take it then that Argon2id is...
For Argon2id, it shows up in the list of features for Windows but is conspicuously absent from Linux. Does this mean that Linux can no longer open a volume so created? If this is the case, then it needs to be noted in rather large print. Linux is a common recovery platform, and if it can no longer open a Windows container/drive/system-drive that uses argon2id, then people will need to know that before they make the switch.
Thank you very much! It work´s.
@cwelzel: You should install latest macFUSE version 5.0.6 (https://macfuse.github.io/). This is what I used for my Tahoe mac Mini.
I got the follow message: Unsupported macOS Version The installed version of macFUSE is too old for the operating system. Please upgrade your macFUSE installation to one that is compatible with the currently running version of macOS. I´m using a MacMini M4.
@cwelzel: can you clarify what issue do you have with VeraCrypt on macOS Tahoe? Any error message? I personally installed and tested VeraCrypt 1.26.24 on macOS Tahoe (mac Mini M1) using both macFUSE and FUSE-T and I didn't encounter any issue.
@redjones888: I cannot reproduce this issue on a cleanly installed Fedora 42. VeraCrypt rpm package explicitly depends on fuse-libs which provides libfuse2 library so its dependency is managed automatically by dnf. Obvisouly has messed up with your fuse installation since libfuse.so.2 should be present at /usr/lib64/libfuse.so.2 (you can check manually if the file is there). I would suggest to reinstall fuse-libs using the command: sudo dnf reinstall fuse-libs
Good morning, I’m new to this forum, and maybe I’m asking a question that has already been asked and answered elsewhere. Since I installed “Tahoe” on macOS, I haven’t been able to access it anymore. Will this be possible again with the new update?
Thank you Sir for your hard work! Much Appreciated
Hi guys I am running Fedora 42 Workstation - and have had Veracrypt installed for weeks now and today it stopped work. So i removed it via Command line and all dependencies, re downloaded the RPM package from Vera's website and still won't open I tried running it from CLI and get this error. veracrypt: error while loading shared libraries: libfuse.so.2: cannot open shared object file: No such file or directory Now I installed all the libfuse files even xterm @fedora:~$ sudo dnf install libfuse2 Updating...
Thanks!
It seems that the document has not been synchronized to Chinese and Russian.
Be sure to enable VeraCrypt options in Preferences: "VeraCrypt Background Task" "Start VeraCrypt Backgound Task" . In the Auto-Unmount section enable the options: "User logs off" "Entering power saving mode" (this is when Window OS goes into sleep mode) "Force auto-unmount even if volume contains open files or directories" . Your Windows OS may be allowing USB connected devices to power down. Google search for Windows "USB selective suspend setting" and set to Disable. Even with the above changes...
@activist4219: unfortunately, I don't have access anymore to an ARM64 device. I'm now resorting to cloud based ARM64 VM to do testing. Working on system encryption requires physical access to ARM64 machine and I cannot afford to buy one for VeraCrypt development. So for now, I can do nothing on this front. If one day I get access, I will resume working on it.
@enigma2illusion: thank you for spotting this. I have fixed the issue. The correct filename is pbkdf2.html in lowercase.
I have done tests on Tahoe using latest version of both MacFUSE and FUSE-T and I didn't encounter any issues. Tests were done after upgrading from macOS Sonoma on a Mac mini M1.
Has anyone upgraded from Sequoia to Tahoe on Silicon M1, using latest versions of MacFuse and Veracrypt and everything works fine?
@idrassi sorry to intrude, but do you have any estimate for when VeraCrypt will support full-disk encryption for ARM64 devices? I’ve had a Surface Pro since the beginning of the year and would really like to go back to using VeraCrypt.
Be sure to enable VeraCrypt options in Preferences: "VeraCrypt Background Task" "Start VeraCrypt Backgound Task" . In the Auto-Unmount section enable the options: "User logs off" "Entering power saving mode" (this is when Window OS goes into sleep mode) "Force auto-unmount even if volume contains open files or directories" . Your Windows OS may be allowing USB connected devices to power down. Google search for Windows "USB selective suspend setting" and set to Disable. Even with the above options...
Be sure to enable VeraCrypt options in Preferences: "VeraCrypt Background Task" "Start VeraCrypt Backgound Task" . In the Auto-Unmount section enable the options: "User logs off" "Entering power saving mode" (this is when Window OS goes into sleep mode) "Force auto-unmount even if volume contains open files or directories" . Your Windows OS may be allowing USB connected devices to power down. Google search for Windows "USB selective suspend setting" and set to Disable. Even with the above options...
Be sure to enable VeraCrypt options in Preferences: "VeraCrypt Background Task" "Start VeraCrypt Backgound Task" . In the Auto-Unmount section enable the options: "User logs off" "Entering power saving mode" (this is when Window OS goes into sleep mode) "Force auto-unmount even if volume contains open files or directories" . Your Windows OS may be allowing USB connected devices to power down. Google search for Windows "USB selective suspend setting" and set to Disable. Even with the above options...
In general all my vc-encrypted external USB hard disk work fine. However I recently forgot accidentally to dismount such an external USB hard disk before Windows 10 shutdown. As a result I got the next time when I mount this external vc-encrypted USB hard disk a notification that this disk may by corrupt since it was not dismounted before last shutdown. I accepted to perform a chkdsk of this disk after mount.....and a lot of errors were found. Hmm, thats bad. Curiously the hard disk in focus was...
@idrassi The online documentation link is broken for: https://veracrypt.jp/en/PBKDF2.html located under the https://veracrypt.jp/en/Key%20Derivation%20Algorithms.html
Thanks for the reply
Thanks for the reply, I updated to version 1.26.27 and allowed the IME, the problem was solved smoothly, and the secure desktop could work normally
Thank you very much for your detailed answer. If I can assist / test something please let me know.
@idrassi Hello again, I tested the latest beta version 1.26.27 and didn't find any errors on my hardware. I’m waiting for support for UEFI encryption because it's a priority for me (Argon2) Thank you, bro!
With the correct password, loading the normal encrypted volume takes 2 seconds, and loading the hidden encrypted volume takes 5 seconds. It seems that this slowness occurs because the normal volume and the hidden volume are not decrypted in parallel together. Currently, the system first performs parallel decryption on the normal volume, and only after the normal volume decryption fails does it proceed to parallel decryption of the hidden volume—this sequential process leads to the delay. It is suggested...
@nilchernek: the 4 issues you mentionned fall in two categories: pretest failure: this is most likely causes by the fact that the driver fails to locate the bootloader boot arguments necessary for the encryption. These boot arguments are stored in special memory regions that normally allow communication between the bootloader and the driver. It happens that on some machines the memory range used by VeraCrypt bootloader is overwritten by another driver on the machine because VeraCrypt driver could...
@miked0a8sfdgafd Below is a screenshot of where the new option is located (I have changed how preferences are presented in the UI) A warning tooltip message is displayed when the mouse hovers over this new setting to explain its purpose.
@fzxx: in case of wrong password, VeraCrypt subsequently tries to open the hidden volume with this password. That's why you see double the time: once for normal header and when it fails it tries hidden volume header. This is part of VeraCrypt plausible deniability approach: automatically trying normal volume followed by hidden volume. So the case of wrong password will always be slowed no matter what we do.
Hi @idrassi, thank you very much for your work and release. I apologize for hijacking this thread, but might the following issues be resolved with the UEFI update? Veracrypt on Hyper-V? VeraCrypt and Windows 11 24H2 stuck during "booting..." System encryption pretest fails on win10 Precise error information for pretest failure Thank you
@miked0a8sfdgafd Please confirm that the Secure Desktop freeze issue when selecting Keyfiles/Tokens in Secure Desktop issue you reported is resolved by enabling the optional IME switch for Secure Desktop in the Windows BETA 1.26.27 version in the VeraCrypt Nightly Builds. Please report back in this forum thread if this resolved your Secure Desktop freeze issue when selecting Keyfiles/Tokens in Secure Desktop. https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/Windows/
For an incorrect password, parallel decryption should also take 2-5 seconds, because each algorithm almost always returns an error in around 2 seconds.
@fzxx: autodetection speed has been fixed already. once correct password is validated by correct KDF, other KDFs are aborted. This has been validated by myself and others on this forum. you original issue was about wrong password taking 10 seconds instead of 2 for normal passpwrd: this is normal as I explained in previous reply since no KDF is able to decrypt the header.
Parallel decryption should be able to increase the speed (once a thread successfully decrypts, the other threads are terminated immediately). Currently, does it seem to be decrypting in the order of algorithms?
@fzxx: thank you for the remainder. Concerning the first issue: I will study it more closely. I agree that HKDF is a modern and stronger way to derive independant key. I will provide a reply after study. Concerning the second issue: this is not an issue! if the password is wrong, VeraCrypt must try all KDF algorithms because it doesn't know the correct one (remember, there are no metadata in VeraCrypt volumes). So the time taken by trying a wrong password will be the time required for the slowest...
There are two issues that have not been fixed. https://sourceforge.net/p/veracrypt/discussion/features/thread/adb29bdd88/#ca37 https://sourceforge.net/p/veracrypt/discussion/technical/thread/5326026904/#e1a6/0af1/97d9
Thank you! I'm going to test it now. <3
@selectline I have uploaded version 1.26.27 with latest changes. It is compatible with 1.26.26 for Argon2. UEFI support is not yet done. It will require moving to 1.27.x. I have been spending time on the driver, so UEFI is in standby. Unfortunately, SSD speedup proved to be very challenging on robustness side so this effort didn't lead yet to a publishable result. I will put the drive aside and look into UEFI bootloader to bring Argon2.
Version 1.26 and newer VeraCrypt versions have deprecated the following features: TrueCrypt Mode HMAC-RIPEMD-160 Hash Algorithm GOST89 Encryption Algorithm . See the documentation below for remediation procedures. Conversion Guide for VeraCrypt 1.26 and Later Update on bumping minimum Windows version requirements for VeraCrypt https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/ Changes in 1.26.27 (September 20, 2025): All OSes: * Updated logo icons to simplified versions...
?
Increment version to 1.26.17 is packaging files.