-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,E71BB607F6613D304DEE82D5B1DEDBFF
データの暗号化技術に関するスレ。ム板らしくコードも交えながらマターリと。
RSA スレは別にあるようなので、主にそれ以外の話題で。
関連スレは
>>2-10 あたり
-----END RSA PRIVATE KEY-----
2
4
6
7
8
9
10!!
思考回路はデバッグ寸前♪
いますぐcore吐きたいよ♪
前スレ927です
選択平文攻撃を対称鍵暗号方式で無視してもよければ
私が考えたアルゴリズムを公開したいと思うのですが・・・
前スレ927の質問↓
対称鍵暗号方式において
対称となる攻撃方法はなにでしょうか?
締め上げ攻撃・ブルーフォース攻撃・既知平文攻撃
などがあるのはわかるのですが、
選択平文攻撃は対称鍵暗号方式では無視してもよいのでしょうか?
> 選択平文攻撃を対称鍵暗号方式で無視してもよければ
> 私が考えたアルゴリズムを公開したいと思うのですが・・・
無視しちゃダメ (差分解読法って知ってる?) だから、公開せんで
よろし。
別に煽ってるわけじゃないんだが、こんなことを聞かなきゃ分から
ない人間が考えた暗号アルゴリズムに意味がある可能性は限りなく
低いので。
♯そもそも、解読者としても一流の人間が検証しながら作ったアル
♯ゴリズム以外は役に立たないものと考えて間違いない。
>1乙
なんかテンプレぽく使われてて恥ずかしいや。
他に関連スレがあったら(この暗号解いてみろ→暗号文貼り付け系は除く)
張っていきましょう
>>12 そのcoreから危険な情報が外部に…
すいません
差分解読と線形解読について解説した
書籍・webサイトを教えていただけませんか?
乱数についても知りたいと思っています。
一応「暗号技術大全」は購入してます。
あと、
「基本算法/基礎概念」「2基本算法/情報構造」
は買いでしょうか?
19 :
デフォルトの名無しさん:04/07/01 17:20
暗号化手法の比較表を出してくれ、と言われたんですが、
どこかにAES、RC4、DES、TripleDESの、
・暗号化・複合化速度
・鍵生成速度
・暗号強度
についてまとめてある資料をご存知の方がいましたら教えていただけませんか?
お願いします。
CRYPTRECの評価報告とか?
>>14 まあいいじゃないの。
基本的な考え方は優秀なのも出てくるかも知れんし。
そうでなくたって、分析入門者向けの練習台に(ry
ショクニン(・∀・)ゲイー
25 :
デフォルトの名無しさん:04/07/02 21:02
>>26 スレ汚し失礼しました。
素人としては、素直にAESが実装された暗号製品を
選ぶように心掛けます…
現役の日本製の暗号ってなくね?
ちゅうか日本の場合暗号に対する考えが甘いような気がすんですけど
>>28 Camelliaとか結構良さげだけど、まだちょいと新しいかもな。
AESも似たようなもんではあるけど。
あと、乱数生成器はMUGIとか……。
>>29 重ねて乙
>>28 今まで「水と安全はただ」であった日本なのに、
暗号なぞ必要であると思うわけないではないか。
もうすこしでプログラムが完成します。
選択平文に強くなるようなアルゴリズムは考えましたが、
候補が二つあり悩んでいます。
遅くとも明日には公開できると思います。
その際に、アルゴリズムの詳細について語らなきゃならんから
それを考えるとめんどくさ
どなたかプログラムをうpするとこ紹介してもらえませんか?
>>14さん
わたしのアルゴリズムは数学に基づいたものなので
差分に対する考慮はいらないかと思ったんです
ここのとこは、アルゴリズムを公開すれば分かってもらえると思います。
あと、66bitの秘密鍵を仕込んだ.exeを公開して
解読者には秘密鍵を当ててもらうことをかんがえています。
解読者は任意に平文を指定できます。
秘密鍵の値をeとすると0からe-1まで暗号化できるのですが、
0x0000000000000000-0xffffffffffffffff
までの平文に対して暗号文が出力されるようにすればいいのですよね?
>>28 日本がどうこう以前にそもそも全部アメリカ産だし。
AESを「現役の暗号」に入れていいんなら
当然日本製の暗号もいくつか入ると思うんですけど
>>32 秘密鍵を .exe に埋め込んだら絶対抜くやついるって。
俺みたいになー。
>>34 それが一番困ったとこなんです。
解読者は自由に暗号にアクセスできなくちゃいけないし
だからといって、こっちが勝手に平文を選んで解読者に渡すというのも
私としては納得いかないし、
どうだ!解読してみろと堂々と言いたいわけで。
なんかいい方法はありますか?
>>35 ここかアプロダに平文を提示してもらって、
それを暗号化してアップすればいいのでは?
それじゃ面倒か。
好きなキーで好きな平文を暗号化できる実行ファイルを公開した上で
キーを秘密にした暗号文を提示して解析できるかでよいのでは。
>>36 解読者は大量に平文→暗号文を入手できるとして
それでも秘密鍵が分からない
というのがよいアルゴリズムなわけですから、
私としては解読者が任意の平文→暗号文を選択できるようにしたいのです
それに、人によって欲しい平文→暗号文が違うとおもいます。
アプロダにアップする方法もありますが、
平文→暗号文を解読者が満足するまでうぷするのは
ファイルのサイズ的に無理があります。
そうなると.exeから抜かれるのもしょうがないかなと思います。
抜いただけの人はどうやって暗号を破ったのかの問いに対しては
ブルーフォースを行ったとしかいえないわけですから、
ブルーフォースで破られるのは問題ないかと
>>37さんのいうようにキーを自由に扱えるようにした方法と
暗号文→平文を自由に扱える方法の両方でいきたいと思います。
cgi形式にでもしてサーバーで公開したらいいんでないの
なんでexeに話が飛んでるのか理解できないけど、
アルゴリズム公開して
実装コード見本、テストベクターも公開で
で復号へのkey challengeがまぁ普通じゃないの?
#exeなんて、気持ち悪くて動かす気にもならないです。(。∀゚)
とりあえず完成しました。
今からアルゴリズムの説明を考えてきます。
((@))
インド (・∀・)シーシーエーツー
アルゴリズム説明しますね。
プログラムは
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/readres.cgi?bo=lounge&vi=1088921677 に添付しています
私は何を公開したらいいでしょうか?
この暗号は数車(かずぐるま)といいます。
歯車が回っているのをイメージした時に思いついたので
このような名前になりました。
わかりづらかったら質問してください。
暗号化
素数^n(nは自然数)となるような数をいくつか用意します。
個人的にこの数を勝手に豆数(まめかず)と読んでいます。
豆数は素数^nとなる数です。
L=abcd(Lはabcdの最小公倍数)とする
(このときのLが秘密鍵です。)
ここでは仮に豆数をa,b,c,dとします。
(a,b,c,dは互いに素でなければなりません)
平文Mをa,b,c,dでそれぞれ割っていきます。
このときの余りをそれぞれa',b',c',d'とすると、
M=ax+a'=by+b'=cz+c'=dw+d'
(豆数a,b,c,dの余りで表現できる数は0からL-1です)
(x,y,z,wは0以上の整数、Mの範囲は0<=M<Lとする)
という関係が成り立ちます。
a,a',b,b',c,c',d,d'を用いて
C'=(((a')b+b')c+c')d+d'
(Mの範囲が0<=M<abcdのとき0<=C'<L)
となるようなC'を計算します。
今度は
C'をaで割りそのときの商をaa,余りをa"
aaをbで割りそのときの商をbb,余りをb"
bbをcで割りそのときの商をcc,余りをc"
ccをdで割りそのときの商をdd,余りをd"(ddは常に0です)
とすると、このとき
C'=(((dd+d")c+c")b+b")a+a"
となります。
a,a",b,b",c,c",d,d"を用いて
C=aX+a"=bY+b"=cZ+c"=dW+d"(X,Y…同上)
となるCを求めます。
このときのCが暗号文です。
M→C'は問題ないと思いますのでC'→Cの求め方
label1:
cZ+c"=dW+d"…壱
となる最小の値を(cd)"とします。
壱を少し変形して
cZ-dW=d"-c"…弐
拡張ユークリッドの互除法を用いて
cZ'-dW'=1となるZ'またはW'を求めます。
両辺d"-c"倍してやって
c(Z'*(d"-c"))-d(W'*(d"-c"))=d"-c"…参
弐と参を比較して
Z=Z'*(d"-c") W=W'*(d"-c")
∴壱は
cd*Z_W+(cd)"=cZ+c"=dW+d"(Z_Wは0以上の整数)
と表されます。
今度は
cd*Z_W+(cd)"=bY+b"
となるような最小の値(bcd)"を求めます。
goto label1;
と、どんどん繰り返していってCが求めれます。
復号はこの逆を行えばいいわけです。
豆数の並べ方に決まりがあります。
素数の小さい順に左から並べます。
つまり、
L=2800のとき
Lを素因数分解して
L=2^4*5^2*7^1
豆数を
2^4,5^2,7^1
とならべます。
今度はLを豆数の数で割ってやります。
ここでは3です。
豆数に右から順に0,1,2と割り振ってやって
2800%3≡1 2800/3=933
1番は5^2ですから
一番左は5^2になります
2^4,7^1と並びます
今度は933を2で割ります
933%2≡1
今度は1番目は2^4ですから
豆数は5^2,2^4とならび
最終的には
5^2,2^4,7^1と豆数は並びます。
そしてこの順に
a,b,cに豆数を代入していきます。
以上で説明は終わりです。
何か質問ありましたらどうぞ〜
あと、わたしが公開すべきものを指定してくださいな。
本質と関係ないところですまないが
引用符として用いられることの多い ' と " だと微妙に見にくかった
あと、 C'=(((a')b+b')c+c')d+d'
こういうのは * を省略してると解釈してOK?
そこで C'をaで割りそのときの商をaa,余りをa"
とか言われると新しくaaという変数を定義してんのかa*aなのか途中の式が見にくい
すんません
C'=(((a')b+b')c+c')d+d'
は*を省略してます
aaは新しく定義してます。
45 名前:梅どぶろく ◆21Da3ggG3M [sage] 投稿日:04/07/04 15:18
今度は
C'をaで割りそのときの商をaa,余りをa"
aaをbで割りそのときの商をbb,余りをb"
bbをcで割りそのときの商をcc,余りをc"
ccをdで割りそのときの商をdd,余りをd"(ddは常に0です)
とすると
' "についてはいい表記の仕方が分からなかったんです。
本筋と関係ないところでホントごめんな
あのさ、秘密鍵とか書いてあるけど、共通鍵暗号だよね?
鍵を素因数分解って、分解できなかったら、どうすんのさ?
鍵長が長くなると分解のコストも高いよね?
分解できても、少ない項だったら弱くね?説明見ても項数は可変ぽいし。
というか、種から鍵を生成するアルゴリズムが必要になってくるんじゃないの?
その場合、本当に鍵と言えるのは種の気もするけど…
あるビット列を鍵として、鍵が素数は不可なら、
素数は除外してBuruteForceが楽になるんだけど
#俺って暇人なだw
>>53 共通鍵です。
簡単に素因数分解できる鍵でOKかと
鍵を秘密に共有すれば
解読者が解読しようとしたらアルゴリズムへの攻撃か
鍵への攻撃なわけです。
ここでは、アルゴリズムは安全であると仮定して
鍵への攻撃のみを考えるとします。
ある鍵Kを66bit鍵としてAliceとBobが共有すれば
AliceとBobは素因数分解するのはKだけでよくて
Eveは66bitの鍵に対して素因数分解を行って
それから鍵の検証ができるわけで
ここで余分なコストが発生するかと思ってるんですが
>あるビット列を鍵として、鍵が素数は不可なら、
>素数は除外してBuruteForceが楽になるんだけど
ここんとこは大丈夫じゃないでしょうか?
合成数のほうが素数より圧倒的に多いわけですし、
EveがKを求めようとしていろいろと鍵を試していった場合、
Kの候補だとした数が素数だった場合泣けてくると思っています。
>>55 たとえばC'を暗号文として扱うと
C'=(((a')b+b')c+c')d+d'
展開して
C'=a'bcd+b'cd+c'd+d'
a'はa周期ごとに0をとるから
その時のC'の値は
C'=b'cd+c'd+d' となり、
選択平文攻撃を用いてMの値に1ずつ加算して
それに対応したC'の値が何周期で
増減を繰り返しているかを見ればaの値がわかってしまいます。
さらに、
M2はbで割り切れ(b'=0)そのときのa'をA,c'をC,d'をDとし
M1+1=M2とするとき
C'1=A*bcd+(b-1)*cd+C*d+D
C'2=(A+1)*bcd+0*cd+(C+1)*d+(D+1)
C'2-C'1=bcd-(b-1)cd-d-1=cd-d-1
となり、差が極端に小さくなります。
(C+1,D+1が0になることは考慮していません)
この性質もまた選択平文攻撃の餌食となり
何周期ごとにC'2-C'1の差が小さくなるのか調べると
bの値がばれてしまいます。
(上のA,B,C,Dと以下のA,B,C,Dは関係ありません)
C'→Cの方法を
M→Cとして扱うと
Mをaで割りそのときの商をx,余りをA
Aをbで割りそのときの商をy,余りをB
Bをcで割りそのときの商をz,余りをC
Cをdで割りそのときの商をw,余りをD(wは常に0です)
とする。つまり、
M=ax+A,x=by+B,y=cz+C,z=dw+D
これを右から代入していって(wは常に0だから削除)
M=(((D)c+C)b+B)a+A
_=abcD+abC+aB+A
となります。
a,A,b,B,c,C,d,Dを用いて
C=ax+A=by+B=cz+C=dw+D
となるCを拡張ユークリッドの互除法により求める。
このCを暗号文とするとこれまた選択平文攻撃の餌食となります。
以下証明
by+B=cz+C=dw+D
となる最小の値をVとする。このとき
C=(b*c*d)*v+V=ax+A(x,vは0以上の整数)
また、M0→C0,M0+1→C1,M0+2→C2とし、(M0を暗号化するとC0が得られるって事です)
M0をaで割りその時の余りをA0,M0+1をaで割りその時の余りをA0+1,
M0+2をaで割りその時の余りをA0+2,
(A0,A0+1,A0+2はaで割り切れないとする。割り切れるときは下で書いています)とすると
C0=bcd*v0+V=a*x0+A0
C1=bcd*v1+V=a*x1+(A0+1)
C2=bcd*v2+V=a*x2+(A0+2)
となります。
C1-C0=bcd(v1-v0)+V-V=a(x1-x0)+(A0+1)-A0
=bcd(v1-v0)=a(x1-x0)+1
C1-C0-1=a(x1-x0)
C2-C1=bcd(v2-v1)+V-V=a(x2-x1)+(A0+2)-(A0+1)
=bcd(v2-v1)=a(x2-x1)+1
C2-C1-1=a(x2-x1)
C1-C0,C2-C1の値にユークリッドの互除法・素因数分解を用いると
bcdについての情報が分かります。
更に、C1-C0-1,C2-C1-1も同様に
aについての情報を与えてしまいます。
今度は
(A0,A0+1,A0+2はaで割り切れないとする****の割り切れる時の場合です)
M3をaで割りその時の余りをa-1とすると,M3+1をaで割った余りは0になります。
M3→C3,M3+1=M4→C4とする。
M3=a*x+(a-1),x=b*y+B,y=c*z+C,z=d*w+D
M4=a*x+(a-1)+1=a*x+a=a(x+1)
x+1=b*y+(B+1),y=c*z+C,z=d*w+D
(ここのx,y,z,wは同じ値です)
この時C3,C4は
C3=a*x3+(a-1)=b*y3+B=c*z3+C=d*w3+D
C4=a*x4+(0)=b*y4+(B+1)=c*z3+C=d*w4+D
C4-C3=a(x4-x3)-(a-1)=b(y4-y3)+1=c(z4-w4)=d(w4-w3)
C4-C3-1=a(x4-x3-1)=b(y4-y3)
∴C1-C0とC4-C3,C4-C3についてユークリッドの互除法・素因数分解を用いると
a*b,c*dについての情報が得られました。
上のような考慮事項があるので
M→C' C'→Cのように二段階の暗号化を行いました。
>>55 多分この暗号にはアルゴリズムへの攻撃はできなくなっていると思います。
上の二つの暗号化方法だとアルゴリズムへの攻撃が有効です。
アルゴリズムへの攻撃の大体の感じをつかめてもらえましたか?
>>all
もっと分かりやすく説明しろ!!!
ってとこがありましたら指摘をお願いします。
悪いけど、ここには個人で暗号検証できるような
能力だったり労力を裂いたりする人間はほとんどいないと思う。
公開しろって言ってた人間も、くれるものは貰っとくって精神だろうしな。
本気なら、本当に気長に待つしかなさげ。
あ,ごめん,質問が悪かったですね.
「鍵への攻撃」「アルゴリズムへの攻撃」という用語の定義がよくわかりません.
「アルゴリズムへの攻撃」=選択平分攻撃?
暗号系には昔から、おれのチンコを見てくれって香具師は、よく現れる。
大抵粗チンなので、放置が普通。
オナニーしたいのなら、別の場所がお勧め。
本番したいのなr(ry
釣られてるのは単に、このスレに暇な香具師が多いんだろ。
知識も何か変な風に覚えてるらしく、単語とか言葉の使い方変だし。
突っ込みどころも多いけど、それを説明するのも('A`)
>>62 釣りではないですよ、釣りにしては手が込みすぎてるじゃないですか
>知識も何か変な風に覚えてるらしく、単語とか言葉の使い方変だし。
ここのとこはここが変と大体の場所を指定していただければ自分で調べますので
箇条書きでいいんで書いてもらえませんか?
そしてまた
>>62みたいなのも多いんだなこれが>暗号関係のスレ
なんかよくわからんが彼は真剣だな。と言ってみるテスト
自分のWeb等で活動をしてみたらどうかと、何も2chにこだわらなくとも。と言ってみるテスト
もっと言うと、日本よりも世界に向けて
テストしてもらうように誘って見たら。
英語なんて調べながらであれば書けるんだし、
きっと日本からのレスよりもくると思うよ。
海外にはアマの暗号マニアぐらいいっぱいいると思うし、
弱点も見つけてくれるかもよ。
#世界は広い、そして...日本はせまい。
>>61 鍵への攻撃はブルーフォース
アルゴリズムへの攻撃は
>>56-59みたいに
数学的な特性を生かした攻撃ってことで
「平文と暗号文のペアを入手して
ある方程式を立てれば鍵をまったく知らずに
暗号文と平文のペアだけで鍵を求めれる」
この方程式・方法を見つけようとするのがアルゴリズムへの攻撃
と考えて一連の発言をしていました。
弱点といえるのかどうかわからんが、2点ほど。
まず
>>54について
Eveが最初からしらみつぶしで攻撃する気なら、
素因数分解が必要になるのはBobだけじゃないか?
AliceもEveも"豆数"から作ればいいんだから。
(と言うか、
>>44 >素数^n(nは自然数)となるような数をいくつか用意
するんじゃなかったっけ?)
これの元になる素数を見つける必要はあるが、
豆数が複数なら出てくる素数は2^33未満だし。
それから、M→C'とC→C'は簡単だから、
分析者が平文・暗号文のペアをいくつか持っている場合に限り、
中間値探索を使って暗号化・復号プロセスの面倒な部分(
>>46)を避けて
鍵のチェックができるね。
どっか大ボケかましてたら優しく教えてください。
>豆数が複数なら出てくる素数は2^33未満だし。
当然、66ビット鍵の場合の話ですよダンナ。
あと、
>>62の言うのは
>ブルーフォース
みたいな細かい点の話とか、
>秘密鍵
(この単語は、公開鍵暗号のプライベート鍵を指すことが多い。
共通鍵暗号なら共通鍵、共有鍵、または単に鍵と言う事が多い。
…気がする。)
>鍵への攻撃
(アルゴリズムの鍵スケジューリングを攻撃する分析法などと混乱しやすいと思われ。
しらみつぶしならしらみつぶしと書くのが得策かと。)
などという混乱を招く表現のことを指してるんじゃないか?
>>49 せっかく2ブロックに分かれてるんだから、
>>44を関数F、
>>45-46を関数Gとして
C = G(K, F(K, M))
こうしといて、FとGの定義を別々に書いとけば
もっと見やすい表現を使えたかもしれないね。
以上。これだけのことで3レスも使っちゃってスマソ
これ、Mは何bitなん?ブロック暗号なのかな?
>>72 Mは可変長です
いくらでも好きなように
暗号化するのがnビット毎の時
対称鍵をn+2ビットにすればOKです
ブロック暗号です。
>44の
> (x,y,z,wは0以上の整数、Mの範囲は0<=M<Lとする)
からして
鍵空間て 2^n < L <= 2^(n+2) の狭いのはどうなん?
あと、ブロック暗号なら、パディングをどうするのかと、
M=0の場合のCの検算をだしてみてくださいな。
>>74 >あと、ブロック暗号なら、パディングをどうするのかと、
これは0〜2^nの値全てに
2^(n+1)の加算を行います
いや、パディング判ってないしw
>>75 nはブロック長?だったらそれじゃうまくいかない。
平文の最上位ビットが0のとき、復号側が平文の長さを知らないと
平文とパディングビットの境目がわからなくなるよ。
ただ、ブロック長がnビット、
平文の長さがpビット(当然 n >= p)のとき、
加算する数を2^(p+1)にするとうまくいくと思う。
要するに、暗号化前に右からp+1ビット目、つまり
平文とパディングビットの境目に1を立て、
(n = pでなければ)それより左のビットには0を立てる。
そして復号後に
一番左にある1のビットと
(n = pでなければ)それより左のビット(すべて0のはず)を捨てる。
これでどうよ?
>>76>>77 >>75の
>これは0〜2^nの値全てに
>2^(n+1)の加算を行います
は間違いです。
正しくは↓↓↓
nビット毎に暗号化するとして(対象鍵はn+2ビット)
0〜2^n-1の値すべてに
2^nの加算を行います。
すると暗号化前の平文は
2^n〜2^(n+1)-1になります。
復号する時は
復号して出てきた値から2^nを減算してやればOKです。
これは、最初の説明に無かったと思うんだけど、修正なの?
いえ、説明するの忘れてました
平文をnビットとするときに鍵長がn+1ビットだと
平文すべてに2^nを加算することができないわけで
(そうすると平文が2^n近くの時に鍵の値を超えてしまうわけです)
そういったことを考慮して鍵長はn+2ビットといっていました。
他に説明忘れはありませんか?
結局、パディングになってない訳だが?
これは、nビット暗号して、n+1ビット出力されるの?
鍵空間は 2^(n+1) <= L <= 2^(n+2) てのはどうなん?
少なくとも使いにくそうだけど、既存の暗号に対して
なにかメリットあるんですか?
メリットは暗号化毎のブロックの長さ・鍵の長さを
自由に選べるってとこでしょうか
数学的な暗号化方法だから
自分では線形攻撃や差分攻撃は意味がないと思っています。
あと、平文と暗号文だけから
鍵Lについての情報を得られるか、得られないかを
数学的に証明できると思っています。
どっちなのかはわかりません
もし仮に、数学的に平文と暗号文だけから
鍵Lについての情報が得られないと証明できれば
他のブロック暗号のように新しい解読方法が見つかって
既存の対象鍵暗号は弱いものになるかもしれない
なんてふうに悩まなくてもいいと思います。
> メリットは暗号化毎のブロックの長さ・鍵の長さを
> 自由に選べるってとこでしょうか
実装する側、使う側するとメリットとは思えない。
むしろ、実装する側からすれば、デメリットかも。
暗号化毎ってなってるけど、ブロック長は鍵長に依存だよね。
鍵を選ぶみたいだし、弱い鍵生成を抑制するコードもくまないと使えない。
これじゃDESの時代に逆戻りみたいだ。
鍵長依存の任意のbit長で出力が1bit増えるなら、既存の暗号と置き換えるのも難しいし。
結局パディングもできないようだから、そこも気をつけないといけないし。
#パディングが何か判ってないって、既存の暗号がどんな物か調べて無い気がしてしょうがないのだけど。
いくらアルゴリズム部分が大丈夫と言っても、暗号全体として弱ければダメだよね。
他の攻撃方法も色々あると思うんだけど。
いくら鍵が大丈夫といっても、既知の情報から復号できてしまえば意味ないわけだし。
ム板で数学証明とかいっても無駄だと思うし。
>>85 >結局パディングもできないようだから、そこも気をつけないといけないし。
>#パディングが何か判ってないって、既存の暗号がどんな物か調べて無い気がしてしょうがないのだけど。
はい、そうですこちらが勝手に解釈して勝手なことを言っていました。
パディングってのは最終バイトが暗号化するブロックに足りない時に
最終バイトをどうやってブロックのバイトにするかってことでよろしいでしょうか?
これは、足りないバイト分0を後ろから足してやります。
このブロックを暗号化、
最後に何バイトがいらないバイトかを示した値を
暗号化してやればいいのではないでしょうか
>>84 >数学的な暗号化方法だから
>自分では線形攻撃や差分攻撃は意味がないと思っています。
線形攻撃や差分攻撃が「より」適用しやすい、の間違いだな。
なぜ既存の共通鍵暗号アルゴリズムがたくさんラウンドがあったり、
Feistel構造やSPN構造を入れてるか分かってるのか?
>あと、平文と暗号文だけから
>鍵Lについての情報を得られるか、得られないかを
>数学的に証明できると思っています。
F(M,L)=C,F^{-1}(C,L)=Mって等式が成り立つんだから、数学的には情報を得られる。
鍵Lを使っても使わなくても暗号化したり復号したり出来るなら、得られないかもしれないが。
>>85 数学的に安全証明が出来るものをム板でさらに安全な実装を考えるってのは意味があると思う。
でも、『非』安全証明が出来るものを、実装でなんとかしようってのは、ちょっと不健全だな。
89 :
デフォルトの名無しさん:04/07/11 22:48
DESについての質問です
UNIXのcrypt関数と同じことをする関数を作ろうとしているんですが、
saltでDES暗号の途中で使う転置表をかき混ぜるみたいなんですが、
どうかき混ぜるかわかりません。
知っているかたいたら教えてください。
90 :
デフォルトの名無しさん:04/07/11 22:57
全く関係ない話だが暗号を評価してもらうにはどうすればいい?
金を積む
有名どころを評価して弱点を見つければいい。
弱点を見つける方が弱点なく作るよりも何倍も難しいが、
少なくとも、それすら出来ない制作者の作ったものは、評価されんだろう。
ごめん。逆だった。
×弱点を見つける方が弱点なく作るよりも何倍も難しいが、
○弱点を見つける方が弱点なく作るよりも何倍も易しいが、
解決したからもういいです
95 :
デフォルトの名無しさん:04/07/11 23:19
C4ってどう?誰か使ってる人いませんか?
>>96 ほんの70ほど前のレスすら見つけられないあんたには
エニグマ暗号程度で十分です。
>>96 このスレには、その話題に振りすぎる奴がいるな。
C2ってどう? 誰か飲んだ人いませんか?
薄い。
薄まってカロリー半分、そりゃそうだ、って感じ
O2ってどう? 誰か吸った人いませんか?
おれ毎日吸ってる
C4ってどう?
X線でも写りにくいし爆発力もなかなかなので、かなりいいですよ。
ネタスレになってんじゃねーか!
暗号だよ。暗号。
>44
その暗号の最大の弱点は
キーLのビット数に比べて
素数分解が簡単になりすぎる事だろうね。
豆数の指数が全て1の場合でさえ
各々の素数は公開キーLの桁の1/4になってしまう。
RSAに代表される素因数分解に起因される暗号では
最低でも、素数の桁として256bitは必要だろうから
公開キーとして1024bitだね。
で、これが、最低レベルの場合。
当然、豆数の指数を増やすと公開キーのサイズはどんどん増える訳で
(Lの桁 ≒ aの桁*指数 + bの桁*指数 + cの桁*指数 + dの桁*指数)
他の共通キー暗号に比べればキーが巨大すぎる。
っと、失礼。
Lは小さくて問題ないみたいだね。
釣りか?w
日本語読めますかw
C4の自己評価書ってのを読んでみたんだけど、これってどうなの?
> C4-1 は,選択平文/選択暗号文攻撃に対して強い:
> 1) カオスの機能自身は一方向である.
> 2) 鍵の処理装置は一方向である.
> 3) 出力データは常に乱数である.
> 上記3 項目により,暗号化に利用した鍵を算出することは実際的でない.
ってあるけど、1〜3までのどれも命題が真であることを示さないと
安全であることにはならないと思うんだが。
3)とか絶対に偽だし。疑似乱数だろう。
>>111 ばっかだな〜
全部真に決まってるじゃないか
C4の世界でだけだけどな
C4の世界でだけってことは…現実世界では安全かどうかなんか、知るかってことで…
そうか、C4に釣られたのか、読んだ時間無駄だっただけだったのかorz
>>111 別に擬似乱数だろうが真の乱数だろうが
暗号学的に必要な条件さえ満たしていれば構わないんじゃないの?
まあ証明や統計的な結果を示さないとしょうがないと思うけど。
>>114 うん、分かってるつもり。
ただ、暗号の場合、乱数は統計的に安全だってのは余計危険だろ?
暗号学的に安全ってのがくせもので、カオスだから予想出来ない、安全なのだ!
って言われても使う気にも薦める気にもなれん。所詮数式だし。
それを解析しているのが自己評価書だと思って期待して読んだだけに
亀レス失礼
shadowpenguin.org にあった解説がいちばんわかりやすかったんだがのう
>>89 拡大転置したE[1:48]に対して、
E[1:12] E[25:36] を Salt(12ビット)に応じて入れ替え。
E[13:24] E[37:48] はそのままでよい。
拡大鍵とXORする前に行う。
ex) Salt が 100 000 000 001 だったら、E[1]<->E[25] E[12]<->E[36] を行う。
教科書を見ずにうろ覚えで書いたのでウソついてたらスマソ
で、トリップでも探すのかい?
>>116 > shadowpenguin.org にあった解説がいちばんわかりやすかったんだがのう
webarchive.org にも残ってないんだよね。別にサイト閉じなくたっていいじゃんよ。
詳しい解説を公開して、「このサイトがあれば安心」と油断させて
おきながら、いきなりサイト閉じるのはテロに等しい行為だ!
と主張してみたりする。
まぁ、公開しようが公開取りやめようが本人の勝手なんだけれども。
118 :
デフォルトの名無しさん:04/07/25 14:08
はー、いろんなこと勉強しなきゃいけないから大変だー。
あらよっと。
OOスレに来るのはバカばっか。
一人消しても、また一人・・・
おまえらスライムか?
なんでOOPL扱えないくせに、OOについて語ってるんだよ。
Cでポリモーフィズムできるようになってから出直して来い。
Vectorなどのコンテナークラスは、オブジェクトを格納できるわけだけど、
明らかにポインタを格納するバグはでないだろ?
それから、最近2chのレベル低くなりすぎ。
数値計算やアルゴリズム、データ構造それから
少なくても、2つ以上の言語についてしっかり知っとけ。
OSやらハードウエアに関する本も少しは読め。
数学の本も少し読んどけ。
サーバーサイドプログラミングはレベル低い。これ事実。
覚える事はいっぱいあるかもしれないけどレベル低いんだよ。
DB周りは特に勘違いしてる奴が多い。
SQL使えるからなんだっつーの?
SQLサーバー自作してから言え。
サーバーサイドの奴は、少し視野を広げろ。
最後に、仕事でプログラムやってるやつは
趣味でなんか作れ。
保守は良いんだけど、何でその内容なんだろう
>>119 最後に、保守カキコにふさわしい文章を選べ。
内容はえらくまともだな。
> OSやらハードウエアに関する本も少しは読め。
少しじゃなくてしっかり読め。
123 :
デフォルトの名無しさん:04/08/13 12:34
バーナム暗号ってどうよ?
利点・欠点を語ってくれ
いやです
利点は解読不可能ということが数学的に証明されている
欠点は平文と同じだけの乱数を用意しなくてはいけない
また、一度使った乱数を二度使ってはいけないので
鍵の配送が面倒。
利点、高速で余分なメモリがいらない。アルゴリズムが簡単。乱数生成期を変えるだけでウリジナル。
欠点、共通鍵と同じ。乱数シードをどうやって渡すか。乱数ジェネレータがへぼいと駄目。
これで合ってる?
127 :
デフォルトの名無しさん:04/08/13 17:04
>>125 > 利点は解読不可能ということが数学的に証明されている
は、ワンタイムパッド暗号の方ですね。
なんでこれだけ他の共通鍵暗号に比べて、パフォーマンスもコストもいいのにそんなに使われないかって、
乱数のランダム性の研究に比べて、乱数の安全性の研究があまりにも進んでないからだと思われ。
プログラム作る側としてはとっても楽だけどw
あのーいつも思ってるんですが、
宝くじってありますよね
宝くじ本体(印刷してある紙)には
偽造技術がほとんど使われてなくて、
宝くじの下にある番号の羅列で
真贋チェックしていると思っています。
ほんでもって、番号はハッシュ関数で生成していると思うんですが、
はずれ宝くじ何枚くらいあれば
番号生成アルゴリズムをクラックすることが可能になりますか?
>>130 なぜ関数で生成していると思うの?
(疑似)乱数でいいじゃん。データベースに対応表を残しといてさ。
つーか俺が作るならそうするが。
そんな何枚も集めなくても、当たりくじ一枚あれば充分。
> 偽造技術がほとんど使われてなくて、
というのが、そもそも甘いんだろう。
>>131 DBに対応表を残すというのはかなり厳しいんじゃないでしょうか?
発行する枚数が膨大ですから、保存容量が莫大になると思います。
>>132 いや、当たりくじは番号の部分が隠されて公開されるじゃないですか
新潟に2億円の当たりくじが届いて公開された時も
番号の部分は黒塗りで隠されていました。
>>133 宝くじの紙を見るに
印刷技術で偽造を防止しようとしているとは思えません。
>>134 自分が本物を持ってれば何も困らないが。
>>135 偽造しようってんですから
当たりくじは持ってないという前提です。
新聞などから得る当選番号と
大量のはずれくじから
偽造できるかという問題です。
もし、できるとしたらはずれくじの必要量は
どれくらいかと思ったんです。
よく観察すると、数字の部分は他と明らかにインクが違うね。
磁気インクとかなんか仕掛けがありそう。
簡単に偽造できるとは思えない。
>>137 一見すると、肖像画も無いし、お札よりも簡単そうだが、実は・・・というパターンかもしれない
>>134 1枚につき4バイトとすれば、10億枚でも高々4GB
それでも容量が足りないというならば、
数字全部を覚えておかず、桁半分は関数で生成し、半分はランダム生成。
これだけでも、解析はできなくなるし、必要な容量は半分になるし。
>>134 > DBに対応表を残すというのはかなり厳しいんじゃないでしょうか?
> 発行する枚数が膨大ですから、保存容量が莫大になると思います。
そんなにたいした容量でもないですよ。多く見積もっても1.2TBです。
しかし昔のことを考えると、関数で生成している可能性が高いですね。
お札と違って厳しいのは、50万円以上は身分証明書が必要なことです。
なので、本物と衝突した場合に追跡されるでしょう。
そう考えると、一部の売り場で交換出来る5万円以下が安全でしょうね。
>>139 1.2TBなら現実的ですね
秘密によるセキュリティーとかでしょうか?
宝くじの番号を生成する方法とか公開してないですよね?
とすれば、深読みするとクラックも可能だと思っています。
みずほ銀行に入社しる
宝くじの偽造ってどういう犯罪になるんだろ?
有価証券偽造
145 :
デフォルトの名無しさん:04/08/21 20:09
MD5もうだめぽ
保守
146 :
デフォルトの名無しさん:04/08/28 07:40
147 :
デフォルトの名無しさん:04/09/11 05:46:19
結局、技術的な話はなかなか出ないな。
自分から振ろうぜ。
MD5の代わりに何を使用したらよいですか?
>>149 今のところ、SHA-256とか、もっとビット数があるのとか。
たぶん1〜2年したら誰かがもっといいハッシュ関数を
作ると思うので、それまでのつなぎとしてだけど。
151 :
デフォルトの名無しさん:04/09/18 16:25:18
AとBがいて、
Aは、ある方法で暗号化したファイルを持っていて
Aは中身はみることはできません。
中身を見たいときは、Bに鍵を申請して
Bが鍵を貸してあげてはじめてファイルを見ることができます。
まとめますと、Bが許可をしない限りAはファイルを見ることが
出来ないっていうことをしたいのですが、
どのような方法が考えられるでしょうか?
わかる方、よろしくおねがいします。
BはAESでファイルを暗号化する。
Bは暗号化したファイルをwebやp2pなどで公開する。
ファイルの中身を読みたいAは暗号化したファイルを入手し
Bに対して鍵を送ってくれるよう依頼する。
Bは送ってもよいと判断したらAに鍵を送る。
鍵を受け取ったAはAESを使って複号化する。
というありきたりな手順ではだめ?
すみません。説明が足りませんでした。
暗号化するのはAになります。
Aが持っているファイルをAが暗号化して
Aが持っていることになります。
それを、AがBに見たいと言って、Bが鍵を貸してあげます。
はじめ私が考えたのは、Bが公開鍵、秘密鍵を作って
Bの公開鍵をAに送って、その鍵で暗号化して
復号化したいときは、Bに言ってBの秘密鍵を
借りるということを考えていましたが、
1.秘密の鍵をAが受け取ったらどんなものかわかってしまうので
2回は使えないこと。(受け取った鍵がどんなものAに知られない方法があればいいのですが)
2、公開鍵方式は、復号化に時間がかかること
がありまして、いろいろと考えております。
共通鍵を使った方法でいい方法はありますでしょうか。
>>153 共通鍵ブロック暗号で全体を暗号化した後に
最初の小さな部分を公開鍵で暗号化するようにすれば
とりあえず速さだけは改善
頭の小さな部分を復号できなきゃ全体を復号することはできない
鍵はその都度生成で我慢しる
やりたいことは分かるが、やりたいことの意味が分からん。
>>154 >共通鍵ブロック暗号で全体を暗号化した後に
>最初の小さな部分を公開鍵で暗号化
なるほどです。
やはり鍵は毎回作る必要がありますか。
的確なアドバイスありがとうございました。
ほんとに意味がわからんな。
ハイブリッドでいいやん
ハイブリッド 共通鍵 公開鍵
でぐぐってみな
>>157 本体の暗号化に共通鍵暗号のみを用いるハイブリッドで題意を満たせるか?
159 :
デフォルトの名無しさん:04/09/18 23:08:36
結局上のMD5とかのハッシュのコリジョン云々って
とても便利な.zip MD5:bbfea44c601e38b5da2cf8b0e7282bbc
というファイルにウィルス仕込んで適当に調節して
同一MD5値にすることが簡単にできるのできないの?
それを聞いているわけだが。
やってみれば分かる
お偉いさんによるとMD5の場合は数分で可能らしいが
問題のないzipファイルにはまずならないだろうな
有用なファイルのふりをしたゴミを作るのが簡単だったりするだけだと思われ
>>158 Aは
共通鍵暗号方式を使ってファイルFを暗号化する(暗号ファイルはF_C)。
共通鍵はk、kをBの公開鍵で暗号化する。
AはF_C, k_CをBに送る。
ファイルを復号したくなったら、Bにk_Cを秘密鍵で暗号化してもらって、
Bの公開鍵で復号してkを得る。
こんな感じでどう?
>>155 もう解決したのなら余計なお世話だけど
やりたいサービスの内容を書いてみたら。
暗号化ではなく認証に関わる問題のような気がするんだけど。
ローカルファイルのチートを防止したいのかね
アプリごとにいちいちドングル挿してたら鈴なりになってしまうよw
>>168 それこそ究極のセキュリティ。
目立つし、簡単に持ち運びできなくなるし。
>>165 たとえば、Aで重要な書類を作成して
普段は、Bの公開鍵によって暗号化してAでも開けられず(Aが外部に漏らさないように)、
Bの許可(鍵に有効期限、回数を付ける。付け方は検討中です)によって開くこと
ができるという感じにしたいと思います。
Bはたくさんのクライアントを監視します。
今のところ、
”共通鍵ブロック暗号で全体を暗号化した後に
最初の小さな部分を公開鍵で暗号化”
がいいかもしれないと考えております。
認証もしますので、認証用の公開鍵、秘密鍵をA、Bともに作って
通信の部分も暗号化されます。
なにかアイディアがございましたら、よろしくお願いします。
>たとえば、Aで重要な書類を作成して
文書を作成するのは専用アプリで?それとも一般的なアプリ?
>普段は、Bの公開鍵によって暗号化してAでも開けられず
Aが編集終了後暗号化前にこっそりそのファイルをコピーしてとっておくことは可能?
>文書を作成するのは専用アプリで?それとも一般的なアプリ?
作成も開くのも専用のアプリを考えております。
>Aが編集終了後暗号化前にこっそりそのファイルをコピーしてとっておくことは可能?
編集中にモニターを写メールで取ることもできるので、
コピー不可は考えておりません。そこまで考えると写メールを
使って撮影しないかどうか目の前で見張ってる必要も出てきてしまいますので
編集中は、Aさんを信用することにします。
Aが自分で「Bの権限に入る」ことをしないとBの権限下にならないのか
それって結局、どっちの許可がないと作業中のファイルを
外に持ち出せないってことになるんだろね?
ファイル保存時に強制的に上の動作をとるような環境を実現できればいいのかな
だとしたらどうやっても無理な気が。
ローカルで暗号化ファイルを復号化する以上
その時点での暗号化ファイルを別の場所にコピーしておいて鍵を盗み見ておけば
それをいつでも展開できちゃうでしょ。
プログラムを解析されなければ安全だけどそれが期待できるなら
最初から共通鍵をバイナリに埋め込んでおくだけで十分だし。
現実的には下の二つくらいしかないと思うよ。
・ドキュメントを平文で保存して、Aが作業するPCのリムーバブルメディア(FDD,USB)を物理的に使用禁止にしてネットにもアクセス制限して他のPCへの転送を禁止する。
・サーバを別のところに立てて認証を行いAが編集するファイルをダウンロードしてオンメモリで編集してサーバに送信する。
>>172 ああ、専用ソフトか。コピー可能というのは、作業中の書類を
Bの許可無しでいつでも再編集できるかたちで保存できる、ということ?
「どうせ写メールで撮影されるのだから、コピーを可能にしても同じこと
(Aにできることは増えない)」の正確な意味がちょっとはっきりしないです
>その時点での暗号化ファイルを別の場所にコピーしておいて鍵を盗み見ておけば
>それをいつでも展開できちゃうでしょ。
>プログラムを解析されなければ安全だけどそれが期待できるなら
>最初から共通鍵をバイナリに埋め込んでおくだけで十分だし。
プログラムはたとえばどのような方法で解析されるのでしょうか?
共通鍵、公開鍵方式の暗号プログラムのソースコードがわかってしまい、
鍵の申請機能だけ無くしたソフトを作れてしまうということでしょうか?
そうじゃなくて危険人物Aが操作する危険な経路・場所であるPCに
Bの公開鍵と秘密鍵両方を結果的に通知してしかも利用するんだろ。
で、その危険なPCで改変されたかもしれない危険なプログラムが実行されて
Bの秘密鍵を出力してAが読み取ったらその時点でアウト。
経路は、暗号化してあるので大丈夫としてよろしいでしょうか?
Bの秘密鍵を出力してAが読み取ってから、
再生はどのようにするのでしょうか?
認証用のAの公開鍵(Bの秘密鍵)←Bの秘密鍵を認証用のAの公開鍵で暗号化
このBから送られてきたデータの中から、暗号プログラムが
Bの秘密鍵を取り出した後に、危険なプログラムがBの秘密鍵を読み取る
ということでしょうか?
Bの秘密鍵が読み取れたとして、復号化のためのソフトは
どうするのでしょうか?
それも、危険なプログラムがするのでしょうか?
鍵の申請の機能を無くしたソフトではなくて
他にどのようなソフトでしょうか?
>>170 > 今のところ、
> ”共通鍵ブロック暗号で全体を暗号化した後に
> 最初の小さな部分を公開鍵で暗号化”
> がいいかもしれないと考えております。
意外と正しく理解されてないっぽいんだけど、たとえば最もよく使
われるブロック暗号利用モードの CBC を用いる場合、そうやって最
初の k ブロックを隠蔽できたとしても、k+2 ブロック目以降は普通
に復号できてしまうので、この方式はあんましセキュアじゃない。
他の一般的モードにしても似たりよったり。
まぁ、MAC を併用して全体を SS 風に構成しちゃうって手はあるだ
ろうけどさ。
でも、それよりは使い捨ての共通鍵を B の公開鍵で暗号化して保存、
必要に応じてそいつを B に送って復号結果をもらう、という普通の
ハイブリッド型構成の方が良くね?
もっとも、MS の NGSCB 辺りが実現した後なら話は変わるかもしれ
んけど、いまどきの普通のプラットフォーム使う限りいずれにしろ
全然セキュアじゃないことは覚悟しとく必要がある。
Aが暗号化も復号も行う以上
共通鍵で暗号化したらその時点で開く鍵はAの手元に入ってしまってアレだわな
>>180 暗号化する前のファイルもAは持ってんだから・・・
>>178 共通鍵公開鍵暗号方式以前に暗号とはなんぞやってところから
おさらいしないと駄目だなこりゃ。根本的に設計(以前に考え方)がおかしい。
簡単に言えばドミノ倒しだな
一つのドミノを倒すこと(解読)ができれば
後のドミノを倒すことができる(あとの平文全てが分かる)
>>179 そこを暗号化したいとは一言も言ってないね。
しなくていいとも言ってないけど。
>>185 k番目の暗号ブロックをBの公開鍵で暗号化するわけではないのですね。
いろいろとネットなどで資料をみているのですが、
どの部分をBの公開鍵で暗号化すれば、全体が復号できなくできる
のかよくわかりません。
よろしければご教授いただけますでしょうか。
-----------------------------------------------------------
違うと思うのですが、私が考えたのは
一つ置きに奇数番目の暗号ブロックをBの公開鍵で暗号化すれば
復号化出来なくなりそうですね。公開鍵での暗号化の時間を短縮できそうです。
>>186 共通鍵だけ暗号化すればいいじゃない
もしくは
C(n+1)=Mn xor Cn
てなかんじでどう?
× C(n+1)=Mn xor Cn
○ C(n+1)=M(n+1) xor Cn
C1は適当な乱数ってことで
> ○ C(n+1)=M(n+1) xor Cn
> C1は適当な乱数ってことで
M_n = C_n xor C_{n-1} だから、暗号文だけから簡単に復号可能っ
てことになっちゃうけど。
そうじゃなくて暗号文ブロックだけじゃなく前の平文ブロックの内
容も連鎖させることで最初が分からない限り後続ブロックも復号不
能なようにしようってことなら、それは EPBC というあんまり一般
的じゃない利用モードだわな。こいつはたしか妙な特性が発見され
たため、あまり使われなくなったってことだったと思うけど。
まぁ他にも Rivest の All-or-nothing Encryption なんて scheme
もあるわけだが、結局のところ
>>187 > 共通鍵だけ暗号化すればいいじゃない
で何が不足なのか明確に示されない限り、こっち方面を突っ込んで
も得るところはないんじゃね?
>>187 >共通鍵だけ暗号化すればいいじゃない
そうですね。共通鍵を暗号化するのが一番よさそうですね。
>>189 >平文ブロックの内
>容も連鎖させることで最初が分からない限り後続ブロックも復号不
>能なようにしようってことなら、それは EPBC
なるほど、そういうこともできるんですね。
使い捨ての共通鍵を暗号化することにしたいと思います。
ありがとうございました。
暗号なんていくら強度が高くなっても、結局ソーシャル的なミスで情報なんて漏れる
んだから意味無いよな。
つうかバイナリレベルのクラックは絶対ないって前提で作るなら
共通鍵埋め込んでそれ使っとけばいいのに。
>>191 まあ、しかしそれはこのスレでは関係ない話だ。
俺は暗号に関してド素人だが言わせてもらう
何 だ こ の 意 味 不 明 な ク ソ 設 計 は !
何の話?
クソ設計とはいえ素人にはまず破れないだろうし
クラッカーが興味を引くデータとも限らないし。
まったく無価値とはいえないな。
197 :
デフォルトの名無しさん:04/09/25 16:08:11
C++用のECCライブラリ、お勧めはありませんか
Apacheライセンス程度でお願いします
Crypto++にいくつか入ってるようだ
200 :
デフォルトの名無しさん:04/09/26 17:02:35
,----、
/ /^ヽヽ
___/ . / | |ヽ__
∩ __ ヽ<(。)ヽ |..|.<ヽ_ |
.U_ ̄ ヽ | | .|__.|
`---,l ヽ .|/ ./
ヽ \____/
/ /\ ./
// | / `、/
 ̄~ |/ |
/⌒/ /⌒\
_/⌒/ (/___// ´ ̄ ̄ ̄\
,--´ ̄ / ___ \
唯一神デオキシス様が華麗に200get!!皆の者俺にひれふせい!
デオキシスは神!!ノーマルフォルムは「攻守のバランスが取れている」!!DEOKISHISU is god!! DEOKISHISU is god!!
>ファイヤー 消防や厨房にまで使われない雑魚は引っ込んでな(プ
>サンダー どんなに貴様がすばやくても俺を追い越すことは不可能だ!!(プププ
>フリーザー 一撃必中?心の目使った後逃げられなければな(ワラ
>エンテイ おまえ伝説だったっけ?弱すぎてしらなかった(w
>スイクン 強さもかっこよさも俺には勝てないってこった(ゲラ
>ライコウ お前は影が薄いんだよ(プゲラ
>レックウザ レゴブロックがホウエン最強なんてこの世も末だな(プゲラッチョ
>ラティ兄妹 バトルタワーでワラワラ出てきてどこが伝説だ?(藁
>レジ兄弟 伝説でもない壷に負けてるし(ピッ
>ミュウツー フリーザのパクリは消えな(^^
>ホウオウ 攻撃高くても物理攻撃少ないじゃねーか(ゲラゲラ
>ルギア エアロブラスト以外はたいした技ないな(プゲラオプス
悪タイプ様ツボツボ様テッカニン様カイオーガ様
すいません調子こいてました許してくださいおながいします
>>199 まあ学ぶのに良い機会だし、まったり作りな。
焦ったらすべて台無しになりかねない部分でもあるし。
×LiNDA
○LiDIA
>>201 そうですね。streamにかませられたらうれしいなぁということで、そっちの方向で実装してみます。
ありがとうございます
dsaの公開鍵ってどこで手に入るんでしょうか?
認証機関が発行している公開鍵アルゴリズムでは
RSAの公開鍵しか見たことないんです。
DSAのg, p, y(=g^x mod p)を入手してみたいんです。
> dsaの公開鍵ってどこで手に入るんでしょうか?
普通は手に入れるんじゃなくって自分で作るもん。
人のが欲しいんなら、たとえば PGP 鍵サーバでも漁ってみる。
>>204さんありがとうございます。
PGP鍵サーバから他人の公開鍵を手に入れることができました。
色々と手に入れて遊んでみます。
OpenSSLのツール群とかPGPとかGNUPGに
DSA署名の鍵生成コマンドがあったような
207 :
デフォルトの名無しさん:04/10/17 00:45:57
あげ
208 :
デフォルトの名無しさん:04/10/21 07:17:13
北海道
からお送りしますた。
Software Designの2004年11月号にCRYPTO2004のレポートがあった。
>>211 この前買ったのはCRYPTO 2003のレポートの回だったりしますか?
214 :
デフォルトの名無しさん:04/11/14 17:12:29
>>213 詳細は知らないけど、時間鍵って鍵を保管する信用機関がしっかりしてないと
駄目なんだろうな。
>>215 なんか、集計結果を機械に表示させたらおかしかったんで
再度処理を行ったらちゃんと正しい結果が表示されたとか
そういうオペレーションの問題だったそうです
217 :
デフォルトの名無しさん:04/11/17 09:19:23
公開鍵方式がよくわかりません。
誰か教えてください
>>217 情報処理技術者試験テキストでも読んでください。
公開鍵方式 の検索結果のうち 日本語のページ 約 39,000 件
>>217 共通の鍵を仲間内だけで共有する暗号運用方式。
安全な回線(携帯電話、E-mail等)で鍵を通知するのがポイント。
また、仲間に一人でも悪い奴がwいるとそいつが鍵を漏洩してしまい
暗号の価値が著しく低下するという欠点がある。
>>217 本とは秘密にするべき鍵を公開してしまう暗号。
暗号化に使う鍵を公開しちゃうってんだからすごいよね。
AliceちゃんとBobくんは交際を親に禁止されていてメールもできません。
共通の友達のCharlieくんにことづけて手紙をこっそりやりとりするのですが、
えちぃ手紙なのでCharlieくんにも読まれたくありません。
そんなAliceちゃんとBobくんですが、初めて出会ったときに(このとき二人は
一目惚れしたのですが、お付き合いすることになるとはまだわかりませんでした)
お互いに自分の公開鍵を書いた名刺を交換していました
(AliceちゃんとBobくんの名刺は数百KBを記憶できるICチップつきなのです)。
そこでAliceちゃんはBobくんへの想いを綴った手紙をBobくんの公開鍵で暗号化し、
Charlieくんに託します。Charlieくんは何が書いてあるかわからないながらも
手紙をBobくんに届けます。
Bobくんは無事にAliceちゃんの手紙を自分の暗号鍵で復号して、
二人の愛は深まるのでした。
文書ファイルFとかのハッシュ値を取るときはどうしてるんしょうか?
sha-1とかだと入力値は512ビットなんですが、
ハッシュ値を取りたいファイルFは512ビットよりも大きいわけです。
これは、Fの頭から512ビット毎にハッシュ値を取り
そのハッシュ値全てをxorすることで
Fのハッシュ値ということにしているんでしょうか?
>>223 ファイルを512bitごとにブロックに区切り
まず固定の初期値160bit(IV値)と一番目のブロックを入力として160bitの出力を計算
次にその160bit出力と二番目のブロックを入力として160bitの出力を計算
・・・
これを最後のブロックまで繰り返す、そうです。
そんなの適当なSHA1なりMD5なりの使い方みりゃ嫌でもわかるわけだが
226 :
デフォルトの名無しさん:04/11/22 15:07:25
>>222 あらかじめ共通の秘密鍵を交換しておくのとどういう違いがあるの?
>>227 親に報告したら烈火のごとく怒り出し、あの放蕩息子と会うことまかりならん!
と即座に連絡手段を失ったと思いねえ。
ついでに名刺に入れるICチップはコストが重要なのでCD-ROMと同様に作成時に
内容が固定されるという設定も追加しとく。
保守します。
231 :
デフォルトの名無しさん:04/12/10 14:51:33
おらおらねたはないのか?
232 :
デフォルトの名無しさん:04/12/10 15:53:45
233 :
デフォルトの名無しさん:04/12/10 17:18:55
サル並のIQでもわかる楕円曲暗号の仕組みについて解説してる
サイト下さい。
それと楕円曲暗号ってJDKライブラリぐらいしか使える汎用ライブラリってないですよね?
235 :
デフォルトの名無しさん:04/12/10 18:38:30
>>234
うおーサンクスコ
オナニーしながら読んでみるよ
神戸は寒いだろうな…
私は頭が寒いです。
blowfishについてなんですが、
Cのソースコード等はグーグルでよく見かけたのですが、
設計書を見つけることができませんでした。
どなたかpdf形式の設計書のある場所を
ご存知の方はおられませんか?
ありがとうございます。
>>239さんの紹介を元にblowfish作ってみます。
トリップ検索をするソフトの使用方法が詳しく載ったサイトを教えて栗
ぐぐれ
ぐぐり方の説明が詳しく載ったサイトを教えて栗
予想通りのレスありがとう
無視されたらどうしようかと考えてたよ
>>245 いやー、まいったなぁー。
ついうっかりはめられちゃったよー。
乱数生成についてなんですが、
ソフトでの乱数はNG
物理乱数生成器を必要としています。
ttp://www.fdk.co.jp/whatsnew-j/release041005-j.html 物理乱数生成USBモジュール「Random Streamer」
グーグルの検索で上のような乱数生成器を見つけました。
私が他にぼんやりと記憶している乱数生成器は
泡の動きを測定して乱数として出力するという
ラヴァランプなるものです。
ラヴァランプの情報又は
他の乱数生成器をご存知の方はおられませんか?
接続デバイスはUSB2.0対応を希望します。
しかし車輪の仕組みを知ることは車輪を利用する上で役に・・・・立たないか
250 :
デフォルトの名無しさん:05/01/11 15:50:17
age
251 :
デフォルトの名無しさん:05/01/14 00:32:54
SCIS参加者点呼age
252 :
デフォルトの名無しさん:05/01/17 01:10:08
暗号とはちょっと違うのですが、
MD5のハッシュ関数に関する話はここで良いのですか?
>>249 C言語の仕組みを知ることはC言語を利用する上で役につだろ
>>252 よりふさわしいスレがあるわけでもないからここでいいよ。
>>249 役に立つに決まっているだろう。
車を引いて重い荷物を運ぶという発想すら浮かばないに違いない。
256 :
252:05/01/17 02:41:11
Windows用のアプリでMD5ハッシュを使おうと思っています。
MS製等で一般的に認知されているMD5ハッシュ作成APIという物はあるのでしょうか?
自作しても良いのですが仕事で使用するので信頼できる物があればそれを使用したいと思っています。
調べた限りではソースや個人が作ったシェアウェアのDLLはあったのですが、
そのまま使っても良いのか悩んでいます。
MD5は時代遅れSHA1使え。
MS謹製の物は.NET Framework版のみ。
C/C++&Win32の物はたぶんない。
BSDLなOpenSSLのソース落として使うのが無難。
MD5はどこにでもあるから適当なもの使え。
OpenSSLはBSDLといっても宣伝条項つきなのでやめた方がいい。
.NET Frameworkの適当な言語でDLL作って
それをC/C++から呼ぶ事はできますか?
最強にして最後の暗号はXOR
というかCryptAPIの知名度が低すぎ
最初のリリースのときもひっそり登場してたし
なんでだろ?
きっと著作権絡みだ
問題があるに違いない
問題なのかどうかはわからないけど、
Windows Media とかのコンテンツ暗号化みたいな Kernel mode 使った奴と違って
単なるdllでの実装だから、クライアントサイドでは容易に cheat 可能ってあたりが
一般配布用AP作る人にとっては使いにくいところではあるよね。
265 :
252:05/01/17 12:30:11
みなさん有り難う!!
CryptAPIを使ってみます。
>>256 私が作ったものでよければあげるよ
ソースつきで。
MD5はつくってないけど。
sha-1, sha-128, sha-384, sha-512
作ってる
糞コードでも起こらないでね
糞コードだったら自分で改造してね。
商用でもOK
>>266 信頼性を求めているのに、信頼性のないソースを提供してどうする。
>>253 C言語の仕組み?機械語に翻訳する仕組みか?
C言語を普通に使うだけなら無用
だから自分で改造したらいいじゃないかと。
ソースつけるんだから。
商用もOKよと。
ただ、私のコードでは世間に出回っているのよりはるかに低速なので
マさんに高速化の方法を教えてもらいたいということなのです。
>>270 MD5 のソースなんて RFC にすら載ってるじゃん。
なんでわざわざ改造しなきゃならんのだ。
しつれいしました。
暗号周りのルーチンを自分で書いて使うやつの気が試練
勉強
勉強のために書くのはいいけど、それを使うのはどうなのよ、という、
クラックの勉強だってば
初期化ベクタが常に同じだとなんで解読できるんだろう…。
初期ベクタは隠さないからね。
暗号文の頭にそのままの形で置かれる。
IV CBC 初期ベクトル
くらいでぐぐってみなよ。
>>269 むしろ、C言語だからこそ必要な気もするがスレ違いかも。
「オレオレ証明書」ってネーミング、いいねえ
高知県の扱いがもはやあれだなw
しまった!
ここ高木先生のスレッドじゃなかった。
誤爆すまそw
wikipediaの暗号理論の項目も
ちょっとずつ充実してきましたね
著者の皆さん乙
>289
(・∀・)帰れ!!
>>289 そのスレはときどき巡回してまつ。
ただ、ウチとは領域が違うのでついてけないケド。
>>232 thx
ブログサイトでも、暗号や情報セキュリティ関連の用語が
キーワード登録され始めてますね
AESの強度ってどのくらいなんでしょうか?
2001年頃にDESに変わる暗号としてAESが出てきたのですが..。
DESよりかは強力だとしても現在のコンピュータの計算能力が相当向上しているし、
以前は手軽にできなかった分散コンピューティングも個人でできる規模になってきましたし..。
それに新しいだけにその安全性が未知のような気がしています。
AESを詳しく解説している、どこか良いサイトか書籍はありませんでしょうか?
AESの評価プラットホームが、
* IBM PC互換機, CPU Pentium Pro 200Mhz, メモリ64MB
* Windows 95, Borland C++ 5.0コンパイラ, JDK 1.1
ってなんか現在の状況ではこころもと無い気がする。
>>295 そのマシン環境でのブルートフォース結果等を基準として
見ているって事でそう言いました。
なら自分で試してみるのが一番だな
>>294 そりゃ暗号・復号アルゴリズムの速度やメモリ使用量を評価するための環境だろうよ。
暗号強度はマシン速度が 100倍になろうが 1000倍になろうが 1万倍になろうが
ビクともしないよ。
>>294 今のコンピューターアーキテクチャーだと、地上の全てのエネルギーと太陽のエネルギーを計算機の計算に利用しても
ブルートフォースが出来ない、っていう熱量限界の話もあるらしい。
計算機の発展よりも、まずは解読アルゴリズムの発展を心配すべきだな。
>>301 じゃNondeterministic Turing Machine使えばいいじゃん。
304 :
デフォルトの名無しさん:05/02/02 20:31:09
熱量限界の話だけど
たしか0〜2^128まで
カウントすることすら不可能だったと思う。
0,1,2,3,4,・・・・・・・・,(2^128)-3,(2^128)-2,(2^128)-1,(2^128)
こんな感じ
>>305 「暗号技術大全」
7.1 熱力学的限界
によれば、
・熱力学の第二法則により、情報を表現するためには一定量のエネルギーが必要
・ある系の状態が1bit変化したときにも、それを記録するために最低でもXXXのエネルギーが必要(物理法則が否定されない限りこれを下回れない)
・太陽のエネルギー全部(YYY)をとってきて、ビットカウンタを回すのに使ったとして、一年間のエネルギーで187bit分回せる(YYY / XXX ≒ 2 ** 187)計算になる
・理想状態でもこれだから、太陽のエネルギーのごくごく一部しか使わず(yyy ≪≪≪≪ YYY)、カウンタを回す以外にも様々な計算をする(xxx ≫≫≫≫≫ XXX)場合、計算量(yyy / xxx)は理想状態と比べてすごく小さい
・というわけで、128bitくらいあれば、しらみつぶし攻撃に対しては、どんなにコンピュータが速くなっても永久に安全だろう
というお話。
>>306 > 「暗号技術大全」
持ってた。読んでみた。
RC5-72 なんかは 72bit だからまだ何とかなってるけど、128 だの 256 だの
になったら、もうお手上げってことでしょ。なんか冗談っぽいんだけど、ほんまなんかね。
たとえば石油 1ガロンからとれるエネルギーでは何 bit まわせるんだろう。
> なんか冗談っぽいんだけど、ほんまなんかね。
対数スケールを甘く見たらあかん。
72が73に増えただけで2倍だ。
72が128に増えたら約72京倍だ。
コンピュータが1000倍速くなっても全然足りない。
>>308 いや、計算量は確かにそうなんだけど、熱力学的に〜って言われるとピンとこない。
要するにエントロピーだろ?
なけなしのガソリン1リットルで車で地球一周できるかどうか計算してみたらムリですた
てな感じだろ
>>306 多世界解釈派の漏れにはそんなの何でもないこと。
鍵が間違っていたら爆死する装置(誤動作の確率2のマイナス128乗以上)を作成して、
適当にランダムな鍵を入力するだけ。鍵が間違っていた世界は漏れにとっては消滅
するので、生き残りの「漏れ」は正しい鍵を手にできる。
生き残りでないの「漏まえ」はどうなる?
汚まえな。
orz
なぜかディスプレイがいかれた
McEliece暗号を秘密鍵にするのってどうよ?
McEliece暗号を秘密鍵にするのってどうよ?
McEliece暗号を秘密鍵にするのってどうよ?
McEliece暗号を秘密鍵にするのってどうよ?
うんこ
>>306 しらみつぶしっていうと確かに膨大な時間がかかるわけだが、
そんなの理論上の確率の問題であって、
何十台ものマシンを並列に稼働させてランダムブルートフォースを
かけた場合に偶然にも見つかる事もありうるって事でしょ。
あとさ〜、あるデータを暗号化した後にさ〜
チェックサムとかさ〜なんかそんなもん暗号化したデータに付与するのあるじゃん?
あれってさ〜キーの手がかりを与えてねーか?(キーの検索に手がかりを与えてるって事)
そんなチェックサムいらね〜と思うけどほんとのところど〜なのよ?
ちなみにブルートフォースの目的って全てしらみつぶしにする事が目的ではなくて、
キーを見つける事だよ?
>>326 「偶然にみつかる確率」を減らすために充分な長さの鍵長の話をしているのに
「偶然にみつかるから可能性があるからダメ」じゃ会話になってないと思うのですが。
>>327 普通はチェックサムもまとめて暗号化すると思うのだけれど、
チェックサムが暗号化されていないなら解読結果の成否チェックが楽になるね。
>>326 確率の問題。
2^128≒10^38
秒速1兆個のキーを解析できるマシンを1兆台。これでもかなり無理があるが、
それを1兆秒、およそ32500年間回したとしても、キーが見つかる確率は、まだ確率100分の1以下。
>>329 解読結果の成否チェックが楽になるとい意味では暗号化されていても一緒か、失礼。
>>326 可能性が0ではないというのは確かに正しいが
簡単に試算してみれば、考慮するのが如何に馬鹿馬鹿しいか分かる
短いレスが数個に分かれてるあたり、脊髄反射であることが伺える
>>326 暗号の世界での「安全」の意味を勘違いしたね?
現実的な時間と予算内に現実的な確率で解(鍵や平文の全部または一部)が得られることがない、
という意味で、絶対に解が得られることはない、という意味ではないよ。
っくりわれめ女子小学生の動画をシーザー暗号で送ってください。age
uuencode して、から、シーザーでおながいします。
暗号化されたままのものを、uudecodeしたら、quick timeでerror
が出たので、大丈夫だと思います。
池沼晒しあげ
>>336 どうぞ。
1d472d2063421064bfbb05f4fbc6146a
「セキュリティは製品じゃない、プロセスだ。」
Rijndael使ってみたいけどS-Boxで躓いてしまった
ごめんね。ママ初めての暗号だから、ごめんね
Hash! Hash!
>>344 0xF*0xFの表作ってあとは上位ビットと下位ビットをごにょごにょしたら良いんじゃね?
岡山の
本屋さんは
悠々自適な生活でうらやましい
意味わからんじゃが
岡村隆史って休日は
本を読んだりして
悠々としているらしいよ
はぁ?
しったかぶってんじゃねーよ
ねるぽ
>348 >350-351
よくわからんがよそでやってくれ
>>354 だからMcEliece暗号を秘密鍵で使ったらどうよ?
ってこと。
かなり強力だとは思うのだが・・・
秘密鍵McEliece暗号。
もちろんやってますが。
くそ扱いされるのは腑に落ちない・・・
>>353 「解読」って・・・あんな露骨な縦読みで・・・
いいからよそでやっててくれ
アンカーまで付け間違えてるし
まぁ enigma 解読でもそうだったように、暗号解読においては平文に
書かれているないようを推測したり理解したりすることは非常に
重要ってことで。
>>362 >われわれは、アメリカ政府官僚が意図的にDES暗号の強さについて誤解するよう
>にしむけているのだと考える。その狙いは:
> * 市民たちにDESを使い続けさせて、政府機関が市民たちを盗聴できるようにする。
> * 政府が解読に苦労するような、DESよりもっと強力な暗号規格が広がるのを防ぐ。
> * DESの輸出可能性を取引材料としてちらつかせる。これは政府にとってはコストが
> ほとんどないけれど、価値があると思われている。
> * 議員や大統領など、政策立案者たちに、法執行機関が暗号化データでとても困っていて、
> それを解読する現実的な方法がないと思わせることで、キーリカバリなどのとんでもない手法を採択させる。
十分ありそうな事だな
あげ
367 :
デフォルトの名無しさん:05/02/22 23:46:21
暗号通信などに用いられる「SHA-1」の攻撃を容易にする研究が公表
サンフランシスコで開催中の「RSA Conference」の
パネルディスカッションにおいて、
認証やデジタル署名などに用いられるハッシュ関数「SHA-1」に対して、
中国の研究者グループが攻撃に要する時間を
大幅に短縮する方法を発見したことが明らかにされた。
SHA-1は、原文から160ビットのハッシュ値を作成する関数で、
通信を暗号化するIPSecなどで広く用いられている。
ハッシュ値は原文のダイジェストにあたるため、
ハッシュ値から原文を復元することは不可能だが、
あるハッシュ値と同じハッシュ値を持つ原文が作成できれば、
文書やプログラムの偽装が可能となる危険性がある。
中国の研究者グループは、こうしたハッシュ値の「衝突」の探索について、
総当たり方式では2の80乗回の試行が必要であるのに対して、
2の69 乗回以下の試行で行なえる方法を発見したとして、
配布しているサマリーではSHA-0と58ステップの
SHA-1について衝突の実例を示している。
なにもコピペしなくてもリンク先読めばいいのでは思うのだが..
「文書やプログラムの偽装」ってなんじゃ?
読んで字のごとくだろ
いや、この文脈で「偽装」って言葉はほとんど聞かないから
気になったの。
まあマスコミなんて(ry
じゃあなんて書くんだよ
>>371 「(デジタル署名された)文書やプログラムの○○」と書くなら、何にするべき?
改竄
「改竄」だと主旨と合わない気がする。
>>372-373 む,言われてみると「偽装」という表現が
一言で表すにはぴったりのような気がしてきました・・・
impressの中の人よ,すまなかった
・・・
ぶらくらはやめれ
セキュリティは製品じゃないプロセスだ
382 :
デフォルトの名無しさん:05/03/17 14:10:25
Linux で書いてるプログラムの中で、ファイルのMD5値を求めたい
のですが、なんという名前のライブラリにMD5値を計算する関数は
入っているのですか?
md5.h
md5.c
crypto/*
シリアルキー解析集「ALTEA」
大好評発売中!
http://openuser10.auctions.yahoo.co.jp/jp/user/dancexxx1960? 市販SOFTやオンラインSOFTのパスワード集です。
オークション関係から画像・OS・表計算・CAD・・・・etc
国内・国外のあらゆる分野のSoftを解析済です。
これを初めて手にされた時には、驚愕される事でしょう。
そして・・・手当たり次第にインストールを始める筈ですw
パソコンをご使用の方なら、必ず!満足されると思います。
解析結果のデータベースには15,000点を越えるパスワードが入ってます。
このパスワード集から検索するだけで、登録や制限解除が出来てしまいます。
シェアウェアを購入して、正規登録したのと同じ状態になります。
余りにもデータが多すぎる為、辞書引のようなパスワード検索SOFTで提供します。
シェアウェア以外にもパッケージ版をVectorなどでオンライン販売してるSOFTにも
多数対応しています。これらをダウンロードして無期限に試用する事も可能です(^^;
WindowsXPやOfficeなどのCDキー(プロダクトキー)ジェネレーターを使えば複数のパソコンに
インストールする事も可能です。デスクトップとノートPCなど2台以上持ってる場合は特に有効ですね。
オンラインSOFTを購入した経験は有りますか?
ありとあらゆる分野の優れたSOFTが、数多くありますよね。
しかし、ほとんどが試用期間や機能制限をして、「気に入ったら購入してください」です。
もう少し使いたいが使用期限切れで、削除・・・再インストールを繰り返していませんか?
386 :
デフォルトの名無しさん:int 2ch =05/04/02(土) 13:21:47
俺は人類最強の男というコピーに引かれ
人類最強になるためにはどうすればよいのか考えた
人類最強なのだからどんなこともできる
手始めに全裸で姉の部屋にアンゲロ、アンゲロとつぶやきながら飛び込む
タンスをこじ開けブラジャーを腰に巻きパンティーを頭にかぶる
姉が呆然としながら見てくるが人類最強なので気にしない
姉のベッドに潜りこみ「幸せだから!幸せだから!」と絶叫
姉は無言で部屋から立ち去る
だがまだ最強には不十分
次は妹の部屋にムッシュムッシュと叫びながら飛び込む
妹は着がえをしている最中だったが人類最強なので無視
半裸で逆立ちをしながら
「俺に充電しろ!!俺に充電しろ!!」と絶叫
妹は大泣きで退散
確実に人類最強に近づく
開脚後転でトイレに飛び込み便座を外し首に掛ける
ゾンビの真似をしながら母の部屋に突撃
タンスを開けると一枚の写真発見
死んだ親父が俺を抱いている写真発見
俺は泣いた
神の暗号の解き方で説いてみて
なにかでてきますよ
387 :
デフォルトの名無しさん:2005/04/06(水) 11:15:21
1.あるシステム固有の情報ファイルのバイトコードを16進数の0x00から0xFFの値で取り出す。
2.プログラム言語にある乱数出力というものを使って、0x00から0xFF個の一意な乱数値を取り出す。
3.1で取り出した0x00〜0xFFまでの値を2で出力させた乱数値の出力された順番とで置換させ、暗号化ファイルを作成。
4.2で作成した複合化テーブルの情報を持つ複合化モジュールと暗号化ファイルをいっしょに保管。
5.実行時は、複合化モジュールからプログラムが開始され、暗号化ファイルは内部で複合化されることで機能する。
....問題は、4で作成した複合化モジュールが解読される事だと思うのですが、どうでしょう?
388 :
デフォルトの名無しさん:2005/04/06(水) 11:38:51 BE:115689986-#
389 :
デフォルトの名無しさん:2005/04/06(水) 12:20:25
置換暗号は暗号に使う数列をもっと長くしないとダメじゃない?
256個じゃすぐに解かれちゃいそう。
難しい話はいいから、車検証のQRコードの暗号を解いてくれ
>>389 てゆうか置換暗号はどこまで行っても置換暗号なわけで。あまり役に立たないと思う。
393 :
デフォルトの名無しさん:2005/04/15(金) 11:10:57
ワンタイム・パッド方式だって置換暗号でしょ。
暗号表が無限長だったら置換暗号でも十分。
自分だけが使う暗号なら適当な乱数列でも生成してワンタイムパッドがいちばん安心だよなぁ。
適当な乱数列なんてどうやって生成するのかわからないが。
別の文章との差分を鍵にするっていうのもいいかな。
まあいずれにしろ鍵の管理は大変になりそうだが。
適当なseed値のrandの出力でいいじゃん
>>393 そんなのじゃ全然使い道がないではないかw
”無限長”って、いったい何?
それは「ファンタジー暗号」だよきっと。
>>396 要は送受信双方でリアルタイムに好きなだけ同じ
乱数列が作れればよい。
そしてそれは量子暗号通信で実用化されつつある
量子暗号かよ。
量子暗号が可能なマシンはどこで買えますか?
余談だが
量子通信では直接任意のビットを相手に送れる訳ではない。
エンタングルメント(量子絡み合い)で結び付けられた
離れた2地点で同じ乱数を生成できるというのがミソ。
これは量子力学の不確定性原理に基づく「本物」の乱数だ。
これを利用して並行する別の通常回線で
ワンタイム・パッド暗号(スクラッチパッドとも言う)で送信する
というのが量子暗号通信の原理だ。
ところでこの
エンタングルメントは間に第三の観測者(装置)が挟まると壊れてしまう。
そうすると生成される乱数は一致しなくなるが
これはプロトコルの工夫で検出できる。
これが「盗聴不可能」と言われるゆえんだ。
エンタングルメントの安定性や速度にまだ問題があるから
実用化されてはいないが
すくなくとも「ファンタジー」からは脱していると思うよ。
量子暗号に詳しく無いんで聞きたいのだが、
2点間でのセッションが確立した場合はそりゃ最高な強度の暗号通信になるが、
セッションが確立する前は相手が本物かどうかってどうやって証明するのさ?
そこでPKIですよ
おサルさんに返答させて相手が本物かどうか当てる有名なテストですね
404 :
初心者(免罪符):2005/04/26(火) 10:05:53
md5とか色んな暗号化方式でハッシュ値を生成するアルゴリズムが
できれば日本語で載ってるサイトはありませんか?教えてくださいお願いします
405 :
デフォルトの名無しさん:2005/04/26(火) 10:21:24
テレビ欄のGコードってハッシュなのかな?
>>405 ハッシュってのは一方向関数。つまりハッシュ値から元に復元はできない。よってGコードはハッシュではない。
Gコードなんてうまく細工したただの圧縮なんじゃない?
>>406 ウソいっちゃいかん。
情報量を保つ必要がないから大抵は一方向になってるだけ。
質問自体は暗号と関係ないな。
まずは自分で実験してからC言語の質問スレへでもどうぞ。
いや実験したんだって。途中いろいろと書き換えてるから確信ないので訊いてるんですが何か?
>>410 > 途中いろいろと書き換えてるから確信ない
そういうのは実験とは言わん罠。少なくとも理系では言わない。
vector辺りに行って適当なフリー祖父と落として故意。
413 :
406:2005/04/26(火) 16:32:59
>>407 一方向じゃないならハッシュとは呼ばないだろ。それじゃただの符号化。
やっぱり俺の思った通りだったぜ(プゲラチョフwwwwwwwww
電話番号の先頭20桁を取り出したものもハッシュ値だ。
一方向じゃないならハッシュとは呼ばないだろ。それじゃただの符号化。
一方向じゃないならハッシュとは呼ばないだろ。それじゃただの符号化。
一方向じゃないならハッシュとは呼ばないだろ。それじゃただの符号化。
ハゲワロスwww
417 :
406:2005/04/26(火) 17:39:09
>>416 符号化と言ったのはちょっと違ったかもしれんが、ハッシュの定義自体はあってると思うけど?
だいじぇすと
420 :
デフォルトの名無しさん:2005/04/26(火) 20:28:43
暗号を使う際に併用するハッシュ関数は一方向性が必要とされる。
他にも非衝突性も必要。
ハッシュ関数はある規則にしたがってある数値を変換したもの。
h(M)=M+1
こんなhもハッシュ関数となる。
>406は暗号で使うハッシュ関数と世間一般で使うハッシュ関数の区別がついていないと思われ。
421 :
406:2005/04/26(火) 22:28:55
>>420 >>h(M)=M+1
これじゃ全ての関数=ハッシュ関数ということにならないか?
すべての値はハッシュ値として使えると言う意味で「なる」。
# 引数を取りその引数に一意に対応する値を返すのであれば
それが実用に耐えるかどうかは別の話。
423 :
406:2005/04/26(火) 22:39:42
なるほど。理解した。
俺すげぇ事思いついた
ファイルの内容をすべてハッシュとすれば
f(x)=x
衝突なくなるんじゃね?すごくね?
逆に
f(x)=0
とすれば絶対にもとのデータを復元できなくなるんじゃね?すごくね?
しかも1通りしかないんだから、1ビットも送信する必要がない。
>>420 嘘つけ。一万歩譲ったとして、それは超広義のハッシュ関数。
「暗号の代数理論」にはこうある。
ハッシュの大雑把な定義は以下の通り。l個の記号の集合から k 個の記号の集合
への関数 H(x) がハッシュ関数であるとは、任意の x について H(x) を計算する
のは容易であるが、次のような性質を持つときである。
1) 同じ H(x) を与える 2つの異なる x の値を見出すことを実行できない ("衝突耐性"), かつ
2) H の像の中の y を与えられて、H(x)=y であるような x を見出すことを実行できない ("原像耐性").
428 :
427:2005/04/27(水) 01:38:12
つーか、「hash」しないのものはハッシュ関数とは言わん。
hash関数を作ったとして、衝突耐性や原像耐性はどうやって検証するんですか
だからそれは「一方向」ハッシュ関数だと何度言わせれば・・・
だけど元々のハッシュの意味が生きている計算機科学の中の一分野だからねえ。
実際「一方向ハッシュ関数」と明示する人の方がほとんどでしょ。
ハッシュテーブルすら自分で実装できないおこちゃまは知らんけど。
ハッシュる、ハッシュる。
ハッシュ関数の中で、(略)の性質を持つものは暗号技術に利用される。←正しい
(略)の性質を持つ関数をハッシュ関数という。←間違い
暗号技術を論じている中でハッシュという用語を用いたとき、暗黙に(略)の性質を
仮定するのは構わんと思うが、勝手にハッシュの定義まで変えてしまうのは迷惑。
435 :
デフォルトの名無しさん:2005/04/30(土) 13:47:12
436 :
デフォルトの名無しさん:2005/04/30(土) 13:50:54
CRC32とMD4って、どっちが耐衝突性に優れてますか?
まあMD5やSHA1が使える状況ならそっちにしますが。
CRCは無いに等しいだろ。MD4も容易にコリジョンを発生させられる。
どっちがましかといえばMD4だろうけどどっちも優れてはいない。
438 :
デフォルトの名無しさん:2005/04/30(土) 14:10:54
そりゃ32bitだし理屈は判るけど、
なんでもかんでもMD5とかだと遅くなるし
32bitとか64bitとかケチらずにもっと多くのビットをさいたらどうよ。
ファイルの一意性を扱うバックアップソフトみたいなソフトを作ってて、
パフォーマンスもある程度重視してるだから、衝突が起きた時点で
初めてより精度の高い奴使いたいんだよね。
まあ二度手間といわれればそうなんだけど。
してるだから→してるから
一次ハッシュ->ファイルサイズ
二次ハッシュ->MD5
以上。
いや、もちろんファイルサイズを最初に見てるけど、
それだけでは頻繁に衝突するんだよね。
問答無用で全ファイルのデータ舐めるのと
衝突上等でサイズだけ見るのとでどっちが速いかなんて
実測して統計データとって見ないとわからないだろ。
ただサイズの衝突がよくあるといっても
後者のやり方の方が結果として計算量とディスクIOが少ないと
予想するからそう提案しただけ。
うん、ありがと。
447 :
デフォルトの名無しさん:2005/05/01(日) 18:31:28
sha1の512倍の性能か!!
448 :
デフォルトの名無しさん:2005/05/01(日) 20:14:35
( ´゚д゚`)えーーー
結局サイズが同じ大きなファイルが結構あるので、
先頭4096バイトだけのチェックを加えました。
一次ハッシュ ファイルサイズ
二次ハッシュ 先頭4096バイトまでのMD5
三次ハッシュ フルサイズのMD5
お、頭いいね
>>449 それなら二次ハッシュにCRCとかの処理軽いやつを使った方がいいんでない? どうせCRC32なら衝突確率は42億分の1だし
>>451 ファイル全部のCRC? ファイルアクセスの遅さが効いてくるから別に嬉しくないだろ。
大きいファイルほど、そんなことするなら最初からMD5を計算する方がマシ。
小さいファイルや先頭4096バイトだけの計算ならCRCだろうがMD5だろうが
大して変わらんから意味がない。
453 :
451:2005/05/10(火) 08:30:43
>>452 2次にCRCで3次にMD5って意味です。
2次にMD5使うのはちょっと重そうかなと思ったんだけど・・大して変わらないと言われればそれまでです。まあ実装者の気分次第ですね。
sha512使っとけ。
コリジョンのことを考えればこっちの方が速度面でも効果的。
>>454 opensslで簡単にベンチマーク取れるから試してみろ。
SHA1でさえMD5より3倍遅い。
456 :
デフォルトの名無しさん:2005/05/11(水) 00:27:06
安全性 > 速度
金言ここにおいておきますね。
>>456 いや、コリジョンなんてそう起こらないし...
この前のコリジョンの発表、何か勘違いしてない?
つうかそれ以前にsha512のが速いと454がきっぱり言い切ってるわけだが。
adlerって使える?
コンピュータ暗号の基礎を学べる本を紹介してください
暗号技術大全かアリス買っとけ
暗号技術大全は高いよ
なぜか近所の図書館にあったりして謎だ
きっと近所にすごい発火ーがいて借りてるんだよ
本物の刃火ーは知の富豪者だが貧民生活者でもある。
467 :
デフォルトの名無しさん:2005/05/13(金) 20:10:57
すんません、
OpenSSLで使われてる暗号って何ですか?
SHA1?
大抵の暗号は実装されてる。ついでにいうとSHA1は暗号ではない。
469 :
デフォルトの名無しさん:2005/05/14(土) 07:25:18
OpenSSLはなんであんなにわかり肉印ですか?
なんか証明書のディレクトリきめ打ちで糞っぽいし。
最初アホかと思いました。
今でも思ってますけど。
ソースからビルドしたまえ。
インターフェースがアホというのは同意。
471 :
デフォルトの名無しさん:2005/05/14(土) 08:18:17
OpenSSLじゃなくて
オナニーSSLに改名したらどうかね
472 :
デフォルトの名無しさん:2005/05/14(土) 08:20:54
「Intel Pentium 4のHyper-Threading機能に脆弱性が存在する」というニュースが
あちこちで話題になってますね。
ちょっと調べてみましたが、キャッシュ攻撃とか
キャッシュミス攻撃とかいう手法だそうで。
ここ最近のSCISでも、いくつか発表がありますね。
>「Intel Pentium 4のHyper-Threading機能に脆弱性が存在する」というニュースが
そういうの"タイミングアタック"っていうらしいな。
475 :
デフォルトの名無しさん:2005/05/15(日) 12:43:14
OpenSSL分かりにくいって?
証明書のディレクトリ決め打ちっていうのはないでしょ?
柔軟性のために分かりにくいと言うんなら
勉強足りないと思うよ
ハッシュが衝突した場合ファイルが上書きされてしまう危険性のある
アプリってありなのか?
上の方のバックアップネタを眺めててちょっと気になった。
上のアプリがそうなのかどうかは知らないけど。
納得して使うならいいんじゃない?
まあもし衝突したらよっぽど運が悪かったんだろうよ。
MD5クラスの衝突を心配するなら完全一致比較した方が良いだろうし。
作為的に同一サイズのMD5衝突ファイルが作れるツールが出来たらヤバイね。
ヤバイどころじゃねぇって
暗号化ZIPファイルをCプログラムから作成する方法を教えてください
そこはかとなくスレ違い
MD5のコリジョン頻度ってどのくらいなんでしょうか?
平文(原文)のサイズ等と相関あるのでしょうか。
与えられたMD5を得る、衝突する平文を任意の数得られるアルゴリズムは存在するのでしょうか。
存在するとしたら、その衝突する原文が存在しうる全てを導出可能なのでしょうか?
突っ込むとこ多過ぎなんだけど、釣りなのか?
とりあえず、
> 与えられたMD5を得る
と言ってる時点でそれは衝突ではない。
おまいらさ、MD5のコリジョンとか言ってるけどよ、コリジョンがあった無かったよりも、
データを改窮してオリジナルデータと同じハッシュ値を生成できることが脅威なんじゃないのか?
要するにさ、任意のハッシュ値を自在に作成できるかどうかって事だよ。
できんのかそれ?
コリジョンは脅威ですよ
>>484 だから、そのコリジョンを制御して脅威になりえる例をぷりーず。
衝突するのを前提で作られてるわけですが
>>483 それはまだ見つかってない。
ただし同一ハッシュを生成する二つの(たぶん意味のない)データを
発生する方法は見つかってる。
これを悪用するのは難しいと思うが。
ハッシュ値が等しくなるデータ(A, B)を容易に生成できた場合
ファイルに署名 := ファイルのハッシュ値を取って,その値に署名
みたいな署名方式だと,Aの署名を署名生成オラクルに作ってもらえば
オラクルに要求していないBの署名も手に入ることになる.
はい,選択文書攻撃成功
ハッシュ値は1024bitもないというツッコミはまた別の話
>>487 そうです.問題なのはそれが簡単に見つけられるかということです.
簡単に見つけられるようなもんを、みんな使ってるとでも思っているのか?
偽の実行可能なデータができなけりゃ大丈夫と思ってる俺はかなりいい加減
簡単に見つかったら衝突前提で作られてるとはいえないわけですが
>>493 そうでしたか.
>>483の問いに「コリジョンを容易に生成できたとして,脅威になるのか」
が含まれていると思ったんで,
>>484では
>>489の意味で
>コリジョンは脅威
と言ったんですが
(コリジョンが存在すること自体が脅威である,という意味ではない)
舌足らずですいません
>>496 ハッシュ関数の衝突困難性は、暗号・署名の安全性に
深く結び付いているってことです
恐らく、
>>483が言いたかったのは、
>容易に生成できた場合
↑この瞬間が脅威になるんじゃないのって事を言いたかったと思ふ
そりゃ脅威だろ
つうか役にたたないだろそんなハッシュ
>>499 えーと、
>>483で
「一方向性を破られるのは脅威だが、それに比べると衝突困難性を破られるのは
そんなに脅威とは思えない。あるハッシュ関数の衝突困難性が破られ
コリジョンが制御可能(コリジョンを起こす入力の組を容易に求められる)に
なったとき、こんな脅威が起きるという例を具体的に出してほしい」
と言ってると思ったんで、その脅威の例を説明してみたんです。
ですので、
>>491や
>>493が何に突っ込んでいるのか正直よく分かりません。
「衝突困難性を満たさないハッシュ関数は、セキュリティ上こういう問題がある
(だからそういう意味でも実用的とはいえない)」と言っているのであって
「実用的なハッシュ関数とはいっても、中には衝突困難性を満たさないものがある」
なんてことは一言もいってないのですが
>思ったんで
思い違いだと思ふ
MD5に弱衝突耐性に問題はないのかと聞いてるだけ。
すると
>>486はどういう意味の質問だったんだろう?
>490 で言い切らなかったもんだから >491 >493 が補強しただけだと思う。
言わんとするところはみんな同じだろ?
505 :
デフォルトの名無しさん:2005/05/29(日) 01:01:43
自プログラムで IVが必要なアルゴリズム使うときは
>>279 が言うように ファイルヘッダに置くのが一般的?
opensllコマンドとかたぶん そーなってるっぽいが。
>>504 なるほど了解です
長々と引っ張ってしまってすいませんでした
オープンスルル!
DVDの暗号(鍵?)が解読されてしまった経緯について詳細にまとめてあるサイトがあったら教えてください。
馬鹿がいた。それが大きなヒントになった。
510 :
デフォルトの名無しさん:2005/06/21(火) 12:57:23
opensslで作成したPEM形式の秘密鍵ファイルから
個別に値(n, e, d, p, q, dmp1, dmq, iqmp)を抽出するプログラムを作りたいのですが、
どのようなルールで出力されるんでしょうか。
手作業でそれぞれの値を抽出してみたんですが、
デリミタがどういうルールで設定されているのかイマイチ分かりませんでした。
511 :
デフォルトの名無しさん:2005/06/21(火) 17:36:23
>>510 PEM_read_RSAPrivateKey でいいじゃん。
513 :
510:2005/06/21(火) 20:57:20
>>512 .net だったんでしばらくあがいてたんですが、
どうにもこうにもいかなかったんで libleay32.dll 経由でやることにしました。
有難うございます。
多倍長整数ライブラリを完成させるプログラム力って
情報工学科学部生の何回生くらいで身につけることが可能でしょうか。
できる奴は小学生。できない奴は一生無理。
授業の課題として出るかどうかってことなら、大学1〜3年くらいじゃん?
あと、情報工学科はプログラム力を付けるところじゃないよ。
メモリ効率を気にしないなら簡単に作れる
速度もな。
自分で下手な独自実装してもバグはありまくりだし遅いしでロクなものに
ならないだろうから、本を見て実装するよし。
たしかfairealでjavascriptによる実装をやってなかったっけ?
518 :
デフォルトの名無しさん:2005/07/13(水) 14:05:50
age
秘密鍵をアプリに持たせて、ファイル関係を暗号化しておきたい場合
逆アセンブルや解析されても比較的強い鍵の保持の仕方ってどういうのがあるの?
ここに書いた時点で強くなくなっちゃうな。
鍵を構成するビットを一つのまとまった個所に置くんじゃなくて分散させるとか
多重暗号化するとか暗いかな
>>520 公開鍵暗号系で、公開鍵のみをプログラムに持たせておく。
復号だけならな。
525 :
:2005/07/20(水) 23:27:07
あげ
>>525 ソースコード読んだけど、これx64とかMMXで容易に64ビット化できそう
SSE2だと逆に遅くなりそう。
×64ビット化できそう
○高速化できそう
暗号強度落としてどうすんねorz
わろす
CipherSaber
keyとなるファイル(ある程度の大きさ、とりあえず1024byte以上)を使って
メルセンヌ・ツイスターを初期化し、nビット毎に乱数との差分を出力する。
簡単な暗号として考えたんだけど、これはどのくらい安全?
keyファイルは見つからないという前提で。
飾りをとると要するに
(値, 位置) から一意に定まる値への写像
だろ? あまり安全とは思えんが。
534 :
デフォルトの名無しさん:2005/08/20(土) 01:09:39
共通鍵暗号方式と公開鍵暗号方式、一般に同一ビット数であれば
暗号強度が高いのはどっちでしょううか?
一緒だ
536 :
デフォルトの名無しさん:2005/08/20(土) 01:13:42
>>536 何故ですか?
そう思う理由を言ってよ。
何となくとか言うなよ。
538 :
デフォルトの名無しさん:2005/08/20(土) 01:25:55
>>537 試験問題の選択問題に、その選択しがないからであります。
>>538 その問題には適用する状況は書いてないの?
540 :
デフォルトの名無しさん:2005/08/20(土) 01:35:48
>>539 問題文全文を転載します。
以下の文章は、暗号化方式について述べたものだ。空欄には「高い」「低い」「長い」「短い」のいずれかが入る
適切なものを選べ
暗号化を行う場合、利用するビット数が増えるほど一般に暗号強度が(1)と言われる。ただし、暗号強度は利用する暗号方式によっても変化する。
一般に同一ビット数であれば、共通鍵暗号方式は公開鍵暗号方式よりも暗号強度は(2)。
また、共通鍵暗号方式は公開鍵暗号方式よりも暗号化に要する時間が(3)。
1と3はあっさり分かったのですが、2だけが分からなかったのです。
高いだろ
ブルートフォースアタックに対して同等の強さを持つ鍵長の比較
対象暗号 公開鍵暗号
128bit 2304bit
112bit 1792bit
80bit 768bit
64bit 512bit
>>540 56bitの共通鍵≒384bitの公開鍵
訂正:対象暗号→対称暗号
要するに高いで正解だな。
公開鍵の方がbit数が高いというデータが目の前にあるだろ?
実際のものを思い浮かべれば言いやん
秘密鍵はZIP暗号化
公開鍵はAPOP認証
ZIPパスワードはブルートフォースでほぼ鍵が見つかる。
APOPは途中を傍受したとしても解読不可能
548 :
532:2005/08/20(土) 03:32:59
>>533 xorならokですか?ってそういう問題じゃないですよね…
暗号文と鍵ファイルが1対1の関係であればかなり安全なんじゃないかと思うんです。
問題は複数のファイルを同一の鍵で暗号化した時なんですが、これは何とかなりそうです。
>>542 それぞれの暗号アルゴリズムによってこんな数値いくらでも変わってくると思いますが。
>>549 アリスか暗号技術大全[Schneier 1996]に文句いいなさい
>>542-543 その「公開鍵暗号」ってRSAに限った話だね。
楕円曲線暗号だともっと短くなる。
1024ビット鍵のRSA暗号と同じ強度が160ビット鍵の楕円曲線暗号で実現できる、
なんて売り文句もある。
どっちにしろ共通鍵のほうがbit数が少なくて済む罠
そういえばAESが解かれた話はまだ聞きませんね。
解かれたらまた選定やり直し
ってかわざわざコンペして選んだんだから問題があればその過程で
よってたかってつつかれてる筈で、こんなに早く解かれたら
暗号研究者は揃いも揃って何をやってたんだバカヤロって話になる
どんな暗号でも逆算は存在するんだろうな
不可逆暗号化してOCR
AESって使うのにライセンス料とかかかる?
無料かつ誰でも自由に使える標準暗号の制定
という理念でAES候補が決定された。
AES使用にライセンス料はかからないし
誰かに許可を求める必要はない。
許し屋マスオみたいだな
>562
お前さんからは危険なにおいがぷんぷんするな
そんな質問したら怖くて誰も答えんよ。
566 :
デフォルトの名無しさん:2005/09/22(木) 16:27:26
保守
567 :
デフォルトの名無しさん:2005/10/01(土) 15:10:17
あげ
フリーソフトでアタッシェケースってのがあるがAESなのね。
なのでCamelliaで作ってみようと思うが
特許は無償開放されているようだが実際使って大丈夫なのだろうか?
メモリも暗号化したほうがいいよな・・・うーん。
>568
大丈夫じゃないの?
特許を無償で使っていいってことは勝手に使っていいよってことでしょ?
だめならお金を取りますっていうと思う。
と>568のレスを見て思った。
メモリの暗号化というのはよくわかりませんが・・・
571 :
570:2005/10/04(火) 15:07:41
ITProの方は読んだけどなんとも中途半端な無償公開だねぇ・・・。
AESそのものが選りすぐりの一品だからなあ。
Camelliaが非常に優れているか、AESに致命的な問題でもない限り
普通は乗り換える理由がないよ。
AESの利用を縛る条文について詳しく
うっかり、自分で最適化したら、
NTTが「いらっさーい」と待ってるかも知れないってこと?w
TWOFISHが…好きです……
> AESの条件に特許フリーと著作権フリーがあったと思うが
放棄だったかもしれないぞ。
フリー(権利は持ったまま利用は無償)と
放棄(権利から何から一切合財放棄)は、全然違うから注意。
> AESの条件に特許フリーと著作権フリーがあったと思うが
放棄だったかもしれないぞ。
フリーと放棄は、全然違うから注意。
580 :
デフォルトの名無しさん:2005/11/04(金) 09:49:00
581 :
デフォルトの名無しさん:2005/11/13(日) 07:21:56
Windows で crypt() 関数を使うのに、
一番手っ取り早い方法って何でしょう?
cygwin
>>581 昔、2chのトリップクラック情報サイトで移植版が掲載されていたのを見た覚えがある。
その線で探せるんじゃない?
>>581 ufc crypt でぐぐれ
utripper にもソース同梱されてる
手っ取り早いのは
>>582の言うとおりcygwin
585 :
デフォルトの名無しさん:2005/12/26(月) 05:54:07
586 :
初心者:2006/01/03(火) 21:08:37
=fcdc3abf25f3e04a2424a82e29afabd2
誰かこの暗号が解ける人居ませんか?
詳しい人に言わせりゃもの凄く簡単な暗号らしいんですけど。
587 :
デフォルトの名無しさん:2006/01/03(火) 22:02:45
16進数→ascii
>>587 ありがとうございます。
けど違うみたいでした…
頑張って自分で調べてみます。
お手数かけました。
589 :
デフォルトの名無しさん:2006/01/12(木) 19:54:46
すみません、質問になってしまうのですが
最近楕円Cramer-Shoup暗号というのを知って
C言語で実装しようと思っているのですがいまいち理解できません。
Cramer-Shoup暗号は実装済みなのですが、これを楕円化すればいいのでしょうか?
その場合、乗法を加法にする(例:g^x→g*x)以外にやるべきことは
なにかあるでしょうか?
自分で調べたことは有限体上の乗法群における要素を
楕円曲線上の有限可換群の要素に変える、というのがありましたが
具体的にどうやっていいのかわかりません。
よろしければ教えていただけないでしょうか?
590 :
デフォルトの名無しさん:2006/01/16(月) 08:44:36
ゲームのリソースの保護のような、プログラム中に復号化鍵を隠すような方法ってどんなのがあるんだ?
まあ、ここで言ってしまったら鍵を隠す方法ではなくなるかもしれんが。
コードにアクセスできる以上、復号鍵を絶対に秘匿することは不可能だが
可読性を下げるためにオススメなのは
「復号鍵を定数でデコーダループに組み入れ定数展開」
ではないかな。
592 :
デフォルトの名無しさん:2006/01/16(月) 23:02:22
もうひとつ聞くけど、暗号化したプログラム本体をリソースとして別のexeに組み込んで、
そのexeが動的に復号化して本体を実行するというようなものはどうやって行ってるの?
windowsアプリのexeを、別のアプリからfopen()などを使ってメモリ上に読み込めてもそこから実行に移す方法が分からない。
>>592 自己展開してるんじゃないの?
通常はWindows OSがやってくれるローディングを自前ですれば
実行可能な状態を整えてメモリに展開できる。
メモリ上に展開した後に、その中のmain関数の場所が分かれば(*ptrmain)()とかやって実行を移せると思うんだけど、
そのアドレスが分からない。展開したメモリの最初のアドレスではないと思うし。
>>594 そういう情報はexeやdllのヘッダにちゃんと書いてありますよ。
main関数のアドレスは書いてないけどね。
つ[upx]
598 :
デフォルトの名無しさん:2006/01/21(土) 23:14:40
三菱が九月に開発したBRUMEだけどアルゴリズムは公開しないのかな?
霞みたいな構造しているんだろうが、実際の所はどうなんだ?
Sボックスはガロア体の合成体で、鍵スケジュールはシフトとXOR?
普通にデバッガ通してメモリダンプかな。
manifestの埋め込まれたEXEをupxかけると起動すらできなくなりました。
逆に、パッキングした状態でサマリが合うようにできれば、アンパッキング防止として使える?
>>598 どうだろね。
オープンになったCamelliaですらフリーのサンプルコードの1つもオープンソース陣営から出てきてないからな。
莫大な金かけて開発した暗号をタダで手放すほど企業はお人よしじゃないでしょ。
CamelliaはCのサンプルコードが提供されてるから遊んでみたけど、簡単に公開できないよね。
NTTとなにやら契約しないといけないみたいで
>>599 upxってリソースをいじってしまうんでなかったっけ。
リソースそのまま残しておくオプションとかあった希ガス
603 :
デフォルトの名無しさん:2006/01/24(火) 21:10:15
Windowsが持っているCryptAPIというライブラリを
使えば公開鍵を利用するプログラムを作れるのでしょうか?
公開鍵・秘密鍵の生成と、それを使った暗号・復号だけが
できればよくて、証明書とか検証とかは必要ないのです。
単に NSS とかを組み込んだだけと違うの?
>>599 ふつうにできてるよ。manifest(XPスタイル?)込みのupx圧縮。
606 :
デフォルトの名無しさん:2006/01/25(水) 22:29:46
rijndaelでjpeg画像を暗号化したときに、(jpegを暗号化したものだと知られれば)JFIF...といったヘッダの部分が
攻撃者に知られるけど、こういう場合は既知平文攻撃をされるの?
あと、この問題はどれぐらい深刻?
607 :
デフォルトの名無しさん:2006/01/25(水) 23:06:01
>こういう場合は既知平文攻撃をされるの?
される。でも、ほとんど手がかりにはならない。なんだったら定型ヘッダを除いて
暗号化すればよい。
>あと、この問題はどれぐらい深刻?
相手として誰を想定しているかによるけど、この質問をしたところから考えて、
あなたがばれたらまずいと思っている人間に解読はまず不可能。
心配する必要はない。
>>603 いまなら、.Net Frameworkの Managed暗号クラス使うのがいいんじゃね?
CryptAPIとか、ライブラリとかインストールする必要ないみたいだし。
610 :
デフォルトの名無しさん:2006/02/15(水) 23:05:19
仮に鍵が0〜255の256通りしかない共通鍵暗号アルゴリズムがあるとして、
乱数で鍵を生成するとき、20でも157でも234でも一様に鍵が生成されるべきだと思うんだけど、
0,1,2,...の順でブルートフォースアタックされたら小さい数の鍵が先に解読されてしまう。
当然、乱数は一様に生成されるほうがいいんだよな?
611 :
デフォルトの名無しさん:2006/02/16(木) 00:15:32
一様に生成されない乱数ってなんか矛盾してる希ガス
やっぱブルートフォースって小さいほうからやるものなの?
ループは大きいほうから減算していったほうが速いらしいじゃん
ループが減算のほうが早い云々は、
i++
temp = 100 - i ;
if ( temp == 0 ) {}
i--;
if ( i == 0 ) {}
のほうが1命令分速いっていう理屈。
暗号の総当りの高速化は1クロック2クロック速いとかそんなこと問題じゃないくらい
暗号化自体に膨大な計算量がかかるのです。
615 :
デフォルトの名無しさん:2006/02/17(金) 23:05:52
IT系ニュースサイトにRSA Conference 2006の記事がいろいろ出てますね
616 :
デフォルトの名無しさん:2006/02/18(土) 18:49:43
つ[擬似乱数生成器]
つ[ミラーラビン法]
618 :
デフォルトの名無しさん:2006/02/22(水) 01:22:38
サイコロって真の乱数生成機として十分?(速度が遅いのは除いて)
たいていの製品(安物)は重心がずれていたり、
1と6の面が若干大きかったりする
618が百回振って、トリビアを作れ。
量子コンピュータでサイコロ振れば
623 :
デフォルトの名無しさん:2006/02/25(土) 04:41:10
ENFOPOL
サイコロでは無く人間の投げ方がランダムなのだ
暗号技術大全って共通暗号鍵方式についてどれくらい書いてある?
>>626 本屋で見てみろよ。そのぐらいは店主も許してくれるぞ。
数学を専攻していて暗号関係の職に就きたいと思ってるんですが、どんな事をやってるんでしょうか?
実際に企業で働いてる方お願いします。
629 :
デフォルトの名無しさん:2006/03/17(金) 06:43:52
KDDIがやらかしたな
もっと、人間的な職業に就きなよ。
>630 研究してる感じなんですか?
人間的でない方が嬉しいです。
給料は安いのに残業時間だけは人一倍長い
>632 やりがいはあるんですかね?
論文のようなものも書いたりするんですか?
64bitに対応したトリップ検索プログラムありますか?
TextSS のWindowsXP(Professional)64bit化おながいします
もしくは64bitにネイティブ対応したテキスト置換ソフトありますか?
氏ね
>>633 まずはこんなところで聞かないで企業さんのところへ行って話を聞いておいで
あと、新人社員って言うのは大抵は雑用が仕事のメインになる
自分で第一目標にこぎつけるまでやる気出さないとダメよ
続きは就職板な
>636 ありがとうございます
就職板に暗号関係のスレありましたっけ?
いってみます
CRYPTOに来てるような企業を対象にすれば?
おまいがその部署に入れるかどうか分からんが
>638 なるほど。非常に参考になります。
指導教官には日本ではあまり力をいれてない分野と言われたのですが、数学を活かせるしこれからの時代セキュリティの重要性は益々大切になってくると個人的には思ってるので、小さな所でもいいのでそのような所で働きたいです。
640 :
デフォルトの名無しさん:2006/03/20(月) 00:01:31
誰か暗号化関数作ってくれ!
キャラクタずらすやつ以外で。
キャラクタひっくり返すやつでいいか?
#include <iostream>
#include<stdio.h>
#include <windows.h>
#define SHIFT_VALUE (500)
int main()
{
char str[]="感ず感じもOK?なのかなWea小列滑稽殺傷件方法決定鴈時";
printf("元:%s\n",str);
for(int i=0;str[i]!='\0';i++)
str[i]+=SHIFT_VALUE;
printf("暗号化:%s\n",str);
for(int i=0;str[i]!='\0';i++)
str[i]-=SHIFT_VALUE;
printf("復元:%s\n",str);
return 0;
}
自分で作ってみました、簡単に見破られそう><
>>641
見破られないならOKです><
つーか、シーザーだな
#define SHIFT_VALUE (512)
648 :
デフォルトの名無しさん:2006/03/24(金) 17:37:07
MD5のリサーチペーパーを書いているのですが、
MD5で得られるハッシュ値を10桁くらいにして、コリジョンを調べるアプリとかってないですかね?
総当りでループぶんまわすコード書けばいいんじゃないの?
>>650 修正BSDライセンスとGPLのデュアルライセンスな件について
>>650 TrueCryptにつっこんでベンチマーク実行してみたんだけど、
スループットがTwofishの半分くらいしか出なかった。Serpentより遅いなんて。
最適化の余地があるのか、これが実力なのか、何かの間違いなのか・・・
ちょっと悲しい
653 :
デフォルトの名無しさん:2006/04/21(金) 20:47:18
見れるけど?
655 :
デフォルトの名無しさん:2006/04/25(火) 20:03:48
見れた。
ウィキペディアはたまに鯖が糞重くてブラウザが死んだみたいになるから困る。
656 :
デフォルトの名無しさん:2006/04/29(土) 23:52:03
>>650 NTTのCamelliaんとこ
変わったなあ。
以前のやる気のなさと大違い。
本気で普及させる気のようだ。
657 :
・∀・)っ-○●◎:2006/04/30(日) 00:01:47
MMX/SSE2でチューニングしてみようぜ。
てか、テーブル展開しすぎ。
アマゾンで大好評だった暗号入門秘密の国のアリスは糞本だったorz
659 :
デフォルトの名無しさん:2006/04/30(日) 00:33:30
660 :
・∀・)っ-○●◎ ◆Pu/ODYSSEY :2006/04/30(日) 00:36:22
DESより速いみたいなこと書いてあるがBitslice DESよりは余裕で遅い
>>659 読めば何かわかるかな?どうすれば速くなりそう?
ほとんどテーブル参照なんだけど
662 :
・∀・)っ-○●◎:2006/04/30(日) 00:43:38
テーブルサイズが大きいと、L2のレイテンシが大きいAthlonなんかではネックになりかねない。
元のソースと読み比べてみるとわかるかも。
テーブルサイズ小さくしてpshufwとかの攪拌命令で広げるようにすればよさげ。
663 :
デフォルトの名無しさん:2006/04/30(日) 01:59:28
665 :
デフォルトの名無しさん:2006/04/30(日) 04:18:43
>>656 DL数は数日で数千だって (←どこかで読んだが何千かは忘れた。)
つい最近Camelliaチップも発表されたらしい。かなりいけてるらしいが。
666 :
・∀・)っ-○●◎:2006/04/30(日) 04:30:06
S-Boxが入力8bitの出力8bitだからbitslice DESみたいに論理演算に展開する
アプローチは使えないっぽい。
せめて4〜5bit単位ならVPERMとかSSE4の新命令pshufbで並列化しまくりなんだが
Camellia_FeistelのUとDの計算は、mmx使えば半分の命令で済むかな?
やるなら関数全部asmで書かないと効果薄い?
668 :
・∀・)っ-○●◎:2006/04/30(日) 05:36:03
Camellia_Feistel(xx,kk,oo) マクロなら、64bitのレジスタがあればたしかに半分にできると思う。
でも一番実行クロック食うのってテーブル参照のロードレイテンシな気がするんだけど。
テーブルを束ねて参照回数を減らす手もあるけどテーブルがキャッシュに収まらなくなるので
逆にレイテンシ伸びる希ガス。
例えばpextrw eax, mm0で16bitずつ抽出してal と ahで分けることで8bitずつの値になる。
AESのASMコードがこんな感じのことやってた。Camelliaでも大体似たような
ことやればいいと思うよ。
まぁフルにASMで書けば扱えるレジスタの制約が多少緩くなるけど、インラインasmで十分だと思う。
669 :
デフォルトの名無しさん:2006/04/30(日) 05:51:16
>>665 >DL数は数日で数千だって
* 初日で2000ダウンロード
>つい最近Camelliaチップも発表されたらしい。
Camellia LSIは,NTTが開発した共通鍵暗号アルゴリズムのCamellia」(カメリア)の
暗号化/復号処理用の専用チップ。最大の特徴は,パッケージ・サイズが8mm角
(1円玉上に四つ載せられる大きさ)と非常に小さく,また消費電力も最大0.3Wととても
少ない点。それでいながら200Mビット/秒のスループットで暗号化処理が行えるという。
同社によれば,「米国の標準暗号AESでは,暗号化と復号に別の回路が必要なため,
最低でもこの2倍ほどのチップ・サイズになってしまう。消費電力やパフォーマンスの
面でもCamellia LSIに大きく分がある」
http://itpro.nikkeibp.co.jp/article/NEWS/20060427/236512/
SCISでもCamelliaの実装に関する発表がいくつかあるね
>>668 ありがとう。MMX使うインラインasmでちょっとやってみたけど
10%くらいしか高速化できなかった・・・。書き方が悪いんだろうなorz
SBOXのテーブルって全部で4kしかないでしょ?L2には乗ってるような
672 :
デフォルトの名無しさん:2006/06/19(月) 22:40:31
ふと思ったのですが、
高bit暗号をかけても、低bit暗号を複数かけても暗号強度はかわらないってことはありませんか?
たとえば128bitRSAで暗号化するのと、64bitRSAで暗号化したものを、さらにもう一度別の鍵の64bitRSAで暗号化するような。
2つの暗号が同時に見つからないといけないので、暗号検索にかかる処理量は128bitと同じくらいになるような気がするんですけど・・・
素人考えかもしれないですがどうなのでしょうか?
>>672 暗号による。しかし普通は鍵長を長くする方が有利。
例えば鍵の長さの二乗の時間で解ける暗号があったとする。
32bit の鍵で2回暗号化すると、32*32 + 32*32 = 2048 の時間で解ける。
64bit の鍵で1回暗号化すると、64*64 = 4096 の時間で解ける。
>>672 条件によってはYes。例えば:
弱:1, 2, ... N回目の暗号化の鍵が独立でない
強:1, 2, ... N回目の暗号化の鍵が独立である
弱:複数回掛けると前段の影響で逆に解読の手がかりを残すアルゴリズム
強:複数回掛けても前段の影響を受けないアルゴリズム
弱:x回目(x≠N)の解読が正しいか(部分的にでも)判定できる
強:N回目を解くまで解読が正しいか(部分的にでも)判定できない
弱:鍵のbit数に対して暗号化ブロックサイズが小さい
強:鍵のbit数に対して暗号化ブロックサイズが大きい
などなど。本当にYesかどうかはアルゴリズムやパラメータや利用モードによるので一概には言えない。
675 :
672:2006/06/19(月) 23:18:56
>>673 レスありがとうございます。
私が考えてるのはちょっと違いまして、
673さんの例でいうと、32bitの暗号解読を1つめの鍵を検索して、
もし正しい鍵を使って解読しても2つめの鍵で暗号化されているので、正しい鍵を見つけたのかどうか判定できないのではないか?ということです。
つまり1つめの鍵を見つけて、次の鍵を探すという処理ができないので、
(1つめの鍵を見つける時間)*(2つめの鍵を見つける時間)
つまり足し算ではなくて掛け算にならないかなぁ・・・・と思ったわけです。
でてきた解読データが「さらに暗号化されたデータ」でも、解除が成功したと判定できるものなんでしょうか?
>でてきた解読データが「さらに暗号化されたデータ」でも、解除が成功したと判定できるものなんでしょうか?
現在実用されている現代暗号方式なら、まず間違いなく「できない」と言い切っていいと思う。
677 :
672:2006/06/19(月) 23:30:24
>>674 レスありがとうございます。
4つの差はなんとなくわかりました。
RSAでのプログラムを組んでいたのですが、高次になるとあまりにも素数発見に時間がかかり、
鍵生成できないのでなんとかならないかと考えてました。
この場合、「指数」「法」「素数」を変えれば鍵が独立で、前後の影響をうけず、途中までの解読が正しいかを判定できないと
いうことが知りたいんですよんね・・・・
ハイブリット暗号?
679 :
672:2006/06/20(火) 03:53:17
>>678 私へのレスかな?
秘密鍵を使うわけではないのでハイブリッド暗号ではありません
「ジャンボ宝くじ」に対する「ロト6」みたいなものかな?素人なので専門用語はちょっとわかりません・・・
>>674 レス674の4つめの暗号化するブロックサイズですが、
暗号化キーのビット幅が小さくなっても、暗号化が局所的にならないように
それぞれの暗号化に対して、対象ブロックをずらしていく(ビットシフト)や複数ビットを1ビットと見立てて暗号化するなどして、
前後のブロックとからめて暗号化してゆけば、1つの高bitキーと同じようなブロックサイズを維持できて、
暗号化強度も上がるんじゃないかと思いました。
逆に解読の手がかりも残りにくくなり、数学的にも指数の連立方程式となって難しくなると思います。
RSAは準指数だから、
例え(1つめの鍵を見つける時間)*(2つめの鍵を見つける時間)になったとしても、
(1つめの鍵を+aビット)したもので抑えられる。aを30だとすると、
鍵が1024ビットになってもaは変わらない。
1024ビットの鍵を重ねても実は1100ビットの鍵1つの方が圧倒的に難しい。
暗号を重ねるというトピックでは、
Double-DESの解読で、平文と暗号文の両方から中間文を生成すると
通常のDESと同じ計算量で解けてしまうというのがある。
だからTriple-DESにする必要があった。
同様に4重-DESはTriple-DESと同じ強度。
>>672は暗号についてもうちょっと調べたほうが良いんじゃない?
>679で君が言ってることはブロック暗号のモードのひとつに過ぎないぞ
682 :
672:2006/06/21(水) 03:35:30
>>680 すっと考えていたのですが、勘違いであるらしいと気づいてきました。
検索側の計算量が指数的に増えるというのは、
(たとえば64→128bitにする場合)2^64→2^128 となるわけではなく、
2^(64bitであらわされる数)→2^(128bitであらわされる数) およそ 2^(2^64)→2^(2^128)のように増えるということみたいですね。
はじめ 2^64 とか思っていたので、(2^64)*(2^64)=2^128じゃないかなどと思っていました・・・・
2段階に暗号をかぶせる場合、平文と暗号文での比較で解けてしまうというのは気づいていました。
メモリがたくさん用意できれば、予想された暗号キー分の解読テーブルを作って比較すれば、
(2^64)*(2^64)ではなく、(2^64)+(2^64)+(テーブル比較時間)になってしまうと思ってました。
やはり暗号を重ねるなら3重以上が必要なんですね
>>681 たしかにここに書き込んでいると知識不足が恥ずかしくなってきました。
ブロック暗号についてぐぐってみましたら確かに私は同じことを言ってるみたいです。
(しかも見た所どのアルゴリズムもCPU演算的に有利そう・・・)
現時点での標準的なPCの処理能力で、アプリに暗号強度として必要十分でかつ現実的な時間で実現したかったのですが、
もっときちんとした勉強が必要そうですね・・・・
683 :
デフォルトの名無しさん:2006/06/25(日) 17:46:38
Cから直接OpenSSLのAPIを使うソフトを作らなきゃいけないのですが、
OpenSSLのAPIリファレンスのようなものが見つかりません。(オライリー
の本のサイトに、BIO関係だけはあるのですが…)
探し方が悪いのでしょうが、英文でも和文でも構いませんので、ご存じの
方いらっしゃいましたら、URLを教えていただけると助かります。
685 :
683:2006/06/25(日) 19:18:42
>>684 レスありがとうございます。
説明が足りなくて済みません。
その本にも公式サイトにも、まとまった情報が無いので困ってるのです ^ ^;
ちなみに、以下の本は所有していますが、いずれにもバラバラに部分的
な情報しか記述されていないのです。圧縮処理などの都合で、すでに
入出力をまとめたクラスが存在するので、可能であれば、BIOを使わずに
OpenSSLにアクセスしたいのです。
・OpenSSL -暗号・PKI・SSL/TLSライブラリの詳細
・C/C++セキュアプログラミングクックブック(1〜3)
・マスタリングTCP/IP SSL/TLS編
いずれにもリファレンスっぽいのはありませんでした。TT
SuicaとかFelica系ICカードって暗号まだDESか3DESてw
ttp://ja.wikipedia.org/wiki/Felica それこそCamelliaにでもしたほうがいいんじゃね?
あとAES決めるときに、Feistel構造だとだめって話があったけど
多分アメリカの軍部の暗号関連の人がFeistel構造について”何か”を発見したからじゃないかな?
ラインデールがSPN構造だから採用されたっていうのもあると思うし。
Feistelって単純な構造だから何かがあるような事はないと思う。
SPNに何かを発見したんじゃないの?軍部の人間としては強力
な暗号よりかは弱い暗号を使って欲しいだろうし。
しかし、Felica。市販されてる非接触の受け側、アレ買えば勝手に決済とか可能なのかね。
ノーパソにUSBでつないで、満員電車にでも乗り込めば金取り放題になっちまうのかね。
>>685 BIOを使わないで OpenSSLにアクセスするって、かなり初歩的なことしかできない気がするけど。
ソケットを attach して使えないこともないけど。
BIO使わず、認証の正当性をどうやって監査するのかと。
[AES] 攻撃:52 素早さ:90 防御:75 命中:41 運:28 HP:168
[Camellia] 攻撃:53 素早さ:51 防御:96 命中:44 運:57 HP:182
AES vs Camellia 戦闘開始!!
[AES]の攻撃 HIT [Camellia]は1のダメージを受けた。
[Camellia]の攻撃 HIT [AES]は18のダメージを受けた。
[AES]の攻撃 HIT [Camellia]は1のダメージを受けた。
[Camellia]の攻撃 HIT [AES]は65のダメージを受けた。
[AES]の攻撃 HIT [Camellia]は1のダメージを受けた。
[Camellia]の攻撃 HIT [AES]は11のダメージを受けた。
[AES]の攻撃 HIT [Camellia]は1のダメージを受けた。
[Camellia]の攻撃 HIT [AES]は37のダメージを受けた。
[AES]の攻撃 HIT [Camellia]は1のダメージを受けた。
[Camellia]の攻撃 HIT [AES]は15のダメージを受けた。
[AES]の攻撃 HIT [Camellia]は41のダメージを受けた。
[Camellia]の攻撃 HIT [AES]は1のダメージを受けた。
[AES]の攻撃 HIT [Camellia]は2のダメージを受けた。
[Camellia]の攻撃 HIT [AES]は35のダメージを受けた。
[Camellia]が[AES]を倒しました(ラウンド数:7)。
魔法のMD5 - MD5バトル
http://www.newspace21.com/mix/btl.php
>>685 SSLeay Programmer Reference とかじゃダメなの?
大して変ってないでしょ。たぶん。
>>686 大事なとこは3-DESだから
まあいいんじゃない?
あのころは過渡期だし。
これから変わるでしょ?
693 :
デフォルトの名無しさん:2006/07/12(水) 02:47:38
すいません全然分かってないのでご教授願いたいのですが、
DESを用いて暗号を作っていますが、
与える平文の文字コードが異なるのに暗号結果が同じになってます。
これはどういうことでしょうか?
何で実装してるんだよ。
どうせ文字列で読み込んでから暗号化とかしてんだろ。
読み込んだデータをデバッグライトすれば答えが出てくるね
698 :
693:2006/07/13(木) 11:35:44
javaで暗号化してPHPのmcryptで復号してます。
文字列で読み込んでから暗号化すると
文字コードは意識しなくていいのでしょうか?
どんなコード書いてんのか知らんけど、
エンコーディングを自動判別とかして文字列にしてるんなら、
その時点でデータは同一になってるだろ。
ファイルのバイトデータを直接暗号化したら、もちろんそうはならない。
700 :
693:2006/07/13(木) 22:02:18
java側で暗号列のバイトデータを書き出してPHP側で復号してます。
>>700 指摘されてんのはそこじゃなくて
ファイルをメモリに読み込むところ、暗号化する前。
java.lang.Stringの内部表現はUnicodeとかそういう
702 :
デフォルトの名無しさん:2006/07/17(月) 00:43:20
703 :
デフォルトの名無しさん:2006/08/06(日) 14:04:16
暗号化して保存しているデータを、自分で復号して使うソフトってありますよね。
たとえば、ブラウザがWEBアプリのID・パスワードを保存してくれる機能とか。
ユーザにパスワードを入力させて、それが秘密鍵になっているというならわかる
んですが、ブラウザの機能だとユーザには何も入力させていないようです。
こういう場合、そのデータをどうやって暗号化/復号しているのでしょうか?
ソフト埋め込みの秘密鍵を使っているのでしょうか?
例えばユーザ透過なファイルの暗号化機能とかどうやってると思う?
なんでもかんでも「鍵」を元にして
暗号化されているという考えはいかがなものか。
でも、近代の暗号は大体が鍵を必要とするだろ。
一口に鍵の生成といっても色々あるわけで
必ずしもユーザが鍵を入力する必要はないわけで
708 :
デフォルトの名無しさん:2006/08/19(土) 16:22:02
秘密鍵McEliece暗号
G:ゴッパ符号の生成行列
H:検査行列
P:ランダムな置換行列
秘密鍵fは符号の生成多項式。
e:重みd以下d/2以上の平文
d:符号の最小距離
c:暗号文
r:乱数
fからGを生成。
暗号化
g:c=(rG+eP)H
復号化
g^{-1}(c)=eP(P^{-1})=e
709 :
デフォルトの名無しさん:2006/08/19(土) 17:29:25
710 :
デフォルトの名無しさん:2006/08/19(土) 23:22:30
Pika Zip
ポコーン
713 :
デフォルトの名無しさん:2006/08/23(水) 20:14:58
(・∀・)ヤコビヤーン!
714 :
デフォルトの名無しさん:2006/08/30(水) 20:33:48
梅どぶろくがなぜあそこまでこのスレの歓心を得たのか?
それ以来過疎スレに。
715 :
デフォルトの名無しさん:2006/09/02(土) 18:48:48
716 :
デフォルトの名無しさん:2006/09/18(月) 10:41:15
ところで公開鍵方式で楕円曲線暗号を搭載した暗号ソフトを公開しようと思うんだが
誰か興味ある?探してもなかったので。
因みに秘密鍵暗号はオリジナル。
今まで暗号ソフトってベクターでも少なかったのはどうして?
特許に気をつけてね。コーディングは書籍見てやってみたけど、
ちょっと実用的な速度にあげるまで暇は無かった。
718 :
デフォルトの名無しさん:2006/09/18(月) 11:52:16
イアン・ブラケの楕円曲線暗号をそのまま実装したんですが。
CM法を使って曲線を生成して素体だけ使って鍵交換しています。
RFCの曲線やSEC?の公開されている曲線がデフォルトです。
公開されている情報を基に作られています。
しかし、自分のやっていることが特許に抵触しているかどうかがわかりません。
本を参考にやってみただけです。そういうのは公開してもいいのでは?
また超楕円ならいいのでしょうか?
あいにくと、特許はその実装にまで影響する場合があるんだな
よく調べた方がいいよ
720 :
デフォルトの名無しさん:2006/09/18(月) 12:01:19
特許に抵触するとどうなるんでしょうか?
特許に抵触するかどうかの判断は誰がするんでしょうか?
722 :
デフォルトの名無しさん:2006/09/18(月) 13:22:38
知ってるなら教えればいいのに、このケチ!
大抵は特許を持ってる企業の法務部が見つけると請求してくる。
webで公開するもしくは販売する場合、アクセスできる国全ての特許で一つでも
あると、ダウンロード数などに応じてしゃれにならない金額を請求されることもある。
ソフトの場合実装に応じてなので、疑わしい場合にも調査されることが多いとは思われるが、
特に楕円暗号の場合には書籍すらでているのに対応するソフトウェアが少ないことからも
推して知るべしな状況ではなかろうか?
ちなみに公開されていて、安易な方法だからといって、実装したときに特許が絡むというのは
いくらでもある。特許をとっているからこそ企業秘密を論文などで公開することができる。
どうせ国内で成立してない特許だから無視してても逮捕とかはされないよ
無視する→アメリカで訴えられる→こっちは日本にいるので当然無視する
→アメリカで有罪が確定するけど別に問題ない
ただし入国禁止になるけどw
725 :
デフォルトの名無しさん:2006/09/19(火) 04:04:33
認証に使う暗号の強度を上げたいと考えています。
MD5やSHA-1のような不可逆関数はいくつかあると思うんですが、どれも
関数を特定してのブルートフォースアタックには弱いですよね。
乱数を生成する時に利用するようなシードが指定できればどの関数で暗号
化したのか特定できないので、ブルートフォースアタックにも強いかな?
と思いましたが、調べた限り(Webでですが)、そんな機能はないっぽいです。
なにかうまい方法はないでしょうか?よろしくお願いします。
>>725 よくわからないけど普通にソルトをかけるのではダメすか?
727 :
デフォルトの名無しさん:2006/09/19(火) 09:17:25
>>723 RFCにあるような内容でも実装すると罪なの?
確かに楕円曲線は特許の地雷原だという話をOpenSSLのメーリングリストでは
よくみかけたけど。でもヨーロッパには普通に楕円のフリーソフトがあります。
ミラクルとかがそう。ないのは日本だけ。
728 :
デフォルトの名無しさん:2006/09/19(火) 09:20:26
楕円曲線なんて日本人の発明でもないのによく特許とるきになった
もんだ世日本企業。その割には話題が下火だけどね。
>>725 シードをブルートフォースアタックする手間が増えるだけ
ブルートフォースアタックへの対抗は、
ビット長のより長いアルゴリズムを採用するのが常道じゃないか?
>>727 ヨーロッパではソフトウェア特許は成立しないから。
731 :
デフォルトの名無しさん:2006/09/19(火) 20:15:36
いいソフトがあるのにそれが共有されないのは不幸なことだ。
なにを言ってるんだ
特許は発明を使ってくださいという事じゃないか
対価を出すだけで努力の結晶を使えるんだぞ
>>727 RFCは技術の仕様をまとめてあるだけだよ
「こんな感じで実装してね」って書いてあるだけで特許は捨ててない
734 :
デフォルトの名無しさん:2006/09/20(水) 03:02:34
FreeSWANはどうなるのさ?フリーソフトだし対価払ってないよ?
作者が払ってるの?
ランダムアクセスされるデータをバイト単位で暗号化することを考えています。
鍵と先頭からのオフセットを渡せば、乱数が得られて、
しかも、暗号学的に安全な擬似乱数生成アルゴリズム
というものは存在するのでしょうか?
全部そうですが
>>737 あれ?私の理解が間違ってますかね?
例えば、線形合同法は乱数Xn+1を得るのに、Xnが必要。
n=10000の乱数を得るためには、10000回の計算が必要です。
ランダムアクセスなので、その後に、n=5000の乱数を得ることもあるのですが、
それには、また5000回の計算が必要になります。
そこで、鍵とnを渡せば、高速に乱数が得られるアルゴリズムは存在しないかと。
>鍵とnを渡せば、高速に乱数が得られるアルゴリズムは存在しないかと。
乱数かどうかはともかく、暗号目的であれば鍵とnを連結したものを鍵として鍵とnを
(良い暗号で)暗号化したもののダイジェスト(先頭バイトとか)が要件を満たすのでは?
でもふつうはそういう用途ではブロック暗号を使うでしょう。
(適当なチャンク単位でストリーム暗号を用いても良いですが)
>>739 なるほどぉ。高速ではなさそうですが、要件は満たせそうです。
> でもふつうはそういう用途ではブロック暗号を使うでしょう。
バイト単位、ランダムアクセス、キャッシュ不可、という状況ですので
どうしてもブロック暗号が採用できないのです。
普通に 64bit (8バイト) 毎にブロック暗号を使うケースと比べて、
8倍遅いだけですもんね。大したことないか。
たしかに。
で、「この暗号化アルゴリズムは?」という問いにはどう答えるのが適切でしょうか?
高速かどうかってことしか見てない時点で、キモ女決定だな。
>>743 そうなんですか?高速さの優先順位が高いことは多いと思いますけどね。
高速なCPUなら100Mbytes/sec以上で暗号処理をしたいところです。
アルゴリズム名は、鍵とnの暗号化をAESでした場合、
「この暗号化はAES」と呼べば、怒るともいれば、納得する人もいそうですね。
( ゚д゚)ポカーン
>>744 君の妄想はとてもキモイから、もう来なくていいよ。
あ、そっか。わかりました。現実的な話が不得意な人だったんですね。
でもヒントを頂いてありがとうございます。
後はどうにでもできますので、これ以上問いつめないから安心してください。
>>740 >バイト単位、ランダムアクセス、キャッシュ不可、という状況ですので
>どうしてもブロック暗号が採用できないのです。
どうして何も考えずに否定するのでしょう。簡単な例を作ってみましょうか。
A,A^(-1)を8*8の行列対とする。
kバイト目の復号化は、k/8から8バイトを取り出しA^(-1)をかけてk%8+1バイト目が求めるバイトの値。
kバイト目の暗号化は、k/8から8バイトを取り出しA^(-1)をかけてk%8+1バイト目を書き換えてからAをかけて8バイト書き込み。
>>747は妄想性人格障害の自覚がないまま自殺したのであった…
>>748 >kバイト目の復号化は、k/8から8バイトを取り出しA^(-1)をかけてk%8+1バイト目が求めるバイトの値。
データのアクセスは上位の別プログラムが行い、そのプログラムの修正は不可だとしてくださいな。
そこに暗号化フィルタを追加したいという訳です。つまり8バイトを取り出すのが不可なのです。
>>750 プログラム改変せずにどうやって暗号化フィルタを追加するんだよ。
プログラムと暗号化の対象をHDDとするとこの間のどこかでフックするしかないのでは。
暗号化対象がメモリなら厳しそうだがHDDなら仮想ディスクみたいなものだしなんとかなるでしょう。
でも、フックできるなら748のようにデータをいじることも可能だよね。
フックのためのプログラムは別プロセスだし。
> プログラム改変せずにどうやって暗号化フィルタを追加するんだよ。
オマエ完全にスレ違いなんだよ。
しかもレベルが低いんだよお前。
>>752 完全にスレ違いってことはないだろ。
ただ、レベルが低いのは認める。
どうせ話題ないくせに
755 :
デフォルトの名無しさん:2006/10/22(日) 11:26:54
>>755 ワンセグなんて画質の悪いもの、現状では解読する価値なしだろ
760 :
755:2006/10/22(日) 22:57:41
そっかー皆、興味ないかぁー
暗号解除できれば、録画したものを他のPCで見ることが出来るし、
出先からストリーム再生も可能だろう。
あとEPG情報や字幕、データ放送も取得できる。
というメリットがあるかな。
そんなことして本当にうれしいのか?
>>760 君の要望程度なら、DVDより次の次世代メディアでやった方が、
画像が綺麗だし満足は大きいだろう。
>>761 うれしいのは、盗聴とかウイルスとか深いところにいる人たちじゃないかな…
763 :
760:2006/10/23(月) 00:08:01
>>762 USBチューナが壊れたり無くなったら再生できなくなるんですよ。
DVDならソフト買えばいいじゃん。
ハイビジョンはまだPCチューナがでてないですから
こっちは強固だけど、ワンセグ自体は大元にはスクランブル掛かっていないしね。
まぁ、純粋に興味もっただけなので自分でやりますわ
そこらへんって独自暗号じゃなくて確立された暗号使ってるだろうから企画書読めば終りじゃないの?
それ以前にワンセグは暗号化されてないしなぁ・・・
>>765>>766 念のためだけど、此処でいっているのは、放送波の規格の暗号でなくて、
バッファローが独自に掛けている暗号ね。知られた暗号だろうし、
USB内蔵の8ビット?CPUでできる程度のことだから何とかならない?ってな話。
カノープスがMVTXシリーズでデジタル放送録画したときも暗号化しているね。
似たようなもん。
発見、こんなところでやってたw<ワンセグ
暗号化されてないストリームなら供給できるぞ。
比較にはなるだろう。
チューナは品薄で手に入らなくてね・・orz
自作自演で暴言吐くようなバカの話聞けるかっての。
>>770 お兄さん、意味不明ですよ?
人間不信に陥ってんじゃない?
つ精神科
正直、771の方が過剰反応してて、病院にいけって感じ。
自作自演?誰が?
ジャイヤンばっか
反応しなきゃいけない理由があったってことだわなw
778 :
デフォルトの名無しさん:2006/10/25(水) 00:20:48
複合結果が検証できない不明の暗号データを解読することは不可能。
そのぐらい理解しておけ。
検証できる結果はあるみたいだお?
>>778 人に文句つける文章を書くときくらい、誤字がないかチェックしようよ。
↑
結果が真か偽か判定できないんじゃ解読は無理だろ。
解読できたからといってそれが真か偽か判定できないのだから。
同一性が確認できなければ、どんな技術つかっても無駄だろ。
真データは腐るほどあります。
100%あっているのでその辺の心配はないですぅ
>>784 真データは腐るほどあるから。ドキュメントが画像になったりするわけだな?w
787 :
デフォルトの名無しさん:2006/11/06(月) 12:51:20
Zebedeeってどうよ?
788 :
デフォルトの名無しさん:2006/11/08(水) 03:28:54
MSNって暗号化できるの?
Cameliaの周辺特許(あるかないか知らないが)にも抵触しない実装の
ソースがオープンソースで手に入るということ?
しかしOpenSSLはライセンスがあれなんだよな、宣伝条項つきなんだよなあ。
792 :
デフォルトの名無しさん:2006/11/17(金) 05:47:41
計算量理論を使って完全秘匿な暗号を効率的に実現する方法ある?
P=NPでなければ鍵長の指数時間かかることが証明されている暗号とかならあるけど
ぶっちゃけ暗号に計算量理論は使いモノにならん。理論的な話が知りたければ数学板にでも行け
>>792 完全な秘匿の定義しだいだが、現行で使われているRSA-OAEPとかは、
基本的には、情報論的ではなく、計算量的に安全なのばっかでしょ。
大きい素数同士の素因数分解は一般に計算量が大きいっていう仮定。
(ハッシュがランダムオラクルっていう仮定も使っているんだけど。)
ペアリング!(・∀・)つ◎
共通鍵暗号では
>>794みたいに互いに帰着させて安全性を保証してるものもあるけど
秘密鍵暗号では指数オーダーが少しでも低くなると「破られた」と見なされるから
秘密鍵暗号に使える安全性の証明は俺の知る限りない
>>796 確か、カメリアかミスティだったか、そんな感じの呼び名の国産の秘密鍵暗号方式は、
アルゴリズムの構造から、desとかを破ったような攻撃方法に対して、強いということが証明できてるらしい、
って聞いた。。記憶があいまい&うろ覚えなので間違っててもご容赦を…。
798 :
デフォルトの名無しさん:2006/11/19(日) 11:47:00
それって量子計算機が発明されたから計算量理論が無意味になったって
いいたいの?
量子計算機でも実現できる計算力は高々クラスexpでしょ?それとも量子計算機
って非決定性チューリング機械なの?それでどこまで計算できるか知らないけど。
もしクラスexpだったら離散対数問題は解けるけどNP完全問題はまだ解けないこと
になるから安全なのでは?
また暗号ではないけど完全秘匿を実現するプロトコルは知られてますよね?
799 :
デフォルトの名無しさん:2006/11/19(日) 12:00:21
なんでも量子通信ではシャノン限界を突破する情報量が転送できる
らしくって暗号やってた数学者は物理学者に水をさされた感じがする。
800 :
デフォルトの名無しさん:2006/11/19(日) 12:13:02
量子計算機が出てきたから皆暗号理論から逃げちゃった?
>>798 NP完全問題はクラスEXPに属する
たいして知らないなら書きこまないほうが馬鹿を晒さなくて済むと思うぞ
802 :
デフォルトの名無しさん:2006/11/19(日) 16:07:03
>NP完全問題はクラスEXPに属する
どこにそれが書いてあるのか教えてエロイ人!
どこに書いてあるもなにもNP⊆EXPは自明だろ・・・NPの定義をよく読め
805 :
デフォルトの名無しさん:2006/11/19(日) 19:09:07
BPQとNPの関係さえまだ明らかでないんですねえ・・・
806 :
デフォルトの名無しさん:2006/11/19(日) 19:33:56
離散対数問題はBQPに含まれると考えていいんですよね?
>>797 共通鍵暗号の証明可能安全性は、
「ある攻撃」に対する証明でしかないです。
具体的に言うと、差分攻撃と線形攻撃。
その他の攻撃(高階差分攻撃や補間攻撃等)に対する耐性は、
「現在のところ破られていない」
という程度に過ぎない。
CRYPTRECレポートを読めば、そういう風に書いてある。
#実装攻撃は別。対策していないデバイスでの電力攻撃やキャッシュ攻撃等では解読は可能。
WindowsのCryptAPIとOpenSSLライブラリって、RSA暗号の互換性ないの?
WindowsのCryptGenKeyでキー作って、CryptExportKeyで公開鍵取り出して
その公開鍵をOpenSSLのRSA構造体のeとnに入れて、
RSA_public_encryptして暗号文を作ったのだが、
その暗号文が、CryptAPIのCryptDecryptで復号化できないのだが。
基本的なアルゴリズムは同じだと思うが、
もしかして、鍵のフォーマットなんかが違ったりする?
結構調べたんだが、それ系の解説サイトがないんだよな。
810 :
デフォルトの名無しさん:2006/11/25(土) 00:37:29
>>809 そんなものどちらかが意識して合わせようとしなければ合うわけないじゃん。
エスパーならできる。
あとはそのエスパーを探してくるだけ
>>808 補間や高階差分に配慮してないけどなんか安全っぽい
って風にみえますが・・・
完全な保障ができないだけで、全く配慮されてない訳じゃないんでは
814 :
デフォルトの名無しさん:2006/11/25(土) 20:04:25
いずれにしても離散対数問題と素因数分解問題に基づいた暗号は量子計算機の登場で
100年も持たないってことでお陀仏なんでしょ?その方がもっと暗号にとっては
危機的な状況だと思うのだが。
だからここはやはりMcElieceを!
816 :
デフォルトの名無しさん:2006/11/27(月) 07:52:46
OpenSSLも楕円曲線も量子計算機のせいであぼーん
物理板や技術系板と違ってここでは量子コンピュータの影響は切実なんだな。
>>809 少なくとも、CryptAPIのRSA鍵は、リトルエンディアンで格納されてるけど、そのヘンは確認している?
量子コンピュータで暗号作らねばな
量子暗号
821 :
ミッション:2006/11/30(木) 14:23:00
Coe ☆ is †
この暗号解けたら
動画あげちゃる!!!
822 :
ミッション:2006/11/30(木) 14:30:54
Coe ☆ is †
この暗号解けたら
動画あげちゃる!!!
823 :
デフォルトの名無しさん:2006/11/30(木) 19:41:25
物理は嫌いなのよ!
量子暗号は都市レベルで成功したってニュースあるし大丈夫じゃね?
量子暗号は中継技術が開発中でインターネットでの使用を目指しているらしい。
だが、量子暗号はプログラム板としては板違いだな。
tp://web1.nazca.co.jp/himajinn13sei/8.zip
なんかどっかで見たことがあるようなアルゴなんだが、
こんなのに似たの無かったっけ?
>>827 *CH
C(0)=(C(0)+C(1)) Mod CH(0)
C(1)=(C(1)-C(2)+CH(1)) Mod CH(1)
C(2)=(C(2)+C(3)) Mod CH(2)
C(3)=(C(3)-C(4)+CH(3)) Mod CH(3)
C(4)=(C(4)+C(5)) Mod CH(4)
C(5)=(C(5)-C(6)+CH(5)) Mod CH(5)
C(6)=(C(6)+C(7)) Mod CH(6)
C(7)=(C(7)-C(0)+CH(7)) Mod CH(7)
C(0)=(C(0)-C(1)+CH(8)) Mod CH(8)
C(1)=(C(1)+C(2)) Mod CH(9)
C(2)=(C(2)-C(3)+CH(10)) Mod CH(10)
C(3)=(C(3)+C(4)) Mod CH(11)
C(4)=(C(4)-C(5)+CH(12)) Mod CH(12)
C(5)=(C(5)+C(6)) Mod CH(13)
C(6)=(C(6)-C(7)+CH(14)) Mod CH(14)
C(7)=(C(7)+C(0)) Mod CH(15)
return
*CHが平文で*Cが暗号文ですか。復号化はどうするんだろう。CH[i]=0になったらどうするんだろう。
平分・暗号・鍵
の関係がよく分からないな。
最初に定義しとけよ。馬鹿
はいはい、お帰りはあちらw
早いところワンセグチューナの暗号解いて他のPCでも見れるようにしておくれよ。
>>831 ワンセグは画質面で資料的価値が無い。
地デジどころかアナログにすら勝てるわけ無いのに。
価値の無いものに対してリソースを注ぎ込む人がいるのかどうか。
どうみても暗号を解くならば地デジ優先です。
地デジキャプチャできるカードの単品販売は無い。
ごく一部のメーカPCのセット販売のみ。
そんな需要の無いところでやっても意味なさそうだな。
DTCPもCPRMも突破できてないから無理だろうけどなw
>>831 オマエ馬鹿だなぁ、プライドばっか高いこいつらがやるわけ無いじゃないか。
「需要がないからやらない」≒「スキル無いからできない」だ
つーか欲しいと思う人が作ればいいだけ
分散コンピューティングでみんなでDESの不動点探そうぜ
(ある1つ以上の平文について暗号化したら平文と同じ文が出力される鍵)
いまさらDESかよ
839 :
ニュース速報+:2006/12/21(木) 02:26:30
FeliCaはトリプルDESですね
MISTY最強
>>837 平文 0x0000000000000000
鍵 0x0000000000000000
そして鍵は56bitに縮約されるためその際に捨てられるbitは
立っていても良いのでその組み合わせ分だけの鍵は存在出来る
さらに都合の悪いことに/etc/passwdファイルの中身の
暗号文の生成には平文が 0x0000000000000000 でパスワードを鍵として(ry
Sboxがあるから鍵0でもどっかで必ずbit立つんじゃね?
だから0は不動点じゃない
さーてどこから始めよう
DESの鍵空間は広大だわ
結局bitの入れ替えとローテーションしかやってない訳だろ。
bit間の演算は存在しない。これは重要な事実だ。
つまり多段で複雑な演算の様に見えているが、
組み合わせ回路だけで構成可能ということ。
そこで入力bit列→出力bit列の対応表に還元して考えてみると、
bit単位での不動点は存在しても平文の不動点は存在しないことは明白。
847 :
デフォルトの名無しさん:2007/01/13(土) 13:59:49
bit
848 :
デフォルトの名無しさん:2007/01/14(日) 11:01:31
同じパスワードから、常に同じ公開鍵(RSAでn=512bit)ペアを生成したいのですが、
生成に使う素数をp,qとすると
1. p = パスワードのsha256ハッシュとする。
2. pの最上位と最下位のbitを1にする。
3. pが素数かどうか判定し、そうでなければ素数になるまでpに2を足しつづける。
4. qについてはパスワードをビット反転したものをsha256ハッシュして計算を始める。
素数判定の方法が同じなら同じ鍵が生成されると思いますが、
問題点があれば指摘してもらえませんか?
256ビットの整数が素数かどうかの判定に時間がかかりそうだなおい。
2の常用対数が0.3くらいだから77桁位か?
>>849 確立判定なら何とでもなる範囲。
だが、その時使う乱数によって非素数が素数と判定された場合、少し厄介。
>>848 問題点1
A, B両氏のパスワードがかぶった場合にまずい事になる。
A pass="aaa"
B pass="bbb"
と入力した場合二人の公開鍵が一緒になるが問題はないのか?
また、問題点2
C pass="aaa"
D pass="~a~a~a"(~aは'a'のビット反転をした値)
の時、パスワードが違うにもかかわらず公開鍵が一緒になる。
(∵pq=qp)
こんな簡単な問題も自分で見つけれない人間は、そもそもセキュリティに
手を出そうとしてはいけない。
>同じパスワードから、常に同じ公開鍵(RSAでn=512bit)ペアを生成したい
こんなのは無謀です。
>>851 書く前に読もうな?
256bitのハッシュ取るんだから元データが24bitとか32bitとかそこらなら衝突する可能性は皆無じゃないのか?
32byte文字列は256bit鍵空間に比べ随分小さいが、ハッシュを使う以上32byte以上の大きさのデータも扱えるから
問題ないだろ。
ただ、俺ならbit反転なんて楽な方法取らずにbit単位で規則的入れ替えするがな。
完全な素数かどうかの判定に随分時間がかかると思うが。
おおーい、
>>848はどうしたー?
また問題点見つけたから、書こうかと思ったんだが
851に対する意見がないのでどうしようか迷ってんだけど。
>>852 >256bitのハッシュ取るんだから元データが24bitとか32bitとかそこらなら衝突する
>可能性は皆無じゃないのか?
あほちゃう?文字数で言えば3文字か4文字だぞ。webでパスワードを設定
する場合に最低でも6〜8文字は設定してくれちゅうとこがほとんどだのに。
それと、sha256とかほとんどの一方向性ハッシュ関数は入力信号の最小単
位が1bitなんですけど。
>ハッシュを使う以上32byte以上の大きさのデータも扱える
こんな事言ってて恥ずかしくない?
sha256の仕様書を教えておくから勉強してこいよ。
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf >ただ、俺ならbit反転なんて楽な方法取らずにbit単位で規則的入れ替えするがな。
>完全な素数かどうかの判定に随分時間がかかると思うが。
どっかの誰かが入力したパスと、どっかの誰かの入力したパスを規則的入れ替え
たものがかぶったら・・・。とかってことまで考えが及ばないの?
だから、もしするんならpassをハッシュしたものをh_passとおいて、
pの元種h_pは、h_passの最下位ビットを0にしたもの
qの元種h_qは、h_passの最下位ビットを1にしたもの
っていう風にして、h_p, h_qをsha256に食わす。
848の言葉で言うなら、新しく生成されたハッシュをパスワードのsha256ハッシュとするんでしょ。
んっと、あと
p, qが素数の時p'=(p-1)/2, q'=(q-1)/2を満たすp', q'も素数でないとやばいよん。
理由とかは数学的な話なので、ここでは詳しく書かないけど。
855 :
848:2007/01/24(水) 18:33:12
>>851 問題点2は理解できたのですが、
pass="aaa"とpass="bbb"から出来る鍵が一緒になるというのはどういうことなのでしょうか。
完全な素数判定は困難なので、
フェルマーテストのような擬素数判定で十分だと考えています。
誰でも編集できる環境にあるファイルに対して簡単に追加できる
2chのトリップのようなものを考えているので、
乱数ジェネレータで事前に生成した鍵を使うのは不便です。
人間の考えるパスだし少々の衝突は仕方ないと考えています。
>>848, >851
問題点1
A, B両氏のパスワードがかぶった場合にまずい事になる。
A pass="aaa"
B pass="aaa"
と入力した場合二人の公開鍵が一緒になるが問題はないのか?
ごめん、↑に訂正だわ。
857 :
856:2007/01/24(水) 19:35:31
858 :
848:2007/01/24(水) 20:12:42
> 同じパスから同じ公開鍵ができなければならない理由
秘密鍵で署名したファイルの末尾に公開鍵を追加したものをうpして見せるような状況を想定しています。
ファイルをダウンロードしたら、裏方でファイル末尾の公開鍵を使って署名を検証します。
そして公開鍵の末尾数バイトをbase64したものをトリップとしてユーザーに表示します。
つまりランダム要素なしに同じトリップパスから
同じ公開鍵ペアが生成できないとトリップにならないんです。
…わかりにくい説明ですみません。
2chで、「名前#トリップパス」という名前で書いたとき、
「名前◆なんたら」のなんたらがいつでも同じでないといけないのと同じ理由なんですが。
>>848 そもそも署名がなんのためにあるか分かってる?
860 :
848:2007/01/24(水) 21:14:45
メッセージ作成者の証明、改ざん防止、否認防止じゃないんですか?
一緒に公開鍵もついてたら改ざんできるじゃん
て思ったけど公開鍵のハッシュで投稿者を同一視したいってことだから関係ないのね
ところでなんで今からRSA使うの?
ElGamalの方が簡単だし、楕円曲線上の群にすれば準指数アルゴリズムも知られてない
上のやりかただとパスワードのハッシュが違っても生成される素数が同じになる可能性があるよ
862 :
848:2007/01/24(水) 22:01:25
RSAは資料が多く、多倍長整数演算を実装すればそれで完成という感じなのですが、
楕円曲線Elgamalは資料が少なくて内容がさっぱりつかめないんです。
ハッシュが同じでも素数が同じになるというのは
2つのパスワードのハッシュがそれぞれ20と22だと、
生成される素数がどちらも23になるというようなことでしょうか。
>>862 >ハッシュが同じでも素数が同じになるというのは
>2つのパスワードのハッシュがそれぞれ20と22だと、
>生成される素数がどちらも23になるというようなことでしょうか。
そうそう。ハッシュ値->素数が単射ならまあよいかもしれない。
aと~aのsha256ハッシュ値に関連性が無ければだけど、たぶんないでしょう
で、ハッシュ値->素数の単射を考えるのは大変なのでもっと簡単な暗号の方
がいいんじゃないかと思ったんだけど
パスワードのハッシュかかぶったらなんていいだしたら
UNIXのログインシステム自体否定することになると思う
公開コンペ
865 :
デフォルトの名無しさん:2007/02/01(木) 00:19:12
FDiVqcgvuVgDxiOTPHGOXBPvlQQraSm+OHEV1LTP
bQQ=
CryptoAPIを使用して、「.crt」拡張子のファイルから署名値を取り出す方法ってどなたかわかりませんか?
868 :
デフォルトの名無しさん:2007/02/11(日) 07:33:44
2種類のハッシュ関数の対を使えばパスワード衝突の問題は回避されると思われ。
md5+sha256
とか。クローフリーペアを使うというか。
>>865 JavaScriptで作られたRSA暗号プログラムって知ってる?
妖精現実ってサイトにあるよ
870 :
デフォルトの名無しさん:2007/02/14(水) 05:04:11
rubyで作った楕円曲線暗号のプログラムを公開しています。
次は忌まわしきHDCPの復号だな
873 :
デフォルトの名無しさん:2007/02/17(土) 18:13:55
ほしゅ
874 :
デフォルトの名無しさん:2007/02/20(火) 20:08:39
ところで岡本栄司の「暗号理論入門」の表紙って何の暗号なんだろう
875 :
デフォルトの名無しさん:2007/02/25(日) 05:51:45
リング署名って参加者が誰かもわからないようになってるの?
量子コンピュータで全ての暗号は解読可能です
すでに16qubitの超高性能な量子コンピュータは商用として生産されています。
この超高性能を使えば人工知能や、温暖化の解決、将来の予測など
なんでも可能です。
16qubitで世界の全てのコンピューターを上回る性能があります。
877 :
デフォルトの名無しさん:2007/03/15(木) 03:52:40
>>876 また量子信者かよ。信仰もほどほどにしておけ。
そんな暗号と因数分解以外できないトランジスタレベルの素材が
実用になるわけないだろ。
878 :
デフォルトの名無しさん:2007/03/15(木) 23:50:53
いくら量子暗号でも、man in the middle 攻撃にはやられてしまうと思うのですが、
どうなのですか?
あーはいはい
AESを解読して論文を発表してからまたどうぞ
880 :
デフォルトの名無しさん:2007/03/16(金) 18:13:42
gpgで3DESって、どうやって3つのキーを指定してるんだろうか?
キーは1つしか聞かれないのに、
9文字以上なら分割して2個のキーとして見なす、とか。
頭の悪い奴が覚えられない文字数のキーなど意味がなく、その文字数が必要と
いうのならば、それ以上の文字数でも同じだろう。
つまりフラッシュメモリなどに記録して鍵として持ち歩けばいいだけ。
キーのアルゴリズム自体をフラッシュメモリで独自に選んだものを保存して
おけば、解読などありえないわけで。複雑な暗号も必要はなくなる。
暗号が解読されるとか騒いで複雑にするのは、単に仕組みが公開されている
からであり、仕組み自体が個人が選ぶユニークなものであれば、複雑な暗号
技術など不用。
解読されるのは全て同じ仕組みにするからであり、全て別の仕組みにすれば
解読などありえない。コンピュータウイルスが寄生するのと同じで
確率的に寄生できるところだけを寄生するだけ。暗号も確実に解読できる
ところだけ解読するだけ。
問題は運用にある、人間に問題がある。
どんな完璧な仕組みでも人間が問題でトラブル訳だ。理屈に支配されている
オマイには理解できないだろうけどな。
どこを何読みすれば>882を解読できるんだか
一つのキーから必要なぶんだけバイト列を派生させるのが普通だろ
計算そのものに対する暗号というのはあるんでしょうか
こんな感じの
・関数fを鍵kで暗号化する。関数f',g,hを生成。
・文"123"にgを適用する。文"abc"を生成。
・"abc"にf'を適用。文"xyz"を生成。
・"xyz"にhを適用。文"126"を生成。f("123")="456"であった。
・このとき、f',g,hを手に入れても、f("123")が"456"になることはわかるが、
それがどのような計算によってそうなったのかはわからない
886 :
デフォルトの名無しさん:2007/03/22(木) 20:19:35
勉強し直し
>>885 関数をブラックボックスだと考えれば
自分がどんだけアホな質問してるかわかるぞ
>
>>888 どんな画期的なのかと思ったじゃねーか。
OpenSSL(v0.9.8e)でWindows Mobile 5.0(CPU Armv4i)用のバイナリビルドしたいんだけど
誰かやり方知ってる?
デフォルトのmakeファイルじゃWCE1.1〜4.2までしかサポートしてない希ガス
デフォルトのmakeファイルを書き換えれば?
>>892 サンクスです 既成の情報があればと期待したのだけれど…手作業で直します
894 :
デフォルトの名無しさん:2007/04/03(火) 18:45:20
行列演算を使った非果敢な計算ならありえます。
>885
895 :
デフォルトの名無しさん:2007/04/03(火) 18:46:01
暗号メールの匿名サーバを公開したいんだけどどうよ?
896 :
デフォルトの名無しさん:2007/04/03(火) 18:51:13
ユーザは公開鍵をサーバに登録する。
ユーザごとに公開鍵は管理される。
サーバには暗号化されたメールしか保存されない。
またウェブメールなので読む場所に関わらずSSLを通して安全な
端末上で登録者本人のみが閲覧可能なメール。
メールにヘッダーを付け、ヘッダが無い平文は自動的に公開鍵で
暗号化される。ヘッダがあるものについてはそのまま保存される。
GPGやPGPとは互換性が無い。
どうやって復号するんでつか?
素数を1から計算していると時間がかかるので
素数のDBみたいなものを作ろうと思うのですが、これってやるとなると
ものすごい記録容量が必要ですよね?
そこで、素数を見つけたらそのハッシュを記録するようにして、
DBにハッシュ値を記録しておくようにすれば、容量の問題も随分と
少なくてすむと思うのですが。
素数の桁数を200桁から250桁まで・・みたいに最初からある程度範囲を絞っておいて、DBに記録しておけば
いいのかなー?と、漠然と考えています。
実際に使う場合は乱数で適当な数値を発生させて、そのハッシュ値を求め、
DBから同じハッシュ値があるか求め、ハッシュ値がDBにあったなら、本当に素数かを計算する・・
こんな手順でやろうかと思うのですが、もっといい方法や「根本的に無理・ダメ」という意見ございませんか?
ハッシュがぶつかることもあるかと思うのですが、その辺はまだどうしたらよいかは考えていません。
何か良い案がありましたら教えていただけたらと思いまして。。
250桁の数値の中に素数がいくつあるのか知らんけど、
ハッシュの桁数にもよるが、事実上ほとんど全部出てきてしまうんじゃないの?
つまり意味なしと思われる。
ハッシュ32ビットでも最低でも2Gの容量が必要。
つまり10進数でならせいぜい10桁少々程度のハッシュしか覚えとけないだろう。
対象となるハッシュ値が疎になるならもっと容量少なくてすむが、
多分そうはならない。
902 :
デフォルトの名無しさん:2007/04/04(水) 08:13:53
1番目の素数を記録させる
2番目以降はインデックスと次の素数までの差を記録する(素数自体よりは小さい値)
3番目
・・・
でいいんじゃない?
903 :
デフォルトの名無しさん:2007/04/04(水) 08:28:31
>897
使用者の秘密鍵は安全な端末か、ICカードの中にあり本人しか
利用できないものと仮定する。
クライアントからSSLを通して秘密鍵を送る。
送った秘密鍵はサーバに残らないとする。
秘密鍵を使ってサーバ上の暗号メールを解読する。
読みたい画面がSSLを通して読める。
ログアウト時に再び暗号化して保存しておく。
>>902 250桁の数値に素数がいくつあるとおもってんだ
>>903 専用の端末やICカードやらとにかくハードがいるなら、
専用クライアントソフトでもあんまり変わらんのじゃないか?
秘密鍵を送信するってのはちょっとなー
普通はやらないだろ。
906 :
デフォルトの名無しさん:2007/04/04(水) 08:53:27
サーバから暗号文を送信して、クライアントでメール利だを起動して読む
みたいな?
907 :
デフォルトの名無しさん:2007/04/04(水) 09:00:18
何なくても本人だって分かる仕組みがないと不便ですね復号。
908 :
デフォルトの名無しさん:2007/04/04(水) 20:08:02
>>898 このスレに、「暗号」の二文字が入っているのが分からないのか?
「数学」であればお前さんのいう方法でもいいだろうけど、
nの付近の素数の密度は約1/log(n)だぞん。
つまり、n/(logn)の素数があるわけだ。
素数200桁だとして、640bit。
2^640 / log640 = 2 ^ 640 / 9 = 2 ^ 641個素数がある
記憶メモリ、どれだけ必要なんだよ。
ある範囲だけ素数を調べるにしても、暗号には使えないよな。
909 :
898:2007/04/05(木) 02:25:38
お付き合いくださった方々どうもありがとうございます。
「ハッシュ値を記憶する」というアイデアはいけるかも!
っと思ったのですが、見事にアイデア倒れだったようですね^^;
どうもご迷惑をかけました。
200桁の数値を記録するのに必要なbit数は
200Log10/Log2≒664
より素数ひとつあたり84byte必要であるとする。
素数の数は200桁まででは
10^200/200Log10=10^198/2Log10≒10^198/4.6≒2.17*10^197
よりおよそ2.17*10^197個(≒1.3*2^315)である。
84*1.3≒109より
必要な容量はおよそ
109*2^315Byte=109*2^275TB
相当な容量が必要である。
計算間違ってたらゴメン。
うん?そもそもハッシュ値がDBにあったところで、どうやってもとの数を割り出すんだ?
913 :
912:2007/04/06(金) 02:19:12
読解不足だった。放っておいてくれ。
ハッシュ値もとめて照合するより、64bitくらいの数までなら32bitまでの素数のリスト作っておいて、
片っ端から割ったほうが速いんじゃないかって思ったんだが、どうだろうか?
素数のリストは素数一個に4byte使って無駄だらけな保存しても4GBには収まったはず。
4GBのディスク読み出すのに何分かかると思ってんだ。
15分もあれば読み込み終わるでしょ。
強い暗号化を施すのに掛ける時間に比べたらまだ少ないほうだと感じるが、どうか。
強い暗号化?
読み出すだけなら10秒もかからん気がする。
すげーディスクだなおい。
最近はそんな早いのか?
>>918 単位に注意w
4GBを10秒弱で読み込むディスクがあったら、是非ベンチマークで他の人の上を行ってくれ。
1MBあたり3ms未満とか、メモリ確保の速度ですか?
921 :
916:2007/04/06(金) 13:33:29
>>917 すまん、「強い」ではなく「処理の重い」
RSAとかの、素数を使う公開鍵暗号の事な。
あー、ハイブリッド式のやつなら処理の重さはあんまり関係ないか。
RSAでの暗号化でいつ素数判定を使うんでつか?
>15分もあれば読み込み終わるでしょ。
>強い暗号化を施すのに掛ける時間に比べたらまだ少ないほうだと感じるが、どうか。
RSAでの暗号化は15分以上かかるのか?
さっさと楕円曲線暗号に移行しよう。
あとRSAで長いデータを暗号化するメリットがない。
ああそうか、楕円暗号ってそっちがやばいんだっけ…
古典的な実装の基本特許はとっくに切れてるけどね
ElGamal暗号なんかはGnuPGとかに使われてるし
perlで使えるcryptのdesについてなんですが、
8バイトある第一引数がdesの64bit暗号化データ、2バイトのsaltが56bit暗号キーと対応すると考えてよいのでしょうか?
その場合、cryptのdesは56bitの暗号キーを使うと聞いたのですが、のこりの40bitはどうなっているのでしょうか?
違う。第一引数がキーで、1バイトあたり下位7ビットだけを使う。
DESでいうプレーンテクストは最初0固定で、改変DEAを25回重ねがけする
(暗号化64ビットに対して更に暗号化をかける)。
saltは12ビットを抽出して拡大転置テーブルの改変を行うもの。
".."を指定すれば通常のDESと同じになるけど。
どうでもいいがなんでコテハンなんだ?
VIPではよくあること
あれ?ダンゴリオンってVIPPERだっけ?
ところで911は俺だが、計算間違ってないよな?
しかし実際、RSAはもう限界が見えてるし、
早くなんとかなってほしいもんだ。
って今どういう状況か全然知らんけど。
そのコテ名初めて出たのって間違いなくVIPだ
たぶんあってるj
>920
すまん早すぎた。2分ぐらいかかるな。
>>936 ちなみに。
NTFSで色々試してみたら、FILE_FLAG_NO_BUFFERINGフラグをつけて1MB単位で読み込むだけなら1秒掛からなかった・・・。
4KB単位でも3秒強ってところかな。 ←原因は最適化が弱い言語でのループ
つけなければ、4KB単位で15秒程、1MB単位で18秒弱。
API先で仮想キャッシュ(実体は普通のメモリ)を使ってるせいで遅くなってると見た。
4GBを超えると色々制限が掛かってくるかもしれない。その場合に割合遅くなるかも。
4GBを1秒で読めるといってるように見えるのは気のせいだろうか…
現在のメモリ帯域って8.5GB/Sとかだよね、確か。
>>930 サンクス。
ソースあたらないとわからないようですね。
PCじゃないアーキテクチャで
メモリの読み出しとか整数論関連の計算やアルゴリズム実行が速いハードウェアを作ろう!
942 :
デフォルトの名無しさん:2007/04/08(日) 11:23:28
fpga
>>939 DDR2 533MHzならそうだね
XDR DRAMなら25.6GB/secはいく。
おおう、もうそんなに速いのか、すげーなぁ…
MD5完全に\(^o^)/オワタ
前から終わってる
DES終わってるのに未だにFelicaとかで使われてるぜ
949 :
デフォルトの名無しさん:2007/04/19(木) 21:45:11
>>948 Felica に使われてんのって 3DES じゃなかった?
相互認証が、ね
なあ、ハッシュを衝突させるアルゴリズムって、どういう考え方をしたら作れるんだろう?
たとえば俺が数分考えた俺最強ハッシュ
// 入力 : 配列 arr[], len
// ここでの int は 32bit でも 128bit でもなんでもいいとして
int a = 適当初期値1, b = 適当初期値2, c = 適当初期値3, d = 適当初期値4, e = 適当初期値5;
for(i = 0 → len-1){
a = b * 適当素数1 + arr[i] % 適当素数2;
b = c * 適当素数3 + arr[i] % 適当素数4;
c = d * 適当素数5 + arr[i] % 適当素数6;
d = e * 適当素数7 + arr[i] % 適当素数8;
e = a * 適当素数9 + arr[i] % 適当素数10;
}
hash = a^b^c^d^e; // 最終結果なわけで
ってのがあったとして、これを総当りでなく理論的に(総当りより短い時間で)破る方法ってのが
存在すると思いにくい。適当数は全て固定でいいとして、こういうのって逆算方法あるのかな?
>>951 %って+より演算の優先順位上だよな?
すると適当素数2,4,6,8,10で剰余取る意味無くね?
for(i = 0 ; i<=len-1 ; i++){
a = (b * 適当素数1 + arr[i]) % 適当素数2;
b = (c * 適当素数3 + arr[i]) % 適当素数4;
c = (d * 適当素数5 + arr[i]) % 適当素数6;
d = (e * 適当素数7 + arr[i]) % 適当素数8;
e = (a * 適当素数9 + arr[i]) % 適当素数10;
}
の方がいいのではないかと。
それと、適当な素数で剰余取ってる関係で上位のbitの反転率が低くなりそうだから、
i=sizeof(int)
#define l 適当な数1
#define m 適当な数2
#define n 適当な数3
#define o 適当な数4
hash = a^(b<<l+b>>(i-l))^(c<<m+c>>(i-m))^(d<<n+d>>(i-n))^(e<<o+e>>(i-o));
な感じにするがな。
953 :
952:2007/05/02(水) 20:07:34
すまん、逆算法についてだったな。
分からん、とだけ言うが、128bit同士の剰余算ってどうやったら効率的にできるんだろう?
954 :
デフォルトの名無しさん:2007/05/02(水) 20:20:51
>>951 高速に処理を行いつつ、衝突を起こさせない。
↑がハッシュ関数の信条。
お前さんのハッシュ関数は衝突は起こせないだろうが、高速処理が抜けている。
アセンブラで書いてみてどれくらいのクロック数になるか見積もってみそ。
また、shaを32bit出力に変換してみてどれくらいのクロック数になるか見積もってみそ。
たとえば、次のような擬似コードで、演算子の優先順位とかは C とか準拠として...
// 入力 (int/char) arr[], (int) len
// 出力はとりあえず 32bit UINT でいいとして
unsigned int a = 36319, b = 100393, c = 205043, d = 309857, e = 460373, hash;
for(i = 0 ; i <= len-1 ; i++){
a = (b * 484643) + (arr[i] % 471139);
b = (c * 111637) + (arr[i] % 376127);
c = (d * 379699) + (arr[i] % 708899);
d = (e * 67219 ) + (arr[i] % 247579);
e = (a * 890711) + (arr[i] % 503879);
}
hash = a^b^c^d^e; // 最終結果なわけで
>>954 汎用 CPU では遅いとは思う。でも、もし俺アルゴみたいな単純アルゴリズムが、速度をそれほど
重視しない && クローズドな状況において、標準的な技術である MD5 や SHA-x よりも強ければ、
標準技術より独自に考えた変なハッシュのほうがむしろセキュリティ上有用ってことになってしまうのかな?
正直、車輪の粗悪なる再発明ではないかと不安だ
すまん 何甘えてるんだ俺って感じだな
MODを求めるのがしんどいな
ワンチップマイコンにも簡単に組み込めるのが普及の条件。
単純な演算だけではどうしようもなくなってくると
結局仕方が無くなると思うけどな。
もしや mod なくても強度 && 散らばりにあまり影響しないのかな
ビットの攪拌やりたいならシフトやS-Boxを使ったほうがいい。
962 :
952:2007/05/03(木) 13:18:37
>>960 俺が書いたコードのように、全体を括弧でくくれば気休め程度に強度は高くなる。
だが、足し算やその前の掛け算でオーバーフローさせて拡散するのもありな気がしてきた。
そのほうが1サイクルあたり(32bit演算としても)200クロック位は速いし?
>>955 AESに選ばれたRijndaelの話なんだけど、
あれよりも高速か高強度の暗号アルゴリズムはAES候補の中にあったわけだし
総合的な性能を求めないのであれば有用なんじゃないの?
ただ、クローズドなのは正直いただけない
>重視しない && クローズドな状況において、標準的な技術である MD5 や SHA-x よりも強ければ、
>標準技術より独自に考えた変なハッシュのほうがむしろセキュリティ上有用ってことになってしまうのかな?
>正直、車輪の粗悪なる再発明ではないかと不安だ
クローズドな環境ってのはどういう意味でクローズドなの?
よっぽどのものじゃないと標準のが安全だと思うけど。
ていうか、末尾のビットいじるだけで規則性が見えるようなのじゃお話にならないんじゃ…
いろいろありがとう。
例示のコードは適当に考えたもので、別にクローズドでなくても良かったし実際どこかで使おうって
わけじゃないんでアレだけど...
よく検証されたオープンな技術は優れている場合が多いけれど、もし無線 LAN の WEP みたいに
攻撃方法が見つかってしまったら兄弟全滅なんで、独自物について安全性を検証する方法があったら
知りたいなぁってのが元々の考えですわ。でも結局、「独自系暗号」の強さを自分で検証するのは
難しいからセキュアにしたいところではオープンな技術を使いなさい、という至極真っ当な結論が
得られた気がするよ。
既知の2種以上のハッシュアルゴリズムでパイプライン処理しとけ。
967 :
デフォルトの名無しさん:2007/05/16(水) 21:57:06
高速で実績のある共通鍵暗号ってどんなのがありますか?
ノートPCに入れて置いているデータの一部を暗号化したいです
Camelliaだな
969 :
967:2007/05/17(木) 00:12:25
>>968 レスありがとうございます
Camellia検討してみます
CamelliaってなんかTDESみたいな構造してるな。
MISTYならわかるが、Camellia対応の暗号化ソフトって一般的に出回ってたっけ
ないと思うしそもAESでいいんじゃないの?
Linux 2.6.21にとりこまれたよ
974 :
デフォルトの名無しさん:2007/05/19(土) 17:40:45
楕円曲線暗号のフリーソフトを開発したんですが、
公開すると問題になりそうですか?
ソース公開なら引っかかることなくね?
976 :
デフォルトの名無しさん:2007/05/19(土) 17:43:56
VJ++で作ったんですが・・・
寧ろ俺は、どんな言語で作ったにせよ、少なくとも
暗号化ソフトのエンジン部のソースコードは公開するべきだと思うが。
可能ならCかJavaか何かのある程度メジャーな言語に書き下す方がいいかと。
>>977 ソースコードの公開よりも
数学的に安全性を証明することのほうが大切。
実装上の問題で穴ができちゃうこともあるから
ソースコードも公開されてるほうがよりいいとは思うけど。
俺は数学的に証明するのとかはかったるいので、
共通鍵暗号と公開鍵暗号のどっちに属するかと、鍵空間の大きさを書く程度なんだが。
確か、メルセンヌツイスタとか何とか言う暗号には使えない乱数生成機の周期の長さは
作者が証明してたな。
暗号には使えないって言っても、乱数系列が特定される恐れがあるからで
安全といわれる乱数とのXORやハッシュ値をとったりすれば十分実用にたえうる。
ちなみにgenrand()で与える引数が32ビット整数1個じゃ、特定しやすいだろうなぁ。
MTの空間の大きさを活用するには初期化には19937ビット分は必要だ。
つうかそもそも目的が違うわけで…
ところで一般的に暗号用乱数のシード初期化ってどういう仕組みになってんの?
たとえばハードウェアのノイズ使ってるとか?
time
タイミングであたりがついちまうだろうが
984 :
デフォルトの名無しさん:2007/05/21(月) 23:59:48
白色雑音だっけか?
あと、資源の使用量の変化とかじゃなかったか?
CPUやらメモリやらスレッド数やら
HDDのアクセス時間の微妙な差異から自然乱数を作る方法を紹介してるサイトがあったな。
10回程度とって他の擬似乱数のseedに使えばちょうどいいとか。
(というのも、遅い)
987 :
デフォルトの名無しさん:2007/05/22(火) 20:27:58
そういえば TPM に乱数生成機能ってないん?
って、ぐぐったらすぐに見つかった。やっぱあるんやね。
◎
363191 3932 433373