Hey,
Can you use the Opensuse Leap42.1 disk encryption for a windows partition when your dual booting?
If so how?
I am no expert, but IMHO, when you encrypt it with openSUSE, it will become unusable for the Windows system in the multi-boot situation.
When that is what you want (only use it for openSUSE) then I do not understand why it is a “windows partition” (I assume you mean that is a partition with a Windows type of file system). Then I would of course use a Linux file system.
So, you better explain a bit more about what you want. The general advice being: Describe the goal, not the step (http://www.catb.org/~esr/faqs/smart-questions.html#goal).
Ok let’s say you were to install a windows partition then install a Linux (Opensuse Leap 42.1 KDE) partition in that situation you would be dual booting between Windows and Linux.
With that said you decide you encrypt your Linux partition.
Now you decide to encrypt the Windows partition with the Linux encryption, would that run?
Would your windows partition data be encrypted?
I think not.
When the partition containing the Windows OS is encrypted using Linux If that is possible at all), I do indeed not think you can boot the Windows OS any more.
Unlikely. You would need to get drivers into Windows to allow it to access the encryption.
It’s probably better to use linux encryption (LUKS) with linux, and Windows BitLocker with Windows.
I’m doing it the other way. On my main linux desktop, I have an encrypted partition that I share using samba. Windows, on a different box (my laptop), puts its sensitive data on those network shares. So the sensitive data is encrypted with linux, but via a network share.
On 01/18/2016 03:16 AM, hcvv wrote:
>
> user89;2749440 Wrote:
>>
>> I think not.
> When the partition containing the Windows OS is encrypted using Linux If
> that is possible at all), I do indeed not think you can boot the Windows
> OS any more.
I think your best bet is either what nrickers suggested about another
encryption technology for you less-supporting OS, or else run a VM within
your Linux system (which is what I do). KVM runs windows very nicely, and
as quickly as windows can go (admittedly it’s not a fast OS, but it’s
faster in my VM than I ever had it on a physical machine, perhaps thanks
to filesystem caching in Linux). There are limits, of course, such as
full system gaming, but then fewer things require the other technologies
now thanks to better game developers (Steam, et al.).
Another option: get windows to support LUKS. Good luck with that one.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
Depends on what kind of encryption you wish to use.
Should make sense, if you’re running full disk encryption, then your disk is unencrypted before any OS loads, so yes…
If you’re running partition-based or file based encryption, then probably no unless the OS supports that encryption.
TSU
On Mon, 18 Jan 2016 09:46:02 +0000, user89 wrote:
> Now you decide to encrypt the Windows partition with the Linux
> encryption,
> would that run?
No, because Windows doesn’t know anything about the encryption you’d be
using from Linux.
In fact, if you encrypted a bootable Windows partition, you probably
wouldn’t even see the option to boot Windows, because the pre-boot
environment wouldn’t have anything to understand the encrypted format.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
On 01/18/2016 09:36 AM, tsu2 wrote:
>
> Depends on what kind of encryption you wish to use.
>
> Should make sense, if you’re running full disk encryption, then your
> disk is unencrypted before any OS loads, so yes…
> If you’re running partition-based or file based encryption, then
> probably no unless the OS supports that encryption.
To be clear: this type of possibly-working full-disk encryption is
hardware-based encryption. I think generally, though, full-disk
encryption refers to software-based encryption such as encryption in LVM.
Software based encryption such as the LUKS encryption of LVM volumes will,
as mentioned previously, probably not work. The reason is that the boot
loader (grub2) is outside of encryption, and then it basically points to a
partition and says “chainloader +1” or something, basically telling the
system to boot directly whatever is there. That will not work if he
partition is encrypted, or so I believe. The reason it works with Linux
is because Linux’s kernel knows how to mount the filesystem prompting for
the encryption passphrase.
If you’ve tested this, please correct me.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
Full disk encryption isn’t necessarily hardware basked although can be based on (typically TPR, storing the keys in hardware).
You can also install the full disk encryption in the first bytes of the disk, and require it to be accessed when first accessed by the BIOS.
TSU
On 01/18/2016 10:26 AM, tsu2 wrote:
> Full disk encryption isn’t necessarily hardware basked although can be
> based on (typically TPR, storing the keys in hardware).
Right; I just mean that I do not think you can do it without hardware
encryption.
> You can also install the full disk encryption in the first bytes of the
> disk, and require it to be accessed when first accessed by the BIOS.
If you mean something other than LUKS, I’d be interested to see how that
works with inferior OS’s. I’ve never seen an option in the BIOS that
would seem to work with encryption, but I haven’t looked, so feel free to
inform me.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
Again,
The main identifying type/mode of encryption can be identified by <when> you are challenged for credentials.
When you’re challenged only after the system has booted and you’re accessing a file, then either the file or the partition or volume the file resides on is accessed, then you’re not doing “full disk” encryption.
Full Disk encryption means that you’re challenged when the disk is accessed.
I haven’t looked at this for a long time because for quite awhile I’ve personally opined that it’s useful only in very specialized situations… portable machines containing high value secrets primarily. Every other scenario is a major increase in risk related to unintentional or intentional corruption which can render the data unaccessible and protects <only> when the system is shut down (at rest). For many if not most systems, you’d get at least as good protection just by locking the machine in a room or cabinet.
The far better encrypting technology is DRM (Digital Rights Management) which protects individual files wherever they might exist, on live systems as well as shutdown and often even when they are copied. In other words, if this had been implemented by the USA for all their confidential and secret documents, you wouldn’t be seeing Wikileaks and other similar… The USA government is just so foolish sometimes…
Getting back to Full Disk Encryption, it looks like there is some documentation and description by Veracrypt that describes what you’re asking for…
Veracrypt calls FDE “system encryption” and describes in general terms its pre-boot authentication and execution
https://veracrypt.codeplex.com/wikipage?title=System%20Encryption
I see that a Google search for “Full Disk Encryption” displays a reference that states that hardware is a required part, but that’s probably not accurate… The hardware piece provides <better> FDE, but it’s not the only way to implement.
TSU
IDK I tried to encrypt my hard drive in yast - partitioner - edit - encrypt device but it gives me this error:
ERROR Could not set encryption System error code is -3016 The encryption password provided could be incorrect
I have seen something similar when I use randomly encrypted swap. Yast recognizes that it is encrypted, because there is an entry in “/etc/crypttab”. But it does not recognize that it is randomly encrypted. So it asks for the encryption, which I don’t know.
My solution for this was to convert back to unencrypted swap just before an new install into the old partitions. Then it would happily use that as a swap partition, and I could set it to encrypt. However, I do have to tell it to format the partition. If I tell it to encrypt, but not format, it assumes that there is existing encryption.
On 01/18/2016 03:16 AM, hcvv wrote:
>
> user89;2749440 Wrote:
>>
>> I think not.
> When the partition containing the Windows OS is encrypted using Linux If
> that is possible at all), I do indeed not think you can boot the Windows
> OS any more.
I think your best bet is either what nrickers suggested about another
encryption technology for you less-supporting OS, or else run a VM within
your Linux system (which is what I do). KVM runs windows very nicely, and
as quickly as windows can go (admittedly it’s not a fast OS, but it’s
faster in my VM than I ever had it on a physical machine, perhaps thanks
to filesystem caching in Linux). There are limits, of course, such as
full system gaming, but then fewer things require the other technologies
now thanks to better game developers (Steam, et al.).
Another option: get windows to support LUKS. Good luck with that one.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
On Mon, 18 Jan 2016 09:46:02 +0000, user89 wrote:
> Now you decide to encrypt the Windows partition with the Linux
> encryption,
> would that run?
No, because Windows doesn’t know anything about the encryption you’d be
using from Linux.
In fact, if you encrypted a bootable Windows partition, you probably
wouldn’t even see the option to boot Windows, because the pre-boot
environment wouldn’t have anything to understand the encrypted format.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
On 01/18/2016 09:36 AM, tsu2 wrote:
>
> Depends on what kind of encryption you wish to use.
>
> Should make sense, if you’re running full disk encryption, then your
> disk is unencrypted before any OS loads, so yes…
> If you’re running partition-based or file based encryption, then
> probably no unless the OS supports that encryption.
To be clear: this type of possibly-working full-disk encryption is
hardware-based encryption. I think generally, though, full-disk
encryption refers to software-based encryption such as encryption in LVM.
Software based encryption such as the LUKS encryption of LVM volumes will,
as mentioned previously, probably not work. The reason is that the boot
loader (grub2) is outside of encryption, and then it basically points to a
partition and says “chainloader +1” or something, basically telling the
system to boot directly whatever is there. That will not work if he
partition is encrypted, or so I believe. The reason it works with Linux
is because Linux’s kernel knows how to mount the filesystem prompting for
the encryption passphrase.
If you’ve tested this, please correct me.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
On 01/18/2016 10:26 AM, tsu2 wrote:
> Full disk encryption isn’t necessarily hardware basked although can be
> based on (typically TPR, storing the keys in hardware).
Right; I just mean that I do not think you can do it without hardware
encryption.
> You can also install the full disk encryption in the first bytes of the
> disk, and require it to be accessed when first accessed by the BIOS.
If you mean something other than LUKS, I’d be interested to see how that
works with inferior OS’s. I’ve never seen an option in the BIOS that
would seem to work with encryption, but I haven’t looked, so feel free to
inform me.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…