Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Encryption Software

Tomb, a Successor To TrueCrypt For Linux Geeks 114

Posted by timothy from the tomb-is-a-nice-friendly-word dept.
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.
This discussion has been archived. No new comments can be posted.

Tomb, a Successor To TrueCrypt For Linux Geeks More

Tomb, a Successor To TrueCrypt For Linux Geeks

Comments Filter:

  • Never heard of it (Score:4, Interesting)

    by waspleg ( 316038 ) on Friday July 24, 2015 @10:01PM (#50179205) Journal

    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.

    • Literally the first few words say they released it yesterday.

    • We know the last build of TrueCrypt is secure. Why replace it?

      • We know that the developers were pretty sure that the last version of TrueCrypt was still secure. You cannot ever know for certain that a software is really secure. You may convince yourself that it is, or that it isn't, but you never know what the other side has done, or is doing.

        The ONLY thing you really know for certain about TrueCrypt, is that the developers felt that their product was being compromised, so they let the world know of their suspicions.

      • We know the last build of TrueCrypt is secure. Why replace it?

        This article is the first I'd heard of the demise of TrueCrypt. Then article goes on to talk of simplicity.

        Not using Linux (games) simplicity to me is to continue using TrueCrypt, even Linux users will need to convert.

        I wish them luck in this endeavor though.

      • 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 /.?)

    • Re: (Score:3)

      by mlts ( 1038732 )

      The stego capabilities of Tomb are interesting. The print to QR code for backups for keys is also much appreciated.

      For me, what is important in a TrueCrypt replacement is cross-platform compatibility. I could create a TC volume on a NAS with a Windows box, mount and toss some files into it with my Linux machine, then mount it on a Mac (obviously, not having multiple machines mounting it at the same time) for more items. VeraCrypt has kept this, and has added the ability to use TC volumes under W8.1, a lo

  • 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.

  • VeraCrypt (Score:5, Informative)

    by Sigma 7 ( 266129 ) on Friday July 24, 2015 @10:29PM (#50179301)

    The successor for TrueCrypt is VeraCrypt [wikipedia.org], 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.

    • 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.

    • Also, a "linux geek" would have already have taken dm-crypt as an alternative, or performed the instructions in some Full Disk Encryption Howto.

      Isn't it built into the installer nowadays? I installed Debian recently and it offered to encrypt my system, but maybe it skipped the partition that holds /bin and whatnot...

      • Re: (Score:3, Informative)

        by Anonymous Coward

        You can encrypt everything but bootloader + kernel + initramfs using a typical good distro installer (including Debian's latest).

        You can encrypt even that, if you use a bootloader capable of decription, but the bootloader will remain unencrypted.

        You can encrypt everything if you use a storage device capable of DRM+crypto, TCG style. But you cannot trust that kind of crap to even operate correctly, let alone implement the crypto (and everything else!) correctly and safely.

        So, usually, one tries to use secur

    • Re:VeraCrypt (Score:5, Informative)

      by mlts ( 1038732 ) on Saturday July 25, 2015 @12:01AM (#50179539)

      There were two forks coming from TC. CipherShed was another, but it hasn't been updated since pre-alpha, so it is probably good to pronounce it dead, so VeraCrypt is arguably the successor for TrueCrypt as of now.

      If I were only worrying about Linux, I'd either use LUKS or perhaps a filesystem based encryption process like EncFS. EncFS doesn't provide as much protection (it does let an attacker know file sizes in a directory), but it is definitely a lot more flexible, and the encrypted files can be backed up and restored with ease.

  • Don't try to piggyback on TrueCrypts popularity (Score:5, Insightful)

    by perpenso ( 1613749 ) on Friday July 24, 2015 @10:40PM (#50179319)
    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.

    • 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.

      I don't know about Mac support, but if Tomb is just a wrapper around LUKS, the volumes it creates should be accessible on Windows as long as you use a filesystem Windows knows about. Ext2IFS doesn't work on anything newer than Windows Vista, so you're most likely looking at FAT32, exFAT, or NTFS if you want your LUKS volume to be portable.

      Assuming a suitable LUKS volume, you can mount it on Windows with LibreCrypt [github.com], which is the successor to FreeOTFE (by way of DoxBox). My work machine still has FreeOTFE on it, but I just installed LibreCrypt on Windows 10 at home and the encrypted volume on my flashstick mounted right up.

    • 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.

      Fer sure. They are just showing those that don't know that there is a widely used and proven encryption program already out, by bringing it up.

      Being a Linux only program and specific versions at that do limit it's usage and spread significantly, to the point of slow obscurity.

  • why? (Score:1)

    by Anonymous Coward

    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.

  • Minimalism and Simplicity = Good! (Score:3)

    by Art3x ( 973401 ) on Friday July 24, 2015 @11:28PM (#50179443)

    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."

  • 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.

  • 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.

  • Nope. (Score:5, Insightful)

    by ledow ( 319597 ) on Saturday July 25, 2015 @12:11AM (#50179573) Homepage

    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.

    • Re: (Score:2)

      by jaromil ( 104349 ) *
      Prominently stated in Tomb's documentation is the goal of separating the physical locations where keys and volumes are stored.
      This is explicitly to address cases of stolen laptop, phone, etc.
      The fact that is easy to use gpg encrypted keys from a remote ssh shell, a phone over NFC or bluetooth or a usb stick is addressing human-behavior as a vulnerability much more than actual encryption technology, which we assume to be fairly advanced and reliable today at least in case of dm-crypt.

    • Re: (Score:2)

      by caseih ( 160668 )

      Not only that but TrueCrypt was designed to do secret volumes within volumes, so if someone coerces your password from you they only get the outer, more innocuous volume. The inner volume containing the real private data is still locked and you can't even prove it's there.

  • 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,

    • Downside is, is that if the LUKS header gets corrupted or destroyed, the entire partition is lost.

      To be fair - that's the downside of encryption (without regular backups). A single bit of difference means no information recovery.

      Using LUKS is unlikely to measurably decrease your chances of being unable to recover information. ie. if the encrypted medium is modified you'll only ever be able to recover data. Data, that doesn't translate into useful information.

      • No, this isn't true. Depending on the encryption mode, a corrupted bit should mean one or two blocks being lost (typically 256 bits). LUKS OTOH has a feature called "anti-forensic stripes" that is deliberately designed to *maximise* the data loss if bits are corrupted on disc. One of the worst/best examples of a mis-feature ever.

        • No, this isn't true. Depending on the encryption mode, a corrupted bit should mean one or two blocks being lost (typically 256 bits).

          Could you expand on that? Do you mean - "it isn't true that if encrypted data is modified it can still be unencrypted and the information recovered"? It does sound like a self-defeating encryption scheme (see further down as to why your user case may significantly differ). If the point of encryption is to "prevent modification or access to information at any point in time" rather than "to prevent the reading of the drive at one, known, point in time".

          Recovering data from a dm-encrypted disk which has damage

          • 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 [tablix.org] 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

            • 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.

              Um, no - you responded to my post. I responded to a post by bdubSOv1iKIJ403M. No mention of plaintext there.

              In this case 'plain' dm-crypt results in typically 128-256 bits of plaintext not being recovered. This guy [tablix.org] has done some experiments and says in practice it's similar between corrupted encrypted and unencrypted data.

              Interesting reference. Thanks. I don't have immediate comments on it other than: nothing looks dodgy about his tests; SS writes and erases are quite different from HDD (I don't understand them). I've bookmarked as something to ask some one of the ASD SME's about.

              I use LUKS (and dm-crypt) for personal and work computers, with critical information also encrypted - because I don't know of a better option

              • 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.

                Um, no - you responded to my post. I responded to a post by bdubSOv1iKIJ403M. No mention of plaintext there.

                It's hard to see how else to interpret your post:

                To be fair - that's the downside of encryption (without regular backups). A single bit of difference means no information recovery.

                Or did you mean a single bit of ciphertext changed would somehow corrupt the rest of the ciphertext?
                I've no wish to get involved in a discussion on other aspects of encryption, just wanted to simply correct a false statement, and get something off my chest about the design of LUKS.

  • successor? (Score:3)

    by Lord Ender ( 156273 ) on Saturday July 25, 2015 @03:13AM (#50179957) Homepage

    TrueCrypt worked flawlessly on Windows, Mac, and Linux.

    Anything which supports only one of the three major platforms is no successor of TrueCrypt.

  • 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!

  • Ban it (Score:1)

    by Anonymous Coward

    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.

Slashdot Top Deals

Any circuit design must contain at least one part which is obsolete, two parts which are unobtainable, and three parts which are still under development.

Close