Re: GRUB and boot partition
On 06/01/18 03:56, Gary Dale wrote: > One once-popular code was to replace all words in a message with 2 > numbers each, referring to a page & word number within an agreed-upon > book. If you used it electronically, you could send a binary file where > each original word was reduced to 2 bytes. That would restrict your choice of book quite a bit - or at least, you'd only be able to use a small part of most/many books. I guess you can optimise it by not splitting the numbers at the byte boundary. Richard signature.asc Description: OpenPGP digital signature
Re: GRUB and boot partition
On 2018-01-03 01:59 PM, David Christensen wrote: On 01/03/18 06:45, Gary Dale wrote: On 2018-01-02 02:35 PM, Pascal Hambourg wrote: Encryption does not require extra space (except for header and block padding). Encrypted data have the same size of cleartext data. +1 Encryption is similar in concept to compression. AFAIK common use on Debian systems: 1. Encryption functions [1] are reversible functions that transform data 1:1 in size, and are lossless. 2. Compression functions [2] are reversible functions that strive for size ratios of N:1, where N > 1 (uncompressed:compressed), and can be lossless or lossly. A related topic is hashing functions [3] (N:fixed, can be difficult to reverse). It could even reduce the space requirements. I'm curious -- can you cite a compressing cipher code that cannot be reduced to independent compression and cipher functions? Encryption and compression both work by replacing strings of letters with something else. I agree that encryption and compression are both forms of coding [4]. Encryption and compression both work by replacing strings of letters with something else. What we call clear text, for example, is just a > Caesar cipher where each letter is replaced by a number (its ASCII code or unicode). ASCII [5] is a transliteration code -- replace a token from one alphabet (Roman letters, Arabic numerals, common English symbols, etc.) with a token from another alphabet (7-bit binary number). Spelling, grammar, and meaning are unchanged. The goal of a substitution cipher is to conceal meaning, and can be done without changing alphabets (e.g. rot13 [6]). Spelling and grammar are unchanged (which facilitates cryptanalysis). Morse code, on the other hand, replaces common letters with shorter sequences of dots and dashes than less common letters. I agree that Morse Code [7] uses frequency-based techniques. David References: [1] https://en.wikipedia.org/wiki/Encryption [2] https://en.wikipedia.org/wiki/Data_compression [3] https://en.wikipedia.org/wiki/Hash_function [4] https://en.wikipedia.org/wiki/Code [5] https://en.wikipedia.org/wiki/ASCII [6] https://en.wikipedia.org/wiki/ROT13 [7] https://en.wikipedia.org/wiki/Morse_code While the intent is different, the techniques are quite similar. One once-popular code was to replace all words in a message with 2 numbers each, referring to a page & word number within an agreed-upon book. If you used it electronically, you could send a binary file where each original word was reduced to 2 bytes.
Re: GRUB and boot partition
On 01/03/18 06:45, Gary Dale wrote: On 2018-01-02 02:35 PM, Pascal Hambourg wrote: Encryption does not require extra space (except for header and block padding). Encrypted data have the same size of cleartext data. +1 Encryption is similar in concept to compression. AFAIK common use on Debian systems: 1. Encryption functions [1] are reversible functions that transform data 1:1 in size, and are lossless. 2. Compression functions [2] are reversible functions that strive for size ratios of N:1, where N > 1 (uncompressed:compressed), and can be lossless or lossly. A related topic is hashing functions [3] (N:fixed, can be difficult to reverse). It could even reduce the space requirements. I'm curious -- can you cite a compressing cipher code that cannot be reduced to independent compression and cipher functions? Encryption and compression both work by replacing strings of letters with something else. I agree that encryption and compression are both forms of coding [4]. Encryption and compression both work by replacing strings of letters with something else. What we call clear text, for example, is just a > Caesar cipher where each letter is replaced by a number (its ASCII code or unicode). ASCII [5] is a transliteration code -- replace a token from one alphabet (Roman letters, Arabic numerals, common English symbols, etc.) with a token from another alphabet (7-bit binary number). Spelling, grammar, and meaning are unchanged. The goal of a substitution cipher is to conceal meaning, and can be done without changing alphabets (e.g. rot13 [6]). Spelling and grammar are unchanged (which facilitates cryptanalysis). Morse code, on the other hand, replaces common letters with shorter sequences of dots and dashes than less common letters. I agree that Morse Code [7] uses frequency-based techniques. David References: [1] https://en.wikipedia.org/wiki/Encryption [2] https://en.wikipedia.org/wiki/Data_compression [3] https://en.wikipedia.org/wiki/Hash_function [4] https://en.wikipedia.org/wiki/Code [5] https://en.wikipedia.org/wiki/ASCII [6] https://en.wikipedia.org/wiki/ROT13 [7] https://en.wikipedia.org/wiki/Morse_code
Re: GRUB and boot partition
On 2018-01-02 02:35 PM, Pascal Hambourg wrote: Le 02/01/2018 à 02:29, microsoft gaofei a écrit : So AES is very lightweight ? I thought cryptography takes very much space , but I saw 1MB space is plenty for AES What are you talking about ? Where did you see this ? It does not make sense. Encryption does not require extra space (except for header and block padding). Encrypted data have the same size of cleartext data. Encryption is similar in concept to compression. It could even reduce the space requirements. Encryption and compression both work by replacing strings of letters with something else. What we call clear text, for example, is just a Caesar cipher where each letter is replaced by a number (its ASCII code or unicode). Morse code, on the other hand, replaces common letters with shorter sequences of dots and dashes than less common letters.
Re: GRUB and boot partition
Le 02/01/2018 à 02:29, microsoft gaofei a écrit : So AES is very lightweight ? I thought cryptography takes very much space , but I saw 1MB space is plenty for AES What are you talking about ? Where did you see this ? It does not make sense. Encryption does not require extra space (except for header and block padding). Encrypted data have the same size of cleartext data.
Re: GRUB and boot partition
On 2017-12-29 06:46 AM, Pascal Hambourg wrote: Le 29/12/2017 à 11:02, deloptes a écrit : microsoft gaofei wrote: I'm thinking about a question ,how my hard disk admits so much data ? If /boot partition is encrypted , then how does my hard disk admit GRUB ? sudo fdisk /dev/sda , and press o to create a DOS partition table . This software starts on sector 2048 by default . So how does the 2048 sectors admit GRUB to achieve encrypted /boot ? FWIW, here is what I replied to the OP's private mail : GRUB core image embeds all the required modules to read /boot/grub, including crypto modules when /boot/grub is encrypted. 2048 512-byte sectors is 1 MiB. GRUB BIOS core image does not need so much space. GRUB BIOS was developed at a time when partition alignment was based on "cylinders", so the first partition usually started at sector 63. GRUB BIOS core image was initially designed to fit in that 30 KiB space. It has grown a bit over time and is sometimes slightly bigger than 30 KiB, but 1 MiB is still plenty of space. A copy of GRUB BIOS core image is kept in /boot/grub/i386-pc/core.img, so you can see its size. you don't encrypt boot Why not ? There's a lot of (not so) old information about /boot. I still have one machine with a separate /boot partition because when I first set it up, it was still required when using an mdadm RAID array.
Re: GRUB and boot partition
Le 29/12/2017 à 11:02, deloptes a écrit : microsoft gaofei wrote: I'm thinking about a question ,how my hard disk admits so much data ? If /boot partition is encrypted , then how does my hard disk admit GRUB ? sudo fdisk /dev/sda , and press o to create a DOS partition table . This software starts on sector 2048 by default . So how does the 2048 sectors admit GRUB to achieve encrypted /boot ? FWIW, here is what I replied to the OP's private mail : GRUB core image embeds all the required modules to read /boot/grub, including crypto modules when /boot/grub is encrypted. 2048 512-byte sectors is 1 MiB. GRUB BIOS core image does not need so much space. GRUB BIOS was developed at a time when partition alignment was based on "cylinders", so the first partition usually started at sector 63. GRUB BIOS core image was initially designed to fit in that 30 KiB space. It has grown a bit over time and is sometimes slightly bigger than 30 KiB, but 1 MiB is still plenty of space. A copy of GRUB BIOS core image is kept in /boot/grub/i386-pc/core.img, so you can see its size. you don't encrypt boot Why not ?
Re: GRUB and boot partition
microsoft gaofei wrote: > I'm thinking about a question ,how my hard disk admits so much data ? If > /boot partition is encrypted , then how does my hard disk admit GRUB ? > > sudo fdisk /dev/sda , and press o to create a DOS partition table . This > software starts on sector 2048 by default . So how does the 2048 sectors > admit GRUB to achieve encrypted /boot ? you don't encrypt boot
Re: GRUB and boot partition
I'm thinking about a question ,how my hard disk admits so much data ? If /boot partition is encrypted , then how does my hard disk admit GRUB ? sudo fdisk /dev/sda , and press o to create a DOS partition table . This software starts on sector 2048 by default . So how does the 2048 sectors admit GRUB to achieve encrypted /boot ?
Re: GRUB and boot partition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Dec 26, 2017 at 02:24:24PM +0100, Pascal Hambourg wrote: [...] > I read that some UEFI implementations allow the user to manage > secure boot keys. Carefully choose your hardware. > > Oh, by the way I forgot twice to mention another situation when an > encrypted /boot would provide an advantage : when the machine has a > platform firwmare which supports LUKS encryption, such as CoreBoot, > then the on-disk boot components could be entirely encrypted. Granted. But if I were *that* deep in the thicket, I'd either shell out the 5K for a PowerPC workstation (which doesn't seem to have all that ME stuff... or they don't tell you?) *or* wait for lowRISC or similar. Doing encrypted-to-the-bottom in view of Intel ME or AMD TrustZone has a bit of a futile taste to me. Cheers - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlpCU5gACgkQBcgs9XrR2kbj9wCZAd7YWlsxOiJA5JlA0XBe3/D+ LQcAnjNhBcZ8HjM2Wm9rcpyVDSlM4iz4 =5ed9 -END PGP SIGNATURE-
Re: GRUB and boot partition
On Tue, Dec 26, 2017 at 02:24:24PM +0100, Pascal Hambourg wrote: > Le 26/12/2017 à 13:58, Reco a écrit : > > On Tue, Dec 26, 2017 at 11:59:18AM +0100, to...@tuxteam.de wrote: > > > > > > > > > > Is there any inherent advantage to having /boot encrypted? > > > > > The only things which might help against an evil maid attack [1] are: > > > secure boot (tying your bootable to secure firmware) [3], > > > > Restricted Boot (let's call the thing the way it should be called from > > the start) could've solve this problem *if* it would be possible to > > force it to verify the bootloader (or the kernel) signed with *user* > > key. > > I read that some UEFI implementations allow the user to manage secure boot > keys. Carefully choose your hardware. I'd use term 'elusive' to describe that kind of UEFI implementation. Everything that can be bought here (I'm talking about x86 consumer-grade hardware, of course) respects MSFT signing key only. If you're lucky, your hardware has CSM (aka BIOS emulation mode). > Oh, by the way I forgot twice to mention another situation when an encrypted > /boot would provide an advantage : when the machine has a platform firwmare > which supports LUKS encryption, such as CoreBoot, then the on-disk boot > components could be entirely encrypted. ... and about the only trouble you have then is to locate that ThinkPad x220 (the only relatively modern laptop model that supports CoreBoot without a hassle I know of). Or a Chromebook if they still but SeaBIOS inside those. If you're preferring conventional desktop PC - you're out of luck with CoreBoot. Reco
Re: GRUB and boot partition
Le 26/12/2017 à 13:58, Reco a écrit : On Tue, Dec 26, 2017 at 11:59:18AM +0100, to...@tuxteam.de wrote: Is there any inherent advantage to having /boot encrypted? The only things which might help against an evil maid attack [1] are: secure boot (tying your bootable to secure firmware) [3], Restricted Boot (let's call the thing the way it should be called from the start) could've solve this problem *if* it would be possible to force it to verify the bootloader (or the kernel) signed with *user* key. I read that some UEFI implementations allow the user to manage secure boot keys. Carefully choose your hardware. Oh, by the way I forgot twice to mention another situation when an encrypted /boot would provide an advantage : when the machine has a platform firwmare which supports LUKS encryption, such as CoreBoot, then the on-disk boot components could be entirely encrypted.
Re: GRUB and boot partition
On Tue, Dec 26, 2017 at 11:59:18AM +0100, to...@tuxteam.de wrote: > On Tue, Dec 26, 2017 at 01:47:23PM +0300, Reco wrote: > > Hi. > > > > On Tue, Dec 26, 2017 at 11:36:13AM +0100, to...@tuxteam.de wrote: > > > On Tue, Dec 26, 2017 at 10:42:46AM +0100, Pascal Hambourg wrote: > > > > Le 26/12/2017 à 02:47, microsoft gaofei a écrit : > > > > >https://wiki.archlinux.org/index.php/GRUB#Boot_partition > > > > >ArchWiki has carried an introduction of GRUB , it offers a feature to > > > > >decrypt your partitions and you don't need to separate /boot . Debian > > > > >also uses GRUB as its boot loader ,but Debian still separates /boot > > > > >partition and leave it unencrypted > > > > > > [...] > > > > > > > Note however that in any case, the early part of GRUB cannot be > > > > encrypted [...] > > > > > > Is there any inherent advantage to having /boot encrypted? > > > > Presumably it should help with scenario such as [1]. > > I don't see that: there must be an unencrypted bit at the beginning > to boot and ask for the passphrase. Whether it's Grub's first stage > (plus a bit) or it's a kernel plus initramfs, actually, shouldn't > make a difference. I don't see any difference too, hence I wrote 'presumably'. > The only things which might help against an evil maid attack [1] are: > secure boot (tying your bootable to secure firmware) [3], There's this saying about curing a headache with an axe. Restricted Boot (let's call the thing the way it should be called from the start) could've solve this problem *if* it would be possible to force it to verify the bootloader (or the kernel) signed with *user* key. But, the things being as they are, Restricted Boot is merely a tool to achieve market dominance for a certain corporation. Whenever Restricted Boot is broken or not is hardly relevant here. > or carrying > your boot media (e.g. SD card) with you, be it Grub+crypto, be it > Grub+kernel+initramfs. Again, not much difference. Indeed. > > > But, as [2] shows us, the protection that's offered by encrypted boot is > > incomplete as it relies on the fact that the bootloader (GRUB) was not > > touched. > > Seems we are in violent agreement, then :-) True. > [3] Given the games we've seen Intel play with their Management >Engine lately... I beg your pardon? Both Intel *and* AMD play this game for last eight years since they invented TPM chip. > would you trust them with that secure boot thing? > I know wouldn't. And no, AMD ain't better. It's really strange to answer such question here, at debian-user. It's non-free software. Nobody sane should trust non-free software. Reco
Re: GRUB and boot partition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Dec 26, 2017 at 12:33:36PM +0100, Pascal Hambourg wrote: > Le 26/12/2017 à 12:24, to...@tuxteam.de a écrit : [...] > >In the days you measure (small) external media in gigabytes, this > >argument has lost a lot of push. > > What does storage size have to do with these situations ? The other way around: if you keep the unencrypted bits in a separate (or somehow specially secured) medium, a strict limitation on its size might favour smaller (i.e. half a bootloader only) over fatter (i.e. a whole bootloader plus a kernel plus an initramfs) solutions. > >But yes, on some specialized hardware that might make a difference. > >FWIW, /boot/grub is 9.1M (yikes! didn't I say I don't like how fat > >the boot loader has become? > > You can remove all the unneeded modules for features that you do not use. Yes, yes, I know. Still... I don't like this overcomplex Grub. Scope creep, if you ask me. Dealing with the "lower half" seems more than enough. But there are tastes for everything :-) Cheers - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlpCNiIACgkQBcgs9XrR2kYipQCfRSacDjIkHtzJj4h4wsQaz5VL ju0An3UU+Pfuu5ogh8AdDKomtTKbV2Dt =qoVI -END PGP SIGNATURE-
Re: GRUB and boot partition
Le 26/12/2017 à 12:24, to...@tuxteam.de a écrit : On Tue, Dec 26, 2017 at 12:10:52PM +0100, Pascal Hambourg wrote: Le 26/12/2017 à 11:36, to...@tuxteam.de a écrit : Is there any inherent advantage to having /boot encrypted? I can imagine a few situations. - When you can enforce the early stage of GRUB integrity by storing it on removable or read-only boot media, checking it with trusted computing, TPM... You could extend this to the whole /boot directory contents instead of encrypting it but parts of it such as the kernel image, initramfs and grub.cfg change quite often, while GRUB itself seldom changes. An alternative to /boot encryption is to sign its contents so that GRUB early stage can check the files when loading them. - When you need to store sensitive data in /boot, such as passphrases for other encrypted volumes. In the days you measure (small) external media in gigabytes, this argument has lost a lot of push. What does storage size have to do with these situations ? But yes, on some specialized hardware that might make a difference. FWIW, /boot/grub is 9.1M (yikes! didn't I say I don't like how fat the boot loader has become? You can remove all the unneeded modules for features that you do not use.
Re: GRUB and boot partition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Dec 26, 2017 at 12:26:35PM +0100, Pascal Hambourg wrote: [...] > As explained in my previous reply, the difference is only in > convenience. You need the boot media to be present and writable when > updating when updating the kernel [...] Yes, I see your point. Then, this one cuts both ways... Cheers - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlpCMu8ACgkQBcgs9XrR2kbDtQCfd8QyQBBPDEVRE0ytvuXtv9Mq NJMAn3ZgzhugBAUCtX4C4+ihwO8TsBvX =LO8n -END PGP SIGNATURE-
Re: GRUB and boot partition
Le 26/12/2017 à 11:59, to...@tuxteam.de a écrit : The only things which might help against an evil maid attack [1] are: secure boot (tying your bootable to secure firmware) Only if you replacy the default keys with your own key in the firmware. Any signed GRUB provided by Ubuntu, RedHat or openSUSE is accepted by UEFI secure boot with the default Microsoft key. or carrying your boot media (e.g. SD card) with you, be it Grub+crypto, be it Grub+kernel+initramfs. Again, not much difference. As explained in my previous reply, the difference is only in convenience. You need the boot media to be present and writable when updating when updating the kernel, initramfs and GRUB config file if /boot is stored on it. On the other hand, if /boot is stored (and encrypted) on the main disk, you do not need the boot media to be present and writable.
Re: GRUB and boot partition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Dec 26, 2017 at 12:10:52PM +0100, Pascal Hambourg wrote: > Le 26/12/2017 à 11:36, to...@tuxteam.de a écrit : > > > >On Tue, Dec 26, 2017 at 10:42:46AM +0100, Pascal Hambourg wrote: > >>Note however that in any case, the early part of GRUB cannot be > >>encrypted [...] > > > >Is there any inherent advantage to having /boot encrypted? > > I can imagine a few situations. > > - When you can enforce the early stage of GRUB integrity by storing > it on removable or read-only boot media, checking it with trusted > computing, TPM... > You could extend this to the whole /boot directory contents instead > of encrypting it but parts of it such as the kernel image, initramfs > and grub.cfg change quite often, while GRUB itself seldom changes. > An alternative to /boot encryption is to sign its contents so that > GRUB early stage can check the files when loading them. > > - When you need to store sensitive data in /boot, such as > passphrases for other encrypted volumes. In the days you measure (small) external media in gigabytes, this argument has lost a lot of push. My whole boot at the moment is 37M, the smallest SD card I can come up at home is 256M, and we kicked it out of our point-n-shoot camera because... 4G. But yes, on some specialized hardware that might make a difference. FWIW, /boot/grub is 9.1M (yikes! didn't I say I don't like how fat the boot loader has become? How long until it needs dbus?), which is an upper bound to the size of grub's "non-unencrypted" part (dunno by how much). Small embedded systems tend to have syslinux, though, or whatever else you use on Arm ;-P Cheers - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlpCMYMACgkQBcgs9XrR2kYfNQCeLOeymSZxg4nghp+aEzUfmogJ 7HcAniw/ih+7TlWk5aNP21UQeJemAKoH =Fvh7 -END PGP SIGNATURE-
Re: GRUB and boot partition
Le 26/12/2017 à 11:36, to...@tuxteam.de a écrit : On Tue, Dec 26, 2017 at 10:42:46AM +0100, Pascal Hambourg wrote: Note however that in any case, the early part of GRUB cannot be encrypted [...] Is there any inherent advantage to having /boot encrypted? I can imagine a few situations. - When you can enforce the early stage of GRUB integrity by storing it on removable or read-only boot media, checking it with trusted computing, TPM... You could extend this to the whole /boot directory contents instead of encrypting it but parts of it such as the kernel image, initramfs and grub.cfg change quite often, while GRUB itself seldom changes. An alternative to /boot encryption is to sign its contents so that GRUB early stage can check the files when loading them. - When you need to store sensitive data in /boot, such as passphrases for other encrypted volumes.
Re: GRUB and boot partition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Dec 26, 2017 at 01:47:23PM +0300, Reco wrote: > Hi. > > On Tue, Dec 26, 2017 at 11:36:13AM +0100, to...@tuxteam.de wrote: > > On Tue, Dec 26, 2017 at 10:42:46AM +0100, Pascal Hambourg wrote: > > > Le 26/12/2017 à 02:47, microsoft gaofei a écrit : > > > >https://wiki.archlinux.org/index.php/GRUB#Boot_partition > > > >ArchWiki has carried an introduction of GRUB , it offers a feature to > > > >decrypt your partitions and you don't need to separate /boot . Debian > > > >also uses GRUB as its boot loader ,but Debian still separates /boot > > > >partition and leave it unencrypted > > > > [...] > > > > > Note however that in any case, the early part of GRUB cannot be > > > encrypted [...] > > > > Is there any inherent advantage to having /boot encrypted? > > Presumably it should help with scenario such as [1]. I don't see that: there must be an unencrypted bit at the beginning to boot and ask for the passphrase. Whether it's Grub's first stage (plus a bit) or it's a kernel plus initramfs, actually, shouldn't make a difference. The only things which might help against an evil maid attack [1] are: secure boot (tying your bootable to secure firmware) [3], or carrying your boot media (e.g. SD card) with you, be it Grub+crypto, be it Grub+kernel+initramfs. Again, not much difference. > But, as [2] shows us, the protection that's offered by encrypted boot is > incomplete as it relies on the fact that the bootloader (GRUB) was not > touched. Seems we are in violent agreement, then :-) I'm not really happy about the path the bootloader has taken, having to understand different file systems, having a module system, etc. Cheers [1] http://searchsecurity.techtarget.com/definition/evil-maid-attack [2] https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html [3] Given the games we've seen Intel play with their Management Engine lately... would you trust them with that secure boot thing? I know wouldn't. And no, AMD ain't better. - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlpCK4YACgkQBcgs9XrR2kYWyQCeK01kZYgaeBxKDC9+0WQNpybr Q1QAn3foaKmg4w4SqAqTmRP+ugX1OZsK =0Qk0 -END PGP SIGNATURE-
Re: GRUB and boot partition
Hi. On Tue, Dec 26, 2017 at 11:36:13AM +0100, to...@tuxteam.de wrote: > On Tue, Dec 26, 2017 at 10:42:46AM +0100, Pascal Hambourg wrote: > > Le 26/12/2017 à 02:47, microsoft gaofei a écrit : > > >https://wiki.archlinux.org/index.php/GRUB#Boot_partition > > >ArchWiki has carried an introduction of GRUB , it offers a feature to > > >decrypt your partitions and you don't need to separate /boot . Debian also > > >uses GRUB as its boot loader ,but Debian still separates /boot partition > > >and leave it unencrypted > > [...] > > > Note however that in any case, the early part of GRUB cannot be > > encrypted [...] > > Is there any inherent advantage to having /boot encrypted? Presumably it should help with scenario such as [1]. But, as [2] shows us, the protection that's offered by encrypted boot is incomplete as it relies on the fact that the bootloader (GRUB) was not touched. [1] http://searchsecurity.techtarget.com/definition/evil-maid-attack [2] https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html Reco
Re: GRUB and boot partition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Dec 26, 2017 at 10:42:46AM +0100, Pascal Hambourg wrote: > Le 26/12/2017 à 02:47, microsoft gaofei a écrit : > >https://wiki.archlinux.org/index.php/GRUB#Boot_partition > >ArchWiki has carried an introduction of GRUB , it offers a feature to > >decrypt your partitions and you don't need to separate /boot . Debian also > >uses GRUB as its boot loader ,but Debian still separates /boot partition and > >leave it unencrypted [...] > Note however that in any case, the early part of GRUB cannot be > encrypted [...] Is there any inherent advantage to having /boot encrypted? Cheers - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlpCJh0ACgkQBcgs9XrR2kaKHgCfd4gQR/kFEAuYIb+EHKgj/gzw Lt4An2c+umNQMn8yDQ8GddyzO6WquVDM =dHDa -END PGP SIGNATURE-
Re: GRUB and boot partition
Le 26/12/2017 à 02:47, microsoft gaofei a écrit : https://wiki.archlinux.org/index.php/GRUB#Boot_partition ArchWiki has carried an introduction of GRUB , it offers a feature to decrypt your partitions and you don't need to separate /boot . Debian also uses GRUB as its boot loader ,but Debian still separates /boot partition and leave it unencrypted Indeed the Debian installer does not allow an encrypted /boot partition. IMO it should be treated as a (strong) warning, not as a blocking error. You can still manage to have /boot encrypted on Debian with extra manual steps. The Debian 8 installer had a flaw that could be exploited : it did not detect when /boot was an LVM logical volume in an encrypted PV. But this trick does not seem to work any more with the Debian 9 installer. Note however that in any case, the early part of GRUB cannot be encrypted. It is that part which asks for the passphrase. If you use encryption only for confidentiality (in case of loss or theft of the computer), it probably does not matter that /boot is not encrypted, because it usually does not contain any sensitive data. But if you use encryption for tamper-proof, then encrypting /boot is not enough, because someone with physical access to the computer could tamper with the unencrypted part of GRUB and modify it to install a keylogger, rootkit...
