this doesn't facilitate any attacks, until proven otherwise.
please note that during installation, there is no valuable data on disk
anyway, or in other words, all data written can be pre-calculated as the
predictable copy of the squashfs is done.
please demonstrate how you can recover
In debian, by default the encrypted partition, after it is setup, it is
filled with random data such that it's encrypted and stored on disk.
In ubuntu, it is our conscious decision to not do this due to
performance constraints by default, upon installation.
There is a a pre-seedable and manually
If the attacker knows what is useful information, it is much easier for
him to get the information wanted. If the attacker knows what is zero
data, it is much easier to get the information wanted.
A chain gets as weak as the weakest link in the chain.
--
You received this bug notification
The problem with no zeroing is that this wasn't done just for fun, there
*was* a rationale for it initially. To quote Evan Dandrea (who
introduced this 6 years ago):
"The installer is writing over any swap partitions to be used by Ubuntu
with zeros, to prevent leaking of data that could enter
There is code to do this in user-setup too.
** Also affects: user-setup (Ubuntu)
Importance: Undecided
Status: New
** Changed in: user-setup (Ubuntu)
Status: New => Triaged
** Changed in: user-setup (Ubuntu)
Importance: Undecided => Wishlist
** Changed in: user-setup
Encryption is supposed to protect the data you store there *after*
enabling it, not *before*. If you want to do both, then it should be
filled with /dev/urandom.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
How does having it zeroed rather than randomized make it easier for an
attacker to find the encryption key? Let's keep in mind this is "just"
swap, too: if I'm not mistaken the key is different every boot.
Marc Deslauriers already put this Wishlist, and I've asked some input
from the Ubuntu
LUKS keys are not randomly generated during boot; they are fixed at LUKS
creation time. As time passes, more and more of the swap space will be
filled with randomish data, reducing the surface area of this attack,
but at least after a fresh install, if you can assume that all or most
of swap is
** Information type changed from Private Security to Public Security
** Changed in: ubiquity (Ubuntu)
Status: New => Triaged
** Changed in: ubiquity (Ubuntu)
Importance: Undecided => Wishlist
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
The attachment "Example to solve issue" seems to be a patch. If it
isn't, please remove the "patch" flag from the attachment, remove the
"patch" tag, and if you are a member of the ~ubuntu-reviewers,
unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by
** Tags added: xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1506995
Title:
Ubiquity facilitate attack on crypto LUKS
To manage notifications about this bug go to:
11 matches
Mail list logo
