13:15 Roundup kriptokonteynerov and encrypted file systems | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| A week ago, drew a trivial task to identify opportunities for the use of encrypted containers or file systems on the passing untrusted hosting. The problem: Ability bekapirovaniya data in any way for disaster recovery. Exception access to that data by unauthorized persons. Inability to access files in case of emergency shutdown of the server and boot from external media. Transparent operation for users with files and any content on the server. OS FreeBSD 7.2 and the maximum scope for imagination in the choice of implementation options. After the nth number of time has developed the following test configuration: GELI - GEOM_ELI (built-in FreeBSD subsystem uses encryption crypto (9) framework (hardware and software encryption)) GBDE - GEOM_BDE [Geom Based Disk Encryption] (built on FreeBSD subsystem encryption) TrueCrypt - Ported version of TrueCrypt 6.1a (using fuse) cryptofs - cryptofs using fuse encfs - encfs using fuse UPD: Table comparing the rates of net and the Encrypting File System. Let's start with the classification systems used encryption. The first two systems use any device defined by GEOM. This may be a physical drive (da0), partition (da0s1), slice (da0s1a), as well as any other synthetic devices created for example through the mdconfig or ggatel. mdconfig - utility uses geom_md and forming a virtual device from your available RAM or disk file, or any other medium. Ggatel - a utility that allows you to convert any device or file that can not be assigned to Class GEOM in this class. TrueCrypt - standalone cross-platform encryption kriptokonteynerov. Fuse_cryptofs - subsystem password disk encryption encrypting the files and their contents using the algorithms specified in the configuration file. Fuse_encfs - a subsystem of the password-key encryption of data on disk encrypting the files and their contents to the control changes to files. All tests were performed on a system having the following characteristics P4 2.8HT/1GB RAM/40GB IDE /. To estimate the speed of the used dd and bonnie. Temporary files and directories kriptokonteynerov files were placed on a partition / var. # Dmesg | grep ad0 ad0: 38166MB <Seagate ST340014A 3.06> at ata0-master UDMA100 # mount | grep var / dev/ad0s1g on / var (ufs , local, soft-updates) First of all, it was necessary to estimate the rate of linear hard disk recording we can get a peak. Testcrypt # / usr / bin / time dd if = / dev / random of = testfile.dump bs = 1m count = 4096 4096 + records in 4096 + records out 4294967296 bytes transferred in 151.801076 secs (28293392 bytes / sec) 151.82 real .00 user 132.96 sys Ie the maximum we can expect about 27 MB / sec for streaming digital. To analyze the speed of the GEOM providers created the file size of 4GB, which is in turn connected to the mdconfig and ggatel(the sector size was set at 4K). Hereinafter referred to as I will try to eliminate unnecessary service information from the package inserts. We checked the linear speed record by GEOM providers. Testcrypt # mdconfig-a-t vnode-f / var / test / testfile.dump-S 4096-u 0 testcrypt # / usr / bin / time dd if = / dev / random of = / dev/md0 bs = 1m 4294967296 bytes transferred in 306.514082 secs (14012300 bytes / sec) 306.55 real .02 user 120.03 sys testcrypt # mdconfig-d-u 0 testcrypt # ggatel create-s 4096-u 0 / var / test / testfile.dump testcrypt # / usr / bin / time dd if = / dev / random of = / dev/ggate0 bs = 1m 4294967296 bytes transferred in 319.859650 secs (13,427,662 bytes / sec) 319.91 real .02 user 133.34 sys testcrypt # ggatel destroy-u 0 As you can see from the test write speed fallen by almost a factor of 2 and ggate provider was a little slower than md, but in principle it is not particularly critical, although the ggate a bit more weight than the system md. Next step is to check the load capacity of file systems running through GEOM providers. First tested md. testcrypt # mdconfig-a-t vnode-f / var / test / testfile.dump-S 4096-u 0 testcrypt # newfs / dev/md0 / dev/md0: 4096.0MB (8388608 sectors) block size 16384, fragment size 4096 using 1913 cylinder groups of 336.98MB, 21567 blks, 21568 inodes. Super-block backups (for fsck-b #) at: 160, 690304, 1380448, 2070592, 2760736, 3450880, 4141024, 4831168, 5521312, 6211456, 6901600, 7591744, 8281888 testcrypt # mount / dev/md0 / mnt testcrypt # / usr / bin / time dd if = / dev / random of = / mnt / testfile.dump bs = 1m 4220518400 bytes transferred in 235.262614 secs (17,939,605 bytes / sec) 235.28 real .03 user 136.49 sys testcrypt # umount / mnt testcrypt # mdconfig-d-u 0 As you can see the speed of files increased and made up 17.1 megabytes / sec. The second testing ggate. testcrypt # ggatel create-s 4096-u 0 / var / test / testfile.dump testcrypt # newfs / dev/ggate0 / dev / ggate0: 4096.0MB (8388608 sectors) block size 16384, fragment size 4096 using 1913 cylinder groups of 336.98MB, 21567 blks, 21568 inodes. Super-block backups (for fsck-b #) at: 160, 690304, 1380448, 2070592, 2760736, 3450880, 4141024, 4831168, 5521312, 6211456, 6901600, 7591744, 8281888 testcrypt # mount / dev/ggate0 / mnt testcrypt # / usr / bin / time dd if = / dev / random of = / mnt / testfile.dump bs = 1m 4220518400 bytes transferred in 228.256445 secs ( 18490249 bytes / sec) 228.29 real .00 user 137.80 sys testcrypt # umount / mnt testcrypt # ggatel destroy-u 0 All other things being equal, ggate showed an increase in speed compared with the md - 17.6 megabytes / sec. It's time to test the bunch of crypto and geom providers. To do this, generate a random key to be used in further tests. Testcrypt # dd if = / dev / random of = / var / test / my.key bs = 4k count = 1 Initialize kriptokonteyner geli testcrypt # mdconfig-a - t vnode-f / var / test / testfile.dump-S 4096-u 0 testcrypt # / usr / bin / time geli init-s 4096-K my.key / dev/md0 Enter new passphrase: Reenter new passphrase: 13.34 real 9.61 user .00 sys As you can see from the output time, geli init quite a long time calculates a bunch of encryption key with a password and writes it to disk. Testcrypt # geli list Geom name: md0.eli EncryptionAlgorithm: AES-CBC KeyLength: 128 Crypto: software UsedKey: Flags: NONE Providers: 1. Name: md0.eli Mediasize: 4294963200 (4.0G) Sectorsize: 4096 Mode: r0w0e0 Consumers: 1. Name: md0 Mediasize: 4294967296 (4.0G) Sectorsize: 4096 Mode: r1w1e1 Kriptokonteyner created and formed a new unit with the suffix .eli, which can be used as a regular block device. Mark it, create partitions and file systems. Create a new file system on kriptokonteynere and test speed. Testcrypt # newfs / dev/md0.eli / dev/md0.eli: 4096.0MB (8388600 sectors) block size 16384, fragment size 4096 using 1913 cylinder groups of 336.98MB, 21567 blks, 21568 inodes. Super-block backups (for fsck-b #) at: 160, 690304, 1380448, 2070592, 2760736, 3450880, 4141024, 4831168, 5521312, 6211456, 6901600, 7591744, 8281888 testcrypt # / usr / bin / time dd if = / dev / random of = / mnt / testfile.dump bs = 1m 4220518400 bytes transferred in 277.940331 secs (15184980 bytes / sec) 277.96 real .03 user 145.50 sys As we have seen the rate dropped to 14.5 megabytes / sec. I'll skip the block layout and test the speed of ligament ggate + geli, since it is identical to the unit geli + md. Since we can not evaluate the performance only on the write cycle, we run bonnie for additional analysis. Summary of results bonnie on all the bundles will be given at the end. Testcrypt # bonnie-s 1024 File './Bonnie.1145', size: 1073741824
As you can see ggate slow on the write cycle, but much faster on the read cycle. Perhaps this is due to buffering and write various methods in Flushing md and ggate. If you try to enter an incorrect key file or password, then geli does not create a device to access the file system, as well as inside the container file like the contents / dev / random, then decrypt it is simply unrealistic. No per file, not entirely. One of the advantages geli is the ability to use multiple encryption keys, say the master key and key users. Initialize container GBDE. testcrypt # mdconfig-a-t vnode-f / var / test / testfile.dump-S 4096-u 0 testcrypt # gbde init / dev / md0-i-K my.key-L / var/tmp/md0.lock-P testcrypt testcrypt # ll / var / tmp / md * md0.lock testcrypt # gbde attach / dev/md0-l / var/tmp/md0.lock-k my.key-p testcrypt testcrypt # ll / dev / md * crw-r ----- 1 root operator, 98 Apr 21 13:25 / dev/md0 crw-r ----- 1 root operator, 100 Apr 21 10:15 / dev/md0.bde crw ------- 1 root wheel, 78 Apr 21 10:15 / dev / mdctl gbde when creating the device uses a lock file which contains the current key to initialize kriptokonteynera. System initialization kriptokonteynera no reversible data recovery procedures, so if you forgot your password or lost the lock file, then you lose all data that were in kriptokonteynere. After initialization kriptokonteynera gbde creates a device with the suffix .bde which can be treated the same way as c .eli. For detailed guidance on the use of both systems can be found here. Run bonnie for testing ligament gbde + md and gbde + ggate. testcrypt # bonnie-s 1024 File '. / Bonnie.1145 ', size: 1073741824
subsystem gbde seem pretty meager value performance, although as seen from the table the CPU time is practically not used in contrast to the geli. What is the reason I did not completely figured out. Is found in an informal network port TrueCrypt 6.1a on FreeBSD, it was decided to try it out. TrueCrypt needs to work on FreeBSD through the fuse, but in fact it was not quite so. Trying to compile the port has led to the fact that the system had to drag xorg, glib, gtk, gnome, wxWidgets and a bunch of other junk. Detailed analysis revealed that the blame GUI interface made in wxWidgets. We GUI was unnecessary and, therefore, by trial and error found the magic sequence for gmake are still collected TrueCrypt on our test system. Gmake NOGUI = 1 WX_ROOT = / usr / local / tmp / wx wxbuild gmake NOGUI = 1 WXSTATIC = 1 PKCS11_INC = / usr/local/include/pkcs11 / TrueCrypt start up cheerfully said: testcrypt # truecrypt 13:35:34: Error: Cannot convert from the charset 'US-ASCII'! Oaths about the fact that TrueCrypt was unable konvertnut help from LANG = C in en_US.UTF-8, which is tightly sewn into the source code. Testcrypt # / usr / bin / time truecrypt-c - filesystem = ufs-k / var / test / my.key - random-source = / dev / random / var / test / truecrypt.dump / mnt Volume type: 1) Normal 2) Hidden Select [1]: Enter volume size (sizeK / size [M] / sizeG): 4G Encryption algorithm: 1) AES 2) Serpent 3) Twofish 4) AES-Twofish 5) AES-Twofish-Serpent 6) Serpent-AES 7) Serpent-Twofish-AES 8) Twofish-Serpent Select [1]: Hash algorithm: 1) RIPEMD- 160 2) SHA-512 3) Whirlpool Select [1]: Filesystem: 1) FAT 2) None Select [1]: Enter password: WARNING: Short passwords are easy to crack using brute force techniques! We recommend choosing a password consisting of more than 20 characters. Are you sure you want to use a short password? (Y = Yes / n = No) [No]: y Re-enter password: Done: 100,000% Speed: 31 MB / s Left: s The TrueCrypt volume has been successfully created. 139,42 real 204,75 user 13,80 sys create a partition without problems mounted. Testcrypt # truecrypt-k / var / test / my.key - mount / var / test / truecrypt.dump / mnt Enter password for / var / test / truecrypt.dump: Protect hidden volume? (Y = Yes / n = No) [No]: testcrypt # mount ... / dev/fuse0 on / var/tmp/.truecrypt_aux_mnt1 (fusefs, local, synchronous) / dev / md0 on / mnt (msdosfs, local) testcrypt # mdconfig-l-v md0 vnode 4.0G / var/tmp/.truecrypt_aux_mnt1/volume testcrypt # ll / var / tmp /. truecrypt_aux_mnt1 / total -rw ------- 1 root wheel 1522 April 21 15:51 control -rw ------- 1 root wheel 4294705152 21 April 15:51 volume But we suffered a bitter disappointment. Contrary to the expected use fusefs, TrueCrypt has used its broadcast of a file through the endpoint md. So we got one extra joint in the transformation kriptokonteynera. The disappointment was even greater when trying to write data to the mounted TrueCrypt Volume deadlock after we have received have been exhausted write buffer for vfs. Dancing with a tambourine around TrueCrypt, vfs options and more to nothing lead and we gave up the idea of ??a normal test TrueCrypt. Unfortunately the current build TrueCrypt can create only two file systems regardless of OS, FAT and NTFS, a hard-coded into the source code. Creating a file system on an unmounted Volume is completely solves the problem of msdosfs, but does not solve the problem of deadlock. Since the tested kriptokonteynery have ended, we tried to implement a backup scheme kakuyunibud these containers. So here we were in for at least a sad fact, than the problems with TrueCrypt. We tried to make the snapshot on the file system on which the storage locations and kriptokonteyner and vytsepiv out a container file to look at its contents. But then he caught the problem. When active file operations kriptokonteynerom attempt to make snapshot leads to deadlock. The system seems to be alive, but at the same time apply to the mounted container can not, and subsequently dies access to all system sections: ( In the absence of transactions kriptokonteynerom snapshot is fine, but the likelihood of subsequent deadlock is also not excluded. And with md devices, the problem manifests itself earlier than ggate. After the deadlock and the subsequent forced dirty (reboot-qn) reboot kriptokonteyner must first check through fsck, otherwise he would not mount. plucked same kriptokonteyner of the snapshot is proving to be broken, with no file system, and without our data. That is very, very sad. Well, okay, you can not use online backup, then 100% can be used offline backup. This kriptokonteynerami with and stopped. The second part of testing involves using fusefs. To test were selected and cryptofs encfs. The difference between the systems is small and the main difference lies in the fact that encfs supports paranoid security mode verifies the integrity of files. testcrypt # cryptofs-r / var / crypto / Enter password: testcrypt # mount_fusefs / dev/fuse0 / mnt testcrypt # df-h | grep mnt Filesystem Size Used Avail Capacity Mounted on / dev/fuse0 18G 5.1G 12G 30% / mnt cryptofs creates a gateway that encrypts the data passing through it with a password specified by the user using the normal file system on the car. The system will be placed in directory, which will be home, the configuration file .cryptofs # See README for details on each parameter [CryptoFS] cipher = AES256 md = MD5 blocksize = 2048 salts = 256 Options - a list of encryption algorithms to be used in this work. Unfortunately the location of the file can not be changed: ( testcrypt # cp / etc / defaults / * / mnt testcrypt # ls / mnt / bluetooth.device.conf devfs.rules pccard.conf periodic.conf rc.conf testcrypt # ls / var / crypto / .cryptofs JuSxlpX8BzEtClI = MuKkkZS2WycuAUc = IO2ylZK9GjApQUWQR697gAD3Valf MOLpk4m8Ew == MuS1mYm2HCdvDE6bVw == The system is very easy to use, but has one drawback. If you accidentally make a mistake with a letter or number with a password - the system will encrypt the data is precisely the password you typed. Chances You will notice that it is not immediately, but users have already poured files to be encrypted new password. filesystem after entering an incorrect password looks something like this. testcrypt # cryptofs-r / var / crypto Enter password: testcrypt # mount_fusefs / dev/fuse0 / mnt testcrypt # ls / mnt / i +??? F9 &?? tg? i-??? F ~ & T?} k-??? L6 {"??? M? 1SA? l ????? y??? }+????" 0W? h encfs this problem is deprived of, but has been much more extensive set Encryption, as well as in the configuration file creates a unique key. With this key encfs determines the correctness of the password, the correctness of the encryption of files and determines which files to show or not show (meaning - this is encrypted key). If you forgot your password, you can safely delete all data recovery, they are not subject. The process works as follows. testcrypt # encfs / var / crypto / mnt Creating new encrypted volume. Please choose from one of the following options: enter "x" for expert configuration mode, enter "p" for pre-configured paranoia mode, anything else, or an empty line will select standard mode. ? Standard configuration selected. Configuration finished. The filesystem to be created has the following properties: Filesystem cipher: "ssl / aes ", version 2:1:1 Filename encoding:" nameio / block ", version 3:: 1 Key Size: 192 bits Block Size: 1024 bytes Each file contains 8 byte header with unique IV data. Filenames encoded using IV chaining mode.A week ago, drew a trivial task to identify opportunities for the use of encrypted containers or file systems on the passing untrusted hosting. The problem: Ability bekapirovaniya data in any way for disaster recovery. Exception access to that data by unauthorized persons. Inability to access files in case of emergency shutdown of the server and boot from external media. Transparent operation for users with files and any content on the server. OS FreeBSD 7.2 and the maximum scope for imagination in the choice of implementation options. After the nth number of time has developed the following test configuration: GELI - GEOM_ELI (built-in FreeBSD subsystem uses encryption crypto (9) framework (hardware and software encryption)) GBDE .- GEOM_BDE [Geom Based Disk Encryption] (built on FreeBSD subsystem encryption) .TrueCrypt - Ported version of TrueCrypt 6.1a (using fuse) cryptofs - cryptofs using fuse encfs - encfs using fuse UPD: Table comparing the rates of net and the Encrypting File System.. Let's start with the classification systems used encryption. The first two systems use any device defined by GEOM. This may be a physical drive (da0), partition (da0s1), slice (da0s1a), as well as any other synthetic devices created for example through the mdconfig or ggatel mdconfig - utility uses geom_md and forming a virtual device from your available RAM or disk file, or any other medium. Ggatel
Mode: r0w0e0
0.7 As you can see <<>> ggate <<>> slow on the write cycle, but much faster on the read cycle. Perhaps this is due to buffering and write various methods in Flushing <<>> md <<>> and <<>> ggate <<>> If you try to enter an incorrect key file or password, then <<>> geli <<>> does not create a device to access the file system, as well as inside the container file like the contents <<>> / dev / random <<>> then decrypt it is simply unrealistic. No per file, not entirely. One of the advantages <<>> geli <<>> is the ability to use multiple encryption keys, say the master key and key users. <<>> Initialize container <<>> GBDE <<>> testcrypt # mdconfig-a-t vnode-f / var / test / testfile.dump-S 4096-u 0 <<>> testcrypt # gbde init / dev / md0-i-K my.key-L / var/tmp/md0.lock-P testcrypt <<>> testcrypt # ll / var / tmp / md * <<>> md0.lock <<>> testcrypt # gbde attach / dev/md0-l / var/tmp/md0.lock-k my.key-p testcrypt <<>> testcrypt # ll / dev / md * <<>> crw-r ----- 1 root operator, 98 Apr 21 13:25 / dev/md0 <<>> crw-r ----- 1 root operator, 100 Apr 21 10:15 / dev/md0.bde <<>> crw ------- 1 root wheel, 78 Apr 21 10:15 / dev / mdctl <<>> gbde <<>> when creating the device uses a lock file which contains the current key to initialize kriptokonteynera. System initialization kriptokonteynera no reversible data recovery procedures, so if you forgot your password or lost the lock file, then you lose all data that were in kriptokonteynere. After initialization kriptokonteynera <<>> gbde <<>> creates a device with the suffix <<>> bde <<>> which can be treated the same way as c <<>> eli <<>> For detailed guidance on the use of both systems can be found here. Run <<>> bonnie <<>> for testing ligament <<>> gbde + md <<>> and <<>> gbde + ggate <<>> testcrypt # bonnie-s 1024 <<>> File '. / Bonnie.1145 ', size: 1073741824 <<>> Sequential Output <<>> Sequential Input <<>> Random <<>> Per Char <<>> Block <<>> Rewrite <<>> Per Char <<> > Block <<>> Seeks <<>> Machine <<>> MB <<>> K / sec <<>>% CPU <<>> K / sec <<>>% CPU <<>> K / sec <<>>% CPU <<>> K / sec <<>>% CPU <<>> K / sec <<>>% CPU <<>> / sec <<>>% CPU <<>> gbde + md <<>> 1024 <> 4436 <<>> 05.03 <<>> 4349 <<>> 1.7 <<>> 2695 <<>> 1.2 <<>> 12920 <<>> 13.07 <<>> 17078 <<>> 2.9 <<>> 130.1 <<>> 0.7 <<>> gbde + ggate <<>> 1024 <> 1971 <<>> 2.2 <<>> 1970 <<>> 0.8 < >> 1480 <<>> 0.6 <<>> 13812 <<>> 15.02 <<>> 17206 <<>> 3.0 <<>> 120.3 <<>> 0.6 <<>> subsystem <<>> gbde << >> seem pretty meager value performance, although as seen from the table the CPU time is practically not used in contrast to the <<>> geli <<>> What is the reason I did not completely figured out. <<>> Is found in an informal network port TrueCrypt 6.1a on FreeBSD, it was decided to try it out. <<>> TrueCrypt needs to work on FreeBSD through the fuse, but in fact it was not quite so. <<>> Trying to compile the port has led to the fact that the system had to drag xorg, glib, gtk, gnome, wxWidgets and a bunch of other junk. Detailed analysis revealed that the blame GUI interface made in wxWidgets. We GUI was unnecessary and, therefore, by trial and error found the magic sequence for <<>> gmake <<>> are still collected TrueCrypt on our test system. <<>> Gmake NOGUI = 1 WX_ROOT = / usr / local / tmp / wx wxbuild <<>> gmake NOGUI = 1 WXSTATIC = 1 PKCS11_INC = / usr/local/include/pkcs11 / <<>> TrueCrypt start up cheerfully said: <<>> testcrypt # truecrypt <<>> 13:35:34: Error: Cannot convert from the charset 'US-ASCII'! <<>> Oaths about the fact that TrueCrypt was unable konvertnut help from <<>> LANG = C <<>> in <<>> en_US.UTF-8 <<>> which is tightly sewn into the source code. <<>> Testcrypt # / usr / bin / time truecrypt-c - filesystem = ufs-k / var / test / my.key - random-source = / dev / random / var / test / truecrypt.dump / mnt <<>> Volume type: <<>> 1) Normal <<>> 2) Hidden <<>> Select [1]: <<>> Enter volume size (sizeK / size [M] / sizeG): 4G < <>> Encryption algorithm: <<>> 1) AES <<>> 2) Serpent <<>> 3) Twofish <<>> 4) AES-Twofish <<>> 5) AES-Twofish-Serpent <<> > 6) Serpent-AES <<>> 7) Serpent-Twofish-AES <<>> 8) Twofish-Serpent <<>> Select [1]: <<>> Hash algorithm: <<>> 1) RIPEMD- 160 <<>> 2) SHA-512 <<>> 3) Whirlpool <<>> Select [1]: <<>> Filesystem: <<>> 1) FAT <<>> 2) None <<>> Select [1]: <<>> Enter password: <<>> WARNING: Short passwords are easy to crack using brute force techniques! <<>> We recommend choosing a password consisting of more than 20 characters. Are you sure you want to use a short password? (Y = Yes / n = No) [No]: y <<>> Re-enter password: <<>> Done: 100,000% Speed: 31 MB / s Left: s <<>> The TrueCrypt volume has been successfully created. <<>> 139,42 real 204,75 user 13,80 sys <<>> create a partition without problems mounted. <<>> Testcrypt # truecrypt-k / var / test / my.key - mount / var / test / truecrypt.dump / mnt <<>> Enter password for / var / test / truecrypt.dump: <<>> Protect hidden volume? (Y = Yes / n = No) [No]: <<>> testcrypt # mount <<>> / dev/fuse0 on / var/tmp/.truecrypt_aux_mnt1 (fusefs, local, synchronous) <<>> / dev / md0 on / mnt (msdosfs, local) <<>> testcrypt # mdconfig-l-v <<>> md0 vnode 4.0G / var/tmp/.truecrypt_aux_mnt1/volume <<>> testcrypt # ll / var / tmp /. truecrypt_aux_mnt1 / <<>> total <<>> rw ------- 1 root wheel 1522 April 21 15:51 control <<>> rw ------- 1 root wheel 4294705152 21 April 15:51 volume <<>> But we suffered a bitter disappointment. Contrary to the expected use fusefs, TrueCrypt has used its broadcast of a file through the endpoint <<>> md <<>> So we got one extra joint in the transformation kriptokonteynera. The disappointment was even greater when trying to write data to the mounted TrueCrypt Volume deadlock after we have received have been exhausted write buffer for vfs. Dancing with a tambourine around TrueCrypt, vfs options and more to nothing lead and we gave up the idea of ??a normal test TrueCrypt. Unfortunately the current build TrueCrypt can create only two file systems regardless of OS, FAT and NTFS, a hard-coded into the source code. Creating a file system on an unmounted Volume is completely solves the problem of msdosfs, but does not solve the problem of deadlock. <<>> Since the tested kriptokonteynery have ended, we tried to implement a backup scheme kakuyunibud these containers. So here we were in for at least a sad fact, than the problems with TrueCrypt. We tried to make the snapshot on the file system on which the storage locations and kriptokonteyner and vytsepiv out a container file to look at its contents. But then he caught the problem. When active file operations kriptokonteynerom attempt to make snapshot leads to deadlock. The system seems to be alive, but at the same time apply to the mounted container can not, and subsequently dies access to all system sections: (<<>> In the absence of transactions kriptokonteynerom snapshot is fine, but the likelihood of subsequent deadlock is also not excluded. And with < >> md <<>> devices, the problem manifests itself earlier than <<>> ggate <<>> After the deadlock and the subsequent forced dirty (reboot-qn) reboot kriptokonteyner must first check through fsck, otherwise he would not mount. plucked same kriptokonteyner of the snapshot is proving to be broken, with no file system, and without our data. That is very, very sad. Well, okay, you can not use online backup, then 100% can be used offline backup. This kriptokonteynerami with and stopped. <<>> The second part of testing involves using fusefs. <<>> To test were selected and cryptofs encfs. The difference between the systems is small and the main difference lies in the fact that encfs supports paranoid security mode verifies the integrity of files. <<>> testcrypt # cryptofs-r / var / crypto / <<>> Enter password: <<>> testcrypt # mount_fusefs / dev/fuse0 / mnt <<>> testcrypt # df-h | grep mnt <<>> Filesystem Size Used Avail Capacity Mounted on << >> / dev/fuse0 18G 5.1G 12G 30% / mnt <<>> cryptofs <<>> creates a gateway that encrypts the data passing through it with a password specified by the user using the normal file system on the car. The system will be placed in directory, which will be home, the configuration file <<>> cryptofs <<>> # See README for details on each parameter <<>> [CryptoFS] <<>> cipher = AES256 <<>> md = MD5 <<> > blocksize = 2048 <<>> salts = 256 <<>> Options - a list of encryption algorithms to be used in this work. Unfortunately the location of the file can not be changed: (<<>> testcrypt # cp / etc / defaults / * / mnt <<>> testcrypt # ls / mnt / <<>> bluetooth.device.conf devfs.rules pccard.conf periodic.conf rc.conf <<>> testcrypt # ls / var / crypto / <<>> cryptofs JuSxlpX8BzEtClI = MuKkkZS2WycuAUc = IO2ylZK9GjApQUWQR697gAD3Valf MOLpk4m8Ew == MuS1mYm2HCdvDE6bVw == <<>> The system is very easy to use, but has one drawback. If you accidentally make a mistake with a letter or number with a password - the system will encrypt the data is precisely the password you typed. Chances You will notice that it is not immediately, but users have already poured files to be encrypted new password. filesystem after entering an incorrect password looks something like this. <<>> testcrypt # cryptofs-r / var / crypto <<>> Enter password: < <>> testcrypt # mount_fusefs / dev/fuse0 / mnt <<>> testcrypt # ls / mnt / <<>> i +??? F9 &?? tg? i-??? F ~ & T?} k-??? L6 {"??? M? 1SA? l ????? y??? }+????" 0W? h <<>> encfs <<>> this problem is deprived of, but has been much more extensive set Encryption, as well as in the configuration file creates a unique key. With this key <<>> encfs <<>> determines the correctness of the password, the correctness of the encryption of files and determines which files to show or not show (meaning - this is encrypted key). If you forgot your password, you can safely delete all data recovery, they are not subject. The process works as follows. <<>> testcrypt # encfs / var / crypto / mnt <<>> Creating new encrypted volume. << >> Please choose from one of the following options: <<>> enter "x" for expert configuration mode, <<>> enter "p" for pre-configured paranoia mode, <<>> anything else, or an empty line will select standard mode. <<>>> <<>> Standard configuration selected. <<>> Configuration finished. The filesystem to be created has <<>> the following properties: <<>> Filesystem cipher: "ssl / aes ", version 2:1:1 <<>> Filename encoding:" nameio / block ", version 3:: 1 <<>> Key Size: 192 bits <<>> Block Size: 1024 bytes <<>> Each file contains 8 byte header with unique IV data. <<>> Filenames encoded using IV chaining mode. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Total comments: 0 | |