[Discuss] TrueCrypt with SSD

[omegahalo at gmail.com (Chris O'Connell)]

Agreed.  I look at drive encryption as a Best Effort protection technology.
 If the laptop is stolen while powered up the preboot password protection is
nullified.

I try to keep in mind the type of person who is probably going to steal a
laptop our laptop (or any laptop in general) and the type of information
they would find.  In reality, whatever they get off from our laptops
probably wouldn't be worth very much.

Thus, I think in the most cases just making it difficult to retrieve the
data with encryption is enough to cause a casual thief to format the drive.

On Mon, Aug 15, 2011 at 11:35 AM, Jerry Feldman <gaf at blu.org> wrote:

> Unfortunately I don't have anything to contribute here. Basically all
> disk I/O systems, encrypted or not write fixed length sectors. Since
> most Linux I/O is buffered, there is not much of a performance hit. But,
> the nature of SSD as discussed. There is certainly an individual file
> encryption, but these don't encrypt swap. Additionally, if the user
> loses the laptop without powering it off, a lot of stuff can be
> recovered from RAM. essentially it all comes down to the behavior of the
> user of the laptop. Even if you have full disk encryption, the behavior
> of your boss could effectively make encryption useless. TrueCrypt also
> does have some optimizations for SSD drives. I think that a lot of stuff
> like TrueCrypt provides a very false sense of security. Personally, I
> would opt for a self destruct where the laptop explodes if stolen :-)
>
> On 08/15/2011 09:07 AM, Chris O'Connell wrote:
> > Does anyone know of any other methods to securing the data on a solid
> state
> > drive?  Any BIOS level or TPM integrated security?
> >
> > On Mon, Aug 15, 2011 at 8:45 AM, Chuck Anderson <cra at wpi.edu> wrote:
> >
> >> On Mon, Aug 15, 2011 at 07:45:26AM -0400, Edward Ned Harvey wrote:
> >>> Incidentally, what *is* the problem with TrueCrypt anyway?  It seems to
> >> me,
> >>> a hard drive looks like a hard drive whether it's a HDD or SSD.  I
> would
> >>> expect it to be fine.  Do they have any details anywhere, what is the
> >>> problem?
> >> Sure, an SSD looks the same as an HDD to the application running on
> >> it.  But unlike HDDs, SSDs perform (in some cases much) worse and wear
> >> out faster when they are full vs. when they still have empty unused
> >> space.  So the ATA TRIM (and SCSI Discard) command was invented as a
> >> way for the application (i.e. filesystem, RAID subsystem, LVM,
> >> encryption subsystem, etc.) to tell the SSD which sectors are free/no
> >> longer in use.  In a normal, unencrypted scenario, a disk starts out
> >> mostly empty--the sectors start out zeroed and are only written to
> >> when they are actually needed.  In contrast, encrypted disks are
> >> always completely "full" or "untrimmed", because from the time they
> >> are initially formatted and encrypted every sector is written to with
> >> non-zero data because the empty encrypted sectors (i.e. the unused,
> >> zeroed blocks of a filesystem living on top of the encrypted mapping)
> >> appear random once they are encrypted onto the underlying physical
> >> device.
> >>
> >> TrueCrypt and many other full disk encryption packages cannot tell the
> >> drive which sectors are actually free (and hence maintain them as
> >> zeroed sectors on the SSD) because they don't support TRIM.  Many of
> >> the packages don't want to support TRIM because it would leak
> >> information about the encrypted disk to a potential attacker.  That's
> >> pretty much it in a nutshell.
> >> _______________________________________________
> >> Discuss mailing list
> >> Discuss at blu.org
> >> http://lists.blu.org/mailman/listinfo/discuss
> >>
> > _______________________________________________
> > Discuss mailing list
> > Discuss at blu.org
> > http://lists.blu.org/mailman/listinfo/discuss
> >
>
>
> --
> Jerry Feldman <gaf at blu.org>
> Boston Linux and Unix
> PGP key id: 537C5846
> PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846
>
>
>
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>
>