Supports numerous hash (including SHA-512, RIPEMD-320, Tiger) and encryption algorithms (Including AES, Twofish, and Serpent) in several modes (CBC, LRW, and XTS), giving more options than any other disk encryption software.
Why exactly is "more options than any other disk encryption software" a good thing?
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... :(
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.
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!
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?
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:
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.
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.
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.
XTS is better than nothing, but to make it secure against key reuse from repeated snapshots we need to have IV / nonce per block, updated with every write - which means we either need to keep them in the same block (thus, no power-of-2 block size for the hosted file system), or in some other way that doesn't kill performance (likely requiring co-operation from the hosted file system).
This looks outstanding! I knew someone would come along with a worthy TrueCrypt successor at some point. Regarding "security tokens": I love my Yubikey. It can act as a gpg smartcard with some configuration. Is it supported?
Note they are discussion the OS partition, not just any partition.
If the OS partition is unencrypted, it is easier to trojan a system if you have access to it without the key (just replace some executable that is bound to execute sooner or later). Also, a lot of cruft remains there such as temporary files, registry updates, etc; e.g. even if you work on a Word file inside an encrypted container, you might find enough parts of it in swap space, temporary files, registry etc - all of which are unencrypted.
Other than swap and system partitions, there should be no difference. But some programs will leak info regardless - it's better to have everything encrypted than just some parts.
It is entirely possible to trojan a system with an encrypted OS partition, by using a bootkit.
For extra security, you should boot off a removable medium. Even this can be attacked if the BIOS is infected.
LibreCrypt is useful against very specific threats. Protecting against attackers that have repeated physical access to your PC, and the technical nous to install keyloggers etc. involves way more than just using a particular Windows program, no matter it's features.
Indeed, note I said "easier" and pointed one of the easier ways enabled by lack of OS partition encryption.
I'll go even farther than parent: If your adversary is determined enough, you should assume that any physical access to your machine, for however short a period, means you should never ever use it again - and that you have no practical way to know if said access has indeed compromised your machine. See e.g., Thunderstrike.
corollary: You can never be sure that your machine, which has passed through 10 different hands (factory, tester, packages, store, courier, ...) is not trojaned to begin with.
I work in a pascal shop. We use freepascal, which does the job really really well. Modern pascal, especially Delphi and the likes, are quite nice. Even moderate coders can, with a bit of planning, churn out good pascal code, which isnt my opinion about c++.
New hires whine in the beginning about the language of choice, but the generally don't take more than a week or two to get the basic gist of it. Our code is well structured, easy to extend, easy to understand and compiles fast.
I haven't worked on many other code bases this size, but I really don't see what could be much better.
We are a private contractor for a smaller government working with a system for hospital journals. The system is expanding quite rapidly (we got popular), but things are still very much manageable, despite the pascal codebase being well over 1MLOC.
The only thing not pascal is the GUI (which is getting ugly because our home-rolled wrapper to qt, so we are probably going to switch to something else) and the web interface (which was a web interface we inherited for this job. It was perl written by someone who thought himself smart. We rewrote that quickly in mojolicious).
So yeah. I work with pascal and do some (very little, I am not responsible for the web) web dev in perl. Now get off my lawn, your Node.js, go and rust is so shiny it hurts my old dusty eyes :)
We have had some code related security issues. Only one that was borderline severe, and that we discovered ourselves and patched by the end of the day (which was my fault, because I didn't follow the coding standard manual I WROTE MYSELF). No real stability issues, no real security problems.
Sometimes the tools matter. In our case not so much. I would love to rewrite the whole thing in Racket just for fun, though :)
Why exactly is "more options than any other disk encryption software" a good thing?