タグ

Algorithmとsecurityに関するrydotのブックマーク (6)

  • GoogleのSHA-1のはなし

    5. • その暗号技術がどのぐらい安全かを表す大雑把な指標 • nビットセキュリティは2 𝑛 回攻撃が必要 • 1回あたりの攻撃コストはあまり気にしない • 𝑂 2 𝑛 という表記 セキュリティビット 𝑛 直線 :𝑂(𝑛) 3次関数 : 𝑂(𝑛3 ) 指数関数 : 𝑂(2 𝑛) 𝑂(log 𝑛) 5 / 21 6. • 第二原像計算困難性(弱衝突耐性) • 𝑚1に対して𝐻 𝑚2 = 𝐻 𝑚1 となる𝑚2 ≠ 𝑚1が分からない • 同じじゃなくてもいいから何か一つ見つけるのが困難 • 𝑂(2 𝑛 )回トライ ; nビットセキュリティ • 衝突困難性(強衝突耐性) • 𝐻 𝑚1 = 𝐻(𝑚2)となる𝑚1 ≠ 𝑚2を見つけるのが困難 • 𝑂(2 𝑛/2 )回トライ ; 𝑛/2ビットセキュリティ • 第二原像を見つけるのは単なる衝突より2

    GoogleのSHA-1のはなし
  • 暗号文のままで計算しよう - 準同型暗号入門 -

    2. • 準同型暗号とは何か • 加法準同型暗号のデモ • 楕円ElGamal暗号 • 完全準同型暗号 • その原理の雰囲気の紹介 • 『クラウドを支えるこれからの暗号技術』 • 公開鍵暗号の最先端応用技術・理論 • 準同型暗号が載ってる和書は現時点で書のみ • 数学成分高め • https://herumi.github.io/ango/ 概要 2/39 3. • 光成滋生(@herumi) • @IT連載記事「クラウド時代の暗号化技術論」 • http://www.atmarkit.co.jp/ait/series/1990/ • CODE BLUE2015 • Excelのパスワード暗号化にあったバグの話 • http://www.slideshare.net/herumi/ms-office-54510219 • 属性ベース暗号の実装でIEEE trans. on Compute

    暗号文のままで計算しよう - 準同型暗号入門 -
  • クラウド時代の暗号化技術論

    エンジニアならば、情報の重要性を誰よりも理解しているはずです。そこで、クラウド時代にエンジニアが知っておくべき「暗号」論を、もう一度おさらいしてみてはいかがでしょうか。デブサミにて反響が大きかった「クラウドを支えるこれからの暗号技術」を執筆した筆者による新連載です。

    クラウド時代の暗号化技術論
  • 暗号の危殆化に関する調査:IPA 独立行政法人 情報処理推進機構

    電子政府、電子商取引において暗号は基盤技術として利用されている。しかし、計算機の進歩等の研究開発の進展により、いくつかの暗号については近い将来に危殆化するものと予想されている。暗号が危殆化すると、電子署名の証拠性に疑義が発生し、電子政府における公文書、電子商取引における契約等の信頼性が揺らぐと考えられる。 このような暗号の危殆化問題について、システム上の影響や技術的・制度的対策、法律上の問題に関する検討は未だ殆どなされていない。そのため、暗号が危殆化した際には、社会的な混乱が予想される。 そこで、調査では主として電子政府において使用される暗号が危殆化した際の影響、法律上の問題について分析を行い、技術的・制度的対策に関する検討の結果を示した。 1. 暗号技術を取り巻く状況 2. 暗号危殆化の定義 2.1. 暗号危殆化の定義 2.2. 暗号危殆化の要因 2.3. 暗号危殆化の進行過程 3.

  • インターネット10分講座:暗号アルゴリズムの危殆化 - JPNIC

    実は、一般数体ふるい法の計算量は、以下のような漸近的な評価が与えられているのでおおよその推定は可能ですが、正確な計算量の予測にはあまり適していません。 ただし、 そこで、関係式収集ステップの計算量を部分的な実験結果から推定する方法を用いて、CRYPTREC※1では素因数分解問題に関する評価結果を2006年度に公表しています※2。 図1:1年間で関係式収集ステップを完了するのに要求されるコンピュータの処理性能予測([3]からの引用) この評価結果から、分解にかけるコストに依存するものの、1024ビットのRSAモジュラスの素因数分解はおおよそ2015年.2020年頃から分解の可能性が高まってくるということが読み取れます。従って、今後、新規にシステムを構築する場合には、1024ビットよりも長いサイズのRSAモジュラスを選択することが望ましいものと考えられます。 移行に際してまずはじめに問題となる

    インターネット10分講座:暗号アルゴリズムの危殆化 - JPNIC
  • Hash-flooding DoS と SipHash - あどけない話

    以前、僕が実装している web サーバ Mighty が、Haskell で書いているにも関わらず、セグメンテーションフォールトを起こしていた。調べたところ hashable ライブラリがリンクする C の DJBX33X が、SipHash に変わったことが原因だった。このときから SipHash が気になっていたし、以前社内で説明した "Efficient Denial of Service Attacks" との関係も知りたかったので、少し調べてみた。この記事は、その覚え書き。 Hash-flooding DoS の歴史 1998 年に Alexander Peslyak 氏が Phrack Magazine で、Hash-flooding DoS を受けたことを報告している。ハッシュは、N 個の要素を挿入するのに通常 O(N) かかるが、ハッシュ値がすべて衝突する最悪の場合では O

    Hash-flooding DoS と SipHash - あどけない話
  • 1