アカウント名:
パスワード:
ちょっくら調べてみたのですがよくわかりませんでした。メールにファイル添付すると1.4倍くらいになるという記事はありました。
自分の場合は2.4TBほどなので30%ほど暗号化で増えても3TBちょっとですからまぁ大丈夫かな。平均余命はあと30年から40年くらいですから過去の二倍相当でも10TBには届かないことを考えればゴミデータ（主に黒歴史系）を削除することで余裕ありますね。もっとも転送時間のほうがシャレにならんような気がします。
ファイルの暗号化ってどれくらいファイルサイズ増えるものなのでしょうか。強力なものほど大きくなるんでしょうか。
暗号化というのは1対1の変換が基本なので、基本的にファイルサイズは増えません。せいぜい暗号化したというフラグとエラー検出訂正用データぐらい。ファイルサイズが増減するのは符号化。あとは暗号化するとデータの偏りが減るので圧縮効率は悪くなります。
暗号化というのは1対1の変換が基本なので、基本的にファイルサイズは増えません。せいぜい暗号化したというフラグとエラー検出訂正用データぐらい。
絶対的に安全が確保できる、（完全な）秘密分散法 [wikipedia.org]による暗号化は、必ずファイルサイズ（の合計）が増えますけどね。
クラウドサービスを信用しない（できない）場合に有用です。二つのクラウドサービスに暗号化データを預けて、両方が揃わないと復号ができないようにするとか、三つのクラウドサービス上の暗号化データのうち二つが揃えば（一つ失われても）復号できるような冗長化確保とかができます。
暗号技術であって暗号化ではないからね。分散する時点で符号化していて、オーバーヘッドはその部分。暗号を復号するためには暗号アルゴリズムや復号鍵の共有が必要だけれどその部分を指してファイル暗号化のオーバーヘッドとは言わないでしょ。
暗号技術であって暗号化ではないからね。分散する時点で符号化していて、オーバーヘッドはその部分。
多分あなたが秘密分散法を理解できていないだけだと思う。私も数学は苦手だけど…
例えば「(t-1)次曲線に乗っている t 個の点がわかれば、曲線を表す多項式が一意に定まるという性質を利用」するシャミアのしきい値法 [wikipedia.org]の一番簡単な例として、一次方程式（直線）を使って 2つの数 (a, b) を暗号化することを考えると：
暗号化：直線 y = ax + b 上の異なる 2つの点 (x1, y1) と (x2, y2) を自由に決める。この点の情報（2組の数字）を、点ごとに分散して保管する（別々のクラウドサービスとか）。
復号： (x1, y1) もしくは (x2, y2) のどちらか 1点の情報から (a, b) を求めることははできない（1点を通る直線は無数に存在する）。2つが揃えば求めることができる（2点を通る直線は1つしかない）。
直線上の点は無限に存在するので、(x1, y1), (x2, y2), (x3, y3), ... と、3つ以上の点を決めれば、3つ以上に分散した情報のうち、任意の 2点の情報があれば (a, b) を求めることができる。
つまり2つの数 (a, b) を 2つに分散させて暗号化すると 2倍の 4つの数に、n個 (n>1) に分散させると n倍になる。（ファイルならサイズが増える。なお、それぞれの数を何 bit で表現できるかは別の問題。）
3組の情報があれば復号できるようにするためには 2次方程式を使えば良い。y = ax2 + bx + c 上の 3つの点 (x1, y1), (x2, y2), (x3, y3) の情報が集まれば、(a, b, c) を求めることができるし、2つの点の情報しか無ければ求めることはできない。このとき 3つの数を、2つの数 3組以上に分散させるから、3つに分散させる場合には 2倍に、4つに分散させる場合には 8/3 倍に、n個に分散させると 2n/3 倍に増加する。
# 以下、t個の点の情報があれば復号できるようにするためには、(t-1)次方程式を使えば良い、はず。
この n個に分散するときに n倍になったり、2n/3倍になったりという増加は、符号化とは関係がないし、この方式には復号鍵というものも存在しない。
暗号にもいろいろあるということです。（どっか間違っているかな…）
同じ平文から常に同じ暗号文が生成されるのを防ぐために先頭に32バイトくらいランダムデータを入れて復号時に読み捨てたりするからちょっと増えるよ
単なる符号化・複合化のオーバーヘッドの話と暗号化のオーバーヘッドの話は別ね。基本的には暗号化したからといってサイズが増えるわけではない。(サイズを増やすような暗号化が存在しないという話ではない)
メールの添付ファイルは最近だとほとんど BASE64 符号化だと思うけど、これは元々6bitの情報を 64 種類の文字 (英大小文字、数字、記号2つ) に置き換える方法。これにより (最近は減ったけど) 7bit しか通せない mail server を経由しても問題ないという考え方。ただし 6bit の情報を ASCII 文字 1 文字 (= 8bit) に符号化するので 4/3 倍 (1.333... 倍) になるという話。#
共通鍵暗号の一部（ブロック暗号のECBモード）でデータサイズが変わらない場合がありますが、共通鍵暗号にしても公開鍵暗号にしても実用的なものはデータサイズが（少しですが）大きくなりますよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
暗号化のオーバーヘッド (スコア:0)
ちょっくら調べてみたのですがよくわかりませんでした。メールにファイル添付すると1.4倍くらいになるという記事はありました。
自分の場合は2.4TBほどなので30%ほど暗号化で増えても3TBちょっとですからまぁ大丈夫かな。
平均余命はあと30年から40年くらいですから過去の二倍相当でも10TBには届かないことを考えればゴミデータ（主に黒歴史系）を削除することで余裕ありますね。もっとも転送時間のほうがシャレにならんような気がします。
ファイルの暗号化ってどれくらいファイルサイズ増えるものなのでしょうか。強力なものほど大きくなるんでしょうか。
Re: (スコア:0)
暗号化というのは1対1の変換が基本なので、基本的にファイルサイズは増えません。
せいぜい暗号化したというフラグとエラー検出訂正用データぐらい。
ファイルサイズが増減するのは符号化。
あとは暗号化するとデータの偏りが減るので圧縮効率は悪くなります。
Re:暗号化のオーバーヘッド (スコア:2)
暗号化というのは1対1の変換が基本なので、基本的にファイルサイズは増えません。
せいぜい暗号化したというフラグとエラー検出訂正用データぐらい。
絶対的に安全が確保できる、（完全な）秘密分散法 [wikipedia.org]による暗号化は、必ずファイルサイズ（の合計）が増えますけどね。
クラウドサービスを信用しない（できない）場合に有用です。
二つのクラウドサービスに暗号化データを預けて、両方が揃わないと復号ができないようにするとか、三つのクラウドサービス上の暗号化データのうち二つが揃えば（一つ失われても）復号できるような冗長化確保とかができます。
Re: (スコア:0)
暗号技術であって暗号化ではないからね。
分散する時点で符号化していて、オーバーヘッドはその部分。
暗号を復号するためには暗号アルゴリズムや復号鍵の共有が必要だけれど
その部分を指してファイル暗号化のオーバーヘッドとは言わないでしょ。
Re:暗号化のオーバーヘッド (スコア:2)
暗号技術であって暗号化ではないからね。
分散する時点で符号化していて、オーバーヘッドはその部分。
多分あなたが秘密分散法を理解できていないだけだと思う。私も数学は苦手だけど…
例えば「(t-1)次曲線に乗っている t 個の点がわかれば、曲線を表す多項式が一意に定まるという性質を利用」するシャミアのしきい値法 [wikipedia.org]の一番簡単な例として、一次方程式（直線）を使って 2つの数 (a, b) を暗号化することを考えると：
暗号化：直線 y = ax + b 上の異なる 2つの点 (x1, y1) と (x2, y2) を自由に決める。この点の情報（2組の数字）を、点ごとに分散して保管する（別々のクラウドサービスとか）。
復号： (x1, y1) もしくは (x2, y2) のどちらか 1点の情報から (a, b) を求めることははできない（1点を通る直線は無数に存在する）。2つが揃えば求めることができる（2点を通る直線は1つしかない）。
直線上の点は無限に存在するので、(x1, y1), (x2, y2), (x3, y3), ... と、3つ以上の点を決めれば、3つ以上に分散した情報のうち、任意の 2点の情報があれば (a, b) を求めることができる。
つまり2つの数 (a, b) を 2つに分散させて暗号化すると 2倍の 4つの数に、n個 (n>1) に分散させると n倍になる。（ファイルならサイズが増える。なお、それぞれの数を何 bit で表現できるかは別の問題。）
3組の情報があれば復号できるようにするためには 2次方程式を使えば良い。y = ax2 + bx + c 上の 3つの点 (x1, y1), (x2, y2), (x3, y3) の情報が集まれば、(a, b, c) を求めることができるし、2つの点の情報しか無ければ求めることはできない。このとき 3つの数を、2つの数 3組以上に分散させるから、3つに分散させる場合には 2倍に、4つに分散させる場合には 8/3 倍に、n個に分散させると 2n/3 倍に増加する。
# 以下、t個の点の情報があれば復号できるようにするためには、(t-1)次方程式を使えば良い、はず。
この n個に分散するときに n倍になったり、2n/3倍になったりという増加は、符号化とは関係がないし、この方式には復号鍵というものも存在しない。
暗号にもいろいろあるということです。
（どっか間違っているかな…）
Re: (スコア:0)
同じ平文から常に同じ暗号文が生成されるのを防ぐために先頭に32バイトくらいランダムデータを入れて復号時に読み捨てたりするからちょっと増えるよ
Re: (スコア:0)
単なる符号化・複合化のオーバーヘッドの話と暗号化のオーバーヘッドの話は別ね。
基本的には暗号化したからといってサイズが増えるわけではない。
(サイズを増やすような暗号化が存在しないという話ではない)
メールの添付ファイルは最近だとほとんど BASE64 符号化だと思うけど、これは元々
6bitの情報を 64 種類の文字 (英大小文字、数字、記号2つ) に置き換える方法。
これにより (最近は減ったけど) 7bit しか通せない mail server を経由しても
問題ないという考え方。ただし 6bit の情報を ASCII 文字 1 文字 (= 8bit) に
符号化するので 4/3 倍 (1.333... 倍) になるという話。
#
Re: (スコア:0)
共通鍵暗号の一部（ブロック暗号のECBモード）でデータサイズが変わらない場合がありますが、共通鍵暗号にしても公開鍵暗号にしても実用的なものはデータサイズが（少しですが）大きくなりますよ。
Re: (スコア:0)
＃なお別途パッドを保存する容量は考えないものとする