タグ

opensslに関するyuroyoroのブックマーク (4)

  • (短いビット長の)RSA暗号を解いてみる - clock-up-blog

    なんでもセキュリティ Advent Calendar 2016 15日目の記事です。 RSA鍵を作るにあたっては鍵長を十分に長くする必要があります。(この「十分に」というのは時代とともに(マシンスペックが上がるにつれ)変わっていくでしょう) 最近だと 2048ビット = 256バイトの鍵を作るのが一般的でしょうか。 この長さが短いと割と簡単に公開鍵から秘密鍵が割り出せてしまいます。 今回やること 今回は長さが十分で無いRSA公開鍵から秘密鍵を割り出す実験をしてみます。 準備 秘密鍵の準備 64ビット = 8バイトという極めて短い長さの鍵を作ります。 $ openssl genrsa -out private.pem 64 Generating RSA private key, 64 bit long modulus .+++++++++++++++++++++++++++ .+++++++

    (短いビット長の)RSA暗号を解いてみる - clock-up-blog
  • OpenSSLの脆弱性CVE-2016-800(DROWN)やCVE-2016-0702(CacheBleed)についてまとめてみた - piyolog

    2016年3月1日(現地時間)、OpenSSL プロジェクトは脆弱性の愛称「DROWN」や「CacheBleed」を含む8件の脆弱性情報を公開し、これら影響を受けるものの修正を行った最新版をリリースしました。ここでは関連情報をまとめます。 脆弱性情報概要 注意喚起 OpenSSL の複数の脆弱性に関する注意喚起 - JPCERT/CC SSLv2 DROWN Attack - US-CERT OpenSSL Projectの公開情報 Forthcoming OpenSSL releases OpenSSL Security Advisory [1st March 2016] OpenSSL version 1.0.1s published OpenSSL version 1.0.2g published An OpenSSL User’s Guide to DROWN 2016年3月1日公

    OpenSSLの脆弱性CVE-2016-800(DROWN)やCVE-2016-0702(CacheBleed)についてまとめてみた - piyolog
  • Name Constraints を使った独自CAの運用手順

    ウェブブラウザが新機能をHTTPSでしか有効にしないことが多くなってきたので、開発環境でもHTTPSを使いたい。でも、開発環境用にサーバ証明書を買うのは手間。Let's Encryptも運用がめんどくさいとか、社内からしかアクセスできないサーバへの証明書発行が難しいとかいろいろあるし…ってそこでName Constraintsを使った独自CAですよ奥さん。 Name Constraints が何であるかについては、以前オレオレ認証局の適切な運用とName Constraintsに書いたとおり。 稿では、Name Constraintsを使うCAの運用手順を説明する。 1. CA鍵と証明書の作成 1.1. CAの秘密鍵を作成 % openssl genrsa -out ca.key 2048 1.2. openssl.cnfにCA証明書に設定する属性を指定するセクションを追記 [priva

  • Neverbleed - RSAの秘密鍵演算を別プロセスに分離する話

    機能毎にプロセスを分割し、それらを別個の権限のもとで実行することで、脆弱性があった場合の影響を抑え込むというのは、一定以上の規模をもつプログラムでは、しばしば見られるデザインパターンです。 qmailは、そのような設計がなされたメール配送デーモンとして名高いですし、OpenSSHもまた、認証プロセスと通信プロセスを分離することで、外部との通信を担当するコードにバグがあったとしても、ルート権限が奪われないように設計されています(参照: Privilege Separated OpenSSH)。 一方で、OpenSSLにはそのような権限分離は実装されていません。Heartbleedの際にサーバの秘密鍵が漏洩したのも、秘密鍵の取り扱いと、その他の通信の取り扱いを同一のメモリ空間の中で行っていたからだと考えることができます。 ないのなら、自分で作ればいいじゃない…ということで作りました。それが、N

  • 1