On 2023-03-11 12:57:56 -0500 (-0500), Timothy M Butterworth wrote:
[...]
> The reason you can not use Login/Password as the LUKS passphrase
> is because The Passphrase can not be different for different
> users. The passphrase is not simply a password but instead it is
> part of the key material
On Wed, Mar 8, 2023 at 11:33 AM Alexey Kuznetsov
wrote:
>
>
> On Wed, Mar 8, 2023 at 7:11 PM Adrien CLERC wrote:
>
>> Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :
>>
>> Hello!
>>
>> I have an idea about how modern linux should work with encrypted LUKS
>> partitions.
>>
>> Hi,
>>
>> I'm
On Mar 10, Stephan Verbücheln wrote:
> On Fri, 2023-03-10 at 15:12 +0100, Marco d'Itri wrote:
> > In the future the initramfs will (usually) be static as well.
> Can you provide more information on that?
Due to multiple reasons, mostly related to secure boot and boot
attestation, there is
On Fri, 2023-03-10 at 15:12 +0100, Marco d'Itri wrote:
> In the future the initramfs will (usually) be static as well.
Can you provide more information on that?
Thanks and regards
Stephan
signature.asc
Description: This is a digitally signed message part
On Fri, 2023-03-10 at 14:28 +, Jeremy Stanley wrote:
> Okay, so you're wanting to rely on encrypted /boot as an incomplete
> alternative to checking file signatures, because the current
> attestation solutions are also imperfect. Keep in mind that
> checksumming isn't providing protection from
On 2023-03-10 13:48:21 + (+), Stephan Verbücheln wrote:
> Encryption per se does not protect against modification, I am aware of
> that. That is even more true for disk encryption where the encrypted
> data block has to fit into the physical disk block, so there is no room
> for a MAC or
On Mar 10, Stephan Verbücheln wrote:
> Apart from the fact that UEFI Secure Boot is an overly complex monster
> which is basically broken[1] by design, my understanding of it is also
> that it does not protect configs, initramfs etc. in /boot. It only
> protects the kernel image and loaded
Encryption per se does not protect against modification, I am aware of
that. That is even more true for disk encryption where the encrypted
data block has to fit into the physical disk block, so there is no room
for a MAC or signature. However, in combination with a filesystem like
btrfs which
Jeremy Stanley writes:
> Disk encryption is great (when properly implemented) to protect
> sensitive information on your machine from prying eyes if it gets
> stolen, but unless you're putting sensitive data in /boot why go to the
> added trouble of encrypting it?
I think this is the key point:
On 2023-03-09 06:21:10 + (+), Stephan Verbücheln wrote:
> Can you explain or refer to literature why encrypted /boot is
> pointless?
[...]
Doesn't really need literature, just some rational thought.
People often confuse encryption with attestation. Try to explain
what security benefits
Can you explain or refer to literature why encrypted /boot is
pointless?
Regards
PS: Let's for now ignore non-security benefits, e.g. that encrypted
/boot means that you do not have to decide on the size of your /boot
partition.
signature.asc
Description: This is a digitally signed message
That is also the main reason why I do not use automatic login. I need
to enter the password anyway.
Unfortunately, the same is true for smartcard login. An OpenPGP
smartcard would be perfect for both login (including SSH public key
auth) and unlocking the keyring, even better than a password, but
On Mar 08, Alexey Kuznetsov wrote:
> 1) grub can ask for a login/password, then MD5 the text and unlock the LUKS
Forget about this part: encrypted /boot/ is pointless from a security
point of view and this complexity does not belong in the boot loader.
Once you accept this then you will end up
Le 08/03/2023 à 17:11, Adrien CLERC a écrit :
Hello,
Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :
Hello!
I have an idea about how modern linux should work with encrypted LUKS
partitions.
Hi,
I'm using LUKS for a long time on both my personal (desktop) and
professional (laptop)
Hi Alexey,
2023-03-08 16:45 CET, Alexey Kuznetsov:
> Right now on a system encrypted with LUKS, the first prompt you'll see is a
> grub passphrase to unlock the device, after OS boot you see a second prompt
> for login/password. This looks redundant.
>
> How about bypassing the second prompt and
On Wed, Mar 8, 2023 at 7:11 PM Adrien CLERC wrote:
> Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :
>
> Hello!
>
> I have an idea about how modern linux should work with encrypted LUKS
> partitions.
>
> Hi,
>
> I'm using LUKS for a long time on both my personal (desktop) and
> professional
On Wed, Mar 8, 2023 at 7:08 PM Agathe Porte wrote:
> Hi Alexey,
>
> 2023-03-08 16:45 CET, Alexey Kuznetsov:
> > Right now on a system encrypted with LUKS, the first prompt you'll see
> is a
> > grub passphrase to unlock the device, after OS boot you see a second
> prompt
> > for login/password.
Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :
Hello!
I have an idea about how modern linux should work with encrypted LUKS
partitions.
Hi,
I'm using LUKS for a long time on both my personal (desktop) and
professional (laptop) computers. Since they are single user (me), I use
autologin
Hello!
I have an idea about how modern linux should work with encrypted LUKS
partitions.
Right now on a system encrypted with LUKS, the first prompt you'll see is a
grub passphrase to unlock the device, after OS boot you see a second prompt
for login/password. This looks redundant.
How about
19 matches
Mail list logo
