復号化について – プログラミング – Home

通知
すべてクリア

[解決済] 復号化について

固定ページ 1 / 2

GG
 GG
(@GG)
ゲスト
結合: 18年前
投稿: 185
Topic starter  

いつもお世話になっています、GGです。

前回の質問(文字列のバイナリ化)を続けてします。
すみません、新たに問題が出ました。

復号化の質問です。

暗号化後保存しました。プログラムを閉じします。
再びプログラムを起動します。
問題:
復号化するときに乱数の発生(randValue[ra_i])は暗号化するときにと違っています、
暗号化randValue[ra_i])!= 復号化(randValue[ra_i])
つまり、
復号化するときに暗号化と同じ乱数を得るのは、どうしたらいいでしょうか。

よろしくお願いします。


引用未解決
トピックタグ
επιστημη
 επιστημη
(@επιστημη)
ゲスト
結合: 22年前
投稿: 1301
 

暗号化時にどんな乱数でかき混ぜたのか(乱数の種)を
どこかに残しておくしかないんじゃないすか?
たとえばファイルの先頭だとか。


返信引用
GG
 GG
(@GG)
ゲスト
結合: 18年前
投稿: 185
Topic starter  

επιστημη さん
ご返事ありがとう.

>暗号化時にどんな乱数でかき混ぜたのか(乱数の種)を
>どこかに残しておくしかないんじゃないすか?
>たとえばファイルの先頭だとか。

”乱数の種”というのは、srand(seed);
にseedの値ですね、
例:
seed=50;
srand(seed);

seedをファイルに埋め込みます。読む時に先にこの数値を
読んで乱数を作成するということですね。
一つの問題があります、
OSが変わっている場合はその乱数が変わっていないでしょうか。
(OSはVistar、XP、2000など、各バージョン)

よろしくお願いします。


返信引用
επιστημη
 επιστημη
(@επιστημη)
ゲスト
結合: 22年前
投稿: 1301
 

それが気になるなら乱数生成ルーチンを自作するがいい。


返信引用
たいちう
 たいちう
(@たいちう)
ゲスト
結合: 23年前
投稿: 662
 

> OSが変わっている場合はその乱数が変わっていないでしょうか。
> (OSはVistar、XP、2000など、各バージョン)

コンパイラのバージョンやコンパイルオプションによると思う。
OSによっては多分変わらないと思うが、実装が公開されていない関数では、
OSによって変わることもありうる。

乱数の種だけを保存して復号しようというのは、
ごく限定的な場合を除いてやるべきではないでしょう。


返信引用
オレンジフィッシュ
 オレンジフィッシュ
(@オレンジフィッシュ)
ゲスト
結合: 18年前
投稿: 58
 

前回の 2007/07/14(土) 21:37:42 で

>※RnadInit()、Rand() は自分で用意して下さい。
>※標準ライブラリの srand()、rand() でも良いですが処理系を変えてしまうと
> 復元出来なくなるかもしれない。バージョンによっても出来なくなるので自作すべ
> し。

と注意書きを残していたのに…。
記憶に残らなかったのね。残念。


返信引用
GG
 GG
(@GG)
ゲスト
結合: 18年前
投稿: 185
Topic starter  

επιστημη さん、たいちうさん、オレンジフィッシュさん
ご返事ありがとう.

>それが気になるなら乱数生成ルーチンを自作するがいい。

自作乱数をできました。乱数発生の初期値(種)をファイルに書き込みました。
復号もうまくできました。

>と注意書きを残していたのに…。
>記憶に残らなかったのね。残念。

当時はその問題が考えていないです。すみませんでした。

>乱数の種だけを保存して復号しようというのは、
>ごく限定的な場合を除いてやるべきではないでしょう。

どういう意味でしょうか、
初期値(種)をファイルの頭部に保存したのですが、
それがよくないということでしょうか。

よろしくお願いします。


返信引用
たいちう
 たいちう
(@たいちう)
ゲスト
結合: 23年前
投稿: 662
 

> どういう意味でしょうか、
> 初期値(種)をファイルの頭部に保存したのですが、
> それがよくないということでしょうか。

コンパイラの用意したrand()関数は、プログラマにとっては
ブラックボックスです。同じ種から同じ乱数列が発生されることは
保証されていません。

同じバージョンのコンパイラで、同じコンパイルオプションなら、
多分、同じ乱数列が得られると(私は)思うので、多分、種と暗号化した
データだけの保存でも、多分、復号できると(私は)思います。

「多分」が気にならなければ、そのままで良いですし、
気になるなら自前のrand()関数を作って、同じ種から同じ乱数列
が得られることを自分で保証してください。
私なら自作します。


返信引用
GG
 GG
(@GG)
ゲスト
結合: 18年前
投稿: 185
Topic starter  

たいちうさん、
ご返事ありがとう.

>コンパイラの用意したrand()関数は、プログラマにとっては

>私なら自作します。
わかりました。

今回の自作乱数はrand()を使わないで、

rndnum=(rndnum*109+1021)%255;
ということです。

次に、解読の問題ですが、いつか不明点があります。

>麩 2007/07/15(日) 16:08:21
>1、乱数列を毎回変更する
>2、構造体の保存順序を毎回乱す。

以上は、一回暗号化一回復号ということですが、
もし、2回暗号化にして、2回復号にするということにすれば、
解読は難しくなるでしょうか。
(やったことがないので、推測)

もう一点は、dllなどファイルはどう暗号化しているのでしょうか、
(解読が不可能に近くなっている)

よろしくお願いします。


返信引用
たいちう
 たいちう
(@たいちう)
ゲスト
結合: 23年前
投稿: 662
 

> 以上は、一回暗号化一回復号ということですが、
> もし、2回暗号化にして、2回復号にするということにすれば、
> 解読は難しくなるでしょうか。
> (やったことがないので、推測)

どのような暗号化を考えているのかわかりませんが、
シーザー暗号の類だったら回数は多分無意味。
そうでなければ、少しだけ有効。

前のスレでも皆さん書いていますが、
小手先の暗号化は簡単に解読されると考えた方が良いでしょう。
気休め以上のものを求めているならば、こんなところで
質問しても無駄です。そのような技術は商品ですから。

> もう一点は、dllなどファイルはどう暗号化しているのでしょうか、
> (解読が不可能に近くなっている)

ソースファイルが暗号化されてexeやdllになっているわけでは
ありませんよ。コンパイルされてexeやdllになっているのですよ。
それともUPXのような話?


返信引用
tetrapod
 tetrapod
(@tetrapod)
ゲスト
結合: 21年前
投稿: 830
 

> 解読は難しくなるでしょうか。
この辺はコストパフォーマンスの問題にすぎない。
暗号・難読化の処理を複雑に行うにはそれなりのコストがかかる。
素人考えの処理をいくら施しても、技術ある人間がその気になったなら
有限時間のうちに解読されうるし、
ごく単純な処理であっても、分析の意欲・興味をそらす程度には有効かもしれない。
ビットを1/0反転するだけでも十分という意見は既に出てたよね。

# 無線 LAN のただ乗りを考えてみればいい。
# WEP 暗号は解読できるとされているが、解読の手間をかけるくらいならば
# 単純に場所を移動して無暗号なアクセスポイントを探すほうが手間がかからない。

その辺興味あれば 3DES とか obfuscator とか調べてみるといいだろうね。


返信引用
GG
 GG
(@GG)
ゲスト
結合: 18年前
投稿: 185
Topic starter  

たいちうさん、tetrapodさん
ご返事ありがとう.

暗号化と復号化に関するの知識は足りないですが、
皆さんのご意見を聞きながら、あー、あるほど、
丸で別の世界気がします。

結論としては、難読化程度しかないですね。
(次にやる気がないです。)
仕方ない、この程度でやめます。

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


返信引用
ITO
 ITO
(@ITO)
ゲスト
結合: 22年前
投稿: 1235
 

 暗号化で調べてみるとフリー・パッケージ等
いろいろなツールがあるみたいです。
 調べてみるのもいいと思います。

# DLLで提供しているのもありました。


返信引用
yoh2
 yoh2
(@yoh2)
ゲスト
結合: 18年前
投稿: 70
 

ふと気になったことが。

と、その前にリンク。
前スレ: 「文字列のバイナリ化」
http://rararahp.cool.ne.jp/cgi-bin/lng/vc/vclng.cgi?print+200707/07070018.txt

今までの話の流れ(前スレも含めて)から、GGさんが行いたいことは、

1. 暗号化されるもの:
アプリケーションが入出力するファイル。(*ファイルフォーマット*を知られたくない)

2. 暗号化を行う主体(=秘密鍵を決める者)
アプリケーションの作者。(GGさん?)

3. 誰に対して復号を許可するか:
アプリケーションのユーザー。

4. 避けたいこと:
アプリケーションを使わずにファイルが読み書きされること。
たとえアプリケーションのユーザーだとしても、アプリケーションを介さずに読み書きされたくない。

5. その他:
暗号化/復号部分は、実行ファイルやDLLなどの形でユーザーの手元にある。(?)

だと思っていましたが、これでよろしいのでしょうか。
現在の、暗号化を行うことに否定的な話の流れは、GGさんの目的が上記の通りだ、ということが前提になっ
ています。
# 5が成立しないなら、まだ可能性はあるかも。

もしそうではなく、

1'. 暗号化されるもの:
アプリケーションが入出力するファイル。(ファイルに書かれている*内容*を知られたくない)

2'. 暗号化を行う主体(=秘密鍵を決める者)
アプリケーションのユーザー。

3'. 誰に対して復号を許可するか:
アプリケーションのユーザーと、ユーザーが許可した者。

4'. 避けたいこと:
ユーザーが許可した相手以外にファイルが読み書きされること。
ファイルを暗号化したユーザーがアプリケーションを介さずに読み書きされることは(モラル上、またはラ
イセンス上NGだとしても)セキュリティ上の脅威ではない。

5'. その他:
特に条件はなし。

だとしたら

> 暗号化で調べてみるとフリー・パッケージ等
>いろいろなツールがあるみたいです。

という状況を利用すれば、独自の暗号化を考えるだとか、適当な難読化で済ますなどよりも楽で、しかもよ
り強固な暗号化が実現できます。
逆に、1'~5'ではなく、1~5が正解だとしたら、たとえ強固とされる暗号化アルゴリズムを適用したとし
ても、結局難読化にしかならないのではないか、というのが私の意見。(5が致命的。攻撃者に秘密鍵を知ら
れる可能性大)


返信引用
GG
 GG
(@GG)
ゲスト
結合: 18年前
投稿: 185
Topic starter  

ITOさん、yoh2さん
ご返事ありがとう.

yoh2さんからのコメント:

>1. 暗号化されるもの:
>アプリケーションが入出力するファイル。(*ファイルフォーマット*を知られたくない)

OK

>2. 暗号化を行う主体(=秘密鍵を決める者)
>アプリケーションの作者。(GGさん?)

OK、わたしです。

>3. 誰に対して復号を許可するか:
>アプリケーションのユーザー。

OK、

4. 避けたいこと:
アプリケーションを使わずにファイルが読み書きされること。
たとえアプリケーションのユーザーだとしても、アプリケーションを介さずに読み書きされたく
ない。

OK,そのファイルの一部に個人情報があります。アプリケーション以外は読み書き禁止。
万が一、流失すると解読しにくい。

>5. その他:
>暗号化/復号部分は、実行ファイルやDLLなどの形でユーザーの手元にある。(?)

NO

>5'. その他:
>特に条件はなし。

OK

以上、1,2,3,4、OK; 5.NO;
5’OK;
です。

一番希望したいのは、強固な暗号化。
解読率は20%以下にしたい。(解読プロの方が除外)

よろしくお願いします。


返信引用
固定ページ 1 / 2

返信する

投稿者名

投稿者メールアドレス

タイトル *

プレビュー 0リビジョン 保存しました
共有:
タイトルとURLをコピーしました