Slashdot Mirror
Tomb, a Successor To TrueCrypt For Linux Geeks
jaromil writes: Last day we released Tomb version 2.1 with improvements to stability, documentation and translations. Tomb is just a ZSh script wrapping around cryptsetup, gpg and other tools to facilitate the creation and management of LUKS encrypted volumes with features like key separation, steganography, off-line search, QRcode paper backups etc. In designing Tomb we struggle for minimalism and readability, convinced that the increasing complexity of personal technology is the root of many vulnerabilities the world is witnessing today — and this approach turns out to be very successful, judging from the wide adoption, appreciation and contributions our project has received especially after the demise of TrueCrypt.
As maintainer of the software I wonder what Slashdot readers think about what we are doing, how we are doing it and more in general about the need for simplicity in secure systems, a debate I perceive as transversal to many other GNU/Linux/BSD projects and their evolution. Given the increasing responsibility in maintaining such a software, considering the human-interface side of things is an easy to reach surface of attack, I can certainly use some advice and criticism.
As maintainer of the software I wonder what Slashdot readers think about what we are doing, how we are doing it and more in general about the need for simplicity in secure systems, a debate I perceive as transversal to many other GNU/Linux/BSD projects and their evolution. Given the increasing responsibility in maintaining such a software, considering the human-interface side of things is an easy to reach surface of attack, I can certainly use some advice and criticism.
Need I say more?
to be honest, and I've been recently reading a lot about potential TrueCrypt replacements. Of course I was looking for FDE mostly, not just a few files.
From your website, I see that "make install" only installs two files, the executable and the manpage, but I prefer keeping my $PATH mostly filled with applications I can update with my package manager.
Never head of it. Probably won't ever again!
I prefer Veracrypt, that is as easy as Truecrypt was.
We know the last build of TrueCrypt is secure. Why replace it?
Only the State obtains its revenue by coercion. - Murray Rothbard
One thing that always worries me is a poor or predictable source of entropy...so much so that I don't even trust /dev/random. Does Tomb have any way to detect that a weak or predictable seed has been used? If not, are there plans to add a warning or such other preventative measures?
Also, are you taking steps to prevent an insider threat such as the whole NIST debacle?
The successor for TrueCrypt is VeraCrypt, as it is a direct fork.
Also, a "linux geek" would have already have taken dm-crypt as an alternative, or performed the instructions in some Full Disk Encryption Howto.
Instead of True Crypt, OO programmers use One crypt, and C programmers use Zero Crypt.
As a "linux geek" my drives and files are encrypted using dm-crypt, gpg, etc. However, this script looks like it would be useful for making transferable encrypted archives. How handy.
I do not know what "TrueCrypt" or "VeraCrypt" are. I have never seen them in any repository.
If its Linux only don't present it as a successor to TrueCrypt. A very important feature of TrueCrypt is(was) that it targets Linux, Mac OS X and MS Windows. Any archive being available to any of the three platforms.
The successor to TrueCrypt will most likely be something derived from the audited TrueCrypt source code. You just won't compare favorably given the single supported platform. You are just going to create a reputation of being one of the lessor choices, which may be entirely unfair.
Don't handicap yourself. Promote your software on its own merits, don't try to piggyback on TrueCrypts popularity, such a strategy will likely backfire.
Why would I want to use this over just using dm-crypt on a LUKS container directly? One less layer of things to go wrong that way. One less layer of obfuscation.
The name "Tomb" is self-defeating. The name implies that the software is already dead.
Without reading anything besides your summary, it sounds like you're on the right track. "Minimalism" and "simplicity," judiciously applied, usually leads to a good result. As Albert Einstein said, "Everything should be as simple as possible, but not simpler."
Why be using a new system? True Crypt is being a perfectly good system for encryption. I only use the same.
So far there seems to be a lot of the latter, but not so much of the former.
While I don't use your software, I do appreciate the fact that you're working on it - and I like the philosophical focus on simplicity.
#DeleteChrome
I hate those guys.
They paint geeks/nerds/linux users with a retard, all-day-on-drugs, stereotype, and not all of us are like that.
At this point they can watch every phone call we make, watch where we walk every minute of the day, watch what websites we go to, read our email.
They can no doubt get in back doors on our computers any time.
Why should they care if we encrypt our hard drives? We're on the internet when our computers are on!
TrueCrypt (now VeraCrypt) is still alive and kicking. better than that, it's been security audited. so why go from a multiplatform system known to be secure to a bunch of scripts that only work on linux?
stop trying to fix what isn't broken.
Anons need not reply. Questions end with a question mark.
Tomb isn't a successor to TrueCrypt, for me at least. Not even close.
TrueCrypt's selling point is NOT an encrypted container. We can do that any number of ways, not least just encrypted loopback, but all of them leak the same amount of information.
Truecrypt's selling point was full disk encryption and a bootloader that hook BIOS interrupts to allow live, in-memory, OS-agnostic transparent decryption. That's not something you can do with a shell-script.
Anything not full-disk-encryption is worthless is the machine is stolen - it probably takes minutes to find the key in swap-files and unlock the containers if they've been used recently. The plain-text is probably still lurking around on disk as temporary files etc.
The only reason I used TrueCrypt was that you could full-disk encrypt and nobody could get in without modifying the hardware of the machine and then getting me to enter my passphrase. Not something that a thief was going to be able to do. It means it was Data Protection compliant, that you could afford to lose the entire machine and not worry, and that it didn't matter what you did with the machine underneath, what OS, what partitioning, etc. even fake partitions with false copies of Windows, etc. in them.
Sorry, but your slashvertisement is exactly what it says - a shell script around some basic command line utilities. It's nowhere close to a TrueCrypt replacement unless your use-case is extremely trivial and - actually - not that secure at all.
As it is, I don't think there's currently a product I can use that I can trust complete boot-time control of, except for TrueCrypt and it's directly-compatible replacements. I will look at various projects as they evolve but, for me, the winner will be whoever gets a UEFI bootloader first.
When I was looking at encryption options a few year ago, I ended up skipping LUKS and using dm-crypt directly instead. LUKS uses some large blocks of random data to postprocess the user-provided key and make brute forcing and dictionary attacks very slow, even with initially weak keys.
Downside is, is that if the LUKS header gets corrupted or destroyed, the entire partition is lost. It's more serious than an MBR, which is easy to reconstruct.
I wanted the purity and hardcoreness of my key = actual key, so I ended up just invoking dm-crypt by hand.
I have never tried Guinness Leeks... are QRcodes like IPv4 addresses in that we will run out of usable ones for wasting them on our cat's buttcheeks?
Portable shell scripting does not happen in zsh. Nor in bash, for that matter. It happens in posix shell, sh, tested against at least two different posix shell implementations.
TrueCrypt worked flawlessly on Windows, Mac, and Linux.
Anything which supports only one of the three major platforms is no successor of TrueCrypt.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Does the fact that a software is a small shell script or a big POSIX C codebase makes you trust it more, or less?
I appreciate the considerations about portability of a shell script being critical, yet ZSh interpreters are very portable themselves.
Last day we released Tomb version 2.1
Hyper cool, friend!
systemd is Roko's Basilisk.
All it's good for is empowering terrorists, pedophiles and malcontents. We don't need encryption, honest people does not, and neither we need anonymization tools, guns, or instructions on how to make explosives. You keep blathering about "freedom" but my freedom to be safe is more important to me, and I'm part of the vast majority of sane people who does not see the use for encryption, guns, tor or even general purpose computers that could be used to hack vital infrastructure and cause harm and even death. We invoke the full might of the law to remove those threats to our security. And it will happen, whether you like it or not.
Curious about your manipulation of to the Devuan project passing via a personal attack against me.
BTW are you Kevin McCurley of Digicrime, based in San Jose?
Isn't this game boring? Yet I have to reply because your claims about Devuan are false:
1- we don't demand no-one else should be able to use systemd. We clearly demand our own rights in choosing to not use systemd and have engaged in an honest quest developing a base system that is alternative to Debian and does not depends from the web of dependencies of systemd, including the init and the device manager.
2- our fund-raise is accountable, the financial responsibility is taken up by a non-profit organization registered since more than 10 years, our financial report is public and reasonably detailed http://devuan.org/donate
regards
Its not the first version, is the latest. Here is the ChangeLog https://files.dyne.org/tomb/Ch...
You two are funny. (It's 5 am. If your brain has not yet started working, he means Fornix 8 would sound like "Fornicate".)
An acquaintance of mine works at The Last Pickle. Yes, really. Apache Cassandra support.
You came to the right place.
I use Truecrypt for a small (10MB) file which I can mount on Linux, Mac and Windows. The mounted file is a FAT32 partition, because that is the only filesystem that is read/write on any random machine.
Could Tomb replace this setup? What would the advantage be?
(Of course, I could go read the article, but who does that on /.?)
like a bunch of super long zsh scripts stringing together a bucketload of binaries that are not verified to be of any systemic state (version differences) all while adding unique features like "forgot my private key" QRcode image ( which is likely to be left sitting on a disk in plaintext in a removed temp file). Have at it folks!
The context of the original post was discussing recovering plaintext when a bit of the ciphertext was corrupted - assuming you have the key and no backups.
In this case 'plain' dm-crypt results in typically 128-256 bits of plaintext not being recovered. This guy has done some experiments and says in practice it's similar between corrupted encrypted and unencrypted data.
With LUKS, if the corruption is in the data, then the result should be the same as for dm-crypt.
But with LUKS, if the corruption is in the header, then there is a possibility *all* the data will be lost (again, we are talking of with the key, but no backups). LUKS is actually designed to maximise this possibility.
The logic is that an attacker is more likely to have a corrupted file. With a password based encryption sheme, the best proxy you have to an 'authorised' person is one who knows the password - in fact that's the only proxy you have.
So making it more difficult for people with the password to read the data, without making it more difficult for people without it to read the data, is a misfeature IMO.
An attacker maliciously changing the ciphertext to change the plaintext in a predictable way is another issue, but LUKS and dm-crypt are equally bad in this respect as neither support authenticated encryption modes.
Moderated Usenet