iida 曰く、 "しばらく前からβだったOpenSSL 0.9.8だが、2005-07-05に正式リリースされたようだ。
細かくは色々と変わっているようだが、特に興味深いところは、
- 既定の署名アルゴリズムがMD5からSHA-1になった
- RC5暗号とMDC2ハッシュが (既定では) 組み込まれなくなった
- RFC 3820 (3280ではなく) のプロクシー証明書の処理が追加
- SHA-224/-256/-384/-512 の追加
- DSA署名にかかる時間で情報の漏洩しないよう、一定時間しないと戻らないよう変更
- ca下位コマンドに-utf8オプションが追加
といったあたりか。"
ChangeLog (スコア:3, 参考になる)
どうせなら ChangeLog [openssl.org] にリンクを貼ってください.
楕円暗号 (スコア:1)
楕円曲線暗号って「まだ枯れてない」とかいう暗号学者もいるみたいですが、
使っちゃダメってことはないんですよね?
実用なさっている方はレビューお願いします。
Re:楕円暗号 (スコア:1)
実用してても、何をレビューして良いのか判らない。
実用しているからと言って、枯れてるか否かは答えようがないし。
Re:楕円暗号 (スコア:1)
前半では、「いや、これだけの数学的根拠があるんだよ」とか
「弱い曲線も見付かってるから、やはり危ないと思う」とかいう情報を期待していました。
後半では、使ってみて「ぜんぜん他と区別なく使えるよ」とか
「ベンチマークとってみたけど、同程度の安全性ならこれだけ速いね」
とかいう情報があれば知りたい、ということを書いていたつもりでした。
混乱させてしまって、すみませんでした。
で、どうなんでしょうね、実際のところ。
ECC-based TLS ciphersuite がどうとか書いてありますので、
早いひとはもう ECC を試していると思うんですが。
covert channel 対策 (スコア:1)
http://www.daemonology.net/hyperthreading-considered-harmful/
Re:covert channel 対策 (スコア:2, 興味深い)
これじゃないかなあ、と思います。
おー!正式版ですかぁ (スコア:0)
きになっていました。
Re:おー!正式版ですかぁ (スコア:1)
↑ (スコア:0)
OPENSSHのサイトにいってしまった事は内緒である
恥ずかしくていえなかったのですが (スコア:0)
Re:恥ずかしくていえなかったのですが (スコア:0)
OpenSSL 3.9.8 とかにしろってこと?
OpenSSL は SSL 限定のライブラリじゃないし、TLS の
存在もあるし、別にいいんでは?
SHA-1やMD5は (スコア:0)
SHA1-とMD5は署名アルゴリズムじゃなくて、ダイジェストアルゴリズムです。
Re:SHA-1やMD5は (スコア:2, 参考になる)
SHA-1は米国立標準技術研究所で認定されてるデジタル署名アルゴリズムですが。
米国政府がデジタル署名の暗号化アルゴリズムとして唯一認めてるのもSHA-1だな。
Re:SHA-1やMD5は(オフトピ) (スコア:2, 参考になる)
但し,最近色々攻撃されているので,NISTは
SHA-224, 256, 384, 512に早めに移行することを推奨しています.
デジタル署名で使用が許可されているのは,
DSA, ECDSA, RSASSA-PKCS#1 v1.5, RSASSA-PSS,
ANSI X9.31(RSAの一種)です.
詳しくは [nist.gov]CMVPのサイトをどうぞ. [nist.gov]
Re:SHA-1やMD5は(オフトピ) (スコア:0)
Re:SHA-1やMD5は (スコア:2, 参考になる)
ハッシュ関数と公開鍵暗号(と共通鍵暗号)を組み合わせないと、署名として成り立たない。
ちなみに、こんな話もあるようです。
Re:SHA-1やMD5は (スコア:1)
Re:SHA-1やMD5は (スコア:1)
Re:SHA-1やMD5は (スコア:1)
「md5やsha1と聞くとハッシュアルゴリズムであると解るのは常識」と定義すると、「既定の署名アルゴリズムのハッシュ関数が」と読み取るのは常識なんじゃないの?
拇印アルゴリズムの存在を忘れていないか?
拇印アルゴリズムの存在を語らずに、「md5やsha1は署名アルゴリズムではない」って話はどうかと思うぞ。
「車のタイヤ交換」とか言うと、「タイヤが車なんだよ」みたいな揚げ足取りみたいな感じ?
自動車のタイヤ(車)を交換すると言わなくても解るよな。
Re:SHA-1やMD5は (スコア:1)
PKIの世界で「拇印」と言うのは、ハッシュ値のこと。「拇印アルゴリズム」とは「ハッシュアルゴリズム」のこと。
何か忘れてることがありますかね?
> 「md5やsha1は署名アルゴリズムではない」って話はどうかと思うぞ。
なにが「どうか」なんでしょうか?今一解らないんですが。別に、「md5やsha1は拇印アルゴリズムである」と言い直しても、私の主張は変わりませんが。
話の流れ、ちゃんと掴んでますか?#764012 [srad.jp]の という発言を受けて、#764022 [srad.jp]で という反論が成されているのですよ。どちらがより正確か、といえば前者だし、後者こそがタイヤと車を混同した発言といえるのでは?
Re:SHA-1やMD5は (スコア:1)
何処で使われているハッシュアルゴリズムかの話であるかを示すために「既定の署名アルゴリズム」と表現されているだけ。
「既定の署名アルゴリズムがMD5からSHA-1になった」の「署名アルゴリズムが」とは、「署名アルゴリズムのハッシュ関数が」を略している過ぎない。
「署名アルゴリズムではない」とか言っているのって、「署名」か「拇印」かを表す表現に対して言葉尻を捉えて揚げ足を取っているに過ぎない。
md5やsha1のより適切な理想的な呼び方は何かを質問している奴に対する解答ならば、「ダイジェスト」や「ハッシュ」と表現するのは適切だろう。
しかし、そもそもはどう言った呼び方が適切か否かという話ではない。
OpenSSL0.9.8でタレコミに「既定の署名アルゴリズムがMD5からSHA-1になった」と書かれている点の是非だろ。
より適切な理想的な呼び方の話ではなく、「署名アルゴリズムが」とは「署名アルゴリズムのハッシュ関数が」というのを省略しただけ。この省略の是非なの。
変更点を署名アルゴリズムのハッシュ関数か拇印アルゴリズムのハッシュ関数かを明確にしたかっただけでしょ?
「拇印アルゴリズム」を抜きに勝手に理想的な呼び方の話をしているだけ。
この枝自体が揚げ足取りなの。
「署名アルゴリズム」という表現の否定は、省略禁止の揚げ足取りそのものなんだよ。
「md5やsha1のより適切な理想的な呼び方」って枝じゃないの。省略行為の是非なんだよ。
ハッシュは拇印でも使われているのだから、省略した理由は分かるだろ。
拇印抜きに省略の是非を語る行為は、省略の目的の存在を考慮していないことになるの。
書き手の文意をまず理解しようとするべきだろ。文意や目的を放置し、言葉尻を捉える行為はつまらないよ。
ハッシュ関数(アルゴリズム)だって、色々あるよな。一部の言語には中身から変数名検索出来る奴もあるし。
「一方向ハッシュ」と表現するべきとか、省略禁止の考えだときりないよ。
md5やsha1から一方向ハッシュって解るんだから「省略した方がすっきりする」と判断して書かれても、それは察するべきだよ。
Re:SHA-1やMD5は (スコア:1)
> が」とは「署名アルゴリズムのハッシュ関数が」というのを省
> 略しただけ。この省略の是非なの。
#764012 [srad.jp]で正確な表現をしているのを、#764022 [srad.jp]ではわざわざ不正確な言い方に変えている。わざわざ不正確な言い方に変えるのなら、それなりの説明(例えば、君が書いたような)があってしかるべき。しかし、#764022 [srad.jp]はそうなっていない。
もし君のような指摘をするなら、私のコメントに対してではなく、#764012 [srad.jp]に対して指摘すべきだろう。まったくのお門違い。出直したまえ。
> 書き手の文意をまず理解しようとするべきだろ。
文意云々で言うなら、#764022 [srad.jp]は、署名アルゴリズムとハッシュアルゴリズムを混同している可能性が十分あるね。だからこそ、私以外の人も同様の指摘をしているのだよ。よく読み、話の流れを掴みたまえ。
Re:SHA-1やMD5は (スコア:1)
「君が書いたような)があってしかるべき」って、俺は、俺が述べたような意味も含まれていると感じたけどな。
>文意云々で言うなら、#764022は、署名アルゴリズムとハッシュアルゴリズムを混同している可能性が十分あるね。だからこそ、私以外の人も同様の指摘をしているのだよ。よく読み、話の流れを掴みたまえ。
「可能性」ですか.....可能性は可能性に過ぎないのでは?憶測で言ってもつまらんだけ。
OpenSSLの実装の話に参加している奴に対して、「署名アルゴリズムとハッシュアルゴリズムを混同している」なんて憶測で語るのはどうかしているよ。
相手の知識を過小評価する必要がどこにあるのだ?
そこそこの知識があるという前提に立てば、タレコミが十分解った上で省略するのも理解出来るはずだし、アメリカの某機関が署名アルゴリズムと呼んでいる旨の話も「省略してそう呼んでいる」って話に感じるのでは?俺はそう感じたけど。
某機関が混同してハッシュアルゴリズムを署名アルゴリズムと呼んでいるのか?
ちがうだろ?単にそこも省略しているってだけなんじゃ?
俺には某機関も省略している旨として提示された様に感じたよ。
「混同している可能性が十分ある」って、そう憶測で考えずに、省略の話をしていると読んだ方が良いんじゃないの?
そもそものタレコミ文も省略して書いているだけだろうし。
Re:SHA-1やMD5は (スコア:1)
君は本当にバカだな。「過ぎないのでは?」というのは、可能性でものを言っているに過ぎないのでは?可能性でものを言っているのでないのなら、きちんと断定すべきだし、そうでないのなら、自分の発言が自分自身に当てはまることを自覚したまえ。
私の考えでは、可能性を指摘することは、十分意味があると思うがね。
君の反論の残りの部分に対しては、「話の流れがまったく見えていない」という一言で終わりだ。
Re:SHA-1やMD5は (スコア:1)
Re:SHA-1やMD5は (スコア:1)
君はこの和文が読めないのかね?
Re:SHA-1やMD5は (スコア:1)
>君はこの和文が読めないのかね?
断定すべき理由が「可能性でものを言っているのでないのなら」ですか。
>文意云々で言うなら、#764022は、署名アルゴリズムとハッシュアルゴリズムを混同している可能性が十分あるね。
#764713
と「可能性」を基に憶測で混同している旨を論じた人が言う台詞か?
(断定すべきなら、まず貴方が断定すべきなんじゃ?)
俺は、貴方が「混同している可能性が十分あるね」と「可能性」と言う憶測を持って論じていたので、止めた方が言い旨を述べたんだよ。
「可能性は無い」と否定しているのではないの。実際に混同していようと俺には何ら関係無いの。
ただ、「単に省略して論じている可能性も十分ある」の。
可能性は可能性に過ぎ無いのだから、そう言った憶測を持って論じることは止めた方が良いと俺は言っているの。
タレコミだって、省略しているだけだろ。
拇印アルゴリズムもあるから、「ハッシュ」と書かず「書名」と書いただけじゃん。
憶測で「知らん奴(署名とハッシュの区別が付かない奴)」と決め付けるのは下衆のすること。
拇印アルゴリズムの存在を知っていて度忘れしていなければ、省略した理由は分かる筈。
他所でハッシュを使うところがあるから、署名の初期ハッシュアルゴリズムの変更と分かるように書いただけ。
それを、揚げ足とって「正しい呼び方じゃない」と言っているだけ。
その後、混同していると憶測で論じはじめる。
それは下衆な展開だぜ。さっさとそれに気づけよ。
# まぁ、「バカ」発言する奴に何を言っても無駄とも感じているけどな。
Re:SHA-1やMD5は (スコア:1)
何の問題もないと思うが。
で、君はどうだと言っているのかね?断定するのか、しないのか?
> (断定すべきなら、まず貴方が断定すべきなんじゃ?)
なぜかね?僕の立場は、可能性の指摘には十分意味がある、というものなのだから、必ずしも断定する必要は無い。
一方君は、可能性でものを言う事は、憶測であり、つまらないことである、と言うのだから、必ず断定すべし。
君と他人は違う人間なのだから、必ずしも立場を一にするとは限らんのだよ。自分と他人の区別はきちんと付けたまえ。
> 止めた方が言い旨を述べたんだよ。
助言ありがとう。しかし、君と僕とは立場が違うようだ。
お礼に、その助言が自分自身に当てはまらないか、よく考えてみる必要がある、と助言しておこう。
> 決め付けるのは下衆のすること。
どこの誰がそんな「決め付け」をしたのかね?僕は可能性を論じたことはあるが、「決め付け」たことは無いよ。君こそ勝手に「決め付け」てないかね?
Re:SHA-1やMD5は (スコア:1)
>一方君は、可能性でものを言う事は、憶測であり、つまらないことである、と言うのだから、必ず断定すべし。
貴方の主張は理解出来ないです。
憶測で論じて断言ではないと?
「必ず断定すべし」と貴方が思っているのならば、「断言した」と取って構いませんが、断言すべき必要性は俺にはさっぱり分かりませんな。
俺は「憶測でつまらないこと」と言えばIDで書いている貴方ならば理解してくれると思っていたが、貴方は「憶測であること」やそういった行為が「つまらないことである」事を認識しない人だった訳ね。
Re:SHA-1やMD5は (スコア:1)
可能性を論じるのであれば、断言はできないだろう。何か反論でも?
なお、憶測だかなんだか解らんが、「決め付け」てしまったのは、Ryo.Fでなくてchanbabaだ。
> 断言すべき必要性は俺にはさっぱり分かりませんな。
chanbabaは、「可能性」で論じることを「憶測」と呼び、「つまらないこと」だと書いた。であればchanbabaは、須らく「断言」すべき、となる。何故なら、「断言」できない「可能性」があってはいけないのだから。
> 俺は「憶測でつまらないこと」と言えばIDで書いている貴方ならば理解してくれると思っていたが、
その思い込みは「憶測」ではないのかね?「憶測」で物を書くことは「つまらないこと」ではないのかね?chanbabaの行為は「つまらないこと」ではなく、chanbaba以外の人の行為は「つまらないこと」で済ますのかね?それはどういう理由から可能になるのかね?
いい加減に自分の誤りを認めたまえ。書けば書くほど、ボロがでるような主張をしてしまったのだから。
言っておくがRyo.Fは、chanbabaの#764364 [srad.jp]の主張を全面的に否定しているわけではない。ただ、その主張をRyo.Fにぶつけるのは、「流れが読めていない」し、「筋違い」だ、と言っている。
#拇印アルゴリズム云々は意味不明だが。
Re:SHA-1やMD5は (スコア:1)
の様な論拠が分からんのばかりですね。
>言っておくがRyo.Fは、chanbabaの#764364の主張を全面的に否定しているわけではない。ただ、その主張をRyo.Fにぶつけるのは、「流れが読めていない」し、「筋違い」だ、と言っている。
>#拇印アルゴリズム云々は意味不明だが。
何に対して「筋違い」と述べているの?
タレコミ文は、「省略」したのか、それとも「区別出来ない奴」とか「間違い」なの?
俺は前者だと思う。「拇印アルゴリズム」に関して「意味不明」と言っていることは俺には理解出来ないよ。
「既定値の変更は」「署名アルゴリズム」のハッシュアルゴリズムであり、「拇印アルゴリズム」のハッシュアルゴリズムの事ではない。
「署名」か「拇印」かが重要な部分であり、長くなるから省略して書いただけなんじゃ?
俺にはそうとしか思えない。タレこんだ彼が「区別出来ない奴」とか「間違い」なんて全く思えない。
単なる「省略」だろ。
で、「流れは」俺は、「省略」で書いたものに対して、揚げ足を取り「省略であることに気がつかない奴ら」と某所でも省略していると言う意味で「署名アルゴリズムって言っている旨を述べる奴ら」で話が噛み合っていないように感じたよ。
きっと「省略であることに気がつかない奴ら」の視点の流れでは、「署名とハッシュの違い」の話を言っているのに技量の無い奴が口挟んでいるように感じていたのだと思うが、
逆側から見れば、省略を否定する論拠は出てこないと感じていたのでは?
だから、俺は「省略」しただけのものに対して、省略の可能性を考えずただ揚げ足取りをする奴がいて、他所でも省略している旨を提示しても「署名とハッシュ」が論点と誤解している貴方にレス書いたの。
拇印アルゴリズムの存在を知っていれば、「既定値が変わった」のは署名アルゴリズムのハッシュアルゴリズムで、拇印アルゴリズムのハッシュアルゴリズムじゃないので、単に「署名アルゴリズム」と省略したと分かるよね。
貴方は深く考えず度忘れしていたのだろ。だから「省略の話」と思えなかっただけだろ。
「省略」したものを、省略したと分かっていながら揚げ足取った奴と同じ主張をしていたのか?
明らかなミスを揚げ足取ってふざけることは俺もあるよ。
でも、省略したものを省略したと分かりながら揚げ足取って楽しむのは下衆だし、省略したことに気がつかず言っていたのなら無様だよ。
だから、俺は省略していることを貴方に伝えたの。
で、貴方は伝えた人に逆切れ。
流れが読めていないのは誰?タレコミ文は省略しているのだろ。
貴方の書き込みは「揚げ足取りに加担しているように見えるの」。
Re:SHA-1やMD5は (スコア:1)
chanbaba以外の人には十分理解できるように書いたから問題なし。
> 何に対して「筋違い」と述べているの?
きっとchanbaba以外の人には解るだろうから問題ない。
> タレコミ文は、「省略」したのか、それとも「区別出来ない奴」とか「間違い」なの?
タレコミ文については「省略」だろう。
タレコミ文のことについては、Ryo.Fは、これ以前に何の言及もしていない。それを勝手に「決め付け」て論じてきたのがchanbabaのやり方だ、ということ。確か君の理論によれば、そういう「決め付け」は「つまらないこと」だったね。
> 流れが読めていないのは誰?
間違いなくchanbaba。おそらくchanbaba以外の人にはそう見えるだろう。Ryo.Fの具体的な指摘・質問に何も応えようとしないchanbabaの態度は、chanbabaを不利にしているよ。いい加減に諦めたまえ。
諦められないというのなら、#765898 [srad.jp]にRyo.Fが書いた「?」一つ一つに答えてみたまえ。結論がはっきりするよ。
Re:SHA-1やMD5は (スコア:1)
e-Words による定義 [e-words.jp]
# MDx は message digest、SHA-x は Secure Hash Algorithm
Re:SHA-1やMD5は (スコア:0, 余計なもの)
Re:SHA-1やMD5は (スコア:0)
違いますがな。
「ハッシュ関数」=「ダイジェスト関数」。ディジタル署名するときにダイジェストを使うけど、署名≠ダイジェスト。
SHA1には負けるけど (スコア:0)
Re:素朴な疑問 (スコア:1)
# 開発工程の最後の1割が実は5割だとか,プロジェクト管理でありがち.
Re:素朴な疑問 (スコア:2, おもしろおかしい)
Re:素朴な疑問 (スコア:2, おもしろおかしい)
64+54=118歳?
Re:素朴な疑問 (スコア:1)
53*64+54=3446才だった。
Re:素朴な疑問 (スコア:1)
Base64なら1*64+2=66じゃないの?
こんな計算よりもこんな計算結果をだすchanbabaさんの年齢がきになる(ぁ
Re:素朴な疑問 (オフトピック) (スコア:2, 興味深い)
BASE64の「1」が二進数の「110101」になるのはいいのですが、
デコードは4符合を3バイトにします。
「110101 110110」→「11010111 01100000」となります。
これを文字にするとASCIIの範囲から外れるのでどうなるのかは書きません。
さらに言うと、パディングが必要なので、エンコード後は
「12==」でなければなりませんね。
単なる臆病者の Anonymous Cat です。略してACです。
Re:素朴な疑問 (スコア:1)
16進数は0-9の後にa-fがあるけど、base64は0-9の前に英数大小26*2が存在し、0-9の後に記号があるはず。
Re:素朴な疑問 (オフトピック) (スコア:1)
RFCに沿った文字のエンコード規格を「数値の64進表記として使ってはならない」と言うルールは無いと思うけど。
Re:素朴な疑問 (スコア:1)
メールの添付ファイルや、HTTPのベーシック認証などで利用される符号化の一種です。
単なる臆病者の Anonymous Cat です。略してACです。
Re:素朴な疑問 (オフトピック) (スコア:1)
0xd7(215)と0x60(96)ですから。
わざわざBASE64なんて持ち出さなくても、0x31(49)と0x32(50)で
50*256+49もしくは、49*256+50で十分化け物だと思います。
単なる臆病者の Anonymous Cat です。略してACです。
Re:素朴な疑問 (オフトピック) (スコア:1)
64進数をbase64の文字を使って表すだけだろ?
6ビット8ビット変換をする理由が解らん。「=」もついていないのに。
16進の「12」だと、アスキーコード表使って各文字コードから8ビットコードを出して、その二つを連結し16ビットコードとしての値を出すみたいな話?
そう言った面倒なことをする意味が分からん。
16進12は(10進)1*16+2=18。0-9,a-fの順だから。
64進12は(10進)53*64+54=3446だろ?
64進(base64の順)は、A-Z,a-z,0-9,+,/の順だから。
数字を文字コードに変換し、でかくなる旨を言っている意味が分からん。数字は数字なのに。
16進のコードの表記は大抵「0x12」みたく書くけどな。
Re:素朴な疑問 (オフトピック) (スコア:1)
あぁ、そういう意味でしたか。
それなら納得です。
> 6ビット8ビット変換をする理由が解らん。「=」もついていないのに。
単にBASE64と言われると、8bit-6bitの変換まで含めて考える人のほうが多いと思うんですけどね。
> 「110101 110110」→「11010111 01100000」となります。
と書きましたが、おかしかったです。
2符号になるのは1byteをエンコードした時なので
デコードすると当然1byteになりますね。
そして2byte目に1のビットが残りません。
ですから「12」や「12==」はBASE64であるはずが無いですね。
単なる臆病者の Anonymous Cat です。略してACです。
Re:素朴な疑問 (オフトピック) (スコア:1)
符号化結果の文字列が"12"なら「110101 110110」で残り2バイトパディングが必須だし、良心的にデコードしても
1byteだけ取り出せて11010111b = 215。
Base64の変換表だけ利用した64進数表記という主張は苦しくないですか?
Re:素朴な疑問 (オフトピック) (スコア:1)
パディングとかもあるから厳密にはそうだが、base64でググれば、64進数表記とも言える旨が書かれているサイトは見つかるはず。
そもそも、18とか12とかって、単なるふざけた茶化しの話だったのだろ。
12は16進数表記の話。だから64進数表記の話をしたまでだけど。
>符号化結果の文字列が"12"なら「110101 110110」で残り2バイトパディングが必須だし、良心的にデコードしても
>1byteだけ取り出せて11010111b = 215。
「12」や「12==」になるbase64エンコード後のデータは存在しないことは既に彼が書いたのでは?
書いた後で無理やりデコードですか....
そもそも8ビット文字でしかない物を数値に変換する変換式はそれで良いのか?
例えば、先頭ビットは符号を表すか否かも決まっていないよね?
>Base64の変換表だけ利用した64進数表記という主張は苦しくないですか?
苦しいか否かって、俺が始めに提示した計算式から何を連想したの?
俺が提示したときに何を思ってbase64と表現したのかが重要なんじゃないの?
16進数では大抵hex表記を使うけど、64進数と述べるだけでは何を言っているか訳分からないだろ。だから、base64と表現したんだよ。
「符号化結果の文字列が」とか「エンコード」なんて俺は一言も述べていないんだし。
#764975の話に対しての議論で、この蒸し返し展開は変じゃないの?
RFCにはbase64は文字列変換って書いていて、数値変換とは書いていないんだし。
変換するのならば、アスキーコード表使って文字に変換すべきなんでは?
でも、トップビット立っているから、何に変換するかってルールは曖昧だよな。
だから、そう言った話をしているのではないと分かる筈なんだけど。
215は苦し過ぎるし、今更蒸し返す程の事なのか?
始めっから「base64とだけ書かずに64進数をbase64文字で表現したらと書け」って話ならば分かるけど、今更蒸し返されたもな。