Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] TrueCrypt EOL, what's next?



Rich Braun wrote:
> Today's news that TrueCrypt is effectively end-of-lifed...

That's an odd situation. Read more about it here:
http://arstechnica.com/security/2014/05/truecrypt-is-not-secure-official-sourceforge-page-abruptly-warns/

The developers updated the web site and binaries to show a warning
saying that the tool could be insecure because it was no longer being
maintained. Several articles characterized this as if the developers
were saying thee were known vulnerabilities in the project.

Lots of confusion over whether the announcement was fake as a result of
a hacked site or legit. Apparently the core TrueCrypt developers were
not known publicly. (I wasn't aware of that.) That makes it hard to
verify these sorts of things. Though all indications so far is that it
is legit.

The reason for ceasing development cited by the developers was that
Windows XP was end-if-life, and newer versions of Windows have a bundled
encryption tool. That's clearly not the full story. (Did they opt to
shut down because some government agency pressured them to put in a back
door?)

Don't these guys know that the proper way to stop development on an open
source project is to just stop updating it and abandon it? :-)
But seriously, the warning on the site/code was good practice, however,
they should have announced the discontinuation in advance, and offered
to transition the project to a new team, if they no longer wanted to
continue development.


> I was thinking if I could get TrueCrypt to come up automatically at
> boot, somehow getting its keys from an internal URL on my home LAN,
> I could make the systems pretty secure against physical compromise (burglary, etc).
> 
> Cryptsetup is a probably-ok second choice...but it'd require even more
> tooling to automate at system restart.

So your threat model is only protecting your systems against data access
after they have been removed from your premises. You're not concerned
with someone attempting to gain access while on-site. That seems fairly
reasonable.

And you have enough systems that manual pass phrase entry would be
inconvenient, or you require that the system can be rebooted without
someone physically present?

I didn't know TrueCrypt had a mechanism for pulling keys from a web server.

I gather with cryptsetup you'd have to cobble together something that
feeds the pass phrase to the booting machine over a console port or
something. Or maybe a 2-phase boot, where you net-boot a minimal system,
mount your local disk, run a command like they described in section 2.9
of the FAQ[1] to read the key[2] from a file (which you'll have on a
network mount or retrieve with curl) and mount the encrypted root
partition, then continue the boot. I'd be surprised if someone hasn't
already done this automation.

1.
https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#2._Setup
2. cryptsetup seems to use the term "key" to refer to the pass phrase.
It sounds like the pass phrase is used to decrypt the "master key" which
is the real key used to encrypted your volume.


> is there any such thing as a good open-source tool for...the other use case of
> emailing sensitive financial or other data that one would typically put into a
> zipfile/tarball?

(This question seems only distantly related to your main topic.)

First choice: S/MIME. Second choice: GPG.

The limiting factor with encrypted email is always going to be your
recipient, their technical skills, and what email software they are
required to use.

 -Tom

-- 
Tom Metro
The Perl Shop, Newton, MA, USA
"Predictable On-demand Perl Consulting."
http://www.theperlshop.com/



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org