base64後、1文字ずつ暗号化すると解読困難？

質問

計算コストを幾分度外視して考えると、通常の業務連絡的な内容のメールであれば、
base64を通してから1文字ずつパスワード付きでハッシュ関数に通せば
パスワードがばれない限りかなり解読困難ですか？
（2文字目からは暗号化後の1文字目もつける→3文字目は2文字目・・・以下末尾文字まで）

またどの程度実用的でしょうか。（用途はどの程度限定されるでしょうか。）

メールにGmailなどの無料Webメールしか使っていないので
なるべく長持ちする暗号化として考えてみました。

回答お願いします。

回答No.2

Wr5 · ベストアンサー

>実際にやると復号のほうは数行のメールでも解読まで何分も
>だんまりになったりするでしょうか。

数行程度なら今時のPC使っている限りはそれほど重くない…と思われますけど……

"こんにちは."をISO-2022-JPでエンコードすると17バイト。
ソレをBASE64でエンコードすると、24バイトに。
SHA512SUMのハッシュで128バイト(バイナリのままなら64バイトですが…)になるので、
BASE64の1文字をSHA512SUMでハッシュを求めていくとなると…3072バイトになります。
SMTPの仕様で、1行80バイトで改行を入れるような決まりがあった…と記憶していますので…
38個の改行(CR+LF)が入って3148バイトの本文になりますね。(たった「こんにちは.」だけで…です。)
# 128バイトのハッシュ化したコードが改行なしで連続していた場合…です。
# 1文字毎に改行コードによる区切りを入れると……どうなるんでしょう？(1行80文字(80バイト)のSMTPの仕様も…まぁ、無視してもたいていはよろしく転送してくれるようですが)

計算のみで実際にハッシュ通したりしていないので処理時間に関しては不明です。
「（2文字目からは暗号化後の1文字目もつける→3文字目は2文字目・・・以下末尾文字まで）」の解釈が曖昧になりますので……
# とりあえず、予めテーブル化することはできないことだけは確定していますが…。

お礼

時間ができたので同日ですが書き込みます。
以前sha256でASCII印刷可能文字全95種類をフルフルで使って
表したら39文字つまり39バイトでした。
SHA512SUMについては詳しくないですが単純に256の2倍だとすると
78バイトになるのでしょうか。
で80バイト毎に改行とのお話（初めて知りました。ありがとうございます）
とすると結局1行1文字に（base64後に）しといたほうが良さげですね。
というかお話の趣旨は大変時間かかって非実用的ということですが
実際どんなもんでしょうか。って自分でやってみればいいのですが
ぶっちゃけプログラム組むの面倒で・・・
あサイズの話が先でしたね、shaというか256bitで良ければ
24バイトを1行1文字にして、1文字当たり改行2バイトずつ付くので
39*24+24*2で984バイトですか。
http://www2u.biglobe.ne.jp/~yuichi/rest/strcount.html
ここまでで←ココマデ 741バイトですから、やはり相当な
分量になりますね・・・
送るほうも制限きつい？そうでもない？けど
問題は受信して解読というか復号するときの処理の重さですね・・・
また考えてみます良かったらお付き合いください・・・

補足

すいません用事が入ってしまいました後日お礼のほうで書かせていただきます。
とりいそぎ、解釈あいまいの部分はbase64は当然64種類しかないので
同じ文字が常に同じハッシュでは頻度でばれそうなので
どの文字も（先頭の1文字をのぞいて）パスワード
（これはメール全体で1個だけ）
をつけるだけでなく、ちょうどハッシュ通したばかりの
（直前の1文字をハッシュ通した結果の文字列丸ごと）を
もつけてやれば、全文字のハッシュ後が全部
違うハッシュになるのでいいかなという考えです。

回答No.4

geshon

どこから言ったらよいのか。

技術的なことから。
まず、パスワードはどうやって知らせるのでしょう？
メールは信用できないので、別の手段ですよね。
ならば、その手段で普段の連絡もとればいいですね。

要は、インターネットの通信において暗号を共通化鍵で
共有するのは課題があるということです。
公開鍵暗号でも同じ問題はありますが、意味合いが違います。

次に復号化の方法が、総当りをして当たったものを繋げてください
というのは、本当に暗号の複合なのですか？
複合と暗号解読の差分はパスワード分でしかないですね。

「計算コストを幾分度外視して」とおっしゃっていますが、
要は、複合のための総当りは実用レベルになるけど、
パスワードの暗号解読分の総当りは実用レベルには達しないと
いう意味に見えます。だとすると、ずいぶん都合がいい
条件ですね。

もうすでにこのへんで、この複合（むしろ解読？）の計算量は
ほとんど意味が無いと思われます。

ZIPのパスワードのほうが、情報量も小さくなるので
よっぽど気が効いていますね。

> 普通の暗号化といっても強度の裏がとれません。

インターネットにあふれる暗号に関する文献を読めば、３０分ぐらいで
暗号の強度比較がだいたい分かると思います。
単に勉強不足なのではないでしょうか？
勉強する気がないのでしょうか？

> だいたいどの暗号化でもハッシュ関数を利用しているし
> というか一番キモなんじゃないでしょうか。

違います。
ハッシュというものは、ある空間から別の小さい空間への写像でしかありません。
使用される用途によって関数個別の特徴が違うだけです。

逆関数は特に必要とされていません。というか作れない。それだけです。
だからあなたの提案する似非暗号には複合方法がなく、単純攻撃と同じ
総当りしか解読の方法がないのです。

暗号化の工程においてハッシュ関数は、チェックサム程度にしか使われていません。
本体そのものは見せたくないが、本体が使われている証拠として使われます。

暗号化の本質とは関係ありません。

逆にハッシュ値がぶつかるような条件をだす計算量が小さいと、本物か偽物かの
区別ができないことを、悪意を持った人が比較的に容易にできることになります。
これは暗号解読の難しさとは関係ありません。

> 暗号化アルゴリズムは複雑なわりに
> 破られただの、どういう条件だとまずいだの
> なんだかんだ話が面倒で、かつ複雑になる一方なので
> そういう面倒な話はハッシュ関数に集約してしまったほうが
> 一般への説明、周知がしやすいので
> 結果として普及しやすいのではと思いました。

あなたが周知しなければ良いのでは？
暗号化に関してもハッシュ関数に関しても、理解が出来ていないようです。

理解していないことは恥ずかしいことでもなければ、理解する必要もありません。
ハッシュにしても、暗号化にしても、ファイルシステムにしても。

でも自分が理解していないことが分かっていない、あまつさえ理解が
足りていないところに、理解の浅い新しい提案をされては、
付き合わされる方は、知識の向上の機会がすくなくなるなるばかりか、
知識のないことを理解している人に、誤った方向を向かせることになりかねません。

自重すべきでしょう。

分からないことを分からないと、真摯に聞く態度が大切だと思います。

辛辣なことを書いていますが、人に物を勧める、提案する態度を取るのであれば、
それだけしっかりしなくてはいけないということです。
時には責任も付いてきます。
間違えば指摘も受けるでしょうし、いい加減なことを書けば批判も受ける
ということです。

お礼

ちょっと気力が続かなかったのでなんか逃げるような返しに
なってしまいましてすいません。
また気が向いたら新たな切り口で質問しようと思います。

補足

なんか周知とか大きなこと言ったのがいけなかったみたいですね。

単に暗号化の方法として個人的に使う上で
なるべく長持ちするかどうか知りたかっただけです。

個人的といってもメールなら相手のあることだから
なんとなく周囲に広まるかもしれませんが。

周りの人からうまくいっているように見えれば
教えることもあるかもしれないし。

パソコン自体そんなものだと思っているので。

時期を逸すると言葉の意味が都合の良い所だけとられて
世の中に定着してしまうので
後から反論するのに大変な労力がかかるのですね。
昔は別にインターネットは逃げないし必要が出来たら
真面目に調べて考えるか
（自分の頭では無理そうというかもう限界と感じたら
しょうがないから諦めるか、でもたいてい
なにかやりようはあるだろ最後は力技で）
くらいに思っていたので
後れを取るというのはこんな面倒なことなんだなあと
実感している次第です。

というか世の中変なんじゃとも思いますが。
憤りというか。

そのあたりが最後の13行を言われてしまうことに
つながってくるのかなと思いました。

あまり勉強する気も起きないのはそんなとこにも
あるかもですね。

なんか話がかみ合わないですね。

どうせ自分がマイナーな奴だからでしょう。

なんかすぐこういう風に何やっても厭になります。

話がずれてきたのでこの辺で。

回答No.3

kmee

思ったのですが、
1つ目が解読されると、パスワードがわかるわけで
2つ目以降は
パスワード(既知)+前段の暗号(既知)+1文字(未知,64候補)
と高々64回の試行で次の文字がわかってしまうわけで。

暗号化の計算量とデータ量が大きいわりには、強度は普通に暗号化するのと大して変わらないのではないか、と思います。

お礼

追記ですが
たしかに現時点では自分ひとりで個人的に使うのですが
いつかは周囲の人間に普及させたいと思っています。
（どうせメールなど相手のあることなので）
なので全てを含めて、
なるべく長持ちする方法を考えている次第です。

補足

普通の暗号化といっても強度の裏がとれません。
それ言ったらハッシュ関数もそうですが、
だいたいどの暗号化でもハッシュ関数を利用しているし
というか一番キモなんじゃないでしょうか。

基本、計算量やデータ量は大きくなっても
技術の進歩で将来的には解決できるのではという
淡い期待が持てますが

暗号化アルゴリズムは複雑なわりに
破られただの、どういう条件だとまずいだの
なんだかんだ話が面倒で、かつ複雑になる一方なので
そういう面倒な話はハッシュ関数に集約してしまったほうが
一般への説明、周知がしやすいので
結果として普及しやすいのではと思いました。

パスワードもハッシュ関数の出力をそのまま使えば
解読困難でしょうし。

駄目になったときは一気に全部駄目ですが
それは現在も同じでしょうし。
というか予防できる質のものではないので
対応を如何に速くうまくやるか、その仕組みをどう
整えておくかといった話になると思います。

回答No.1

Wr5

>base64を通してから1文字ずつパスワード付きでハッシュ関数に通せば

パスワードが共通だとしましょう。
ハッシュ関数を通した結果から、入力元は取り出せませんから、1文字あたりパスワード付きハッシュを通す必要があります。
1文字確定するたびに64パターン程度のハッシュ関数呼び出しと比較が必要になります。
# まぁ、実際には64種類程度ですから、「パスワード＋BASE64での1文字」のハッシュ結果を64通りテーブルにしてしまえばいいだけですが…

>（2文字目からは暗号化後の1文字目もつける→3文字目は2文字目・・・以下末尾文字まで）

という条件ではテーブルも使えませんから、長文メールになればなるほど(デカい添付ファイルが付けばさらに)負荷が重くなりますね。

現実的ではない。
と思われます。

お礼

上の補足ですが
>実際にやると復号のほうは数行のメールでも解読まで何分も
「解読まで」は余計でした。
失礼しました。

補足

base64後で何文字くらいであれば現実的でしょうか？
暗号化は、ほぼ文字数だけハッシュ計算をすればいいので
その負荷ですが、復号は1文字あたり64倍ということで
文字数の64倍の負荷（＋比較して一致したものを探す負荷が
1文字ずつかかる）だと思っていますが。
実際にやると復号のほうは数行のメールでも解読まで何分も
だんまりになったりするでしょうか。