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.
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.
We know the last build of TrueCrypt is secure. Why replace it?
Only the State obtains its revenue by coercion. - Murray Rothbard
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.
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.
Replace the word "republicans" with "ruling class" and you'll be closer to the truth. Why do you think the Demoplicans are any different than the Republicrats?
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
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.
Need I say more?
Can't rule that out about anything. In this case you're talking about the guy (Denis Roio) with dyne:bolic under his belt - and the "non-profit" behind it and his "campaign" to fork Debian. A self-described "researcher in philosophy of technology and software artisan". He's done at least one TED talk (I can't be bothered looking for the link).
The Tomb project is interesting and I've been following it for a while - the main thing that differentiates it from other LUKS-made-simple tools is the addition of steganography capabilities.
Despite his numerous, um, eccentricities and involvement in the rabid and vitriolic campaign against systemd, it's the code that counts. In this case it's just wrappers around dm-crypt, dm-setup and LUKS designed to make LUKS easier for people who find it difficult - and to add a few other features. Like anything else that is meant to be trusted to the same degree it should be independently audited.
Note: there are plenty of reasonable objections to systemd. Those that hold them don't demand no-one else should be able to use systemd, raise money unaccountably so a handful(?) of anonymous self-described "Unix gurus" can "fork Debian" (yeah - and I'm going to build a moon mission in my basement). Or use threats/trolling/FUD.That would be more like an NSA style campaign to divide the Linux community and keep their existing init flaw backdoors in place on hard-to-get-to systems.
Cue the usual sock-puppet forum flooding and disinformation [sigh]
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."
How do you even test your source of entropy reliably? Sure you can do some statistical analysis, but if you don't even trust /dev/random, what do you trust? A chip would be less reliable IMHO than either using the kernel seeding /dev/random (at least you have control over the code) or a HAVEGE type algorithm (prediction at that level requires insane amounts of resources)
Custom electronics and digital signage for your business: www.evcircuits.com
The name "Tomb" is self-defeating. The name implies that the software is already dead.
Agreed. If marketing is important.
Vault is already used by many projects. I'd suggest ForNix - but then I do have a black sense of humour (it's latin for vault, also brothel). AbSis? another latin word with double meanings and a likelihood that it'd become the butt of jokes . CryptoPorticus? Cautus is good, but there's a possibility that if it ever failed he'd never shake the "CaughtUs" meme that would result - besides, it's a business name.
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
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.
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.
How do you even test your source of entropy reliably? Sure you can do some statistical analysis, but if you don't even trust /dev/random, what do you trust? A chip would be less reliable IMHO than either using the kernel seeding /dev/random (at least you have control over the code) or a HAVEGE type algorithm (prediction at that level requires insane amounts of resources)
If you trust /dev/random you're off to the wrong start (and living in the past) - especially as far as credibility goes. Use /dev/urandom. Given that you only need 256 bits of entropy to get computationally secure numbers for a long, long time - the "how do you test entropy reliably" is a straw man.
There are some case where it's better to use /dev/random. This is not one of them.
Fun facts - dm-crypt uses /dev/urandom, VeraCrypt uses /dev/random and /dev/urandom (on Linux and Mac)
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 sound like"
Want the truth? I don't fit into any of the labeled boxes. I'm most comfortable with the libertarian label - but I don't agree with all their shit either.
Why don't you take a good, hard look at the two party system? The two are in collusion to prevent any other party from gaining any power. Look at federal funding. The D's and the R's agreed to split all of the money that the fed has available for elections. They gave a little lip service to the concept of democracy, by saying IF any other party gained x% of the vote, THEN that party could gain funding from the fed. And, all the while, the two parties continue to split all the fed's money on campaigns designed to ensure that no third party ever gets x% of the vote.
And, that is one of the Libertarian party's beefs, as well as one of their goals. They are closing in on x. Each and every election cycle, they gain a point.
Watch carefully now - the D's and the R's are about due to move the goalposts. Instead of x% it's going to be changed to 5x% or more.
And - no, a Libertarian is not a Republican. The two share SOME ideas, beliefs, and opinions - but Libertarians have far more in common with liberalism than they do with conservatism.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
are QRcodes like IPv4 addresses in that we will run out of usable ones for wasting them on our cat's buttcheeks?
No.
QR codes encode arbitary text (in one of several character sets). There is no central registry of what that text means so QR codes in general can't "run out". The ammount of text that can be encoded depends on the size (in "modules") of the QR code, the character set and the desired error correction level.
QR codes used for taking people to websites generally encode URLs. Even a quite long URL can be encoded in a reasonable size QR code though shorter URLs are certainly preferable for more reliable scanning due to stronger error correction and/or larger "modules".
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Because Republicans on the Supreme Court are consistently voting to make the situation worse. Prior to Citizens United, it was possible to at least attempt to address the corruption of the system via the elected legislature (or at least throw the bums out if they won't address it). Now, we apparently have to ammend the Constitution to remove a ridiculous manufactured equivalency between corporate bribery and free speech. It's silly to pretend that that's not the result of a significant difference between Republicans and Democrats. And the reason Republicans did it is that they think political money favors them - nothing more, nothing less. So, there's that difference too.
Posted from my Android phone. Oh, I can change this? There, that's better...
And - your cherished democrats are somehow different? Presumably because they routinely vote on matters in ways which you approve?
And, what about Joe Mainstream? BOTH sides of the court just fuck him over.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
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 /.?)
/dev/urandom will not wait (block) for sufficient entropy and thus is (theoretically) more vulnerable to attacks than using /dev/random. You should ALWAYS use /dev/random if you are worried (paranoid) about the cryptographic strength of your result.
I was talking about seeding your randomness and how to test entropy is definitely a necessity. If you sneak in some vulnerability, most likely you'll want to be able to predict the random numbers generated at certain points in time but still make it look like you have sufficient randomness for people that are not in the know. How do you test against that?
Why does the OP not trust /dev/random? If you're using a hardware device (eg. Intel processors or another dedicated chip), there is a greater chance it was compromised by US/Chinese intelligence than whatever kernel algorithm which you can check the source code for.
The OP stated that /dev/random cannot be trusted, if you don't trust open, tested code which you can compile yourself, what do you trust? If you're building it yourself, you're doing it wrong.
Custom electronics and digital signage for your business: www.evcircuits.com
You'd like proof of entropy in a /. post? What next - pi demonstrated to 10000 places in a Twitter post? Instant education you can sprinkle on your breakfast and some else to feed it to you?
/dev/urandom will not wait (block) for sufficient entropy and thus is (theoretically) more vulnerable to attacks than using /dev/random. You should ALWAYS use /dev/random if you are worried (paranoid) about the cryptographic strength of your result.
Yes /dev/random blocks. It gives out exactly as much randomness as it has entropy in its pool. But that's not always a good thing - which is why cryptography is not intuitive - it's also why cryptographers e.g. Bruce Schneier, choose /dev/urandom as the preferred source of cryptographic randomness on UNIX-like systems.. Rather than selectively picking from what I wrote to support pre-invested emotional belief - try reading it in context. (there are situations when /dev/random is the best choice).
"sufficient" entropy is the stumbling block. How does /dev/random determine what's sufficient entropy? Note: that I've already pointed out that 256 bits is a secure level of entropy, and don't make the mistake of trying to keep a complex subject so simple it becomes stupid.
There is no entropy counting going on there, it's estimation. The amount of entropy some source is giving you isn't something obvious that you just get, along with the data. It has to be estimated. When the estimate is too optimistic, the property of /dev/random you have invested so much in, that it's only giving out as many random numbers as available entropy allows, is gone. It's hard to estimate the amount of entropy. /dev/urandom doesn't have enough available entropy it injects entropy - “low quality random” numbers from a pseudorandom number generator (a cryptographically secure one) that is running alongside the rest of the random number machinery. This CSPRNG (both /dev/random and /dev/urandom use the same CSPRING) is just seeded once (except when it's not) with “true randomness” from the randomness pool. Perfection is the enemy of good. 256 bits is enough..
If
tl;dr You are right, all cryptographers are wrong. As I've already pointed out /dev/urandom is the preferred choice of leading cryptographers.
I was talking about seeding your randomness and how to test entropy is definitely a necessity.
Care to put that in a context? A time frame for your test would be a good start - some of us, like the processes that use entropy, do have time constraints. Be sure and allow for realistic limitations and biases - like the system timing signals.
If you sneak in some vulnerability,
That's a big if. (try kippers - so much more substance than red herrings) There is always a big if - in everything. It's the same uncertainty that paralyses obsessive compulsives.
most likely you'll want to be able to predict the random numbers generated at certain points in time but still make it look like you have sufficient randomness for people that are not in the know. How do you test against that?
It's a major concern only if: you take the first part of the sophism, a theoretical uncertainty and conflate it with a fact; believe it is possible to prove entropy (which it isn't), in a flawed system with a single biasing clock; and then tack on the broken logic of how do you prove the complex to the ignorant (people who are not in the know). You've married a straw man to a red herring and both of them live in a castle in the clouds. It should be no surprise all their off-spring are red-headed step-children.
And, you use the word "conservative" like it's a "bad thing". Apparently, you're one of those divisive liberals, who only sees evil in conservatism, and you want free reign to rebuild the world in some socialistic image.
Sadly - communism doesn't have one single success story to point to. And, we should trust the liberals? They want to take a failed system, and impose it on the United States.
Fuck that - we can fail on our own, and in our own fashion. To hell with modern day American liberalism.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
Why do some people always act as if the only options are conservatism and communism? Neither seem to be working, so we can start thinking about alternatives.
Agreed. How do you propose that we convince the majority of Americans to agree? I've often said that I'm willing to vote for people of all parties. I'm even willing to see a member of the Communist Party in congress, if it breaks the grip of the two parties who share a chokehold on the US. It was ONE OF the things that made Obama look good, when he crawled out of the woodwork - he APPEARED to be more independent than other candidates.
We need some Libertarians in Washington, along with some Green/Conservative party members, a Worker's or Labor party - in short, we need to borrow from Parliamentary governments. I don't believe that there is another nation on earth that would continue to elect Republicans or Democrats when they continue to relentlessly rape the people.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
I don't know how to convince the majority of the Americans of anything, but I think that maybe the discourse needs to be changed. I see anything that doesn't fit the Democratic/Republican mold being labeled as extremism, and I guess that doesn't help adoption.
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