Post by firstname.lastname@example.org Post by jack3,?.com Post by email@example.com
Which of the several spawns from TrueCrypt can I trust with my data?
What's wrong with trusting the original until the other(s) prove their
I'm no expert on this stuff. I'm just relying on past performance. I
find that's the best to do with proggies or people.
According to; https://truecrypt.ch/downloads/
Windows (XP/Vista/7/8) sig TrueCrypt Setup 7.1a.exe
I want to move to win 10, and install a fresh (whole disc?) encryption
product. Is "TrueCrypt Setup 7.1a.exe" compatible with win 10?
The comedy of it. The Community score is +874.
The article here hints at the practical details.
Windows 7 and Windows 10 are similar, in that they're BCD
based, and both Windows 7 and Windows 10 have separate boot
materials someone can manipulate. But in Windows 7, they might
have been using MBR and BIOS boot, rather than the more
futuristic GPT and UEFI boot. As long as you remain conservative
in your choice of setups, Windows 10 has many things in common
with Windows 7.
One of the reasons Windows 7 has System Reserved and C: , is so
that Bitlocker can encrypt C: and leave System Reserved unencrypted.
That allows boot materials to be on System Reserved, and with the
Bitlocker driver and/or control panels loaded, then C: can be
considered. You need a bit of a boot loader, to prepare for
You can also combine boot materials, onto C:, to reduce the
number of primary partitions used on MBR disks. The technique
is shown here. Doing this, would cause problems for applying
Bitlocker to all of C: . For your TrueCrypt, you'd have to
understand where the boot materials are hidden, so that the
entire disk can be encrypted. There has to be a small bootloader
For example, right now I have an SSD with Windows 10 on it,
with MBR partition, BIOS boot, and no System Reserved. That
means the BCD file and \boot are on C: .
You should follow the instructions in the TC manual for Windows 7,
and do likewise on Windows 10. If doing an Upgrade Install,
your existing MBR partitioning choice and BIOS boot choice,
should continue to work.
The SuperUser thread, while not authoritative by any means,
suggests decrypting before upgrading. And I have to agree
that's the safest approach. And it doesn't really matter
what set of initial conditions you provide, Upgrade Installs
have a measure of danger, and you should backup first. If
you find, for some reason, that no backup tools do a good
job on an opened TrueCrypt setup, you have the option of
using "dd.exe" and while that drive is a data drive (you're
not using it), you can just dd all the sectors into a large
file for safe keeping. There is always *some* way to do
a backup, if the commercial products are barfing.
http://www.chrysocome.net/dd # usage info is here
When I calibrate backup software, I make my first "safety"
backup with dd.exe. If the attempt to restore my backup
using the commercial software fails, then I restore the separately
collected image file using dd.exe. Use an Administrator Command Prompt
window to make your dd.exe backup, as dd.exe needs raw
access to the disk to back up the sectors. You can
even do such "dd" activity from Linux if you want,
as they have a dd too.
And if you did that, backed up a TrueCrypt drive, there's
no point trying to compress the image of the drive.
Encrypted drives are "high entropy" and don't compress.
In other cases, if someone asked, I might suggest
"piping" the output of dd to the command line version
of 7ZIP, to make the file smaller. But if the disk is
encrypted when you try to copy it in an inactive state,
then the file should be in-compressible. If you shove
1TB of data into 7ZIP, you'd get 1.001TB of data out
of it, and no savings accrued.
I don't encrypt things here, because of the "write once,
read never" nature of encryption. Does Truecrypt have
known data recovery techniques ? If the file system
screws up, how does a person get their data back ?
If I did put things in there, it would have to be
things I could afford to lose.
As an example of an experiment I carried out recently,
I tried to boot from a VHD image. Windows allows
adding a VHD file as a second OS, in a multiboot
Win10 Native (on C: partition)
Win10 VHD (a file containing the whole OS, stored on C: )
Well, two things happened. First, the boot screwed up,
with the Windows 10 VHD screen flashing over and over
again. It was a bitch to deal with and shut down (Task
Manager helped). But while I was in there, I also tested
attempting to run an Upgrade in there, using the
16299 ISO image. And the installer flat-out said, it
doesn't support upgrading VHD images. So it's possible, if
you attempt to use a Win10 DVD, that the installer will
announce its policy at the very beginning, before you've
invested a lot of time on it.
As I understand it, the drop-dead date for the
"Free Upgrade" to Win10 is Dec.31 of this year.
For the past little while, the "Accessibility" excuse
was used by Microsoft, for continuing to offer the OS
as a free upgrade to Win7 SP1 and Win 8.1 users.
If you're using a retail boxed copy of Windows 10,
then you have no time constraints on your project,
and can try after Dec.31 if you want.