「Google Apps」、送信メールにDKIM署名が可能に
Googleは米国時間1月6日、「Google Apps」を利用する企業に対し、送信メールの認証を容易にし、メッセージが本当にその企業からのものでスパムではないと受信者が安心できるようにすると発表した。 Google Appsの全エディションにおいて、管理者は、コントロールパネルの「Advanced Tools」タブにおいていくつかのチェックボックスを選択することにより、送信メール用に「DomainKeys Identified Mail（DKIM）」技術を有効にすることができる。「Gmail」は2004年のリリース当初から、電子メール署名に関する各種規格をサポートしているが、実装にはそれ以上の設定とリソースが必要であった。 機能的には、これによって、合法的な電子メールメッセージがスパムフィルタによってブロックされることが少なくなる。 eBayやPayPalの名を語るフィッシング詐欺から直
研究者がMD5の衝突によりAuthenticodeで署名された実行ファイルを生成
すでに破られているハッシュアルゴリズムであるMD5を、SSLの証明書の検証に用いることによる危険については最近かなり聞くようになっている。米国時間1月17日、ある研究者がAuthenticodeで署名されたバイナリファイルと署名が一致する、悪意のあるソフトウェアの作成に向けて、大きな一歩を踏み出したことがわかった。 研究者のDidier Stevens氏は、Peter Selinger氏が説明する、同じMD5のハッシュ値を持つ2つの実行ファイルを生成する技術を使って、MicrosoftのAuthenticodeプログラムで署名された実行ファイルのペアを生成することもできることを示した。この技術を使うと、悪意のある人物が、Microsoftによって署名されており、正しいものとして検証されるが、実際には悪意のあるドライバを作成することが可能になる。 SSL問題の場合と同様に、Authentic
OpenSSH 情報 - [misc][暗号]「原理から学ぶネットワーク・セキュリティ 第5回 電子証明書と認証局」の問題点
2008/01/02 - [misc][暗号]「原理から学ぶネットワーク・セキュリティ 第5回 電子証明書と認証局」の問題点 原理から学ぶネットワーク・セキュリティ 第5回 電子証明書と認証局：ITproの問題点を挙げていきます. 一通り作成しました. 導入部 公開鍵暗号では，「秘密鍵」と「公開鍵」の2つの鍵をペアにして使います。この2つの鍵は，次の2つの性質を持っています。 性質1）秘密鍵から公開鍵は容易に生成できるが，その逆は非常に困難（図1）。 性質1は間違いです. 秘密鍵から公開鍵は容易に生成できることは公開鍵暗号の必要条件ではありません. 公開鍵から容易に秘密鍵が生成できては公開鍵暗号として成り立たないので, この点は問題ありません. 性質2）秘密鍵で暗号化した情報は，そのペアである公開鍵でなければ復号化できない。また公開鍵で暗号化された情報は，そのペアである秘密鍵でなければ復号
OpenSSH 情報 - [misc][暗号]「原理から学ぶネットワーク・セキュリティ 第4回 ハッシュ関数」の問題点
原理から学ぶネットワーク・セキュリティ 第4回 ハッシュ関数：ITproの問題点を挙げていきます. 一通り書きました. 作成中の段階では間違っていた部分があったのを確認していますが, 修正したつもりです. 私も暗号屋ではありませんので, 文章の内容の保証は致しません. 修正の御指摘は歓迎します. 導入部 データ構造としてのハッシュ/ハッシュ・テーブルと暗号技術のハッシュ関数を混同して説明するのは, 誤解を生むおそれがあります. 仮に暗号技術のハッシュ関数の説明の中でデータ構造としてのハッシュに触れる場合でも, 異なるものと説明したほうがよいでしょう. ハッシュ関数の説明として, 一方向性だけが挙げられていますが衝突耐性についても触れておくべきです. 後のコラムで衝突耐性について触れられていますが, 内容は不正確です. ハッシュ関数の実験 この部分の内容に問題はありません. ただし, 先に衝
高木浩光＠自宅の日記 - 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと
■ 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと 「コンピュータセキュリティを基礎から」というと、暗号の解説、特に共通鍵暗号と公開鍵暗号の違いからなどといった解説をよく目にする。昔は専門の方によって注意深く書かれていたのに対し、ここ何年かはひどい状況になっている。先月、宮崎で開かれたSCIS 2008の席でも暗号研究者の方々との雑談でそういう話になった。私は暗号は専門でないのでその話題は迂闊に書けないできたが、このところの巷の誤り解説の氾濫ぶりは目に余るものがある。 最もひどく蔓延っていてしばらく消えそうにない間違い解説の典型例は次だ。 「公開鍵で暗号化したものを秘密鍵で復号するのと同様に、秘密鍵で暗号化したものを公開鍵で復号できるようになっている。」 事例1: 日本ベリサイン株式会社による公開鍵暗号方式の解説 このような共通鍵暗号方式の問題点を解決する暗号方式が、公開鍵暗号方式
暗号の危殆化と新しいアルゴリズム — 旧メイン・ブログ | Baldanders.info
L が鍵長で N が被署名データのサイズです。 FIPS186-3 ドラフト案ではこの組み合わせの中から選択して使うべきとしています。 ところで署名・暗号に使う鍵の長さはどの程度が適当でしょうか。 確かに長ければ長いほど安全といえますが， 長すぎる鍵はとりまわしが不便です。 この件については IPA/ISEC による 「将来の暗号技術に関する安全性要件調査」 が参考になります。 詳しい内容はそちらを読んでいただくとして， 結論としては， 今後10年のスパンで考えるなら共通鍵暗号の鍵で128ビット程度で十分なようです。 128ビットの共通鍵暗号鍵を公開鍵暗号鍵に換算するとどの程度になるかは難しいですが（先ほど紹介した調査報告書では参考値としながらもかなり大きい鍵を要求しているように読めましたが）， これについては RSA Security による 「A Cost-Based Security
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
