Quantcast
Channel: VeraCrypt
Viewing all 7620 articles
Browse latest View live
↧

New Post: 2nd hidden drive letter exists, and appears after dismount and eject

January 25, 2016, 8:34 pm
$
0
0
Hello,

The issue can occur when using both TrueCrypt and VeraCrypt volumes or if you used version 1.15 in the past which has this problem.

There may be something in the registry causing the issue.

First upgrade to latest version 1.16 or higher. I include this statement for the benefit of other users reading this thread.

With the all volumes dismounted, perform the following.

Using a modified version of Idrassi's instructions:
Check the registry key "HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices" using regedit. Scroll down and you'll find entries starting with "\DosDevices\" which indicate the drive letters that are taken by the system. Before mounting any volume, double click on each one and remove the ones contains the name "VeraCrypt" and "TrueCrypt".
Also, there are other entries whose name start with "#{" and "\??\Volume{": double click on each one of them and remove the ones whose data value contains the name "VeraCrypt" and "TrueCrypt".
.
Reboot PC.

Kind Regards.
↧
Search

New Post: Allow using "blocks range" within storage device to create/mount encrypted volume

January 26, 2016, 3:39 am
$
0
0
@quainta,

i couldnt really figure out where did you take this number (9,663,676,416) from, bytes, bits, sectors?... but thats not important.... i assume it is correct.... but in order for you to decrypt your own volume, you will have to memorize and enter the offset number (upto 9,663,676,416)..... so in the current version of VC, if you just append your offset number at the end of your password, then bruteforcing it will require exactly 9,663,676,416 more combinations to complete :)
↧
↧

New Post: Writing to external hard drives in a hidden OS

January 26, 2016, 5:24 am
$
0
0
Is there any way to mount an external hard drive NOT as read-only? I would like to write data to one. I've tried removing the read-only attribute with diskpart and through modifying registry but it didn't work.
It makes transferring any data between the decoy and hidden OS very difficult - I've used CDs for this because every USB device is read-only.
↧

Source code checked in, #903cefcde39bcb81315356a3d6041fabd72d3a80

January 26, 2016, 4:13 pm
$
0
0
Language XML files: update with new fields. Reoder node so that new additions are at the bottom. This makes it easier for Crowdin.com import.
↧

New Post: Allow using "blocks range" within storage device to create/mount encrypted volume

January 26, 2016, 11:31 pm
$
0
0
@quainta,

I didnt say the offset number value is to be appended to the password. I am just saying that as you have to memorize the offset number and enter it somewhere, you will achieve the same enhancement in terms of bruteforce if you just add that number at the end (or start or wherever) of your current password with the current version of VC.

Mathematically (unfortunately), there is no way to add N bits of "entropy" to your initial input (be it password, pim number, offset position number, etc.) and achieve even N+1 required operations for the bruteforce attack on your system, unless you use artificial iterations (or other similar operations such as the PIM iterations in VC), that will slow down the mounting process.

As to plausible deniability however, your suggested method can be eventually indeed used in a very smart way...
↧
↧

New Post: I wonder if this is a good Veracrypt security practice. THANKS ADMIN.

January 26, 2016, 11:44 pm
$
0
0
Hi VC admin,

I posted 2 questions in the following thread last week and perhaps admin is busy or has overlooked the questions, as so far there is no reply. Sorry to raise the questions here again and a reply from admin or any VC users knowng the answers, would be much appreciated. Thanks.

Question 1 is related to whether a method of backing up VC containers from a hard drive to a SD card is a good VC security practice or not.

Question 2 is not directly to VC but is also related to computer security and anyone who have relevant knowledge and can provide a little assistance is greatly appreciated.

The 2 questions are described in the following thread that was posted last week.

https://veracrypt.codeplex.com/discussions/650339

Thanks.
↧

New Post: Allow using "blocks range" within storage device to create/mount encrypted volume

January 27, 2016, 12:52 am
$
0
0
@Alex512

Looks like you totally misunderstand the idea. The idea is to locate, within container (file or raw device), of size M, encrypted volume of size N (N < M).

That gives (M - N) possibilities to locate actual position of encrypted data. Other encryption parameters known, it would require up to (M - N) times as much time to decrypt the volume.

This is about hiding the actual volume location and thus nullifying bruteforcing attempts if location is guessed incorrectly. If you only know PIM and password, you will have to try up to (M - N) times before you actually find and decrypt it.

I hope this time you understand the idea.
↧

New Post: Allow using "blocks range" within storage device to create/mount encrypted volume

January 27, 2016, 1:25 am
$
0
0
quainta wrote:
@Alex512

Looks like you totally misunderstand the idea. The idea is to locate, within container (file or raw device), of size M, encrypted volume of size N (N < M).
correct
That gives (M - N) possibilities to locate actual position of encrypted data. Other encryption parameters known, it would require up to (M - N) times as much time to decrypt the volume.
i would say it would require up to M possibilities to locate the start of the file (equals to M times more combinations to bruteforce)
This is about hiding the actual volume location and thus nullifying bruteforcing attempts if location is guessed incorrectly. If you only know PIM and password, you will have to try up to (M - N) times before you actually find and decrypt it.
Yes, but if one tries to bruteforce it, he will try all M possible locations of the start of the hidden file, thereby multiplying the possible possibilities by M. Add M to your password and you get the same :)
↧
Search

New Post: Can't boot

January 27, 2016, 2:45 am
$
0
0
Hi Guiys,

Can you please help me to solve this?

When I open my Lenovo think pad it said like:
"The file is possibly corrupt. the file header checksum does not match the computed checksum " and never go through my start up. It's stuck.

Please help.

Thanks
↧
↧

New Post: Can't boot

January 27, 2016, 2:59 am
$
0
0
Hi,

Can you please post a screenshot of the error message?
When does this error appear? Is it Windows error?

VeraCrypt never displays such message. Without details, nobody can help.
↧

New Post: Can't boot

January 27, 2016, 3:04 am
$
0
0
Hi idrassi,

Here's the screenshot. Don't know what to do.

Thanks

Inline image 1

↧

Released: VeraCrypt version 1.17-BETA18 (Jan 26, 2016)

January 27, 2016, 4:11 am
$
0
0

Changes between 1.16 and 1.17-BETA17 (26 January 2016) :

  • All OSs:
    • Support UNICODE passwords: all characters are now accepted in passwords (except Windows system encryption)
    • Cut mount/boot time by half thanks to a clever optimization of key derivation (found by http://home.arcor.de/skanthak/)
    • Sign binaries using both SHA-1 and SHA-256 to follow new Microsoft recommendations.
    • Solve issues under Comodo/Kaspersky when running an application from a VeraCrypt volume (Reported and fixed by Robert Geisler)
    • Bootloader: Protect password/PIM length by filling the fields to maximum length with '*' after ENTER
    • Solve issue with system favorites not being able to be mounted to drive A:
    • Solve lost focus issues for after displaying the waiting dialog
    • Implement PIM caching, for both system encryption and normal volumes. Add options to activate it.
    • Internal rewrite to make VeraCrypt native UNICODE application.
    • Workaround to avoid false positive detection by some anti-virus software.
    • Hide disconnected network drives in the list of available drives. Add option to make them available for mounting.
    • Solve issue that caused in some cases configuration and history XML files to be updated even when not needed.
    • Fix leak of path of selected keyfiles in RAM.
    • Fix TB unit can't be deselected in VeraCryptExpander.
    • Add Alt+i keyboard shortcut for "Use PIM" checkbox.
    • Minor GUI and translations fixes.
  • Linux/MacOSX:
    • Fix issue of --stdin option not handling correctly passwords that contain a space character (reported and fixed by Codeplex user horsley1953).
    • Fix issue creating volumes using command line with a filesystem other than FAT.
    • Support K/M/G/T suffixes for --size switch to indicate unit to use for size value.
↧

Updated Release: VeraCrypt version 1.17-BETA18 (janv. 26, 2016)

January 27, 2016, 4:11 am
$
0
0

Changes between 1.16 and 1.17-BETA17 (26 January 2016) :

  • All OSs:
    • Support UNICODE passwords: all characters are now accepted in passwords (except Windows system encryption)
    • Cut mount/boot time by half thanks to a clever optimization of key derivation (found by Xavier de Carné de Carnavalet)
  • Windows:
    • Fix dll hijacking issue affecting installer that allows code execution with elevation of privilege (CVE-2016-1281). Reported by Stefan Kanthak (http://home.arcor.de/skanthak/)
    • Sign binaries using both SHA-1 and SHA-256 to follow new Microsoft recommendations.
    • Solve issues under Comodo/Kaspersky when running an application from a VeraCrypt volume (Reported and fixed by Robert Geisler)
    • Bootloader: Protect password/PIM length by filling the fields to maximum length with '*' after ENTER
    • Solve issue with system favorites not being able to be mounted to drive A:
    • Solve lost focus issues for after displaying the waiting dialog
    • Implement PIM caching, for both system encryption and normal volumes. Add options to activate it.
    • Internal rewrite to make VeraCrypt native UNICODE application.
    • Workaround to avoid false positive detection by some anti-virus software.
    • Hide disconnected network drives in the list of available drives. Add option to make them available for mounting.
    • Solve issue that caused in some cases configuration and history XML files to be updated even when not needed.
    • Fix leak of path of selected keyfiles in RAM.
    • Fix TB unit can't be deselected in VeraCryptExpander.
    • Add Alt+i keyboard shortcut for "Use PIM" checkbox.
    • Minor GUI and translations fixes.
  • Linux/MacOSX:
    • Fix issue of --stdin option not handling correctly passwords that contain a space character (reported and fixed by Codeplex user horsley1953).
    • Fix issue creating volumes using command line with a filesystem other than FAT.
    • Support K/M/G/T suffixes for --size switch to indicate unit to use for size value.
↧
↧

New Post: HELP - URGENT: I Cannot Mount My Encrypted Drive !!!

January 27, 2016, 5:36 am
$
0
0
Hi Kaliya,

As testoslav explained, in situations like yours, partitioning the disk to have the exact same layout as before will solve the issue since you will end up with the same location as with the original partition and since the embedded backup header is located at the end of the partition you should be able to mount it using VeraCrypt if you check the mount option "Use backup header embedded in volume".

To be sure, I reproduced your situation in my side:
  • I started with a disk containing only one partition and which is encrypted with VeraCrypt.
  • Using DISKPART, I perform a CLEAN command on the disk: no more partitions on the disk
  • I used Windows Disk Management MMC to create a new partition on this and I choose not to format it (The disk was originally portioned using Windows Disk Management, that's why I choose it in order to have an identical layout).
  • I used VeraCrypt to mount the partition without the option "Use backup header embedded in volume": mount failed.
  • I then checked the option "Use backup header embedded in volume": mount succeeded!!
If you did this and it fails, this would mean that either the embedded header was erased somehow during your unfortunate manipulations or that you don't have the same partitions layout as before.

So the question is what tool was used to partition the disk originally?
Probably it was not done using Windows Disk Management and that's why you are not able to have the same layout as before. If you don't know, you could try to use a Linux Live CD to recreate a partition maybe you'll have more luck.


At this stage, nothing more can be done.

There was a tool for TrueCrypt called TestCrypt that tries to locate lost header in situations like yours but the project seems abandoned and no one has done a VeraCrypt adaptation of this tool. If such tool existed, you could have used it to scan your entire disk for the lost header (although such scan would take several hours if not days).
Personally I don't have time to work on such tool but hopefully someone can do so in the near future.
↧

New Post: Can't boot

January 27, 2016, 5:13 pm
↧
Search

New Post: Allow using "blocks range" within storage device to create/mount encrypted volume

January 27, 2016, 5:36 pm
$
0
0
@Alex512 Adding the counter (from 1 to M-N) to the password only gives the same raise in attempts amount. That's the only similarity.

Note that if the actual encrypted volume location is not known within the container media, adversary would efficiently waste their time trying to bruteforce the junk data. As far as I know, the only way to make sure this is encrypted volume is to try to decipher it the regular way. If password and/or PIM are unknown, that can make adversary's task much more time-consuming.

So, now only to wait and see whether anyone is interested to implement it.

Implementation notes: if adversary can keep track of container media changes, it would also be reasonable to overwrite with high entropy random generator other parts of the media (containing no information), to make it harder to guess where actual data are located.
↧

New Post: Can't boot

January 27, 2016, 7:43 pm
$
0
0
FYI: Your image is not showing in your post. You need to upload the screenshots and post the links.
↧
↧

New Post: Can't boot

January 27, 2016, 7:56 pm
$
0
0
Hi Enigma,

It's a blackscreen with Error Message:

The file header checksum does not match the computed checksum


↧

New Post: plausible deniability using passwords

January 27, 2016, 9:00 pm
$
0
0
I would like to propose the following change for your consideration a password that appears to allow access but simply shows a innocent-looking data file.
↧

New Post: Can't boot

January 27, 2016, 9:18 pm
$
0
0
Hello eera,

In the past, were you able to shutdown or reboot your PC with VeraCrypt system encryption of the OS successfully?
Do you remember which version of VeraCrypt you were using?

Scanning the language.xml file, the error message you posted does not match any of the VeraCrypt error messages.

Google searching using the error message your provided appears to be a problem with the Windows OS boot files are damaged.

I assume you get the VeraCrypt bootloader screen to enter your password. After you enter the password and hit enter, you then get the posted error message. Is that correct?
↧
Viewing all 7620 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>