Dm-crypt/LUKS (Ubuntu and Debian default) vs. VeraCrypt: Which is better?

Calling all disk encryption autists.

I've been using Windows + VeraCrypt for the last two years, but I'm currently migrating to Ubuntu (specifically Xubuntu). I want to use full disk encryption in Ubuntu so my two options are dm-crypt/LUKS or VeraCrypt.

Which one is stronger? Additionally, what are the default settings for the full disk encryption in Ubuntu? I attempted to google this but I failed to find the default settings. I know that VeraCrypt can do cascading algorithms but dm-crypt/LUKS can't. It may be possible to configure dm-crypt/LUKS to be as secure as VeraCrypt, but the installation is transparent and doesn't mention the default settings, much less allow you to change them.

With VeraCrypt I'm using cascading algorithms AES(Twofish(Serpent)), XTS, HMAC-SHA-256. Can dm-crypt/LUKS be configured to use the same?

Please help.

Other urls found in this thread:

grc.com/misc/truecrypt/truecrypt.htm
grc.com/sn/sn-582.htm
defuse.ca/truecrypt-plausible-deniability-useless-by-game-theory.htm
ostif.org/the-veracrypt-audit-results/
twitter.com/SFWRedditVideos

Use "Create LUKS containers and encrypt" during install w/Ubuntu don't use Verashit.

Don't select "Encrypt my home folder" it's useless you want FDE via install. Let Ubuntu choose the defaults because you aren't a crypto engineer and haven't run any specific tests or broken any implementations to know why you shouldn't just use the default.

The whole 'cascading' algorithms is security theater, it doesn't offer any benefit.

technically vera is better but do you really need ultra secure encryption?

But what is the default in Ubuntu 16.04 LTS? I can't trust it if I don't even know what it is and it's done transparently during install. At least with VeraCrypt I know what the setup is because I configured it myself.

Cascading algorithms might be security theater, but it gives me better peace of mind.

Gotta protect myself from CIAniggers.About to dump some damaging info on Shillary to WikiLeaks.

Further, realize that the whole point of FDE is solely to defend against theft. If there's something on there (secret insider trading documents you don't want the police to find) then you would want to in addition of using default install dm-crypt/LUKS, encrypt those individual files with either gnupg or grab portable LibreSSL and use ChaCha20 to encrypt them, but gnupg is better since you'll understand it.

Full disc encryption has a serious problem which is known as fail-open, if anything happens you just hand all your info to somebody in plaintext like Ross Ulbricht. You should also use individual file encryption

You can always manually use dmcrypt there's an archwiki telling you exactly how to do this.

The problem is you do not understand the options, you absolutely should just use the defaults that dm-crypt authors (or Ubuntu) has chosen. Twiddling with knobs will lead to doom all you need to worry about is a sufficiently decent enough password to avoid billions of guesses per second and manual file encryption to protect your sensitive wikileaks cianigger stuff

if you plan a war against CIA then even the most secure encryption won't help
they'll get to your ass somehow

Also for the record I've done Tanja Lange courses in Crypto, the old matasano crypto challenges, and I work as a consultant and even I wouldn't bother changing the default values of dm-crypt because there's a thousand things I don't understand about them like how slow will they make accessing my drive, how does the custom hash I've chosen respond to GPU farms hashing passwords because I've probably just weakened the FDE by changing the default which was specifically chosen to slow down guess attacks.

You also want to disable your firewire ports too if they exist and plug w/ epoxy so they can't grab your memory and just extract the password (though there's a dozen other methods they can use). But you shouldn't ever rely on FDE in the first place.

To be fair, I doubt the Ubuntu people are encryption experts and chose sane default settings for new installs to begin with.

Their encryption has been audited though, many times over. DJ Bernstein has pages on this, also where he warns against not trusting the 'encrypt my /home' option and going with full disc encryption (with default options). You can after install get any details of the Luks containers you want from the command line, you'll see it's dm-crypt default options they aren't adding/taking away anything like Android with it's bullshit kernel mod instead of using dmcrypt so they could avoid GPL license.

The key takeaway is never just trust FDE. files you want to remain private should be encrypted as well. You can also make another mini container if you wanted with LUKS after booting into your system with FDE, and manually mount it to have an inner container you can fill with whatever but that's a bad idea too it would be better to just use gnupg and make sure the filenames aren't "SEEKRITS.TXT.GPG"

This is the ultimate paranoid install

>Default OS encryption (Win/LUKS/whatever)
>Create VM
>Install SubgraphOS
>Subgraph will encrypt again
>Follow instructions to apt-get update SubgraphOS
>Use GPG, inside your Subgraph FDE (inside your main computer FDE) to again encrypt individual files. The use of a Yubikey for this is perfect because malware can't get it.
>Use Subgraph CoyIM for chat (OTR encryption) over Tor
>Use Signal for everything else
>Never back up XTS encrypted disk images to docker/cloud (dunno why you would do this, but lot's of sysadmins do)

>not TEMPEST class computer
just fucking write down all your passwords on a sticky note and slap it on the fridge, save gov the effort

I don't really understand disk encryption.

If you really have something to hide, what the fuck are you going to do when someone comes and says "I'll shoot you if you don't give me the key"?

>what is hidden volume

And what if everybody without a gun comes and says give me the key?

most of the time it is practice for a work environment

>Give them a 200 character key
>Does not work
>Tell them that they must have typed it in wrong
>Repeat

It's for the cases where your data gets leaked remotely, and there's no way to leverage you with torture or anything.
Besides, legally, threatening to kill someone to get their key is a crime several dozen tiers worse on the criminal scale than data theft. We're talking max security 30 years vs min security 1 year.

People don't risk an extra 29 years in a max security prison without damn good reason.

> Not still using truecrypt

The files would be safer on your desktop.

no one here using rubberhosefs

VeraCrypt implies Windows, so I think the answer is obvious.

>Using verashit instead of Truecrypt
>inb4 verashits audit

Why not back up XTS images?

Details?

Use hidden volume, not gonna explain how that works, google it

>used to have full disk triple cascade encryption with a 64 character password
>stopped using it because got tired of typing in said password

what's wrong with veracrypt?

I post this at least once a week

grc.com/misc/truecrypt/truecrypt.htm

>ctrl+f
>veracrypt
>0 results
try again

veracrypt has been audited and steve has said it should be fine to migrate over to veracrypt now

>literally no problem with truecrypt
Switch to vera guys, it's way better!!! Thanks NSA :DD

you should say that you're a retard in the first place and save me keystrokes

VeraCrypt can't do system-wide encryption on Linux as far as I know, and LUKS leaves the /boot partition unencrypted, plus VeraCrypt allows hidden volumes, i'd go for Vera when possible.

i got a big leek for you mr. cia

Steve: Yeah, I agree. Now, again, it was never our sense that there was a critical gotcha in TrueCrypt. But we did say, oh, was it about a year ago, I think it was when the Project Zero findings came out, it's like, okay. Because it was a problem in the kernel driver. There was an elevation of privilege that any process in the system could leverage because there is no way to restrict driver access to a specific process. So it just, it was like, okay. And we said on the podcast, eh, it's probably time to migrate. Certainly if you're setting up a new system, use VeraCrypt. Don't stay with TrueCrypt. It's a superset. And of course moving forward it's becoming more important to be able to have support for UEFI for modern hardware platforms. And VeraCrypt continues to do that, and TrueCrypt just won't do it at all anymore.

Literally the same fucking site
grc.com/sn/sn-582.htm

I shouldn't have used code tags

>Steve: Yeah, I agree. Now, again, it was never our sense that there was a critical gotcha in TrueCrypt. But we did say, oh, was it about a year ago, I think it was when the Project Zero findings came out, it's like, okay. Because it was a problem in the kernel driver. There was an elevation of privilege that any process in the system could leverage because there is no way to restrict driver access to a specific process. So it just, it was like, okay. And we said on the podcast, eh, it's probably time to migrate. Certainly if you're setting up a new system, use VeraCrypt. Don't stay with TrueCrypt. It's a superset. And of course moving forward it's becoming more important to be able to have support for UEFI for modern hardware platforms. And VeraCrypt continues to do that, and TrueCrypt just won't do it at all anymore.

How is adding another container within an encrypted drive bad?

If your on ubuntu use the files app to easily create encrypted drives.

If you want FDE you probably need to reinstall ubuntu and select the option during installation.

>B-b-but muh hidden volume

This only works on Windows and also it's useless because they know it exists, and they know you're hiding it.

>investigated person is a criminal and pedophile with tons of evidence on him besides his harddrive contents
>"I-i swear guys I only have pictures of wojaks and pepes on my hdd, the child porn and lists of CVV2 info doesn't exist!"

1. Remove your DD
2. Launch a custom live USB Xubuntu iso with all the packages you want.
3. Encrypt a microSD dm-crypt plain mode with your files.
That's the most secure option out there.

I started using arch what should i do for encryption

Should I just install veracrypt? it got audited now so i think it'd be easier to use than dm crypt/luks

>i wiped out my HDD and all the evidence/i don't save pics because i was expecting this raid
prove me lying
also:
>keeping pepes on hidden volume
if you're this retarded, your ass deserves to be raped in jail

defuse.ca/truecrypt-plausible-deniability-useless-by-game-theory.htm

>using extreme cases to prove your point right
if shit goes this far, then fuck them. they can torture me to death but i won't give them what they want. i'll probably bite my tongue off and kill myself anyway
but if, in 99% of cases, it's a simple police investigation, i'm safe to lie my way out of it

how about you just don't commit any crimes you fucking nigger

because i don't cater to your retarded rules of the world, govdrone

>le anarchy is so kewl

>asking for a permission to fart

This is a nonsense approach, you cannot protect yourself from the eyes of three letter agencies. However you want to protect corporate secrets, you have work on your laptop that has some value, or something along these lines I'd recommend using LUKS as full disc encryption + veracrypt for encrypted containers. No line of defence is enough by itself, however by making more and more walls, more attackers will stop bothering.

Obv change your habits completely - no password stored in your browser, HTTPS everywhere, end to end encrypted emails, chat, common sense 2k17 edition etc etc.

does full disk encryption kill my ssd?

What the fuck?

Nonsense.
a) Not all users of truecrypt live under those circumstances
b) Not even all oppressive governments would blatantly use torture. Sure, if you live in Syria you are fucked up, but at that point you are fucked up and you might not have even done anything.

>porn storage
>23 characters

>corporate secrets
>7 characters

help pls

Why would it? Posting from my 128 GB SSD encrypted with LUKS

If you have plans of overthrowing the government they will definitely use torture

Read about Ruby Ridge

well, it doesn't help its lifespan. but i wouldn't worry about it too much

if i have plan of overthrowing the government, i won't be a total moron and keep any evidence on my PC. i won't even give them a reason to suspect me because of my internet browsing history

I live in a state that used to be a satellite of USSR. You can imagine it as a classic totalitarian state. We had dissent that tried to make people go to streets and oppose. And still physical torture was very rarely used (mostly in the 50s and 60s not later on) against dissent. So it really depends ...

There has been lots of cases in the US of FBI informants for example making a radio show talking about how they don't like the government, being racist etc and trying to encourage people to commit acts of violence or other hatecrimes and then ratting them out.

Or a Nazi skinhead group that emerged that kept beating up other Nazi skinheads but in actuality it was FBI informants stifling opposition.

I wouldn't dare to say it's impossible, but not every government is fucked up in this way, there are states in which being in dissent will make your life hell, but won't necessarily lead to your destruction and torture - thus in these cases using encryption in general for your plans is a valid form of opposition.

>'murican example
not everyone lives in a shithole

I think it depends on if you actually become a threat to the system.

If you're just some random NEET saying "le government suxx" it's different from an actual group forming that's willing to use violence

>The whole 'cascading' algorithms is security theater, it doesn't offer any benefit.


>one algo is cracked
>no worries, I have X more down the line to crack

Yeah, no.

Thats retarded. Youre retarded. "The weakest kink of full disk encryption is that theyll hit you with a rubber hose till you unlock it."

Have you considered nesting dm-crypt containers inside each other? I mean, that's what veracrypt does, it's not the same as encrypting each byte twice, but it's essentially the same.
>encrypt /dev/sdX
>decrypt, creates virtual device at /dev/mapper/[name]
>encrypt [name]
>repeat

That was COINTELPRO right?

Has dm-crypt/LUKS been audited? VeraCrypt has been audited.

As I already stated an example, in the past there was a dissent which eventually took the government down. It was a totalitarian state and yet it did not chose to use hard torture (which doesn't mean they couldn't make one's life into hell) and the people in dissent survived even together with their families and eventually saw the fall of the oppressive government. This is not about being a neet or not, it is about the place and the political system. In many states using encryption to pass on your resistance towards unjust government is a total legit thing and very crypt / LUKS help you to do it secretly and effectively. Using these tools to hide dissent doesn't equal you ending skinned alive, waterboarded or whatever. Obviously if people all around you end up dying, no matter what tools you use you should be scared for your life. But no every oppressive government acts in this extreme way.

Audit mean shit, faggot.

The QuarksLab audit of VeraCrypt found 26 vulnerabilities, and they have all been fixed now. So audits do mean shit, you massive fucking faggot.

ostif.org/the-veracrypt-audit-results/

dm-crypt/LUKS has never been audited by a professional security team and likely contains a ton of vulnerabilities.

>dm-crypt/LUKS has never been audited by a professional security team and likely contains a ton of vulnerabilities.

WHAT THE FUCK

I thought dm-crypt/luks was audited to shit, that was why you guys kept shilling for it and pointing out that Veracrypt was insecure because it wasn't?

What the fuck Sup Forums

user, consider necking yourself if you think the only way to go through complex security software is shit.

Trusting corporations ever. Yeah, you're the faggot.

>trusting encryption software that hasn't been audited

You must choke on a thousand dicks daily.

t. mactoddler

3 questions somebody please answer for a beginner
1. How insecure is full disk encryption with an unencrypted flash drive as the grub/boot device? Grub kept failing to install for me on an encrypted drive, even with that one crypto option enabled
2. Do I need to encrypt ram or is that completely erased once power is removed? I have tmp mounted on tmpfs in fstab per ssd recommendation, should I remove that?
3. Is there noticeable performance degradation if I don't use discard on a ssd? Arch and gentoo wiki's say not to use discard with dmcrypt. Will that fuck performance noticeably?

Props if somebody actually helps out, this isn't /g's typical amd/battle station/desktop thread shitpost so I'm not sure if anyone will respond

>le evil corporations are out to get me

lmao kill yourself.

Great strawman reptilian.

It's not a strawman if that's what you actually believe

Who audits the auditors?

Erm user, sorry to tell you this, but you are legit retarded. Can you show us some proof about IDRIX being untrustworthy? We are not discussing google here ...

They can't prove you have a hidden volume. It just looks like random data.

OSTIF does you fucking autist.

You dont crack the alogorithm, you crack the key. Not to mention cascading algorithms can sometimes make it easier to crack.

1. I don't know
2. Memory is erased when the power goes out. It does take a little time so a forensics team can theoretically freeze your RAM (literally) and pull data off it but they have to be fast about it. I'm not even sure what you mean by encrypt RAM, I dont think that's possible.
3. I dont know

Why is FDE bad?

dm-crypt/LUKS is better on Linux. The default settings in Debian and Ubuntu at this time are fine, if you choose a strong passphrase (I suggest 10 word Diceware, ideally).

There is really no point in cascading. You might want to use Serpent if Serpent-XTS is faster on your hardware (it has a fast bitsliced SSE implementation, so if you don't have AES-NI it might be faster in software).

No disk encryption mode provides integrity. That requires the overhead of MACs or authentication tags, and since things tend to massively freak out when handed unusual logical sector sizes or FDE is anything but completely transparent, there is no room to put them.

That is a serious problem when the attacker can access your volume, either with write access or with the ability to read it over time.

This is true of all disk encryption modes, including the CBC sometimes used (with or without large-block diffusers), LRW and XTS.

In theory, filesystem-based encryption can fix this easier than block-device layer stuff, because it can use authenticators. In practice, I'm not aware of a popular implementation that does?

That old project with Assange from back then? No.

Marutukku (or its older inspiration, stegfs) is very, very probably not what you want. Think about what it does, and the threat model. It cannot protect you. It might be able to protect your data, but YOU are fucked if you use it. I doubt that is what you want.

I'll expand on this re: Marutukku.

Steganographic filesystems like Rubberhose, stegfs, or (in part) TrueCrypt's hidden volume functionality, prevent you, the user of the cryptosystem, from proving that you have honestly complied (presumably under duress) with a "request" to decrypt a given volume, by (in one form of another) creating more than one volume, and possibly throwing the keys to some away.

This does not in any way prevent the attacker from (figuratively or literally) breaking your kneecaps with a rubber hose. In fact, it prevents you from being able to convince them not to: because the system is in use, and because you can't prove you don't know something, you can't prove you've given the attacker everything.

Marutukku's operational purpose is to apply pressure to members of an organisation to try to prevent them from complying under duress, by putting them in a position where they cannot prove that they are giving the adversary everything they have, so they may as well sacrifice themselves for the organisation and save the data, rather than sacrifice themselves and the data.

As an individual user, it is very probably exactly what you do not want.

>111
trips confirm