ふらっと C#,C♯,C＃（初心者用） Part131 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/09/08(金) 18:12:11.06

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。

他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。

内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。

なお、テンプレが読めない回答者は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください

>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part130
https://mevius.2ch.net/test/read.cgi/tech/1500327645/
■関連スレ
C#, C♯, C＃相談室 Part94 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1492843013/

■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/

■情報源
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/

**デフォルトの名無しさん** · 2017/10/09(月) 14:40:20.42

>>896
トンチンカンなバカレスするお前は初心者以下

**デフォルトの名無しさん** · 2017/10/09(月) 14:52:27.91

>>899
わからないならそう言えば？

**デフォルトの名無しさん** · 2017/10/09(月) 14:58:22.98

>>900
関連スレに2度と来ないでくれ

**デフォルトの名無しさん** · 2017/10/09(月) 15:01:38.21

>>900
じゃあ早く俺のレスに答えて

**デフォルトの名無しさん** · 2017/10/09(月) 15:02:18.20

ID:KtpP5XlM はただの荒らしだろ
もう構うな

**デフォルトの名無しさん** · 2017/10/09(月) 15:02:45.85

>>887
無意味ではないよ
文字列抜き出すのとアルゴリズムの解析とでは
必要な時間が全く違うからね
それこそ難読化の出番

**デフォルトの名無しさん** · 2017/10/09(月) 15:05:23.09

>>890
Aに秘密鍵、Bに公開鍵で。
Aの秘密鍵を守る対策は別途必要

**デフォルトの名無しさん** · 2017/10/09(月) 15:06:38.70

埋め込みでリソース持つのと、外部ファイルで持つのってセキュリティそんなに変わらんでしょ？

**デフォルトの名無しさん** · 2017/10/09(月) 15:07:25.29

そもそも暗号化手順＋暗号キーを知られたくないならまだしも暗号キーをとにかく知られたくないというのが分からない
元の質問者は終了宣言しているし外野が条件変えながら議論しても無意味

**デフォルトの名無しさん** · 2017/10/09(月) 15:09:31.57

暗号化通信の基本もわかってないのにプログラマ名乗っちゃダメだろ君たち

**デフォルトの名無しさん** · 2017/10/09(月) 15:10:52.65

>>908
逃げんな
早く答えろ

**デフォルトの名無しさん** · 2017/10/09(月) 15:15:00.06

>>891
それなんの意味があるんだよ w

**デフォルトの名無しさん** · 2017/10/09(月) 15:18:53.37

公開鍵で暗号化プログラムA
秘密鍵で復号プログラムB
Bの利用者は鍵ペアを生成
外部ファイルとして秘密鍵をプログラムに渡す
公開鍵を通信相手に渡す
終わり

**デフォルトの名無しさん** · 2017/10/09(月) 15:22:46.29

コード書けりゃプログラマじゃないぞ
お前らはC#なんてやっとらんでITパスか基本情報でも取ってこい

**デフォルトの名無しさん** · 2017/10/09(月) 15:29:43.51

そのまえに日本語が書けないと困るな

**デフォルトの名無しさん** · 2017/10/09(月) 15:30:38.86

そういや試験は来週ぐらいか

**デフォルトの名無しさん** · 2017/10/09(月) 15:39:49.40

>>911
だからそれなんの意味があるんだよ w
>>906の意味わかってないのか？

**デフォルトの名無しさん** · 2017/10/09(月) 15:54:47.16

if(HashPasswordForStoringInConfigFile(パスワード, "sha1").ToLower() == ハッシュ文字列)
{/*編集可能処理*/}

って書いてあった

**デフォルトの名無しさん** · 2017/10/09(月) 15:57:26.54

>>916
>>879のデータの暗号化とパスワードの認証は別の話
ハッシュで認証するから元のパスワード持っていなくていいよ、てのはわかるが

**デフォルトの名無しさん** · 2017/10/09(月) 16:04:00.40

認証したいなら個別に別ルートでパスワード発行

ユーザー全員に共通パスワード持たせたいならセキュリティ諦めてリソース持つぐらいで十分
できれば中間にAPI噛ませて何かあった時の被害をコントロールできるようにしておいたほうがいい

**デフォルトの名無しさん** · 2017/10/09(月) 16:39:19.76

>>917
単純にテキストだけの話なの？
バイナリファイル読み込め的な？

**デフォルトの名無しさん** · 2017/10/09(月) 16:39:54.37

以前List<T>オブジェクトをXmlシリアライズ・デシリアライズする拡張メソッドを作ったのですがユーザー定義クラスのときだけ動きません
public static void SaveXml<T>(this List<T> list, string path)
{
T[] xmldata = list.ToArray();

using (FileStream fs = new FileStream(path, FileMode.Create))
{
XmlSerializer xml = new XmlSerializer(typeof(T[]));

xml.Serialize(fs, xmldata);
}
}

こういった感じでList<MyData>型の変数myDataList.SaveXml("D:\hogehoge.xml")と呼ぶとxml.Serialize(fs, xmldata)のところで
System.InvalidOperationExceptionが投げられます。ただのList<string>型の場合投げられません。
どこがまちがっているでしょうか？

**デフォルトの名無しさん** · 2017/10/09(月) 17:09:31.29

とりあえずその投げられた例外をToString()して全部読んでみて

**デフォルトの名無しさん** · 2017/10/09(月) 17:14:46.63

>>911
はあ？
秘密鍵丸見えじゃ無意味って理解出来ないの？

**デフォルトの名無しさん** · 2017/10/09(月) 17:18:01.05

>>922
君は果てしなく馬鹿だね

**デフォルトの名無しさん** · 2017/10/09(月) 17:19:21.84

自分だけはバカじゃないという前提

**デフォルトの名無しさん** · 2017/10/09(月) 17:23:16.60

>>923
違う用途ならともかくこの件においては
データ改変できて無意味

**デフォルトの名無しさん** · 2017/10/09(月) 17:24:22.08

>>925
そうかいじゃあやってみなよ

**デフォルトの名無しさん** · 2017/10/09(月) 17:28:38.64

>>920
型以外の条件を一切変更していないのに（ダメな人は他の条件も変えてたりするから困るw）
TがMyDataの場合だけ例外は発生するのであれば、
普通に考えてMyDataがXMLシリアル化可能な条件を満たしてないんでしょう。

例えばデフォルトコンストラクタがないとかそもそもpublicなクラスじゃないとか。

**デフォルトの名無しさん** · 2017/10/09(月) 17:28:45.97

>>926
は？
間違ったやり方をやるわけないだろバカ

**デフォルトの名無しさん** · 2017/10/09(月) 17:29:14.61

>>928
できないんだね

**デフォルトの名無しさん** · 2017/10/09(月) 17:34:23.08

>>921
できなかったのはコンストラクタ定義していたせいでした、すいません

**デフォルトの名無しさん** · 2017/10/09(月) 17:42:16.72

馬鹿の壁みたいだ

初心者のためにかくと
公開鍵は暗号化する鍵で誰にみせてもいい
秘密鍵は暗号を解く鍵でみせてはいけない

B利用者は自分のための公開鍵と秘密鍵を作る
作った秘密鍵をプログラムBに渡す

公開鍵は誰にでも渡してプログラムAで鍵をかけてもらったものを送ってもらう

B利用者は送られたものをプログラムBで鍵を解く

送った内容は秘密鍵を持ってないと中身がみえないので安全

**デフォルトの名無しさん** · 2017/10/09(月) 17:47:02.95

命名スレで暴れてた馬鹿おじさん
こんなところにいたのか

**デフォルトの名無しさん** · 2017/10/09(月) 17:48:41.75

秘密鍵を相手に渡すのは馬鹿の極み
公開鍵は誰に見られてもいいので
難読化とかそういう以前の問題

セキュリティがどうこう言う前に勉強すべき

プログラムBが公開鍵持ってても何の問題ない

**デフォルトの名無しさん** · 2017/10/09(月) 17:49:44.10

お互いにバカバカいっててレベル低い系？

**デフォルトの名無しさん** · 2017/10/09(月) 17:50:42.44

>>929
アスペか？日本語すら出来ないバカは死んでろ
生きてる価値も意味も皆無だから

**デフォルトの名無しさん** · 2017/10/09(月) 17:51:09.22

馬鹿は馬鹿同士でお互いにバカにしあっていればいい
俺は横から初心者のために解説してるだけ

**デフォルトの名無しさん** · 2017/10/09(月) 17:51:40.46

>>935
鏡に語りかけてる
やばいやつだこいつ

**デフォルトの名無しさん** · 2017/10/09(月) 17:51:44.57

実にどうでもいい話だけど、元の質問者のケースは別人の間の通信ではないので、
公開非公開の区別の意味はないね。

この分野全然知らんけど、サーバーに復号化のための情報を置いたら安全って発想は
ちょっと理解できんなあ。

それってハッキングする側から見たら、単にサーバーの認証を突破するひと手間が
増えただけの話じゃないの？

**デフォルトの名無しさん** · 2017/10/09(月) 17:52:50.89

争いは同レベル同士で起こるとはよく言ったものだ

**デフォルトの名無しさん** · 2017/10/09(月) 17:54:11.26

>>938
多分適当にググれば10分ぐらいで何を言ってるかわかるよ

**デフォルトの名無しさん** · 2017/10/09(月) 17:55:23.10

>>933
ユーザーに改変されたくないデータをやり取りする場合そのやり方だと無意味

**デフォルトの名無しさん** · 2017/10/09(月) 17:56:26.56

うっわ無知な馬鹿に絡まれた
最悪・・・

無知でも考えれば何とか答えが出るのに…

**デフォルトの名無しさん** · 2017/10/09(月) 17:56:55.32

>>937
バカはセキュリティ意識がないんだな

**デフォルトの名無しさん** · 2017/10/09(月) 17:58:13.55

>>942
答えられないの？

**デフォルトの名無しさん** · 2017/10/09(月) 17:58:55.36

>>938
最初から読めばファイル配布の稚拙なシステム作ろうとして注意されたのが分かる
多分本人は問題の本質に気付いていない
そしてこの問題はC#以前の話

**デフォルトの名無しさん** · 2017/10/09(月) 17:59:02.92

人間の基本行動原理

自分だけはバカじゃないという前提
自分だけは誰よりも常に正しいという前提

**デフォルトの名無しさん** · 2017/10/09(月) 18:04:39.80

パブリックキーで暗号＆復号化するのはパケットの話
サーバに収めるデータやDBは別

**デフォルトの名無しさん** · 2017/10/09(月) 18:08:41.86

>>938
そうじゃなくてサーバーに復号化の情報を置くのではなくサーバーで復号化させるってこと
A-B間で直接やり取りできるなら別にサーバーじゃなくてもいい

どうでもいいけど質問者の案件の詳細がわからない限りこれ以上の言い争いは不毛だぞ

**デフォルトの名無しさん** · 2017/10/09(月) 18:11:27.11

サーバーで復号したものを安全にBに持ってくるにはまた暗号化が必要なんでは？

**デフォルトの名無しさん** · 2017/10/09(月) 18:12:13.10

ようやく自分の誤りに気づき終息させようとするの術

その前に嵐扱いした人に謝ったほうがいいんじゃないかなｗ

**デフォルトの名無しさん** · 2017/10/09(月) 18:14:40.29

>>949
一時的な暗号鍵を使う
その鍵は保存されないしユーザーにはわからない

**デフォルトの名無しさん** · 2017/10/09(月) 18:17:25.45

>>950
俺に言ってるのかな？何も間違ったことは言ってないけど

**デフォルトの名無しさん** · 2017/10/09(月) 18:18:49.58

>>952

>>911の手法は少なくとも正しい

**デフォルトの名無しさん** · 2017/10/09(月) 18:19:37.05

情報小出しにして質問する→勝手な憶測で返す→条件無視の議論に発展
このコンボやめてくれ

**デフォルトの名無しさん** · 2017/10/09(月) 18:20:42.30

いつまで続けんの？

**デフォルトの名無しさん** · 2017/10/09(月) 18:20:54.51

>>953
ユーザーが改変できるってさっきから指摘してるんたが？
逃げずにはやく答えてみろよ？

**デフォルトの名無しさん** · 2017/10/09(月) 18:22:18.03

実にくだらない

**デフォルトの名無しさん** · 2017/10/09(月) 18:24:21.88

>>948
要するに、「デコーダー」側がハッカーと正規ユーザーを区別できなきゃ安全でも何でもないよね

**デフォルトの名無しさん** · 2017/10/09(月) 18:24:23.29

>>956
まだ気づいてないのか？

よーく考えてみたら？
条件というか設定が間違ってる

それはBからAに送信するときの暗号化の話だから問題が逆
それにユーザーがコード改変して暗号化前に情報変えるのは無関係だろ

**デフォルトの名無しさん** · 2017/10/09(月) 18:25:26.98

例えば>>959の文章でいうと

>まだ気づいてないのか？
>
>よーく考えてみたら？

の部分が不要

**デフォルトの名無しさん** · 2017/10/09(月) 18:32:17.71

>>959
気付いてないのはお前の方だろバカ
ユーザーの元に秘密鍵があれば改変したデータを作って利用できるだろ

**デフォルトの名無しさん** · 2017/10/09(月) 18:34:29.22

>>961
>気付いてないのはお前の方だろバカ
不要

**デフォルトの名無しさん** · 2017/10/09(月) 18:34:41.77

>>951
今度はその一時的な鍵をサーバーとBの間でどうやって安全に交換するかって問題に帰着すると思うが。

**デフォルトの名無しさん** · 2017/10/09(月) 18:36:12.76

>>958
全然要されてない
要するなら利用者がハッカーだとしてもこのやり方なら安全ってこと

**デフォルトの名無しさん** · 2017/10/09(月) 18:37:34.88

やっぱり馬鹿の壁だな
理解できない相手に正論を言っても無駄

**デフォルトの名無しさん** · 2017/10/09(月) 18:37:45.93

>>961
> 気付いてないのはお前の方だろバカ
お前だよ w

> ユーザーの元に秘密鍵があれば改変したデータを作って利用できるだろ
ちゃんと質問者のレス読めよ
>>890
> アプリAで暗号化、アプリBで復号化、他者はBしか持っていないという状況

**デフォルトの名無しさん** · 2017/10/09(月) 18:38:21.65

今日の赤ＩＤは全部ＮＧで問題ない

**デフォルトの名無しさん** · 2017/10/09(月) 18:38:55.70

>>963
公開鍵を使うに決まってるだろ・・・

**デフォルトの名無しさん** · 2017/10/09(月) 18:39:34.24

>>965
>やっぱり馬鹿の壁だな
>理解できない相手に正論を言っても無駄

不要

**デフォルトの名無しさん** · 2017/10/09(月) 18:40:11.30

公開鍵と秘密鍵についてよくわかってないのが多いな

httpsじゃダメだって言うんだろうな
怖い怖い

**デフォルトの名無しさん** · 2017/10/09(月) 18:41:35.96

>>938
同じ鍵で解読できる暗号が2種類あった場合、利用者に複合鍵を渡すと両方解読されてしまう
サーバーで複合すればユーザー情報に基づいてひとつだけ解読可能みたいなこともできる

あと、ローカルでの解読と違ってサーバーに不正アクセスするのは犯罪になるという障壁もある

**デフォルトの名無しさん** · 2017/10/09(月) 18:42:38.62

>>966
はあ？
他者がBを持ってそのBに秘密鍵を置くなんてもってのほかだぞ？お前もバカか

**デフォルトの名無しさん** · 2017/10/09(月) 18:43:23.56

>>972
>はあ？
>お前もバカか

不要

**デフォルトの名無しさん** · 2017/10/09(月) 18:43:57.77

>>964
安全じゃないでしょう。
質問者のケースの場合、暗号化されたデータをハッカーは利用可能。
要するに>>938

**デフォルトの名無しさん** · 2017/10/09(月) 18:44:02.73

>>972
>>911を100回読めばいいよ

B側の秘密鍵は利用者ごとに作るんだよ…

**デフォルトの名無しさん** · 2017/10/09(月) 18:44:41.48

>>970
お前のようなバカはブラウザに秘密鍵があるんだな
怖すぎ

**デフォルトの名無しさん** · 2017/10/09(月) 18:45:48.40

>>976
>お前のようなバカは

不要

**デフォルトの名無しさん** · 2017/10/09(月) 18:46:10.47

頭のおかしな人のふりをして逃げ切るの術がはじまったのかよ

**デフォルトの名無しさん** · 2017/10/09(月) 18:46:34.09

>>975
>100回

不要

**デフォルトの名無しさん** · 2017/10/09(月) 18:46:51.21

>>978
>頭のおかしな人のふりをして逃げ切るの術がはじまったのかよ

不要

**デフォルトの名無しさん** · 2017/10/09(月) 18:47:42.62

>>974
全然違うって
> この分野全然知らんけど
知らないなら理解しよう

**デフォルトの名無しさん** · 2017/10/09(月) 18:48:15.79

>>968
それじゃサーバー=Aと本質的に変わってなくて単に余計な経路を追加しただけ。

**デフォルトの名無しさん** · 2017/10/09(月) 18:51:07.76

仕組み

サーバとクライアントで別々の鍵ペア（秘密鍵、公開鍵）を作ってお互いに
公開鍵を渡す
ネットを通すときは相手からもらった公開鍵で暗号化
受け取った側は自分の秘密鍵で解読

秘密鍵はネットを通らないので間で傍受されても普通は暗号解読不能

**デフォルトの名無しさん** · 2017/10/09(月) 18:51:39.28

>>982
Aと他者が使うBが常時やり取りできるならサーバーである必要もないとは言ってるし
そもそも安全な暗号化する鍵の保存についての答えだが

**デフォルトの名無しさん** · 2017/10/09(月) 18:53:53.42

>>975
だから利用者側に秘密鍵があれば利用者が改変したデータを作れてしまうだろ
まだ理解出来ないの？？

**デフォルトの名無しさん** · 2017/10/09(月) 18:55:21.55

>>985
>まだ理解出来ないの？？

議論に不要な記述

**デフォルトの名無しさん** · 2017/10/09(月) 18:55:41.00

>>985
秘密鍵関係なく暗号化前のデータを変えれば意味ないでしょって言ってるんだけど

暗号化したらユーザーがデータを変えられないと思ってるなら間違い

**デフォルトの名無しさん** · 2017/10/09(月) 18:58:23.22

つかれた
秘密鍵は何度も言ってるけど暗号解除のための鍵

プログラムBが秘密カギを持ってるとするとプログラムAからのデータを受け取るときの
暗号解除のため
だからユーザーがデータを書き換えるとかそういうのは違う

**デフォルトの名無しさん** · 2017/10/09(月) 18:58:38.89

うーん、繰り返しになるけど、質問者のケースは別人の間の通信じゃないので鍵をペアにする意味なんかないですよw

問題はどうやったら正規ユーザーだけが利用できる「復号化装置」を確保きるかって話。

「復号化装置」を外だししたら安全だって話は普通に正しくないでしょう。
そんなのハッキングする側から見たら「ほんのひと手間」増えるだけ。