On Mon, 28 Jan 2019 at 10:13, Patrick O'Callaghan <pocallaghan@xxxxxxxxx> wrote:
>
> On Sun, 2019-01-27 at 20:46 -0800, jdow wrote:
> > On 20190127 14:44:52, Patrick O'Callaghan wrote:
> > > On Sun, 2019-01-27 at 19:56 +0100, Wolfgang Pfeiffer wrote:
> > > > > Given that encrypting the disk means (at a minimum) reading the entire
> > > > > contents and rewriting it,
> > > >
> > > > No. I don't think data is written and rewritten. See below.
> > >
> > > If it's not being read and rewritten, it's not being encrypted. It's as
> > > simple as that. A cryptosystem that doesn't read the plaintext? How
> > > does that work?
> > >
> > > poc
> >
> > Give me an image if the disk and after suitable time and effort I have access to
> > the whole thing if only the directory entries are encrypted. So the tool in
> > question gives a false sense of security at best.
> > {^_^}
>
> If that's indeed what it does, I agree.
>
> Another point: several people have mentioned using /dev/urandom. It's
> important to note that this is a *pseudo-random* generator. It starts
> from a random seed, but from that generates a completely deterministic
> pattern. If you have the seed, you have everything. And since the idea
> here is to overwrite the disk, the first part of which contains
> "plaintext" that follows a regular layout (partition table etc.) it
> makes the task of decoding the disk even easier as that's the only part
> you would actually have to analyse at a physical level.
>
/dev/urandom isn't purely pseudorandom, it does use entropy from the
pool, it will become pseudorandom when entropy runs out and become
random again when more entropy arrives. Unless you have a hardware
entropy source I suspect using /dev/random will take a much longer
time to produce enough data even for a single over-write. However it's
worth noting that the over-write process is not simply XOR with the
written bytes (in which case enough plaintext to work out the sequence
would definitely let you recover the rest of the data), it's
attempting to randomise the hysteresis effect on the media, which is
why multiple writes are good, because though they theoretically just
increase the number of possible residual states each time you do it
the residual size of the signal you're over-writing is reduced, and
attempting to get the sequences applied to a known plaintext will
become harder. I wouldn't recommend just doing /dev/zero if the CIA,
or even a moderately funded newspaper might specifically be after your
data, but it would certainly be enough to stop a casual user plugging
it in and getting anything back, a few urandom writes is enough to
stop anyone without serious cryptographic expertise and access to the
equipment necessary to read the platters directly getting anything off
the disc.
--
imalone
http://ibmalone.blogspot.co.uk
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
