Cascade ciphers is such a ridiculously common request, and educating users only gets you so far. No matter how much I explain that a flaw in the implementation is a lot more likely than a AES breakthrough, they still say stuff like "the security margin of AES is a lot lower than Serpent or Twofish".

After snowden people actually started to request non-american stuff like the old GOST standard... :(

Disclosure: I am the maintainer of https://github.com/t-d-k/LibreCrypt

You are correct, cascaded cyphers don't increase security except in exceptional circumstances, and can decrease security if wrongly implemented. But LibreCrypt doesn’t actually support cascaded cyphers, so the point is moot.

What mode would you suggest using? XTS isn't exactly a good option but it seems like the best option here.

The best option would be to add a MAC or authentication tag correctly, for example with an AE mode like CHACHA20_POLY1305, AES_256_GCM, AES_256_OCB, or one of the new CAESAR candidates, etc.

But then you'd need extra space for the MAC/authentication tag, and disk encryption often isn't placed somewhere in the driver stack where you can get away with, say, a 4080-byte logical sector for a 4096-byte physical sector. Nothing expects that. Performance problems, stuff complains, even crashes, as anyone messing with 2352 byte sectors on CD-ROMs has maybe experienced. (Has anyone tried doing it anyway in more recent years? The last time I tried to implement it was back when ckt was working on PGPdisk, and it didn't go well.)

You could put the authentication tag somewhere else, but you have to be very careful with that, and it also means seeking: you could do that better if you were a filesystem, but as a transparent block device filter, as basically all FDE is, XTS is probably about as good as you're going to get - but remember that it is helpless against malleability or historical snapshots.

XTS is the best option here, but what kills me is that all three modes have deficits, and they're not the same deficits. Pick your poison! But don't ask us to tell you which is which!

Do you know of a good technical write up regarding the pros and cons of these? Thanks

What options are superior to XTS? As I understand it XTS does have some weaknesses, but is still the superior option versus LRW & CBC w/ secret IVs. I'm not aware of any other well supported block cipher modes other than those major three?

There is not really AFAIK. I was wondering if TpTacek had a recommendation.

It's terrible. Disk encryption in the cloud is going to be so easy to break though I suppose its better than nothing? whelp

The same reason that Linux has 9 major file systems - because we can, and its free software, which means personal choice is paramount.

In encryption one or two properly implemented and audited is better than 10 flawed ...

Thats sorta what I'm implying - I'd rather have 2 good filesystems rather then 9 options each with their own differing set of corner and edge cases.

Sorry. Sarcasm gets missed sometimes on the internet.

I count three of them: ext4, xfs and btrfs. Did I miss any other general purpose FS that is still significant? (No, JFS and Reiser aren't, sorry.)

So you defined 3 systems as "significant", and are challenging to name more, when you know ahead of time nothing else falls under your definition. So brave!

According to Google Trends, JFS is the third most popular file system on Linux, and Reiser is #1. F2FS is pretty big too, and it's the fastest on Linux 4 / SSD:

http://www.phoronix.com/scan.php?page=article&item=linux-40-...

Disclosure: I am the maintainer of https://github.com/t-d-k/LibreCrypt

The advantage is that if a flaw is discovered in an algorithm, then it is possible to switch to another without changing tools.

People want options and different people want different options. More options means more people will get the options they like best.

In my zuluCrypt project[1],i started with no options because i thought the default options for each supported format was "good enough for everybody" and not long afterwards,the more frequently requested feature was to add more options.

I think more options is good.

[1] http://mhogomchungu.github.io/zuluCrypt/

This is why there are still people encrypting with ciphers that use 64-bit blocks: because Schneier wrote one, and people "like" him.

Blowfish was a good choice at the time, and for some users switching away would cost a lot and give little benefit.

We will say the same about chacha20 in 25 years. It will probably still be secure, but there will be better choices.

Blowfish is a block cipher with an 8 byte block. The benefit of switching away from it is not small. Even RC5 would be better choice.

Did you need to restate that it had an 8byte block? It was clearly blowfish you meant from the beginning.

Anyway, before the AES competition most block ciphers had blocks that size and RC5 is still very much patented.

Blowfish was not a bad choice. I stand by that.

Choice, like mutation and sexual reproduction, accelerates evolution. More options means better options over less time.

Seems like a loaded question.

It is listed under features, and it doesn't state that it is good or better than other software. Whether it is a good or not is a subjective decision.

In my opinion it is good because you have more choices available.

It appears to be an open source project. Is your question relevant in the first place?

It's not inherently bad, but choice for choice's sake is generally not a good thing for security software in my view.

Saying you support more features in non-security software might be a great thing but saying you support more ciphers, encryption algorithms, etc... than the competition just means a higher probability you're supporting weak/broken security algorithms and/or that the implementations are not well audited.

That, and the overwhelming majority of users are going to have no idea what the actual difference is between all the options nor are going to take the time to investigate what exactly is the difference between RIPEMD-320 & SHA-512. Nor should they have to for that matter.

The goal here is to implement high quality security software. The more features you support, the more code is in your product, and the harder it is to ensure that your code is in fact delivering the security you're aiming for.

> Nor should they have to for that matter.

They don't, they can just leave the defaults.

Because it leads to diversity and flaw in one algorithm won't affect the entire user base. Of course developer must provide only safe and well tested algorithms.

A practical flaw in, say, AES is going to be so much more to worry about than just your disk encryption. That's a major breakthrough. Even so, the response to that is to layer ciphers, not to support many more. But that's still rather silly as it's astronomically more likely to find a bug in implementation or design of the FDE than in AES.

As far as implementation bugs, supporting many options means more users will pick the wrong options, and the attack surface becomes larger so that the chance of implementation issues goes up.

There might be flaw in implementation. Those are much more likely.

> As far as implementation bugs, supporting many options means more users will pick the wrong options, and the attack surface becomes larger so that the chance of implementation issues goes up.

Application must prevent users from picking the wrong options.

Bugs in the implementation are bad enough. I don't really care how the encryption is not secure, but that it isn't.