アプリ版:「スタンプのみでお礼する」機能のリリースについて

暗号化ソフトを作ってみたんですが復号化できる人いますか?

セキュリティーのため、ソースコードは非公開です(笑)

もしとけたら、パス(分かれば)と生データを教えてください
生データだけでも結構です。

返信がなくてもつまらないので分からなかったら、
分からなかった事と分からなかった理由なども知りたいです。

というか・・もしソースコードが分かってもパスが分からない限りは
仕組み的に絶対、解読は無理なのではないかと思ってるんですけど・・・。
そういう事もあるんでしょうか?

よろしくお願いします。

以下、暗号化データです。
(バイナリなのでBase64エンコードしてあります。)
エンコード前の暗号済データは

MD5:
23DDD53B188B1AEA135E744876274E80です


f0x9vE3IhtyguB3Cp/Ix9osGb55qbskO8R/nBVXrf+Uztpd5bnJ7tRaKACfsyjUvKKT4LQJbriRM
XxVzz2Te4w+E1yrfPVHHeOVMweH7YTzcD6tFVxVxEjnmSjcUvdTVdpgLosERosbMm/vqGfpYt70v
TA4VreMyvcon2Psn3ITeAKb6/5cMov/ZUwBAgiPC6aLEMwleafBtK/G8pnJkHmd2i8sBCAmyIM9B
bWMjWkA5FW1YGF3MmcvHLUXIpD3o8+637qkF+wb9MLKwqEkqw/nefbk7VCcwWxLfPdwq6cJ/EQ17
KCcvJ4Hj/Ntfp6dy5Mngie3sjD/f7Cr31lKCVIququ/YN1MifRez9ZHa8H7RQiM1Tt2Yeo5vv90Y
vVNUK8QW7r4AysVw2GDzfJX6K8SRJnwDibqykEGhRuFMzFvRq/wUVpQ2bn1eWtcohEiDHNG4Wp/z
zmKGN5dslA0tTbDrqN0cTsBlYK4x859qK/0rJxqwtZ367MwGX4i9+9hqKU8MDWpfmvXAdg6adgkx
Ni+MCoKbU4QVoyeFTN9w0vzeq/7i+yyPNIu2fOsi5YmJwYSTyx+Bekk90Oaa9nBRDpP5FL+W4dbt
J/YUoSkDrMY7rohvnSQuhpE7WSRJIC8oR2S7XsbFQAidfT4xPxAokjZQOP8Oz+jaO6cabWemCE8Y
/ni7tuqIq6E9QSWYBmbLVuCB9o8yl0WV6lulwbemBhf+OQ4u0uS6vU2gqBTy5rTwGaQ9pNW3sLrS
MNg2swke+t30uKcf/SlknDjAnHId4kky6Y7KFG+M9QqtYOGD64YnAwDn3NeT1NI1f2kytIJDVlgl
0i+29bWufBchc7aXgwsR1SQSOmekRD+pFOSaXDa97elsOsjCE9rCOE7Lgtjk7cUgTWUC69bew6lL
p+pc3YYquYQfV9f/+AfNzZNgwFebHluO9aSlS5ilB71lUY8ahxsoWA8SRLryMzufFHGfqzfIIK0O
DCdefXBrHvS26exMEpD9ImoSh9vtqOX3BKfF+2QrD9/uR9g3OHr0Id0w41NOFiBuzMOjRjjtEA5J
OQDS7O8rMfz+JEFz2blVlRHbjTLtXvCpXSKna2d87vXNexL3Z1R5LXiYPjNRA1m7u0SPRwv/BUMy
lhVGwfF3RNo6z7VRVJMc04U0GmPsd2qylNVgm7Af1KSPNmaNdxAvYg8M0+6LwV+BI8ZxDyGc6j9n
7pIgZnhWq4qTQ4EVg618exOWwUaM71gN/CzTdWxsZz5w+/42bPIWNvxSTZEc/h3KoszjiCN9xf0/
zVvg0UEphftCTmoDP8MghMU5OpVGaO4DEsn40eTsSSCWGewvWNS1bcFT6f3LQ3kHpCxCqJeeqKRO
97pRY+an5SY+s7rCtRefz7pUUERnP3ZlKG5HQ+pEZXY/+sH5rnCWNROupiWnaHtTq9omOpWS7RxL
vur51ZnSgDYV67HvvqSue0+/OPTj2Ic6k6EyBbHs9fIT/Mva4MluA3xkFOzQaR+Ou83pAqmowgYy
yBPJfyfTHsQ3XMN2QnomoZ24Z43TiM8AcX6aq/OdsdMDyclZIZ24JmKbt8QtukzfSdgQ7mqL7yoC
M4KOCAiZqzIozSWj3+9vDckq3Y/E15Ud2SDnT1tEHiYxrdVgVcbzQcq15AxQNLy5HIczIvdkLYuW
0jqtLPkezHIDCNRk+gzaIAJhEJaOvmqJC0k6yDG5QIFHvqhkX2bNof3zMJnA

A 回答 (5件)

>具体的には主に排他的論理和を使ってデータを隠蔽しています。


排他的論理和での隠蔽は、比較的「よくある手法」だったりします。

で、極論を言えば「暗号を破られ難くする最善の方法は、暗号文の存在を悟られないようにする事」だったりします。

例えば「何の変哲もない風景写真の画像情報に、別の画像が埋め込まれている」とか。

例えば「ある有名な漢詩をテキストファイルとして打ち込む際に、特定の位置の漢字の幾つかを、わざと似ている別の漢字に差し替え、誤字の位置によって特定の情報を埋め込む」とか。

そういう訳で、コンピュータ上での「究極の暗号」とは「そこにデータがあると気付かせないように、存在そのものを隠蔽する事」だったりします。
    • good
    • 0

>というか・・もしソースコードが分かってもパスが分からない限りは


>仕組み的に絶対、解読は無理なのではないかと思ってるんですけど・・・。
>そういう事もあるんでしょうか?

使い方にもよるんですけど、、、

アルゴリズムは解読可能なのでアルゴリズムが秘密であることが前提だとするとすぐにクラックされます。なので評価してもらいたいならまずアルゴリズムを公表した方が早いですね。

ただしセキュリティのポイントには「目立たない」というのもありますので、実用的に使おうと思って作ってるなら公表はお勧めしないですけど。

アルゴリズムがわかっていてパスワードがわからない場合は総当りになりますので計算時間次第です。(そういう意味で絶対はないです)

ただ、別の方も書かれてますけど正解に達したかどうかの判定が難しい場合は、さらに判定のための時間が必要になります。ご自分でも書かれてますが、判定を容易にする仕組みは解読を加速します。(脆弱性というのとはちょっと違う)

鍵が無くても複合できる暗号は穴があることになるので実用性には欠けます。

あとは、実用性について言うならデータ量が爆発すると用途が限定されますね。

それと、一つの鍵がばれただけで全てがチャラにならないような仕組みなども最近は要求されます。(DVDであっさりクラックされたのは、、、)

この回答への補足

自己レスですが・・。

>そのようなキーは無数にあると思いますし・・。 

あーでも、だめかー。判定が可能だとそれ以外を切り捨てればいいので
かなり限定されてしまいますものね。難しいなぁ。うーん。でも利便性を考えると辞書アタックが可能なのは仕方がないかな・・。結構大きなリスクのわりには得るものは少ないですけど、PC初心者にも使えるものとなると・・。

判定を文字列じゃなくて画像のヘッダ部分とかをとったバイナリにして画面に描画して文字が読めるかで判定とかw画像は毎回ランダムに文字の描画位置やフォントや、ノイズ化とか歪みとか、背景を変えないとだめですね。それって一種のキャプチャじゃw。

補足日時:2009/10/02 12:37
    • good
    • 0
この回答へのお礼

なるほど、絶対はないのですね。それもそうだと思いました。考えてみましたがこのソフトの場合はどんなにキーが長くても512bitのキーに置き換えられてしまうので、パターンは

2の512乗で1.3407807929942597099574024998206e+154

個に限られてしまいますね。ってこれってどのくらいなのか全然わからないですけどww。無限に速いコンピュータなら一瞬でしょうかw。

本当はどのくらいの強度があるのか数学的に計算して、どの用途にくらいなら実用可能かどうかだせばいいのでしょうけど、難しいですね・・。データ量に関してはフッタ情報の512Byteが増大するだけなので大丈夫です。

解読を加速させるような情報を付加してしまっているのですね。。あと、この質問で暗号化されたフッタの中の復号化成功が判定可能な文字列はなるべく短い物がいいらしい?という事が新たにわかりました。色々ご指摘をいただいて改めて深く考察することができます。大変ありがとうございました!

お礼日時:2009/10/02 12:29

>あと処理について気になった点なのですけど、このソフトではまず最初にフッタ部分を復号化して、正確に復号できたかを調べて、パスワードが正しいかを検証しその後に復号化処理を行うのですが、これは脆弱性につながるでしょうか?



繋がりますね。

「パスワードが正しいかは調べない」の方がセキュリティーが向上します。

「パスワードが正しいかを検証する処理」を解析されれば「正しいパスワードを求める処理」を作られてしまいます。

なので「入れられたパスワードが正しい物として復号し、復号した結果が元の平文と一致しなくても責任を取らない」と言うのが良いです。

更に言えば「元ファイルと暗号文ファイルは同一サイズで、ヘッダフッタは付加しない」かつ「暗号化と複合化は、同一の処理」であるのがベストです。

例えば
・パスワードABCで、Hello world」を暗号化すると「@jk:a$H8)q*」が得られる
・パスワードABCで、「@jk:a$H8)q*」を暗号化すると「Hello world」が得られる
・パスワードABC以外で、「@jk:a$H8)q*」を暗号化すると「Hello world」ではない結果が得られる(パスワードを間違っても気にしない。異なる結果が得られるだけ)
・パスワードを変更すると、まったく別の結果が得られる
・パスワードを少しだけ変更した際でも、全文が大きく変更されるようにする(類似パスワードで類似した結果が得られると、パスワードの相違点と結果の相違点から、パスワードの各文字がどのような変化をもたらすか推測できてしまう)
と言うようにするのが良いです。

特に「暗号化と復号化が異なる処理」であるのは極力避けねばならず「復号化処理」が存在する限り「復号化処理を解析されてしまい、暗号を解読されてしまうのは避けられない」でしょう。

その為「暗号化アプリしか存在せず、復号化アプリが存在しない。しかし、同一の鍵で暗号化を何度か繰り返すと元に戻り、結果的に復号化した事になる」と言うのがベストな回答です。

例えば「同一の鍵を使って、ある処理を4回繰り返すと、元に戻る」と言う処理を作成し「暗号化時は、その処理を1回行う」「復号化時は、その処理を3回行う」と言うようにします。

処理の繰り返し数は「1回と3回」でも良いし「3回と1回」でも良いし、推測不能な規則に従って「n回と4-n回(nは1~3の可変)」でも構いません。

このようにすると「暗号化と復号化が同じ処理」なため「復号の処理を解析される心配がない」のです。

どのように複雑な暗号を考案しようとも「その暗号を実現する為のアプリケーションソフトを公開しなければ意味がない」ですから「アプリケーションソフトを解析されても暗号が解けてしまわないようにしなければならない」のです。

その「解析されても暗号が解けてしまわない、唯一の方法」が「復号処理が存在しない」と言う方法です。

この回答への補足

つまり完全な復号化ができているかを判定してるわけではないという事です。復号化ができたらしい?・・という判定です。データの完全一致は全て復号した段階で行おうと思っています。

復号データが完全に一致するキー⊂復号データの一部が一致するキー?


あと・・・・。

・パスワードを変更すると、まったく別の結果が得られる
・パスワードを少しだけ変更した際でも、全文が大きく変更されるようにする(類似パスワードで類似した結果が得られると、パスワードの相違点と結果の相違点から、パスワードの各文字がどのような変化をもたらすか推測できてしまう)と言うようにするのが良いです。

この二点に関してはそういう結果の得られるような一方向関数を利用しているのでクリアだと思います。


ただどんなによい関数を使っても、使い方がまずいと全然だめだとおもうんで、色々考えて自己検証してみてるのですが、一つ自分で脆弱性を見つけてしまったんですよね。

考えてみれば全然駄目な実装でした。もはや暗号化ソフトといえないような致命的なものでした。(恐らくソースコードが入手できて、元のデータの一部が512bit単位が推測できれば大部分が復号化できてしまう?)一応、一部いじれば修正可能っぽいんですが、難しくて頭が混乱しそうです。頭が良くないんでパズルをやっているような気分です。

ご回答とても参考になりました。ご回答ありがとうございました

補足日時:2009/10/02 11:57
    • good
    • 0
この回答へのお礼

親切、丁寧なご回答ありがとうございます。

復号化処理と暗号化処理は同一の方がよいのですか。それは知りませんでした。ただ偶然にも難しい復号化処理は行っていなくて、付加情報をつけたり削除したりする以外は復号化処理と暗号化処理は同一のものです。ただし繰り返しは行わず一回のみの処理で戻ります。

一方向アルゴリズムなどの数学的に高度なアルゴリズムは利用させていただいているものの、自分で書いた部分はかなりシンプルなアルゴリズムなので・・。具体的には主に排他的論理和を使ってデータを隠蔽しています。そもそもシンプルで効果的な面白い仕組みだと思ったのがこのソフトを作ろうと思ったきっかけなので。。


一応ユーザとして軍や諜報機関や国家クラスの機密情報を守る層をターゲットにしているわけではなく、一般ユーザの日常的なデータを守り手軽に使える・・という事を想定してるのでデータの復元性やユーザビリティにウェイトを置こうと思っています。ただその中でも暗号化ソフトである以上はそれなりのセキュリティーは一応確保したいなと欲を出しています。(XPのEFSなんかがあるので、いくら使いやすくてもファイルシステムに勝てるとは思わないですけど・・w)やっぱりセキュリティで優位性がないと駄目ですかね・・。別にお金を取ろうとおもってるわけではないのでそこまでは気にしないんですけど・・。でも少しは使ってほしいなとw

>「パスワードが正しいかは調べない」の方がセキュリティーが向上します。「パスワードが正しいかを検証する処理」を解析されれば「正しいパスワードを求める処理」を作られてしまいます。

やはりそうですか。判定方法はフッタの復号化されたバイナリを文字列として扱って特定の文字列が含まれるかで判定しています。考えてみたのですが、

このソフトの復号化の場合、完全に一致する復号化キーが必要で仮に復号化処理を行ってみて、特定の文字列が含まれるキーを探しあてたとしても、完全に一致するわけではないので一応大丈夫かなと思っているのですが実際のところどうなのでしょうか。。。そのようなキーは無数にあると思いますし・・。 

(長いので補足欄に続きます。すみません)

お礼日時:2009/10/02 11:54

>暗号化ソフトを作ってみたんですが復号化できる人いますか?



論理的に言えば「これだけの情報では不可能」です。

もし仮に「暗号化済みデータだと言って与えられたデータが、実は、暗号化してない、平文データと同一だった」とします(つまり、一切、何の加工も施されていないデータ)

この時、解読を試みる側は「実は、暗号化してない、平文データと同一」だと言う事を確かめる術はないのです。言われた通り「暗号化されているのだろう」と思うしかありません。

で、この質問文で与えられた情報のみでは「暗号化されていないデータと、暗号化されたデータが、どのぐらい異なるのか?」つまり「暗号化されていないデータと、暗号化されたデータが、同一なのか、同一でないのか?」を判断する事が出来ません。

「一切、加工を施されてない生データを提示されて『これは暗号化されているから、解いてみて』と言われても、その嘘を見破れない」のです。

このように「出題者の嘘を見破る事が出来ない状況」では「本当に暗号化されているのか、はたまた、実は暗号化も何も施されていない生データなのか、見分ける事が出来ない」ので「仮に暗号化されていたとしても、それを、暗号化されている物として認識する事が出来ない」のです。

また「ランダムに並べられた、意味の無い英数字の列」を提示され「これは暗号文です。解いてみて」と言われても「意味の無い英数字の列だと見抜けない」でしょう。

それと同じで、質問者さんの提示した暗号データも「暗号化データなのか、意味の無いランダムなデータなのか、区別のしようがない」のです。

従って、結論として「提示されたデータが、暗号化データなのか、生の未暗号化データなのか、ランダムな無意味なデータなのか、確かめる術が無いので、暗号を解く以前の問題であり、暗号を解く事が出来ない」と言う事になります。

本当に「暗号が解けるかどうか検証して欲しい」ならば、最低限
・暗号化データを与える
・与えたデータの詳細を提示する
・与えたデータを復号化出来た場合の詳細を提示する
必要があります。

例えば
「暗号化したデータは以下の通りです(と記述してデータを提示する)」
「暗号化したデータは、とある形式(画像の形式は伏せます)の画像データで、64×64ピクセルの24ビットフルカラー画像です」
「うまく復号化出来た場合、添付画像の『赤い花の画像』が出てきます」
などのように「手掛かりとなる情報」を与えて下さい。

貴方がやった事は「スペイン語がまったく判らない人に、スペイン語で話しかけるようなもの」で、相手は、貴方の口から出た音を聞いても「音」としては認識しますが「言語」として認識できず「単なる雑音」にしか聞こえません。最低限の手掛かりとして「これはスペイン語である」と言う情報が必要です。

この回答への補足

長文のご返信ありがとうございます。ご指摘ごもっともと思います。なので少し情報を捕捉させていただきます。

・暗号化データを与える
 既に質問文章にあるのでクリアですね

・与えたデータの詳細を提示する
上の暗号化されたデータのMD5値は23DDD53B188B1AEA135E744876274E80であるテキストデータが暗号化されたものです。512Byteの固定長の先頭位置変動式フッターデータがファイルの語尾に暗号化された状態でついています。

フッターの位置可変とは、フッター自体の位置は計算可能(語尾512Byte)なのですが、その中で意味のあるデータの先頭の位置が可変で、例えば、51Byte目から意味のあるフッターのデータが始まるとしたら、それ以前の50Byteは無意味なランダムデータで埋められるという意味です。また意味のあるデータの後ろも512Byteに併せる形でランダムに埋められます。この暗号化フッターには元のファイルの詳細データなどが入れてあります。

なので復号化の後に語尾の512Byteは無視してMD5を計算してください


・与えたデータを復号化出来た場合の詳細を提示する

SHIftJIS + CR + LF 形式のテキストデータです。暗号化フッター部分(512Byte)をとりのぞいた未暗号データのMD5は「54B1BC6C78A52293B2DE23A7278E8524」になります。動物系アスキーアートテキストが書かれています。語尾の512Byteは無視して計算してください。


・・なんだか、これだけの情報でも無理そうですね。そもそもどんな処理で暗号化されたものなのかわからなければ・・。あとは処理の方式(ソースコード)さえわかればクラックする、とっかかりはつかめるといったところでしょうか・・。それがわからなければ無理・・でしょうか?すみません。下手な質問で・・。脆弱性とか検証してもらうならソースは必須ですよね・・。

もしこのソフトを配布するとなるとソースは、頑張れば復元可能なのでとっかかりはそろってしまうと思うのですけど・・・。


ファイルになるべく、どのソフトで暗号化したものかヘッダーなどの情報をつけないようにした方が、暗号化データとしてはセキュリティーは高いと思うのですが、利便性とトレードオフになるのでつけようと思っています。・・むしろ、もうつけたのですが・・。

それと一応、質問文のデータには余分な生(未暗号)のヘッダーなどの情報はつけてません。・・懸賞金などのメリットも一切ついてないのに、こんな面倒なクラックコンテストみたいな質問なんて挑戦してくれる方はいないかもしれませんね・・。

質問とはまた少し違った追加質問的になってしまいますが、関連する質問なのでお聞きしたいのですが、この上に書いた処理方式でセキュリティー的に気になる点お気づきの点などございましたら教えてください。

ご指摘及び丁寧な解説ありがとうございました!

補足日時:2009/09/30 14:08
    • good
    • 0
この回答へのお礼

あと処理について気になった点なのですけど、このソフトではまず最初にフッタ部分を復号化して、正確に復号できたかを調べて、パスワードが正しいかを検証しその後に復号化処理を行うのですが、これは脆弱性につながるでしょうか?


たとえば虹や辞書などでクラックする場合最初にこの計算ができてしまうと高速に成否判定ができてしまうのであまりよくないらしい事は私にも推測できるのですけど、

全てのデータを復号化の後に成功か否かを検証するとどうしても間違って入力した場合にファイルサイズが大きい場合に特に、ユーザーのコストが増大してしまうと思うのでこのような仕様で実装しようと考えたのですけど、なにか他にいいアイデアはあるのでしょうか。



今のところ辞書対策として暗号化用の初期値の計算に一方向関数の出力結果をまたかけてって感じで繰り返しつかって数秒かかるようにしようと思ってるのですが・・。一方向関数の結果の衝突の可能性を考えるとこれも脆弱に繋がるのでしょうか?結果が512Bitの関数を使うので衝突の可能性はそんなに高くない気もしてるのですけど・・。

計算した最終初期値と衝突するものを探せばよいので、これはまったくの無意味ですか?まったくの暗号素人が暗号化ソフトをつくってるので色々と分からなくて・・。いっぱい質問してしまってすみません。

お礼日時:2009/09/30 14:54

・答えられるわけがない


・どんな答えでも正解
のどちらがお好みですか?
    • good
    • 0
この回答へのお礼

そうですね。質問に不備があったようでした

ご返信ありがとうございました!

また機会がございましたらよろしくお願いいたします。

お礼日時:2009/09/30 13:33

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!