LibreCrypt: Transparent on-the-fly disk encryption for Windows. LUKS compatible
github.com
github.com
Why exactly is "more options than any other disk encryption software" a good thing?
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-...
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?
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.
They don't, they can just leave the defaults.
It's terrible. Disk encryption in the cloud is going to be so easy to break though I suppose its better than nothing? whelp
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.
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.
We will say the same about chacha20 in 25 years. It will probably still be secure, but there will be better choices.
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.
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.
> 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.
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 advantage is that if a flaw is discovered in an algorithm, then it is possible to switch to another without changing tools.
The GUI code is in ObjectPascal/Delphi and is likely a fork of the discontinued FreeOTFE: http://en.wikipedia.org/wiki/FreeOTFE
Sadly, the FreeOTFE licence means I had to change the name.
The latter solution works in ZFS already.
> LibreCrypt does not support encryption of the operating system partition, for this we recommend Ubuntu Linux.
What are the benefits of encrypting a partition over using an encrypted file mounted as a 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.
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.
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.
As far as I see at first glance:
+ Works on Windows.
+ Encrypted volumes can be read by Linux.
- No encryption of system partition.
- No hidden volumes. (?)
+ Encrypted Linux volumes (LUKS) can be read by windows.
Actually it not only supports hidden volumes, but unlimited nested ones, while TrueCrypt supports a maximum of one hidden volume, see: https://github.com/t-d-k/LibreCrypt/blob/master/docs/plausib...
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.
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 :)
One difference is that Pascal has much better type-safety, which makes it more appropriate for high-integrity software.
I think the only better choice for reliable code would be ADA.