Well guys, after I have successfully used the newest version of TrueCrypt on a bunch of other topics I now want to accomplish full system encryption (with Pre-Boot Authentication) on OpenSuse 11.1.
Hint: It seems to be the case that full system encryption is not supported (yet?). Anyone here who is able to confirm my statement?
TheMask.
Not sure if I understand you correct because this is in Applications and you talk about ‘system encryption’.
Nevertheless the following link may be of interest: Encrypted Root File System - openSUSE
What I actualkly meant is live system encryption of the whole drive like possible on windows. That’s missing on Linux so far…
Thanks anyway.
TheMask.***
Mh… I´m still struggling with system drive encryption. What I actually want to accomplish is to encrypt my whole system drive an the fly. Everything.
Somehow that should be possible with TrueCrypt (at least it´s no issue to do so on any Windows system).
Arrg… I´d really love to use TrueCrypt for that task - if ANYONE comes up with a hint/solution/possibility: PLEASE feel free to reply. THANKS.
TheMask.
According to the documentation, TrueCrypt can currently encrypt the following operating systems:
* Windows Vista
* Windows Vista x64 (64-bit) Edition
* Windows XP
* Windows XP x64 (64-bit) Edition
* Windows Server 2008
* Windows Server 2008 x64 (64-bit)
* Windows Server 2003
* Windows Server 2003 x64 (64-bit)
So apparently nothing for Linux, yet…
Lenwolf
Via google I found TrueCrypt - Free Open-Source On-The-Fly Disk Encryption Software for Windows Vista/XP, Mac OS X and Linux on top. It says (among other things):
Free open-source disk encryption software for Windows Vista/XP, Mac OS X, and Linux
So where do you get stuck?
Good boy. 
I get stuck setting up full system drive encryption (option is missing on Linux version I guess…) including pre-boot authentication.
TheMask.
For everyone who is interested: I´ve opened a thread about the issue on the TrueCrypt forum.
Please view it here: :: TrueCrypt Forums ::](http://forums.truecrypt.org/viewtopic.php?t=15018)
TheMask.***
I’ve just been given a good “alternative” for TrueCrypt, which I want to share with you. The Following answers are coming from TrueCrypt board members:
I’ll try it and maybe I’ll report back later how things worked out for me. If anyone knows of a “better” software, please let me know right away!
In the meantime I hope I could help those guys who have been looking for a good solution too. 
Enjoy.
TheMask.
I know it’s been a while since this post was updated but reading it and the thread in truecrypt forums was educational.
I currently use Truecrypt on my windows laptop, but wanted to install any linux distro on it as the primary OS. My concern was I wanted to be able to encrypt the entire volume so if someone stole my laptop, they would see basically a blank hard drive. If they stole it to get personal data from me and new it was encrypted they would have to spend hours and hours, in fact I think it was somewhere in the neighborhood of 2000 years to decrypt the data. (My password is quite long and random.)
The reason I think it needs to be an entire system encryption is to make sure that while I am using the drive everything written to the HD is in an encrypted form. So when working on a document, website, whatever that has temporary files that may contain sensitive data that the system never has the ability to write that cleartext to any temporary location with out it being encrypted.
Full hard drive encryption gives me the sense of security that the OS can’t accidentally write on the HD in clear text. (I am trusting that to be the case anyway.)
I have not fully looked into what happens in linux on the boot and root drives, they may in fact be read only drives, or have the ability to be setup as read only. If that’s the case, now I am trusting the OS to honor the read only status and not write my sensitve data there in clear text for someone with advanced hard drive tools to be able to pull that data off, even if it’s over written. (I know there are ways to see “ghosting” on drives even if things are overwritten. Hence the reason for 30+pass drive wiping software.)
Again thanks for starting this thread over a year ago, I will continue to read up on this subject. If you have any links or places you have also looked for a solution to this problem, please post or send me a PM on the forums here.
Until the next time,
Thirteen
Remember drive in windows means partition. So when you say full drive in a windows reference you are speaking about a partition. You can install Linux on a single partition thus a single drive in windows speak. And encrypt it.
What a surprise! And how exactly are you going to boot it then?
Last time I checked the best you could do was to use two partitions. One of them has to be unencrypted and should contain GRUB or something alike. And the rest can be encrypted. However, not every Linux supports that and normally they also require “/” and “/usr” to be unencrypted.
I do not know how good Truecrypt is, but on top of all this misery with LUKS and friends the only out-of-the-box solutions do not allow you to use anything but plain password as a way of authentication. So if you are among those who are truly concerned about security and prefers to use things like security tokens then you have to hack that bootloader yourself, hoping that if you get it right your patch won’t be wiped out by the next software update. This also means a lot of wasted time.
On 07/19/2012 01:06 PM, rtvd wrote:
> This also means a lot of wasted time.
this is an over three year old thread (the post replied to is over two
years old, also replying to a stale thread)…
the thread dealt with versions no longer supported, and hints no longer
(if ever) valid…
if you (‘rtvd’) are searching for answers to a problem you have, i
hereby commend you for doing that
–thank you–
but be cautious before putting to use what may (or may not) have worked
in a no longer supported version…because, this Linux is a FAST moving
train…lots of stuff that worked one way in openSUSE 11.4 is no longer
valid if one attempts to apply it to openSUSE 12.1 (and the same for
12.1 to 12.2, etc)
pay attention to the posting dates and versions discussed…
–
dd
On Thu, 19 Jul 2012 11:06:02 +0000, rtvd wrote:
> I do not know how good Truecrypt is, but on top of all this misery with
> LUKS and friends the only out-of-the-box solutions do not allow you to
> use anything but plain password as a way of authentication. So if you
> are among those who are truly concerned about security and prefers to
> use things like security tokens then you have to hack that bootloader
> yourself, hoping that if you get it right your patch won’t be wiped out
> by the next software update. This also means a lot of wasted time.
Truecrypt supports the use of key files as well.
Truecrypt, however, does not support full-disk encryption and booting
Linux - only Windows. From what I’ve read on the Truecrypt forums,
they’re not likely to add it because FDE doesn’t provide actual plausible
deniability.
I’ve been toying with the idea, though, of combining a bootable USB flash
drive with a full disk encryption setup - the idea being you should be
able to boot from a flash drive and (optionally) use a key file on the
flash drive (or a secondary flash drive, sdcard, or the like) for
authentication.
The thing that I haven’t worked out (logically) is updating the kernel.
Since the initrd is not on the system but would need to be on the flash
drive, So a kernel update would likely be more involved to make this work.
But the argument I’d make with the truecrypt folks as well is that FDE
isn’t always about plausible deniability, but it might be about fully
securing a portable device like a laptop. Yes, I can encrypt my home
directory/partition and that helps, but it doesn’t help protect installed
programs, configurations, etc, and that may cause other compromises. For
example, a VPN config stored in /etc/NetworkManager wouldn’t be protected
if the home partition is the only thing encrypted.
I use FDE on an external USB drive not because I need plausible
deniability, but because I have sensitive data that, should the drive
crash, I need to be sure is unrecoverable. I had an enclosure with 2
500GB drives and one crashed hard - and I had no easy way to guarantee
the data was unreadable using forensic tools - and for peace of mind, I
wanted to be sure that they weren’t readable since I had things like old
tax returns backed up there.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
An encrypted LVM would take care of that. I’m not sure if that is possible with truecrypt, but it does work well with LUKS encryption.
For your other issue, using a usb drive as a key, I think kernel updates should work as long as you have the usb mounted as “/boot” during the update.
You could probably have a local “/boot” for when the usb is not mounted. In that case a kernel update should still work, except that you would have to manually synchronize the usb with the local “/boot”. Unfortunately, there’s a fly in the ointment if using grub2. A kernel update presumably runs “mkinitrd”, and with grub2, “mkinitrd” reinstalls grub2. And that could be a problem if the usb is not mounted.
On Thu, 19 Jul 2012 17:36:02 +0000, nrickert wrote:
> hendersj;2475247 Wrote:
>> For example, a VPN config stored in /etc/NetworkManager wouldn’t be
>> protected if the home partition is the only thing encrypted.
>
> An encrypted LVM would take care of that. I’m not sure if that is
> possible with truecrypt, but it does work well with LUKS encryption.
Yeah, that would take care of it - but for a challenge (probably more
than anything), I thought I’d see about designing something that worked
with truecrypt specifically. 
> For your other issue, using a usb drive as a key, I think kernel updates
> should work as long as you have the usb mounted as “/boot” during the
> update.
One of my goals as well is that the flash drive is just used for boot and
then can be disconnected from the system. Obviously it would need to be
present when the kernel was updated, though. My thinking is that if it’s
just where initrd comes from and gets the system to the point where the
encrypted drive is decrypted and then hands off to the system to finish
the boot.
So in that case, thinking about it, a kernel update shouldn’t break
anything. The trick becomes defining the filesystem after truecrypt is
in memory decrypting the encrypted device.
> You could probably have a local “/boot” for when the usb is not mounted.
> In that case a kernel update should still work, except that you would
> have to manually synchronize the usb with the local “/boot”.
> Unfortunately, there’s a fly in the ointment if using grub2. A kernel
> update presumably runs “mkinitrd”, and with grub2, “mkinitrd” reinstalls
> grub2. And that could be a problem if the usb is not mounted.
Yeah, and I do want to be able to remove the flash drive after the system
is running. One reason for that is that if the flash drive with the keys
is plugged in and someone nicks the laptop, then one purpose of
encrypting the drive is defeated. So the flash drive would be unplugged
and carried in a pocket or a bag separate from the laptop itself.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C