♌️ 👨‍🌾 ⚗️ 暗号コンテナーと暗号化ファイルシステムの比較テスト 👩🏽‍🎨 🍹 ☣️

1週間前、暗号化されたコンテナまたはファイルシステムをリモートの信頼できないホスティングで使用する可能性を判断するために、重要なタスクが作成されました。

主なタスク：

-災害復旧のために任意の形式でデータをバックアップする機能。

-権限のない人によるこのデータへのアクセスの除外。

-サーバーの緊急シャットダウン中にファイルにアクセスできず、外部メディアから起動できない。

-透過的なユーザーは、サーバー上のファイルやコンテンツを操作します。

-OS FreeBSD 7.2および実装オプションの選択における想像力の最大範囲。

n番目の時間の後、次のテスト構成が形になりました。

GELI -GEOM_ELI（crypto（9）フレームワークを使用してFreeBSDに組み込まれた暗号化サブシステム（ハードウェアおよびソフトウェア暗号化））

GBDE -GEOM_BDE [Geom Based Disk Encryption]（FreeBSDに組み込まれた暗号化サブシステム）

TrueCrypt -TrueCrypt 6.1aの移植バージョン（ヒューズを使用）

cryptofs-ヒューズを使用するcryptofs

encfs -fuseを使用したencfs

UPD：クリーンなファイルシステムと暗号化されたファイルシステムの速度を比較する表。

使用する暗号化システムの分類から始めましょう。

最初の2つのシステムは、GEOMで識別されたデバイスを使用します。これは、物理ドライブ（da0）、パーティション（da0s1）、スライス（da0s1a）、およびmdconfigやggatelなどによって作成された他の合成デバイスです。

mdconfigは、 geom_mdを使用して、既存のRAMまたはディスクまたはその他のメディア上のファイルから仮想デバイスを形成するユーティリティです。

ggatelは、このクラスのGEOMクラスに割り当てることができないデバイスまたはファイルを転送できるユーティリティです。

TrueCryptは、自律的なクロスプラットフォームの暗号コンテナー暗号化システムです。

fuse_cryptofs-構成ファイルで指定されたアルゴリズムを使用してファイル名とその内容を暗号化するディスクデータのパスワード暗号化サブシステム。

fuse_encfs-ファイルの変更を制御してファイル名とその内容を暗号化するディスクデータのパスワードキー暗号化サブシステム。

すべてのテストは、P4 2.8HT / 1GB RAM / 40GB IDE /という特性を持つシステムで実行されました。

作業速度を評価するために、 ddとbonnieが使用されました 。

一時的な暗号コンテナファイルとファイルディレクトリは、/ 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) 

最初のステップは、ピーク時のハードドライブへの線形書き込み速度を評価することでした。

 testcrypt # /usr/bin/time dd if=/dev/random of=testfile.dump bs=1m count=4096 4096 + 0 records in 4096 + 0 records out 4294967296 bytes transferred in 151 . 801076 secs ( 28293392 bytes/sec) 151 . 82 real 0 . 00 user 132 . 96 sys 

つまりストリーミング録音では、可能な限り約27メガバイト/秒を期待できます。

GEOMプロバイダーの速度を分析するために、4GBファイルが作成され、それがmdconfigおよびggatelに順番に接続されました （セクターサイズは4Kで決定されました）。さらにテキストに沿って、コードの挿入から不要なオーバーヘッド情報を可能な限り除外するようにします。

GEOMプロバイダーを通じて線形記録速度を確認しました。

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 0 . 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 ( 13427662 bytes/sec) 319 . 91 real 0 . 02 user 133 . 34 sys testcrypt # ggatel destroy -u 0

テストからわかるように、書き込み速度はほぼ2倍低下し、 ggateプロバイダーはmdよりもやや遅いことが判明しましたが、 ggateはシステムにmdよりも少し多く負荷をかけますが、原則としてこれは特に重要ではありません。

次のステップは、GEOMプロバイダーを介して機能するファイルシステムの負荷容量を確認することです。最初にテストされるのは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 13 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 ( 17939605 bytes/sec) 235 . 28 real 0 . 03 user 136 . 49 sys testcrypt # umount /mnt testcrypt # mdconfig -d -u 0

ご覧のとおり、ファイルの処理速度が向上し、17.1メガバイト/秒に達しました。

2番目にテストされた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 13 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 0 . 00 user 137 . 80 sys testcrypt # umount /mnt testcrypt # ggatel destroy -u 0

すべてが等しい場合、 ggateはmdと比較して速度が向上しました-17.6メガバイト/秒。

たくさんの暗号プロバイダーとgeomプロバイダーをテストするときが来ました。これを行うために、今後のテストで使用されるランダムキーを作成しました。

testcrypt # dd if=/dev/random of=/var/test/my.key bs=4k count=1

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 0 . 00 sys 

時間の出力からわかるように、 geli initは長い間、パスワードを使用して一連の暗号化キーを計算し、ディスクに書き込みます。

testcrypt # geli list Geom name: md0.eli EncryptionAlgorithm: AES-CBC KeyLength: 128 Crypto: software UsedKey: 0 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 

暗号コンテナーが作成され、接尾辞.eliが付いた新しいデバイスが形成されました。これは通常のブロックデバイスとして使用できます。マークアップして、パーティションとファイルシステムを作成します。

暗号コンテナ上に新しいファイルシステムを作成し、速度をテストします。

testcrypt # newfs /dev/md0.eli /dev/md0.eli: 4096 .0MB ( 8388600 sectors) block size 16384 , fragment size 4096 using 13 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 0 . 03 user 145 . 50 sys

ご覧のとおり、速度は14.5メガバイト/秒に低下しました。 ggate + geli bundle markup and testing unitは、 geli + mdブロックと同じなのでスキップします。記録サイクルだけでは作業速度を評価できないため、追加分析のためにボニーを実行します。

すべてのバンドルに関するボニーの作業の概要は、記事の最後に記載されます。

testcrypt # bonnie -s 1024 File './Bonnie.1145' , size: 1073741824 

順次出力順次入力ランダム
1文字あたりブロックする書き換える 1文字あたりブロックする求める
機械 MB K /秒％CPU K /秒％CPU K /秒％CPU K /秒％CPU K /秒％CPU /秒％CPU
ジェリ+ md 1024 17178 25.7 18324 8.4 5684 2.2 14492 15.1 15185 2.3 139.8 0.7
ゲリ+ ggate 1024 13855 20.6 12018 5.2 6388 2.7 19021 21.8 22473 4.2 136.5 0.7

ご覧のとおり、 ggateは書き込みサイクルでは遅くなりますが、読み取りサイクルではずっと速くなります。おそらく、これはmdおよびggateの書き込みバッファリングおよびさまざまなバッファフラッシュメソッドによるものです。間違ったキーファイルまたはパスワードを入力しようとすると、 geliはファイルシステムにアクセスするためのデバイスを作成しません。また、内部のコンテナーファイルは/ dev / randomの内容に似ているため、復号化は単純に非現実的です。ファイルも全体もありません。 geliの利点の1つは、複数の暗号化キー（マスターキーとユーザーキーなど）を使用できることです。

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 0 , 98 Apr 21 13 : 25 /dev/md0 crw-r----- 1 root operator 0 , 100 Apr 21 10 : 15 /dev/md0.bde crw------- 1 root wheel 0 , 78 Apr 21 10 : 15 /dev/mdctl

デバイスを作成するとき、 gbdeは現在のキーを含むロックファイルを使用して、 暗号コンテナーを初期化します。暗号化コンテナ初期化システムには可逆データ回復手順がないため、パスワードを忘れた場合やロックファイルを紛失した場合は、暗号化コンテナ内のすべてのデータが失われます。 cryptocontainerを初期化した後、 gbdeはサフィックス.bdeを持つデバイスを作成します。これはc .eliと同じ方法で処理できます。

両方のシステムを使用するための詳細なガイドは、ここにあります。 bonnieを起動して、 gbde + mdおよびgbde + ggateバンドルをテストします。

testcrypt # bonnie -s 1024 File './Bonnie.1145' , size: 1073741824 

順次出力順次入力ランダム
1文字あたりブロックする書き換える 1文字あたりブロックする求める
機械 MB K /秒％CPU K /秒％CPU K /秒％CPU K /秒％CPU K /秒％CPU /秒％CPU
gbde + md 1024 4436 5.3 4349 1.7 2695 1.2 12920 13.7 17078 2.9 130.1 0.7
gbde + ggate 1024 1971年 2.2 1970 0.8 1480 0.6 13812 15.2 17206 3.0 120.3 0.6

gbdeサブシステムはかなり低いパフォーマンス値を示しましたが、表からわかるように、 geliとは異なり、プロセッサー時間は実際には使用されませんでした 。私が最後までそうし、見つけられなかった理由は何ですか。

ネットワーク上のFreeBSDで非公式のTrueCrypt 6.1aポートを見つけたので、試してみることにしました。

TrueCryptは、ヒューズを介してFreeBSDで動作するはずですが、実際には、すべてがそうではないことが判明しました。

このポートをコンパイルしようとすると、xorg、glib、gtk、gnome、wxWidgets、およびその他のジャンクがシステムにドラッグされたという事実に至りました。詳細な分析により、GUIインターフェースはwxWidgetsのせいであることが明らかになりました。 GUIは必要なかったため、試行錯誤を繰り返して、テストシステムでTrueCryptを収集したgmakeのマジックシーケンスが見つかりました。

gmake NOGUI= 1 WX_ROOT=/usr/ local /tmp/wx wxbuild gmake NOGUI= 1 WXSTATIC= 1 PKCS11_INC=/usr/ local /include/pkcs11/ 

TrueCryptは、次のように言ってから始めました：

testcrypt # truecrypt 13 : 35 : 34 : Error: Cannot convert from the charset 'US-ASCII' !

宣誓とは、TrueCryptがヘルプをLANG = Cからen_US.UTF-8に変換できなかったことを指します。これはソースに組み込まれています。

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: 0 s The TrueCrypt volume has been successfully created. 139 , 42 real 204 , 75 user 13 , 80 sys

作成されたパーティションは問題なくマウントされました。

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 0 -rw------- 1 root wheel 1522 21 15 : 51 control -rw------- 1 root wheel 4294705152 21 15 : 51 volume

しかし、私たちは残酷に失望しました。 fusefの予想される使用に反して、TrueCryptはmdを介してエンドポイントファイルの変換を使用し始めました。したがって、暗号コンテナーの変換に別のジャンクションが追加されました。マウントされたTrueCryptボリュームにデータを書き込もうとしたときに、vfsの書き込みバッファが使い果たされた後にデッドロックを受け取ったとき、失望はさらに大きくなりました。 TrueCryptの周りのタンバリンとのダンス、vfs設定などは何の役にも立たず、TrueCryptの通常のテストのアイデアを放棄しました。残念ながら、現在のTrueCryptビルドでは、OS、FAT、NTFSに関係なく2つのファイルシステムしか作成できません。これはソースコードにハードコードされています。マウントされていないボリュームにファイルシステムを作成すると、msdosfsを使用する問題は完全に解決しますが、デッドロックの問題は解決しません。

テスト済みの暗号コンテナーが不足しているため、これらのコンテナーに何らかのバックアップスキームを実装しようとしました。一般的に、ここではTrueCryptの問題ほど悲しい状況はありませんでした。マウントされた暗号コンテナーが配置されているファイルシステムでスナップショットを作成し、そこからコンテナーファイルをフックしてその内容を確認しようとしました。しかし、彼らは問題を見つけました。暗号コンテナを使用したアクティブなファイル操作では、スナップショットを作成しようとするとデッドロックが発生します。システムは稼働しているように見えますが、同時にマウントされたコンテナにアクセスすることは不可能であり、その後、すべてのシステムパーティションにアクセスできなくなります:(

暗号コンテナでの操作がない場合、スナップショットは通常発生しますが、その後のデッドロックの可能性もあります。さらに、 mdデバイスでは、問題はggateよりも早く現れます。デッドロックとそれに続く強制的なダーティ（リブート-qn）リブートの後、最初に暗号コンテナーをfsckでチェックする必要があります。そうしないと、マウントされません。スナップショットから取り出された暗号コンテナーは、実際には、ファイルシステムが欠落しており、データがないために破損していることが判明しました。とても悲しいことです。まあ、大丈夫、オンラインバックアップは使用できないので、100％オフラインバックアップを使用できます。暗号コンテナでこれをやめます。

テストの2番目の部分では、fusefsを使用します。

テストには、cryptofsとencfsが選択されました。システム間の違いは小さく、主な違いは、encfsがファイルの整合性をチェックする偏執的なセキュリティモードをサポートしていることです。

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は、マシン上の通常のファイルシステムを使用してユーザーが設定したパスワードを使用して、通過するデータを暗号化するゲートウェイを作成します。システムが機能するためには、ホームとなるディレクトリに.cryptofs設定ファイルを配置する必要があります

# See README for details on each parameter [CryptoFS] cipher=AES256 md=MD5 blocksize=2048 salts=256

設定は、作業で使用される暗号化アルゴリズムのリストです。残念ながら、ファイルの場所は変更できません:(

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==

このシステムは非常に使いやすいですが、欠点が1つあります。パスワードを入力するときに誤って文字や数字を間違えた場合、システムは入力したとおりのパスワードでデータを暗号化します。すぐにこれに気付かない可能性が非常に高く、ユーザーは既に新しいパスワードで暗号化されるファイルをアップロードしています。間違ったパスワードを入力すると、ファイルシステムは次のようになります。

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にはこの問題はありませんが、すでにより広い暗号化設定があり、構成ファイルに一意のキーも作成します。このキーを使用して、 encfsはパスワードエントリの正確性、ファイル暗号化の正確性、および表示するファイルと表示しないファイルを決定します（つまり、このキーで暗号化されます）。パスワードを忘れた場合は、すべてのデータを安全に削除できますが、復元することはできません。作業のプロセスは次のとおりです。

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 : 0 : 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. Now you will need to enter a password for your filesystem. You will need to remember this password, as there is absolutely no recovery mechanism. However, the password can be changed later using encfsctl. New Encfs Password: Verify Encfs Password: testcrypt # mount | grep mnt /dev/fuse0 on /mnt (fusefs, local , synchronous) testcrypt # cp /etc/defaults/* /mnt testcrypt # ls /mnt bluetooth.device.conf devfs.rules pccard.conf periodic.conf rc.conf testcrypt # ls /var/crypto/ .cryptofs Nq2IBppvuCpNNHuYS1k5dn-q wiNUtxqXvJqCLs3s-u1qwJrA .encfs6.xml gNsHASsB,5N2H1TZlWTJjldR B7rx58O9WjTGrjeTaiFXjREamAQzW7u3oK3NOK1KuN4Rp- sTZaWdYP4B-oXrW1d1COMMNV

データのバックアップは、スナップショットをパーティションから削除する通常の方法と、ファイルを目的の場所に直接コピーすることによって実行できます。主なことは、逆復号化の可能性のためにキーを保存することです。

結論：この記事で取り上げたディスク上のデータを暗号化する方法はすべて、日常生活で使用する資格があります。使用する暗号化システムに応じて、必要な機能を短時間で入手できます。私がテストしたシステムの中で、私はまだgeliとencfsを選ぶでしょう。最初のシステムは、ハードウェア暗号化モジュールの使用という観点から非常に魅力的です。どのプロセッサ時間を使用してデータ暗号化に費やさないか、パーティション全体を暗号化する機能を使用します。 2番目のシステムは、暗号化されたファイルの整合性制御モードと多くのパラメーターを変更する機能にとって興味深いものです。 encfsに敬意を払って、持ち運びが必要ないくつかの外部ライブラリへのシステムの依存関係に注意したいと思います。再びgeliでは、大きなアレイのバックアップに問題があるかもしれません。まあ、それは基本的にそれです。この資料をお読みいただきありがとうございます。

すべてのシステムのBonnieベンチマーク比較チャート 。

		順次出力						順次入力				ランダム
		1文字あたり		ブロックする		書き換える		1文字あたり		ブロックする		求める
機械	MB	K /秒	％CPU	K /秒	％CPU	K /秒	％CPU	K /秒	％CPU	K /秒	％CPU	/秒	％CPU
ジェリ+ md	1024	17178	25.7	18324	8.4	5684	2.2	14492	15.1	15185	2.3	139.8	0.7
ゲリ+ ggate	1024	13855	20.6	12018	5.2	6388	2.7	19021	21.8	22473	4.2	136.5	0.7
gbde + md	1024	4436	5.3	4349	1.7	2695	1.2	12920	13.7	17078	2.9	130.1	0.7
gbde + ggate	1024	1971年	2.2	1970	0.8	1480	0.6	13812	15.2	17206	3.0	120.3	0.6
fusefs + cryptofs	1024	17207	23.8	21015	10.7	6494	3.5	16202	17.1	16829	3.2	70.1	1.2
fusefs + encfs	1024	19073	25.3	23250	11.4	7676	3.9	16402	18.4	19187	3.5	70.3	1.2

UPD：クリーンなファイルシステムと暗号化されたファイルシステムの速度を比較する表。ソフトアップデートのオンとオフを切り替えます。

		順次出力						順次入力				ランダム
		1文字あたり		ブロックする		書き換える		1文字あたり		ブロックする		求める
機械	MB	K /秒	％CPU	K /秒	％CPU	K /秒	％CPU	K /秒	％CPU	K /秒	％CPU	/秒	％CPU
fusefs + cryptofs	1024	17207	23.8	21015	10.7	6494	3.5	16202	17.1	16829	3.2	70.1	1.2
fusefs + encfs	1024	19073	25.3	23250	11.4	7676	3.9	16402	18.4	19187	3.5	70.3	1.2
cleanfs + su_on	4096	33745	33.5	32517	12.8	10681	4.4	34911	35.9	39035	7.7	80.1	0.5
cleanfs + su_off	4096	34918	33.4	35108	12.9	11188	4.5	37268	38.3	39513	7.6	84.6	0.5

(C) Aborche 2009

暗号コンテナーと暗号化ファイルシステムの比較テスト

More articles: