この暗号化方式の条件は都合が良すぎですか？

暗号化の方法として次のようなものを考えました。

１．暗号化したいテキストファイルを用意する。
２．base64を通したのち、1行1文字にする（1文字ごとに改行する）。
３．1行目の先頭にパスワードを付けたのち、行まるごと(改行は除いて)
　　SHA256に通してその出力で行まるごと（改行は除く）置き換える。
４．2行目の先頭に３．と同じパスワードを付け、さらにその後ろに
　　1行目をつけてから行まるごと(改行は除いて)
　　SHA256に通してその出力で行まるごと（改行は除く）置き換える。
５．４．を最終行まで繰り返す。
　　（パスワードの後ろに続けるのは常に直前行(と元々あった1文字)とする）

この場合、復号のためにはパスワードが分かっていれば
全行（というか全文字）最大64回ずつ総当りすることになりますが、

ここで、パスワードもSHA256の出力だとすると、

パスワードの総当りと、全行の各1行ずつにつき最大64回ずつの
総当りで、

後者は、実用レベルに達するが、前者は、実用レベルに達しない

という、計算機環境というか、世界というか世の中というかは、

想定として、都合が良すぎですか？

もちろん暗号化したいテキストファイルのサイズによると思いますが、
現状あるいは近い将来（遠くても10年後くらい？）では、
この暗号化は実用的ではない（ならない）でしょうか？

それとも永遠に実用的でないでしょうか？

No.8 回答者： Werner 回答日時： 2011/02/14 02:24

> 認証に256bitのパスワードを使っているオンラインストレージ

> （中略）
> 種の256bitさえ覚えておけばOK
>
> という考えでよいでしょうか。
そう言う考えで良いと思います。


> 暗号化アルゴリズムを素人が勝手に考えて人に勧めて
> 使わせるなというご意見については
要するに、「自作の暗号アルゴリズムの安全性なんてだれも担保できない」、
という事を言っただけなので、
安全性が保証されなくても問題ないのであれば
特に言うことはないです。
（普通は実運用では安全性を気にするのでANo.7の様にコメントしましたが。）


あと、すでに指摘されていたと思いますが、
SHA256を利用しているからといって、
安全性がSHA256に準じた物になるわけではありません。
運用を間違えれば安全性は落ちます。
（実際にあった例としてはRC4の運用の一つであるWEPの脆弱性とか）


「種256bit+暗号化したいデータ名」をSHA256に通して
暗号鍵生成に利用するという運用も考えているようですが、
これくらいであればたぶん問題はないと思います。
少なくとも、「種256bit」をそのまま暗号鍵として利用する場合に比べて
安全性が落ちると言うことはないでしょうから。
また、パスワードをハッシュ関数に通して暗号鍵に利用するという運用自体は珍しくないです。
共通鍵暗号方式はAES等の安全とされるアルゴリズムを使えばよいと思います。


余談ですが、「適当な値＋パスワード」のダイジェストをとり
それを暗号鍵に使う(もしくはパスワード認証用のデータとして使う)という手法はよく使われます。
この適当な値をsaltと呼びます。
saltは暗号化結果と共に保存する(そうしないとパスワードが分かっていても鍵が分からない)ので、
暗号化の強度自体は上がりませんが、
同じパスワードに対する暗号化結果が毎回異なる為
ある種の攻撃に対して強くなります。

No.7 回答者： Werner 回答日時： 2011/02/05 23:55

安全とされる共通鍵暗号の鍵長は

向こう10年くらいなら128ビットでも十分（技術進歩の程度によって変わるかもしれませんが）、
万全を期すなら256ビットにすれば良いと言ったところです。

なお、安全とは総当たり以外に解読法が存在しない、という意味だと思ってください。

何故か1024ビットでは足りないとか言う話が出てきていますが、
これは公開鍵暗号のRSAに限った話です。
同じ公開鍵暗号でも、例えば楕円曲線暗号では同じ鍵長でも強度は違います。
（あと、もし公開鍵暗号の話をしているなら鍵を人間が覚えるような運用なんて普通しません。）


> ちょっと前まではSSLしとけばいいじゃんと思っていたのですが
> 途中の経路は全然暗号化してないらしいので
SSLはEnd to Endの全経路が暗号化されます。
（Man in middle攻撃を受けた場合は話が変わってきますが、
それはちゃんとした証明書を使ってどうにかする話。）


> そんなに既存の暗号化アルゴリズムは強度が高いのでしょうか。
アルゴリズムが公開されており、多くの研究者によって検証（攻撃）されている
暗号アルゴリズムなら安全です。
少なくとも一般人はそう判断するしか有りません。

> よく分からないで使うくらいなら
> この方法のほうがいいかなと思ったのですが。
素人が適当に作ったアルゴリズムを使うくらいなら
既存の安全とされている暗号アルゴリズムを使った方が安全です。
というか、素人が暗号アルゴリズムを作るなんて一般的には愚行です。
（作るだけならいいのですが少なくとも実運用するのは）

暗号アルゴリズムを作って運用するなら、
少なくとも暗号アルゴリズムの安全性を保証する必要がありますが、
あなたにはできないでしょう？
少なくとも私にはできません。


> 衝突が発見されず入力1bit差で出力がほぼランダムに
> 半数のbitが反転するなら
> 最初から全てそれでやればいいのではないでしょうか
一般的な暗号アルゴリズムを通すと、出力は乱数（ランダム）にしか見えません。
「最初から全てそれでやればいいのではないでしょうか」と疑問を呈していますが、
そんなのは暗号アルゴリズムとしては当たり前の性質です。



結論としては、データを暗号化したいなら素直にPGPでも使いましょう。
私も重要なデータを暗号化してない経路に流す必要があるときはPGPを使いました。

この回答への補足

要するに種となる256bitだけ覚えておけば
後は計算を重ねていけばデータ暗号化のパスワードも
算出できるというか秘匿しておいたものを
復号できるようにしたいのですが、
PGPだと秘密鍵を作成する必要がありますが
これは作成用プログラムを実行しないと作成できないので
種の256bitと直接には関連づけられないですね。

例えば種256bit+暗号化したいデータ名(+必要なら変更回数)
をSHA256に通した出力をそのまま秘密鍵にすることは
できませんよね。

なのでPGP秘密鍵は仕方ないので作成プログラムで
作成するとして、それをどこに保存しておくかですが、
認証に256bitのパスワードを使っているオンラインストレージ
に保存しておけば、
手元のパソコンが壊れても、
極端に言えば災害とかで何もかもなくしても
種の256bitさえ覚えておけばOK

という考えでよいでしょうか。

SSLについては別途整理して質問します。

暗号化アルゴリズムを素人が勝手に考えて人に勧めて
使わせるなというご意見については
別に相手が拒否すればそれ以上強要しようとは
思いませんが自分だけのデータとかなら
例えば自分のメールアドレスに送っておくときに
今回質問した方法で暗号化というか変換して
送るとかならいいですよね。
誰かが真似したいといってきたら
SHA256がなんかやばいみたいな話が出ていなければ
やり方さえきちんと理解している人なら
SHA256が駄目になったときに自分だけで対応できることを
（まぁここのサイトみたいなとこで確認的な意味で
質問するくらいはOKとして）条件にいいよと返事する
といったかんじでどうでしょうか。

書いてて思いましたがこれだったら秘密鍵も
この方法で自分宛にメールしとけばいいですね。

最初からすべてそれでやればいいとは
種パスワードにSHA256のような性質を持ったものを使って作れば
あとは全部つながるからそれでやればいいということが
言いたかったのですが
重要なデータについてはPGPということであれば
それは秘密鍵は好きな名前にできないので
できないですね。

他の質問とごっちゃになって補足しちゃってるので
わかりづらくてすみません。

補足日時：2011/02/06 21:22

この回答へのお礼

ご回答ありがとうございした。

お礼日時：2011/02/06 21:22

No.6 回答者： mtaka2 回答日時： 2011/02/05 09:20

なんかもう一つの質問と補足が交錯しちゃってますが、

とりあえずここで挙げられている暗号化アルゴリズムの問題について。
つづきはもう一個の方で回答します。


このアルゴリズムの場合、パスワードに関しては、SHA-256前の生パスワードは推測不要です。
「パスワードのSHA-256値+データ1文字」をSHA-256にかけているわけですから、このとき
解読に必要なのは「パスワードのSHA-256値」だけで十分であり、元のパスワードは不要です。
つまり、「SHA-256値の256bit分」の総当たりをするだけでいいわけです。

パスワードが256bitより短いのであれば、SHA-256の256bitを総当たりするより、パスワードを総当たりにする方が簡単になりますが、
パスワードが256bitより長い場合も、256bit以上のパスワードを総当たりをする必要はありません。

つまり、この暗号の強度は、「256bitとパスワードの長さのうち短い方」になるわけです。

本来SHA-256は入力の長さに応じた総当たりが必要になるわけで、
256bitよりも十分に長い入力に対しては、その長さに応じた強度があると言えるわけですが、
そのメリットが生かされてないわけです。

もう一方の質問で挙げられているSHA-256を使って「覚えやすいパスワードから解読されにくいパスワードに変換する」というアイデアの場合、
「種パスワードまでわかる必要はない」ので「SHA-256値を総当たりすればいい」という同じ問題をかかえているわけですが、
暗号化ではなく認証用と考えれば、256bitで十分だろうと思います。

この回答への補足

毎日毎日ご回答頂きまして誠にありがとうございます！
ここまで付き合って頂いてここでお礼を申し上げることしか
できなくて本当にすまなくまたありがたく思っています！

認証用では256bitで充分ということですね。
では、暗号化のパスワードは、認証を要するネット上の
オンラインストレージに置いておけばいいので、

乱数での4096bitが暗号化する平文ごとにひとつで
平文の数だけ増える場合でも、
そのままストレージにログインしたらその直下の
フォルダに並んで見えてればそれでOKということですか？
あとは暗号化ファイル（コンテナ）が並んでいるだけで。

あれでもパケットキャプチャされて解析されたら
やっぱり80日？向こうの質問の補足で出した、
・・・えっと別のほうで続けます！ありがとうございました！

補足日時：2011/02/05 10:10

この回答へのお礼

本当に何度もお付き合い頂いてありがとうございました！！

お礼日時：2011/02/05 10:10

No.5 回答者： mtaka2 回答日時： 2011/02/04 19:30

> 次に認証と暗号化の鍵としてのパスワードは求められる強度が全然違う

認証の場合、たとえば解読に3ヶ月かかるとして、1ヶ月ごとに鍵(パスワード)を変更すれば、もう解読される心配はなくなります。

一方、暗号化の場合、たとえ1ヶ月ごとに鍵を変えたとしても、過去にやりとりした暗号文は無くなったりしません。
1ヶ月毎に鍵を変更した場合、2ヶ月前のメールはまだ解読されてませんが、3ヶ月前までにやりとりしたデータは解読されてしまうってことになります。
この場合、鍵の変更間隔は関係なくの「内容が陳腐化してそのデータが解読されても構わなくなる」ような期間を想定した強度の暗号を使うことになります。


> 現状の性能向上から考えて数年持てば（解かれなければ）いいといったことで、基準を決めているのでしょうか？

考え方としてはその通りです。ですが「数年」程度では全然不十分です。
たとえば、上述のパスワードの例の「解読に3ヶ月かかる暗号で一ヶ月おきにパスワード変更すれば大丈夫」というのは厳密には正しくありません。
総当たりで全部チェックするのに3ヶ月かかるのなら、33%の確率で1ヶ月以内に解読できるってことになります。
つまり「解読に3ヶ月かかり、1ヶ月ごとにパスワードを変更」するのは「33%の確率で解読される」ようなリスクを受け入れるということになります。

解読される可能性を減らすためには、暗号強度をもっともっと強くする必要があります。
「解読に1000年かかる暗号で、パスワードを1ヶ月おきに変える」のは、「解読される確率0.008%」のリスクを許容するということであり、
「解読に1億年かかる暗号化」で「10年は解読されない」ことを期待するのは「10年以内に解読される確率は0.00001%」のリスクを許容するということになります。
暗号化に必要な計算量と、解読されないことを期待する期間と、解読されるリスクとを天秤にかけて、どういった暗号を使うかを決めることになります。


> SHA256では衝突なしというか未発見なんでしょうか？？
> 総当り80日で分かるんですよね？？

これは入力長の問題です。
たとえば、SHA-256の入力が1バイトしかないなら、そのハッシュ値は256通りしかありません。
それを全て計算しておけば、簡単に「ハッシュ値」から「そういうハッシュ値が得られる1バイトのデータ」が求められます。入力が2バイトなら、たったの65536通り。
入力長が長くなれば、どんどん組合せ数が増えていって、それだけ「総当たりで計算する」のにかかる時間が増えていって、そのうち「総当たりで計算するのは無理」になります。

たとえば、1KBの入力をSHA-256にかけた場合、その結果であるハッシュ値から、対応する1KBの入力を総当たりで求めるには「2^8192」通りの試行が必要になります。これはもう天文学的な試行回数です。
つまり、試行回数は出力である「256ビット」ではなく入力である「8192ビット」の方に依存してるわけです。
ですから、ハッシュ関数に短い入力を入れるというのは、使い方が間違えていると言えるかと。

この回答への補足

またまた回答ありがとうございます。
よく分かってきました。そうすると
例えばGmailのメアドを決めるのに
種パスワード＋Gmail0をSHA256通して頭から使えるだけ取る
なんてのは種パスワード＋Gmail0の文字列が8192bitだか
4096bitだかないと総当りされちゃうんですね。
仮に4096bitとすると
256bitで半角39文字だから16倍して624文字ですね。
そうすると種パスワードが最低でも、
サイト名1文字+変更回数数字1桁で2文字引いて
半角622文字必要な訳ですね。←ここまでで
434バイトですから覚えとくというのは大変そうですね。
http://www2u.biglobe.ne.jp/~yuichi/rest/strcount …
そうすると種パスワードを覚えるのは無理なので
結局現状のように物理媒体と紐付けされて、
それを紛失したりしたら
結局その利用にパスワードがかかっていたとしても
（しかもパスワードをちゃんと64bit10文字英大小文字数字記号
全種類使って決めたとしても）単純に総当りでも最長で80日
で解かれるので、紛失したら無効にしなければ
いけないと。

物理媒体があるから紛失するんだから無くせばいいかと
思っていたのですがそういう理由で未だに無くならないの
ですね。

しかもこれからその624文字も文字数増える一方だと。
だとすると共通IDカードのようなもの1枚決めるしか
なくなりそうですね？
そうすると結局国家管理になりますね。いや別にいいですけど。

なんとか生態認証でもなく一切物理媒体も必要とせず
共通かつ公開された演算回路に
秘匿されている定数をパラメータに指でタイプするとかで
入力する方法で
好きに種パスワードを作れる方法はないもんですかね？
結局IDカードだろうが携帯のSIMカードだろうが紛失するので。
昔だったら単にIDとパスワードでフリーのメアドも簡単に
作れてネットのIDというかあるユーザーの存在というか
作れたのに最近はフリーでも例えばFirefoxからGmail作るには
携帯の番号必須とか。
なんか１０数年遅れただけで不公平というか。

しかし厭なら種パス624文字決めて暗記しろ
勿論全く意味を持たない文字列で、でないと辞書アタックとか
されるし
という話ですねひたすら力技ですね。でも昔アカウント大量に
作っておいた人は新規は無理だが分化させていけば？
世の中なんでもかんでも既得権益ですね。

補足日時：2011/02/04 20:34

この回答へのお礼

要するに現状では最低でも4096bitつまり624文字必要なので
そんなの覚えられる訳ないだろということで
携帯ならSIMカードとか、クレカでも何でも
物理媒体必須なのですね。
まずそれが無くしたりするから厭だったのですが。
どこがネットワーク社会だとか思ってたのですが。
かといって生体認証とかいって指紋とか掌とかいって
それがデータ漏れたらどうやって変更するんだよとか
薬品で指紋焼くのかとか思ってましたが。

なんか世の中結局便利になったようで面倒になる一方
なんですね。

どうもありがとうございました。

お礼日時：2011/02/04 20:39

No.4 回答者： mtaka2 回答日時： 2011/02/04 11:03

> 1 その保証は暗号化アルゴリズムの保証と比べてそんなに弱いのでしょうか。

どんな暗号化アルゴリズムでも、暗号文は、正しい鍵があれば、必ず復号できて元の平文が得られることは保証されています。
「非常に低い確率ではあるが、暗号文が復号できないことがある」というのでは、暗号化アルゴリズムであるとすら言えません。
そんなアルゴリズムは、それだけで一蹴されて没になることは確かです。
はっきり言って、2の方はほとんど余談。

> 2 64bitは総当りしても直ぐに解析終了してしまうほど小さい（短い）のでしょうか。

たとえば、かつて暗号化アルゴリズムの主流であったDESは鍵長が56bitでしたが、「総当たりで実用的に破れる」ということで今はもう使われていません。
(たとえば、アルファベット+英数字で96種類として、8文字で96^8=約7×10^15通りになります。これは「1台あたり毎秒100万回の試行」で「1000台並列」なら80日で解けます。)

それよりも長くすれば解読にかかる時間も増えますが、今後のコンピュータ技術の進歩の可能性を考えると、8文字を10文字にするといった程度では暗号としては安心できません。

> lifehacker初め色々なサイトでも様々なパスワードの
> 作り方が特集されたりしてるのではないでしょうか。

認証に使うパスワードと、暗号化の鍵としてのパスワードは分けて考えましょう。
暗号化においては「覚えられる程度の長さのパスワード」を鍵に使うこと自体がもう時代遅れです。


> よく分からないで使うくらいなら
> この方法のほうがいいかなと思ったのですが。

既存の暗号化アルゴリズムは、その中身が全て公開されており、様々な人からチェックを受けています。
暗号化においては「絶対に解読できない」ような信頼性は求めません。そんなのは不可能ですから「解読するのに1億年かかるから、実用的には解読されない」といった方向で信頼性を確保しています。
そして、コンピュータの進歩やアルゴリズムのチェックとともに「かつては1億年かかるはずだった暗号が、今では一週間で解読できるようになった」→「今度の新しい暗号化は今時のコンピュータでも解読に1億年かかるぞ」みたいな形で暗号化の方も進歩してきているのです。
(最初からその新しいアルゴリズムを使えばいいじゃないかと言うかもしれませんが、新しいアルゴリズムはかつてのコンピュータでは計算量が多すぎて実用的にならなかったのがコンピュータの進歩によって実用できるようになってきたものだったりするわけです)

適当に思いついたいい加減な暗号化アルゴリズムに、それだけのチェックを期待できますか?
まあ、SHA-256 を使っている分、ある程度の安全性は担保されていると言えるでしょうけど、そもそも「SHA-256は大丈夫」なんですか?
質問者さんがそれを安心できるなら、同様にRSAやAESを信用してもいいんじゃないでしょうか。
逆に、AESもRSAも信用できないというのなら、SHA-256も信用すべきではないんじゃないかと。
ハッシュ関数も自身で考えるぐらいのことはしてみてください。

> なぜたとえばメールならメールで
> 既存の暗号化アルゴリズムを用いているので
> Gmailのような無料メールでも
> 全く何の心配もありません
> というふうにならないのでしょうか。

あまり流行っていないのは「送信者と受信者が双方共に対応しなければならない」が、「受信者がどういうメール環境を使っているのか送信者にはわからない」というのが最大の原因です。
相手が「暗号化したメールを受信して復号できる」ことを事前に同意/確認を得てからではないと、暗号メールを送ってもただの文字化けメールです。

ですが、メールの場合、暗号化したメール送受信のための規格はすでに定まっています。ですから、その規格にそって暗号メールを送るのであれば、まだ相手が対応ソフトを入れている可能性はありえます。
ところが、質問者さんが新たに暗号化アルゴリズムを提案するというのであれば、まずそれを暗号化・復号するソフトを開発し、さらにそれを相手に渡してインストールしてもらう、という事前準備が必要になります。

あとは、メールについて言えば、質問者さんが挙げているような「共通鍵暗号」は使いものにません。
あるパスワードで暗号化したとして、復号するのにもそのパスワードが必要なのだとしたら、
どうやってそのパスワードをメールを送る相手に伝えるのか、という問題があります。
その点に関しては、公開鍵暗号を使うのに比べて、共通鍵暗号のメリットがまったくないです。

この回答への補足

なるほど段々と理解できてきました。
仰っている暗号文とは、「正しい鍵があれば、必ず
復号できる(元の平文が得られる)」なのですね。
自分個人が使うには（いやメールとかだとそりゃ相手がいますが）
まぁ適当でいいかなと思ってました。
大体大丈夫だろうし、くらいな。

なんかオーバースペックな方に話伺っていたみたいで
すいません。
こうなると確かにあとはほとんど余談なのですが
せっかくなのでこの機会にいろいろ教えていただけると
ありがたいです。

まずちょっと瑣末な点ですが
>アルファベット+英数字で96種類として
英大小文字+数字記号で、ASCIIだと95種類だと思いました。
（ASCII印刷可能文字）

それで仰るとおり80日ですが、言われて思い出したのですが
まえに何かで読んで（多分ネット）
大体3ヶ月に1回パスワード変更というのは、
こっからきてるのかと思ったりしました。

こういうのって、たぶんですが
一番最初にそうなったから、そうなった
的な話ですよね？世の中全体として、
全世界の演算能力が全部あわせてこれくらいだったときに、
なんか不届き者がコンピュータ使うようになって
実害が出て無視できなくなって
悪いこともしないでただ使ってただけの人も
巻き込まれたというか、何もしないわけに
いかなくなって各自で対策しなければいけなく
なった、その対策がパスワードの設定とか。

そのとき、パスワードの強度が最低これくらい
ということで、3ヶ月たったら変更しないと
ただの総当りでも解かれちゃうよ
ということで3ヶ月とか。

この推測というか想像というか当たってるでしょうか？

次に認証と暗号化の鍵としてのパスワードは求められる強度が
全然違うといったお話ですが
暗号化の鍵としては3ヶ月で、いえ80日ですか、で解かれちゃう
ようでは全然お話にならない、ということだとすると
80日ごとに変更必須とする、といっても確かに
メールだとパケットだだ漏れだからキャプチャされたら終わりだし
そうするとメールというより、サイトにメールを置いて
いちいちログインして見る、といってもどうせ
手元のマシンで見えるということはパケットで流れてきている
のだからキャプチャされたら・・・
ちょっと前まではSSLしとけばいいじゃんと思っていたのですが
途中の経路は全然暗号化してないらしいので
仮にエンドエンドで全経路暗号化されていれば、
いやそうであってもパケットを全部記録されれば
256bitくらいならやっぱり総当りでも80日で解かれるということ
ですね。
ん？そうすると4096bitであろうがメールでなくサイトであろうが
パケットキャプチャされて解析していればいつかは解かれる
ということですね。そうすると暗号化の強度というのは
実際の所は、よほど画期的な、例えば量子コンピュータが
何かの拍子で実用化してしまったとか無い限り、
現状の性能向上から考えて数年持てば（解かれなければ）いい
といったことで、基準を決めているのでしょうか？
例えばオンラインストレージにデータをPGPとかで置いて、
アクセスするにはSSLで4096bit（あるのか知りませんが）
で仮に全経路SSL保護されているとすると
仮にプロバイダあたりで全部キャプチャされて解析されたと
しても数年かかるとか。
しかし実際は途中の経路は保護されないようで・・・
そうするとデータ例えばメールだとしても、そのものを
暗号化しないといけないしその強度の基準は
まぁコンピュータ技術の進歩具合が現状の延長なら
数年持つ、が目安と。
で4096bitなけりゃ話にならんよということですね。

で、最初の質問というか考えてみた暗号化というのも
おこがましいですが、最初のでやるとすると
要は1行目のパスワードを4096bitつまり95進数で
えっと３９ｘ１６で６２４ですか、この文字数にして
あとはハッシュ通すとかは同じで、
でその624文字どうやって決めるのですが
当然法則性があっては駄目なので
といっても最低でも擬似乱数生成器使うと思いますが
これはsha256からは作れないということですね
ん？しかしそうするとどうして
SHA256では衝突なしというか未発見なんでしょうか？？
総当り80日で分かるんですよね？？
すいません分からなくなってきました・・・

補足日時：2011/02/04 13:57

この回答へのお礼

あ分かりましたkey->valueのkeyが（ほぼ完全に）分からない（分かれない）
ということとvalueが256bit（SHA256として）であるということとは
何の関係もないということですね
そうすると結局Passwordは4096bit即ち624文字
これはSHA256から作るわけにはいかないと。
SHA4096できるまで待てでも出来た頃にはもう全然弱い
以下繰り返すので永遠に未達と。

要はリンケージは絶対に不可能ということですね？
もう少し考えて見ます。
他は読んでませんがありがとうございました。

お礼日時：2011/02/04 14:15

No.3 回答者： Wr5 回答日時： 2011/02/03 21:36

手元で動けるubuntu 10.10でスクリプトにしてみました。

エンコードが…
#!/bin/bash

ENCPASS="Password!!"
for BASE64_1 in `cat $1 | base64 -w 0`;do
BASE64_2=`echo -n ${BASE64_1}|cut -b 1`
BASE64_1=`echo -n ${BASE64_1}|cut -b 2-`
ENDCHAR=""
while [ "${BASE64_2}" != "" ]; do
ENCWORD=`echo -n ${BASE64_2}${ENCPASS}${ENDCHAR}|sha256sum|awk '{print $1}'`
ENDCHAR=`echo ${ENCWORD}|cut -b 64`
echo ${ENCWORD}
BASE64_2=`echo -n ${BASE64_1}|cut -b 1`
BASE64_1=`echo -n ${BASE64_1}|cut -b 2-`
done
done

デコードが
#!/bin/bash

BASE64LIST="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"
DECODETEMP=/var/tmp/DecodeTemp.txt
ENDCHAR=""
ENCPASS="Password!!"
rm -f ${DECODETEMP} > /dev/null 2>&1
for ENCWORD in `cat $1`;do
if [ "${ENCWORD}" == "" ];then
break
fi
CNT=1
BASE64CHAR=`echo -n ${BASE64LIST}|cut -b ${CNT}`
while [ "${BASE64CHAR}" != "" ]; do
if [ "`echo -n ${BASE64CHAR}${ENCPASS}${ENDCHAR}|sha256sum|awk '{print $1}'`" == "${ENCWORD}" ]; then
echo -n ${BASE64CHAR} >> ${DECODETEMP}
ENDCHAR=`echo ${ENCWORD}|cut -b 64`
break
fi
CNT=`expr ${CNT} + 1`
BASE64CHAR=`echo -n ${BASE64LIST}|cut -b ${CNT}`
done
done
base64 -d ${DECODETEMP}

デコードのラストでbase64コマンドがエラー吐いてしまいますが……
# リダイレクトで保存しているファイルはサイズ同じ…なんですけどね……。

テストに使用した文章は…この質問文で。(jisコード変換してますけど)
1406バイトが121940バイトにふくれます。
$ time ./6495050encode test_jis.txt > test_enc.txtt
real0m10.315s
user0m0.268s
sys0m0.552s

$ time ./6495050dencode test_enc.txt > test_dec.txxt
base64: 無効な入力
real2m33.089s
user0m6.844s
sys0m8.909s

デコード処理、たぶんに無駄があるとは思われますが…。
# 既に指摘されているとおり、ハッシュの衝突が発生したらアウトですが。

この回答への補足

すいませんウブントゥとかやる気力が今ちょっと出ないです・・・。
いつか必ず試してみますのでそれまでお待ちくださいすいません・・・。

補足日時：2011/02/04 19:40

No.2 回答者： mtaka2 回答日時： 2011/02/03 18:51

> 1

強衝突は見つかってませんが「衝突が発生しない」わけではありません。入力が257bit以上の場合、それを256bitに縮めるわけですから、必ずどこかに衝突は発生します。
試行する1文字64種の違いで衝突が発生する可能性は確率的に非常に低いかもれませんが、だからといって衝突しないことを保証はできません。

> 2
SHA256自体は256ビットありますが、その元になったパスワードが8文字なら、たったの64bitな試行で総当たりできます。
また、「2回3回とSHA256を通」すことが分かっているのであれば、解析する側も2回3回とSHA256を通せばいいだけです。

まあ、256bit=32文字以上のパスワードを付ければ、256bitの総当たりが必要になるわけですが、
一方、たとえば、RSAなどの既存の暗号アルゴリズムでは、鍵は乱数で生成した1024～4096ビット程度の長さは確保することになっています。
それに比べれば、鍵長が256ビットというのは短いです。

この回答への補足

１．
＞試行する1文字64種の違いで衝突が発生する可能性は確率的に非常に低＞いかもれませんが、だからといって衝突しないことを保証はできません。

その保証は暗号化アルゴリズムの保証と比べてそんなに弱いのでしょうか。

２．
64bitは総当りしても直ぐに解析終了してしまうほど小さい（短い）
のでしょうか。
http://www.passwordmeter.com/
でa0!Z97_?の8文字で100%になりましたが
もうこんなのでは全然ダメということでしょうか。

あと256bitで39文字だったので128bitで19文字から20文字、
そうすると64bitだと10文字だと思いますが。

もちろんパスワードがあってそれをSHA256なりで39文字という
ことなのでパスワード自体が弱ければ（辞書に収録されていれば）
弱いですがまさにそのために
lifehacker初め色々なサイトでも様々なパスワードの
作り方が特集されたりしてるのではないでしょうか。
それで更に自分流のアレンジを加えて
パスワードを決めているというのが
だいたいの現状ではないでしょうか。

RSAで鍵長が1024～4096bitあるのは
オーバースペックということには
ならないのでしょうか。
というかそれ以前に
そんなに既存の暗号化アルゴリズムは強度が高いのでしょうか。
なんか少しググると怖そうな話が
沢山でてくる印象があるので
よく分からないで使うくらいなら
この方法のほうがいいかなと思ったのですが。

既存の様々な暗号化アルゴリズムは
なぜたとえばメールならメールで
既存の暗号化アルゴリズムを用いているので
Gmailのような無料メールでも
全く何の心配もありません
というふうにならないのでしょうか。
あまり使われている話を聞かないのですが。
結局バックドアがあるのではといった懸念を
払拭しきれていないから
みんな専門家っぽい人がなんかいうけど
あまり気乗りしないので使わない
面倒だし
といったかんじになってしまっているのでは
ないでしょうか。
もっと単純明快にわかりやすくしないと
またなんとかの暗号化アルゴリズムが破られたとかで
騒ぎになると
やっぱしだめかと思われると
もう2度と誰も使ってくれないのでは
ないでしょうか
なのでその辺も整理して絞って
アピールしないと
いくら凄くても誰にも理解されないで
そのままなんじゃないでしょうか。
たとえば自分も面倒そうだし
パスワード自体決めるのが面倒だしで
なにかPGPのソフトとかも入れてみたことが
ありますが全然使いませんでした

暗号化方式だけの話ではなくなってきますが
なにか全体として変というか
なにかが足りていない気がしてならないのですが
衝突が発見されず入力1bit差で出力がほぼランダムに
半数のbitが反転するなら
最初から全てそれでやればいいのではないでしょうか
発見されたら仕方ないので対衝突性のより高いとか
bit長が大きいだかに関数変更して全部変更するしか
ありませんがそれをやりやすくする仕組みを
作っておけばよいのではないでしょうか。

なにかいまひとつ利用されてない感があるのですが
なにがそんなにまずいのでしょうか。

補足日時：2011/02/04 07:43

No.1 回答者： mtaka2 回答日時： 2011/02/03 16:37

問題は2点。

1. ハッシュ関数を総当たりでチェックするという方法は、暗号アルゴリズムとして見た場合、復号できる保証がありません。
確率的にかなり低いですが、64文字のうち複数の文字が同じハッシュ値になる可能性があります。
そうなった場合、もう復号できません。

2. 暗号解読に対する強度がまったくありません。
質問者さんは暗号と解読について誤解されているように見受けられます。
暗号解読においては、単に暗号文だけがあって、それに対応する平文を求めるようなことは出来ませんしありません。与えられた暗号文に対し、無数の平文が考えられますから、暗号文だけでは解読は不可能です。

まず最初に「平文と暗号文の組」が与えられ、それを元に暗号の解析を行い、
その解析結果を基に「どんな暗号文でも平文に戻すことができる」ようになります。

たとえば、あるアルゴリズム・鍵で、平文「IBM」が暗号文「HAL」になったとします。
一方、別のアルゴリズム・鍵で平文「PIT」が暗号文「HAL」になったとします。
このとき、暗号文「HAL」だけからは「IBMを暗号化したもの」か「PITを暗号化したものか」区別できませんので、これだけでは暗号解読することはできません。

ですが、平文「IBM」が暗号文「HAL」になる、ということが分かっていれば、
それを元に暗号解析を行い「おそらくシーザー暗号で1文字ずらし」と判明、
以後、暗号文「WNT」に対し平文は「VMS」である、などと暗号解読したりできるようになるのです。

質問者さんの方式では、平文と暗号文があれば、1行目についてパスワードの総当たりだけで、パスワードが求まります。
後は、そのパスワードに基づいて復号できることになります。

この回答への補足

１．SHA256はハッシュ値の衝突つまり同じハッシュ値になる
（複数の互いに異なった）入力が未だ発見されていない
ため、その対衝突性に依存するということで、
復号できる保証はそれ（対衝突性依存）ということでは
保証があるとはいえないのでしょうか。

２．暗号という言葉の定義が私がなにか
とりちがえているということでしょうか。

強度だけについてみれば
1行目についてパスワードの総当りだけでといいますが
総当りといっても２の256乗ですが
だけといってもほぼ無理ではと思いますが

パスワードに使われそうな言葉は辞書が揃っている
といっても2回3回とSHA1256を通せば
まず解読は無理というか不可能というか困難ではないでしょうか

暗号ではないと言われたら話の前提が崩れますが
パスワード解読について強度がないとは
言えないと思いますが

補足日時：2011/02/03 17:37

この回答へのお礼

訂正SHA1256→SHA256
です

お礼日時：2011/02/03 17:37