Porteus

The Linux "cryptoloop" kernel module (+api) is ***still broken*** (and has been since "the beginning of time" -> since its implementation).
First and foremost; Do not use it! (Use loop-AES, Luks or Truecrypt instead.)
Secondarily, putting it into a great, new distro (Porteus) and making it convenient to access/use for inexperienced users is a really bad idea because it creates the worse case scenario: a false sense of security!
For those who are not familiar with the past 7 years of Linux kernel development (since 2004), here are (remain) the problems with "cryptoloop" (which is why cryptoloop was curiously missing from Slax despite the fact that it may seem like an obvious addition. Thomas was keenly aware of the problem...):
1) The cryptoloop system is being deprecated and dropped from the 2.6 kernels - finally! - and for a very good reason, because its broken!
- The following assumes a writable media install (USB etc.) of Porteus. -
2) Running filesystems (FS) on files is a really bad idea, running a journaling FS on a file is even worse and running an encrypted journaling FS on a file is as bad as it gets. (Read the loop-AES manual if you'd like to learn Why. One of the many reasons is that file backed loop devices ***will*** dead-lock under certain circumstances because "With file backed loop devices, correct write ordering may extend only to page cache (which resides in RAM) of underlying file system. VM can write such pages to disk in any order it wishes, and thus break write order expectation of journaling file system." ) Truecrypt, for example, has a substantial amount of specific code to handle file-backed crypto devices - about 50% of the entire code.
2a) The cbc implementation of linux cryptoloop is broken - and always has been.
3) Watermark Attacks, especially on "soft" >1024 bit block, journaling FS are a given while the block size on any modern FS >256MB really should be at least 4096 bits. (- Attn: Fanthom! Perhaps some indication in the manual or extra provisions for the larger optimum FS block sizes...)
4) To replace the Boot Loader and the Kernel with a "fake" one is especially easy on Live Systems - Porteus. The checksum will not help either because we will replace that too and even if you notice a bad checksum - the first time booting the "fake" system - by the time it becomes apparent two things happened: A) If the network connection is already configured (Porteus) then you've already transmitted your password(s); Someone on the other end already replaced your Libs with modified ones - e.g. stole everything that is in the loop container.) -- Example: It took us less than 12 seconds on a 4Mbit network connection to replace losetup with a modified version and afterward have the system continuously transmit the /etc/shadow, /sbin/init and any other files, at will. One can even replace the cached checksums (for root, etc.) with ease which means they will be always "correct" after the first boot! At this point the system is not only wide open - and transmitting everything and anything - while letting the user believe that all is well and the data is secure, but it is also transmitting everything to the great yonder.

Correct me if I'm wrong but I think providing a false sense of security to the novice/average user is a critical issue/error. Cheers

p.s. With the same effort/implementation currently in place in porteus why not just replace cryptoloop with dm_crypt (Luks)? Implementing loop-AES would be an even more spectacular feet in porteus, it being far from obvious or easy.

Thanks you for your warning, but I guess nobody uses cryptoloop for serious security bussines. The issues you explain are well known and documented.

The cryptoloop system is being deprecated and dropped from the 2.6 kernels - finally! - and for a very good reason, because its broken!

Great. I always use cryptsetup. This will prevent some distributions from implementing defective security solutions. I think cryptoloop needs to go.

Running filesystems (FS) on files is a really bad idea, running a journaling FS on a file is even worse and running an encrypted journaling FS on a file is as bad as it gets

Running filesystems from regular files is a bad idea mostly because the resulting drop of performance, fragmentation of the file inside the host filesystem and criptographic issues derivated from using encrypted files in devices with wear leveling (read Truecrypt manual, it is greatly explained). I have never heard of a encrypted filesystem becoming corrupted because it was hosted on a regular file, but I have to investigate about this.

Watermark Attacks, especially on "soft" >1024 bit block

Another well know issue, this is the most important. I encrypt my data so nobody will be able to crack my security in a short time. Why the hell would I use a system vulnerable to watermark attacks after having learned by heart a passphrase of 40+ characters? If I take the time to generate and learn that random password, I wan to use a solid system that will not be broken in less than a decade.

To replace the Boot Loader and the Kernel with a "fake" one is especially easy on Live Systems

False.

I always carry mi live system on me, so they would have to take it from me before infecting it. Even if you are able to do so, and you infect my drive, it is not a crytoloop vulnerability. Cryptsetup, Truecrypt or any other block-level encrypter are vulnerable to rubber horse attacks, cold boot attacks or other side channel attacks (like placing a keylogger in the LIve System).

It is easier to infect a regular laptop with a keylogger, because the owner is not likely to carry it around everytime. If he leaves it in the room of an hotel while he is visiting a museum, a terrorist can enter the room, install the keylogger and go away. As the usb drive can be used as a key ring, and the owner is most of the time having his keys with him, it is harder for a bad guy to take the usb.

This is why, when you set up a full-disk-encrypted system in a laptop, you are recomended to install everything under cryptseup except the /boot partition, which can be installed in you usb drive. You can even install the system without MBR or partition table.

The checksum will not help either because we will replace that too

Checksums help if you have them listed outside the drive and you check their integrity regulary. This is the principe under Tripwire or Aide: they can crack your system, but if you have the checksums stored in another drive, and you perform daily tests, it will be hard to put malware in the LiveUSB without being discovered.

A final note: I think that, for GNU/Linux environments, Cryptsetup is a better option than Truecrypt. After all, Truecrypt support for GNU/Linux is more a matter of politeness than something else. Most cool stuff Truecrypt does is Windows only, plus Truecrypt is not as integrated, allows no full disk encryption for bootable OSes, Truecrypt's plausible deniability is very LAME in GNU/Linux (and outside), etc, etc. Unless you need cross-platform compatibility, there are no much reasons to use Truecrypt under GNU/Linux.

Posted after 24 minutes 9 seconds:
I have made a PorteusBuild for Cryptsetup. Have a look here:

http://www.porteus.org/forum/viewtopic.php?f=76&t=687

Then again, since Truecrypt releases the source code as well as it has inherent (and very well implemented) pipelining built into it (unlike dm_crypt, etc.) I can think of 3-4 very good reasons why one should prefer Truecrypt. (Its popular for more than just the "cool stuff" in it! Try benchmarking on a large scale, for instance..)

Putting the cryptsetup...txz out there was thoughtful of you. Now if you just included an initrd alteration script with it so average users could actually take advantage of it... Cheers.

A per forum rules: "No Quote pyramids"
fanthom

OK, so why put it there?

Because backward compatibility, I guess. I still think is not a good thing to have cryptoloop as the default encryption system.

Not "mostly" nor does it have anything to do with performance - unless, of course, you consider a dead-locked filesystem "under-performing"?

I guess that is "under-performing", indeed. I have investigated a little, and it seems crytoloop is not only a bad implementation, is also a risk for the data. Another reason to kick it off.

I beg to differ, vehemently. The reason has absolutely nothing to do with the nature of usage or different security precautions.

My words were not written to defend cryptoloop, they where written to point that you were refering to a weakness that could also affect any other encryption solution.

In domestic computing, physical defense makes 95% of the security, plain and simple. Your little brother does not need to put malware in your PC in order to break it: he can just use a baseball bat. The same goes about side channel attacks. In cryptoloop's case, you say that someone can take advantage of the defective loop driver? That's correct. And know what? To fool cryptsetup, an enemy just needs to replace/modify the boot loader so there is a keylogger to catch the password, or any software to intercept the binary key. Once the hardware has been in enemy hands, you cannot trust it anymore. When the LiveUSB is guarded in a house where there are five Rottweilers and a freak who sleeps with a sword under his bed (just an example), likeness of the device being compromised are greatly reduced.

Encryption is the last resort, the last line of defense. You will have no problems if they can't get your drive (sometimes easier said than done).

No, it does not. Once again, its because simply replacing the loop driver will compromise the entire system which is not the case in non-Live Systems.

I see. However, we turn back again over the "physycal defense" thing I have mentioned. This is not to excuse cryptsetup at all for being not a good thing, as this renders it useless for serious work.

Then again, since Truecrypt releases the source code as well as it has inherent (and very well implemented) pipelining built into it (unlike dm_crypt, etc.) I can think of 3-4 very good reasons why one should prefer Truecrypt. (Its popular for more than just the "cool stuff" in it! Try benchmarking on a large scale, for instance..)

I thought pipelining does not work for GNU/Linux? I have not used Truecrypt in some time, so I may have missed something in the last years.

Please, share your 3-4 reasons to use Truecrypt! Don't be so evil not to tell me! Don't hesiate in posting a link to any serious benchmark about the subject.

I don't think I would switch from dm-crypt even if Truecrypt outperformed it in the benchmarks. Superior speed does not compensate the unclear shutdowns issue, for example (have they already fixed that?). Anyway, it is good to have data to compare.

Now if you just included an initrd alteration script with it so average users could actually take advantage of it...

It is worth some time and investigation.

I'm not intimately familiar with all the benchmarks out there (as I imagine there are plenty) but here is a quick excerpt from what we found. (Recent USB 3.)
===========================================
USB 3 PCIe (NEC rev. 2a): 16 x 2;
Sequential block alloc. optimized for Corsair Voyager Flash 32GB USB 3.0;
OS: Slax 6.2 (PAE); Slackware (32 & 64 bit) 13.37 basic (2.6.38.4);
Single cab. 8x2 NEC PCIe2 indpt.control.; 2 x Xeon W3550 /oc 3.98 GHz, FSB 1333 MHz / 16 thrds.
--------------------------------------------------
Speeds (r/w) on identically configured Corsair Voyager 32GB USB 3.0 Flash Drives;
Linux software RAID 0 (kernel dm_raid), blocksize 4096, chunk size 512, FS ext2 and xfs as indicated; AES-256.
----------------
Median 15 independent (clean cache) run per instant.
----------------
Slackware current 64 bit - 2.6.38.4 - RAID 0 - ext2
#Dr.<>GB<>RawRd.[MB/s]<>Tc<>dmC RawWrt.[MB/s]<>Tc<>dmC
1 32 81 36.19 32.86 74 32.22 28.37
2 64 120.18 54.91 49.3 108.26 45.7 40.61
3 96 165.75 75.2 68.72 168.38 69.2 62.69
4 128 220.97 98.18 90.32 204.54 93.03 85.78
5 160 286.21 131.06 120.03 257 112.62 106.16
6 192 359.16 164.21 143 303.82 139.48 130
7 224 421.55 175.29 166.49 391.85 163.01 146.45
8 256 446.8 192.36 179.82 403.67 178.67 160.75
9 288 498.33 225.28 195.16 494 220.11 201.03
10 320 610.91 259.57 232.94 558.33 246.45 233.07
11 352 647.66 282.84 266.47 588.25 256.39 237.12
12 384 731 303.7 279.52 607.65 272.71 246.93
13 416 733.77 309.99 290.53 669.68 300.06 267.84
14 448 783.13 322.91 305.12 728.08 326.13 288.19
15 480 923.09 416.47 367.19 836.93 378.19 309.03
16 512 963.06 441.51 379.57 808.97 394.11 321.13
----------------
===========================================
The occasional, "unreasonable" jumps between odd and even numbered ports/drives are due to a controller issue (work in progress), nevertheless, it should illustrate the general idea.

@fanthom
I understand that Gus(terapolis) gave you the idea about 3 years ago to use the cryptoloop driver but it was a bad idea then and ever since. (The man is not known for frequent mistakes but this happened to be one of them. :-)

Cheers

EDIT: The above benchmarks do Not hold true after >2.6.38. (Significant improvements to dm-crypt .)

yep - seems that cryptoloop was deprecated in 2.6 kernel indeed - thanks for pointing this out pizarr0.
i was reading about loop-aes and dm-crypt and seems that from maintainers point of view dm-crypt is better solution as it doesn't need patching of the kernel and utilities (mount, umount). i think i'll go with dm-crypt for the next release so.
in next 2 weeks i should be able to perform some initial tests on these.

one thing to ask:
Ubuntu (and other major linux distros) offers encryption of /home dir as a standard feature in their installer. it's done with journaled fs (ext4 i guess). does it mean that corruption does not apply over there?
or maybe potential corruption is loop-aes specific and they are using more another "safe" solution?
if anybody knows the answer - pls share.

For your information, Knoppix 6.2.1 (don't know about more recent releases) uses cryptoloop with (I think) ext2.

I have read in an old FAQ from cryptsetup that dm-crypt does better with the deadlocks issue.

The device-mapper core provides much better facilities to stack block devices. dm-crypt uses mempools to assure we never run into out-of-memory deadlocks when allocating buffers.

Will cryptsetup become part of porteus 1.1 ?

rather not as we are very close to final release.
i may dig into it for porteus-2.0 if users needs this functionality.

@all
please shout in this thread if you want encryption of whole porteus back.

Well, i'd love to see the ability to aumount luks encrypted devices in porteus.
All my external drives have a small encrypted partition where i put critical files, and everytime i boot porteus i need to manually mount.
In ubuntu i just plug and ubuntu asks me for the password , and automount it ... i really like it.

I'd love to see this kind of behaviour in porteus.

I have compiled cryptsetup myself and created my own module.

Hope maybe in porteus 1.2 we get this kind of support for encrypted drives.

I think encryption of everything is not necessary. Rather ... just a virtual folder somewhere on the device to encrypt all your porn important material.

please shout in this thread if you want encryption of whole porteus back.

Between having a flawed security scheme and having none, I prefer having none. That does not mean I like having none...

While brokenman says

I think encryption of everything is not necessary. Rather ... just a virtual folder somewhere on the device to encrypt all your important material.

I think that having an encrypted persistant image for all the changes the base install suffers is a must-have. Operating systems use to be very messy. Your (supposedly) encrypted data can easily leak to caches, unexpected folders, etc, and chunks of it may be available outside the encrypted folder.

A classical example is an encrypted folder (e.g: Math_homework) which contains thousands of highly sensitive information (e.g: porn pics). When you open the folder and start accessing the files with an image viewer, the image viewer can store a list of recent documents, which will remain even after finishing you "Math homework" and closing the folder. The photos themselves won't be (directly) leaked, but if someone launches the image viewer and sees names like "XXX.jpg" in the Recent Dopcuments list, you are in trouble.

Most efective defense against this kind of behavior is to encrypt it all.

brokenman wrote:I think encryption of everything is not necessary. Rather ... just a virtual folder somewhere on the device to encrypt all your porn important material.

+1
I only used 120Mb+ encrypted container for mail and few other programs. Just in case my USB flash drive will get to wrong hands.
Although I copied it to RAM on startup and copied back on shutdown (or any other time I wanted changes there to be saved).
This way I wasn't affected by occasional unplugging of USB flash drive.

Is there already some new way to store private information in Porteus 1.1 that won't be changed in the nearest future?

P.S. Thumbnails is first thing I disable so I'd vote for this to be default option.

P.P.S What other weaknesses I can expect with "copy2ram" and without using "changes" cheatcode?

P.P.S What other weaknesses I can expect with "copy2ram" and without using "changes" cheatcode?

Data can leak to the swap space if you are not careful. If the encryption implementation you use is a lame one, this could lead to an attacker retrieving data from your swap space and performing a chosen plain text attack against your encrypted folder.

The loop encryption is considered a lame one, by the way.

Back to the topic: my vote for a fully encrypted persistent image is because some people wants to store the changes they make to the system, and in such scenario, partial encryption might not be enough.

please shout in this thread if you want encryption of whole porteus back.

yeah
like the install of fedora 16 whit the option to encrypt disk or not installing the system in ext4, and work well
i dont like encrypted containers either