5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

■暗号化スレ■

1 :低速たん:01/10/11 03:02
データの暗号化技術に関するスレ。
ム板らしくコードを交えながらマターリと。
RSAスレは一つあるようなので、主にそれ以外の話題で。

とりあえず俺の足りない頭のフル回転手伝って〜。

2 :デフォルトの名無しさん:01/10/11 03:07
とりあえず姉妹スレ

突然のの事故などで死んだとき・・・
http://yasai.2ch.net/test/read.cgi/win/983975912/

ネタスレっぽいけどところどころまじめ。

3 :低速たん:01/10/11 03:07
ネタフリしまっす。

インターネット上を通過させるデータの暗号化をしたいけど、
SSLは低速、おおげさ、etc.. だからイヤンって人は俺以外
にもいるんじゃないかと予想。
公開鍵暗号を使わないでデータを安全に運ぶ各種方法キボン。

とりあえず、俺が考えているのは次のようなの。

HostA(server) -- internet -- HostB(client)

という環境で、まず B が A に username/password を
送りつけて認証を受け(*1)、そのあと B が A にバシバシ
データを投げるようなアプリケーションを考えていて、
その投げるデータを暗号化して保護したいと思ってます(*2)。
なお、password(以下P)は、あらかじめ安全な方法でBの手元
に届いています。

(*1)では、APOPのようなチャレンジ&レスポンス方式を用いて
認証を行い(よって P は平文では流れない)、(*2)では鍵に P
をそのまま使った共通鍵暗号でお互いにデータを暗号化しようと
思ってます。

アルゴリズムは、前者はSHA1、後者は3DESかAES(Rijndael)を
考えてます。

でー、とりあえず質問。この方法はDQN?

・根本的に危うい。すぐ破られるぞ秋厨
・素直にSSL
・もっとよい方法/アルゴリズムがある
・そういうことをする為のソフトウェアが既にある

ほかダメ出しきぼーん。
俺暗号弱いので、やさしくしてください。

4 :デフォルトの名無しさん:01/10/11 03:08
量子暗号がいまいちわからん。
「観測が粒子に影響をおよぼすので、盗聴されると分かる」
とかなんとか言っているが。
良い解説ページがあったら教えて。

5 :低速たん:01/10/11 03:11
ども>>2

もいっこ。

AESの実装って
http://csrc.nist.gov/encryption/aes/rijndael/
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/
http://fp.gladman.plus.com/cryptography_technology/rijndael/
とかsourceforgeなんかに結構あるけど、どれがイケてん(枯れてる
とか速いとか)の?

6 :デフォルトの名無しさん:01/10/11 06:36
optimized C reference ver 3 は良いコードだよ
P5,MMX,SSE で高速化したバージョンもあるけど
ISO C じゃないので面倒くさい(nasm要るし)
twofishよりはコードが素直でいじりやすいね

7 :デフォルトの名無しさん:01/10/11 06:51
え!低速かよ!なにがってアレだよ、アレ。例の。
だけど>>1もよくやるよね。こんなに不景気なのに。
戦争とか起きちゃってる時世にさ。おかまいなしだから困っちゃうよ、俺。
まぁ、ブッシュもいろいろ大変だけどさ、日本もそれなりに大変なわけなのよ。
小泉総理。これがまたアイドルみたいな扱いされちゃって。おまけに調子に乗って
息子さん、俳優になってるし。まぁ、あの類はすぐに人気がなくなるんだけどね。「孝太郎?誰だ、そりゃ」みたいに。
もう時間がないから、おれ行くけどさ、これだけは覚えといて。

「糞スレ立てるな」

8 :デフォルトの名無しさん:01/10/11 07:06
誰か >>7 を decrypt してください。

9 :デフォルトの名無しさん:01/10/11 07:16
え!暗号化かよ!なにがってアレだよ、アレ。例の。
だけど>>8もよくやるよね。こんなに不景気なのに。
戦争とか起きちゃってる時世にさ。おかまいなしだから困っちゃうよ、俺。
まぁ、ブッシュもいろいろ大変だけどさ、日本もそれなりに大変なわけなのよ。
小泉総理。これがまたアイドルみたいな扱いされちゃって。おまけに調子に乗って
息子さん、俳優になってるし。まぁ、あの類はすぐに人気がなくなるんだけどね。「孝太郎?誰だ、そりゃ」みたいに。
もう時間がないから、おれ行くけどさ、これだけは覚えといて。

「糞レスつけるな」

10 :デフォルトの名無しさん:01/10/11 07:16
>>8
おいおい。暗号だよ。

11 :デフォルトの名無しさん:01/10/11 07:38
共通鍵暗号で十分なんじゃないの?
日本の母国USでは、解けない暗号を
禁止する方向だし。

12 :デフォルトの名無しさん:01/10/11 10:22
>>9は decrypt を 暗号化 と思ってるのだろうか?

13 :デフォルトの名無しさん:01/10/11 13:06
もちかかちのなねみちみにてらのちみきちいかいにすなみらしちのちる
せなすらきなすちもなこちみみらのにもにかちかにみちすちね
のらみみちこなみみとんらなとなきなみにてちのちすなんらみいる

14 :デフォルトの名無しさん:01/10/11 13:11
>>12
>>9じゃなくて>>8

15 :8=12:01/10/11 13:47
>>10
>>7って暗号化されてるんじゃないのか?
だから、誰かに decrypt してもらおうかと…。

>>14
ん?

16 :デフォルトの名無しさん:01/10/11 22:04
Zebedeeってクライアントとサーバで秘密の鍵を共有しているのになんでわざわざ
Diffie-Hellmanであらためて鍵交換するのですかね?

17 :デフォルトの名無しさん:01/10/11 23:33
いくら複合化の鍵は秘密にしているとはいえ、
暗号化の鍵を公開していたら意味無いじゃん。
どうしてこんな簡単なことに気づかないの?
みんな騙されてるんじゃない?

18 :デフォルトの名無しさん:01/10/11 23:35
>>17
秘密にしてるのは復号化キーの方だから、問題ないです。
複合化キーは確かにまずいかもね。

19 : :01/10/11 23:36
複合→復元では?
それとも私の知らない言葉?

20 :デフォルトの名無しさん:01/10/11 23:42
じゃ、公開鍵も秘密にする。
特定の人にこっそり渡す。

21 :デフォルトの名無しさん:01/10/12 00:48
>>19
復号のことでしょ?

22 :低速たん:01/10/12 01:06
帰宅してみればマタリと荒れてますな。

>>6
ありがとうございます。さっそくいじってみます。

>>16
よくわかんない(自信ない)から、>>3のやりかたは捨ててzebedeeの
ソノ部分を流用させてもらおっかなーと思ったり思わなかったり。GPL
だっけ?

23 :衒学:01/10/12 01:46
「暗号化」の逆は「復号」です。
「暗号」の逆は「平文」。

24 :デフォルトの名無しさん:01/10/12 02:09
暗号の逆が平文?
ほんと?暗号文じゃなくて?

ところで、りじんでーるってどんなもんなの?
今一番お薦めのブロック暗号って何?

25 :デフォルトの名無しさん:01/10/12 02:21
>>24
http://www.zdnet.co.jp/news/0010/03/rijndeal.html

26 :デフォルトの名無しさん:01/10/12 02:45
MISTYのコード手に入ったんだけど、これって
使えるのかな?性能的にも特許的にも。

27 :デフォルトの名無しさん:01/10/12 02:48
GPLだと思われ >>22

28 :デフォルトの名無しさん:01/10/12 07:25
>>24
どうして「暗号」の逆が「暗号文」?
理由を言ってみてよ。

29 :デフォルトの名無しさん:01/10/12 07:32
>>23、24
暗号の逆は復号
暗号文の逆は平文

30 :デフォルトの名無しさん:01/10/12 07:33
>>28
たぶん24は
「ほんと? "暗号文"の逆が平文なんじゃなくて?」
といいたかったのでしょう。

31 :30:01/10/12 07:34
かぶった・・よねコレ? 鬱。

32 :デフォルトの名無しさん:01/10/12 10:30
>>4
それ、漁師コンピュータの話じゃないのか・・?
少なくとも量子力学では対象の状態変化無しには対象の観測は不可能だとしている
から、学問的な話じゃないか?

33 :デフォルトの名無しさん:01/10/12 11:05
量子コンピュータとは別で、通信路の話だと思いますよ

思いっきり乱暴に言うと光子1個まで信号を弱くすれば受信出来るのは一人だけっていう原理

34 :いいかげんな話:01/10/12 11:44
なんだったかな…。
ある粒子を二つに割れて、双方の挙動が全く対象的になるような現象があるらしくて、
片方の粒子を測定した瞬間に、反対側の粒子が消滅するという現象があるらしい。

で、その粒子を暗合として使えば、一種の公開鍵暗合として使えて、
しかも相手が読んだことを瞬時に知ることが出来る…

というような話だったと思うような思わないような…。

35 :プログラマー名無したん:01/10/12 12:49
>>3
ネタスレっぽいがマジレスしてみる。

それって、
(1) AからBにAの公開鍵を送りつける
(2) BはAの公開鍵を使ってセッション内で使いたい共通暗号鍵(セッション毎に毎回作り直す)をAの公開鍵で暗号化して送る
(3) 以後AとBの通信はBが作った共通暗号鍵で通信する
と同じことじゃない?

あと、ユーザのパスワードを共通暗号鍵に使うのは、ユーザがパスワ
ードを短い間隔で変更するのならともかく、どう頑張っても人間の記憶
の都合で短くても数ヶ月のスパンだろうから、一回でもパスワードが解
読されてしまえば次に変更が行われると期待される数ヶ月の間は常に
通信が解読されっぱなしになると思う。下手すればユーザが意図的に
「パスワード無し」にする人が居ないとも限らないし。

そうすると上であげたように、共通暗号鍵はセッション毎に作り直す形
態のほうがユーザへの負荷も少なく、かつ機密性が保たれる(もしも
共通暗号鍵が解析されても、次にセッションを張り直すときには共通
暗号鍵が変わるから)はず。

さらにいうと、確かに公開鍵/機密鍵対暗号はあまりに負荷が大き
いけど、今から仕様決めすると考えれば、それが実現(プログラムを
作って)する頃には公開鍵/機密鍵対暗号をしても大して問題にな
らないほどプロセッサの性能が上がってるような気がするけど(今も
既にそうだし)。

要は鍵対暗号のデメリットは各コンピュータのプロセッサへの負荷な
んで、今販売されてる標準的なPCをターゲットにするなら、Celeron
800MHzくらいだろうから、それを想定しても公開鍵/機密鍵対暗号
で大した問題にはならないと思う。

36 :名無したん:01/10/12 12:57
>>4
量子暗号について
http://www.rs.noda.sut.ac.jp/~ohya/study/qcrt.html

37 :デフォルトの名無しさん:01/10/12 13:16
>>34
たしかEPRのパラドックスとかいう名前。検索してみ。
つーか漁師暗号の話はここでやることかい? 物理板のほうがいいんじゃないの?

38 :デフォルトの名無しさん:01/10/12 13:28
while(len--) *p ^= 0x55;

39 :デフォルトの名無しさん:01/10/12 22:12
>>4
ページではないが、サイモン・シン『暗号解読』って本に載ってたよ。

40 :デフォルトの名無しさん:01/10/13 02:45
いま一般に普及している暗号技術って寿命どれくらいなんだ?
量子コンピュータが実現すれば、残らず解読されてそうな気がするんだけど、どう?

41 :デフォルトの名無しさん:01/10/13 02:49
コンピューター暗号+生暗号を組み合わせるのはどぉ?

42 :デフォルトの名無しさん:01/10/13 03:10
生暗号って初めて聞いた。つまりどういうことでしょう

43 :デフォルトの名無しさん:01/10/13 03:30
>>42
まだ生きてるって意味。暗号化する前のデータ。

44 :デフォルトの名無しさん:01/10/13 03:42
>>43
ほー。それって効果があるもんなんでしょうか。
っていうか、復号化するときに困りそうな。。

なんか資料があったら教えて下さい。(^-^;

45 :デフォルトの名無しさん:01/10/14 01:42
>>3

>>35が言ってるように、毎回ユーザのpasswordで暗号化するってのが気になるな。
どんなアルゴリズムを用いてたとしても、同じ暗号鍵を使い続けるってのは、
統計情報とかを使って破られてしまいそうで恐い。

それに、万が一秘密鍵が洩れてしまったときに、tcpdumpなんかで
過去の通信内容を保存されていたりしたら、それらも全て解読されてしまうわけで。
で、こういう状況にも耐えられるようにするには、今のところDiffie-Hellmanを
使って鍵交換するしかない。
# もちろん秘密鍵が洩れたら、以後の通信の安全性はどうやっても守れないが。

まあ、>>3はそこまでの安全性を必要としているわけじゃなさそうだけど、
SSLやsshとかのプロトコルが何故そうなっているかを考えていくと、
単に遅くて嫌だって理由で公開鍵暗号を避けるのはどうかなって思っちゃうな。

46 :デフォルトの名無しさん:01/10/14 01:49
通信内容も、たとえ解読されても意味不明にしておくべき。

昨日、電車で聞いた会話
A 「アナルは?」
B 「送り返してやったよ」
A 「じゃあレベルMだね」
B 「うん」

これも立派な暗号技術のひとつです。

47 :デフォルトの名無しさん:01/10/14 02:19
ナニを送り返したんだか気になる。

48 :デフォルトの名無しさん:01/10/14 02:22
>47
運子では?

49 :3:01/10/14 03:04
>>35,45さん

なるほどなるほど
とても勉強になりました。

>それに、万が一秘密鍵が洩れてしまったときに、tcpdumpなんかで
>過去の通信内容を保存されていたりしたら、それらも全て解読されてしまうわけで。

もうこのへんで完全に納得しました。すべて了解です。
35,45,16ほか皆様どうも!Diffie-Hellmanでイキますわ。

50 :デフォルトの名無しさん:01/10/14 03:32
>>40
量子暗号技術も実現して問題なしといいたいが、
移行期間が問題やね...。

51 :デフォルトの名無しさん:01/10/14 03:55
量子暗号じゃなくて、量子コンピューターですが。
計算量が飛躍的に向上したら、どんな暗号でも
しらみつぶしできるんではないかと。

それに合わせて、鍵長を長くすればよいのかもしれないけれど、
そうなると、今みたいにパスワードを暗記なんかしてられないよなぁ。。

なんてことを思ってみた。

52 :デフォルトの名無しさん:01/10/14 04:04
何通りにも復号できれば、どれが正しいのかわからなくなる。

53 :90:01/10/14 04:15
正しく復元できなければ何をしんじればいいのかわからなくなる______

54 :デフォルトの名無しさん:01/10/14 04:33
総当たりって、復元された文が正しい言葉になるまで、
パスワードとして可能な全ての組み合わせを試すのですよね?

その方法では、
パスワードが複数用意されている場合、
正しいパスワードは分かりません。

55 :デフォルトの名無しさん:01/10/14 04:49
正しくないパスワードってパスワードなの?

56 :デフォルトの名無しさん:01/10/14 05:34
正しくないパスワードを正しいパスワードと思わせるのが味噌なんだなこれが。

57 :デフォルトの名無しさん:01/10/14 06:22
なにも一つの暗号文に複数の平文を持たせるんじゃなくて、
複数の暗号文作っとけばよいのではないかと思ってみたり。

58 :デフォルトの名無しさん:01/10/14 06:24
量子暗号技術って鍵配送くらいしか使いみちがなくない?
どうなの?

59 :45:01/10/14 16:11
>>3
すまん、ここ訂正。
> で、こういう状況にも耐えられるようにするには、今のところDiffie-Hellmanを
> 使って鍵交換するしかない。
ssh1のように公開鍵暗号を使って短時間限りの鍵のペアを用意してやれば
安全に鍵交換できるな。
# まあ、Diffie-Hellmanよりコストがかかるし、別の問題も出てくるから
# 普通は使わないけど。

あと、Diffie-Hellmanだろうと何だろうと、鍵交換をやるときは
MITM攻撃を防ぐためにちゃんと通信相手を認証してやらないとダメ。
で、サーバ側の認証には公開鍵暗号がよく使われるんだけど、
この Diffie-Hellman + 公開鍵暗号 って組合せはssh2プロトコルの
鍵交換のやり方そのものなんだよね。
http://www.ssh.com/tech/archive/secsh/transport.txt
だからOpenSSHのソースを参考にするってのもいいかも。

60 :45:01/10/14 16:34
>>51
量子コンピュータが登場しても、すべての暗号技術が無に帰すわけじゃない。
量子コンピュータ≠非決定性チューリングマシンだから、
手あたり次第の解法しかないNP完全問題なんかは解けないって意見が支配的。
だから、ほとんどの共通鍵暗号も安全だと思っていい。

でも、公開鍵暗号を用いた鍵交換や認証はズタズタになるわけだから
一大事であることには違いないんだけど。

鍵交換の手段としては量子暗号とかも考えられるけど、
現在のインターネット上の通信には使えないしね。

この話題については通信技術板のスレでもやってるので見てちょ。
http://mentai.2ch.net/test/read.cgi/network/981732339/

61 :3:01/10/14 23:50
>>59

>あと、Diffie-Hellmanだろうと何だろうと、鍵交換をやるときは
>MITM攻撃を防ぐためにちゃんと通信相手を認証してやらないとダメ。

これなんですが、
http://www.rtpro.yamaha.co.jp/RT/docs/ipsec/ike.html
の「2. バケツリレー攻撃」を見ると、

> これは、悪意を持った第三者(Bob)が2人の間に入り、TomとMaryに
> なりすますものです。ただし、Bobはgとpの値を知っている必要が
> あります。

とあります。なので、DHで使うp,gが漏れていないという前提でよけ
れば、公開鍵暗号を併用しなくてもOKですか?

すっかりOpenSSLでTLSv1という心境ですが、勉強のためおしえてもら
えるとありがたいです。

62 :デフォルトの名無しさん:01/10/16 13:44
>>6

>optimized C reference ver 3 は良いコードだよ
>P5,MMX,SSE で高速化したバージョンもあるけど
ってどこにあるんでしょうか?

63 :デフォルトの名無しさん:01/10/24 23:55
>> これは、悪意を持った第三者(Bob)が2人の間に入り、TomとMaryに
>> なりすますものです。ただし、Bobはgとpの値を知っている必要が
>> あります。
>
> とあります。なので、DHで使うp,gが漏れていないという前提でよけ
> れば、公開鍵暗号を併用しなくてもOKですか?

普通はp,gを秘密鍵にするようなことはしない。
そもそもp,gの選び方は、鍵交換の安全性に直結するから、
あらかじめ慎重に選んでおいたものだけを用いるのが普通。
Diffie-Hellmanでなりすましを防ぐ方法はいくつかあるけど、
簡単なのは交換した鍵のハッシュ値を(共有)秘密鍵で署名してやる方法。

それはそうと、Diffie-Hellman使う時点でかなり大きな計算量が
必要なんだけど、それでも公開鍵暗号を嫌う理由は?
というか、数多くある暗号方式のそれぞれにメリットとデメリットがあるし、
絶対に安全な通信なんてものは実現不可能なんだから、
どこまでリスクを下げたいのかってのと、それにどのくらいコストを
かけられるのかってのを天秤にかけてやらんとダメよ。

たとえば、共通鍵暗号は高速だけど鍵管理が難しく、公開鍵暗号は
低速だけど鍵管理は共通鍵暗号より楽、というように。
# それこそ、十分な長さのパスワードが用意できて、しかも絶対にそれが
# 洩れないって自信があるのなら、>>3のやり方でもいいし。

64 :3:01/10/25 00:13
解説ありがとうございます>>63

>普通はp,gを秘密鍵にするようなことはしない。
>そもそもp,gの選び方は、鍵交換の安全性に直結するから、
>あらかじめ慎重に選んでおいたものだけを用いるのが普通。
ええと、例えばOpenSSLとか使うと、DH_generate_parameters()
関数で1024bit程度のp(とg)はすぐ作れますが、そうやって作ったp,g
のなかでも安全なのは一部だけだからさらにふるいにかけるのが普通と
いうことでしょうか?

と、
>Diffie-Hellmanでなりすましを防ぐ方法はいくつかあるけど、
>簡単なのは交換した鍵のハッシュ値を(共有)秘密鍵で署名してやる方法。
すみません、ここ、文意が読みとれませんでした。もう少しくわしく
方法を解説していただけませんか?

他のところはごもっともです。検討します。

65 :デフォルトの名無しさん:01/10/25 00:39
ssh2はどうなってんのよ

66 :デフォルトの名無しさん:01/10/25 03:08
どうなってるとは?

21 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)