タグ

2018年2月21日のブックマーク (4件)

  • Rubyで楕円曲線の鍵共有(ECDH)と加算 - Develop with pleasure!

    Bitcoinで使われる楕円曲線の鍵について、bitcoin-rubyを使って鍵交換(ECDH)と楕円曲線の加算をしてみる。 鍵共有(ECDH) アリスとボブが持つ鍵を使って共通鍵を生成してみる。 アリスとボブはそれぞれお互いの公開鍵を知っており、秘密鍵をそれぞれa、b、楕円曲線のベースポイントPとすると、 アリスの公開鍵は、 Q(a) = a*P ボブの公開鍵は Q(b) = b*P となる。 この前提でアリスとボブがお互いに相手の公開鍵を自分の秘密鍵を使ってスカラー倍算する。 アリスは a * Q(b) = ab*P ボブは、 b * Q(a) = ba*P 楕円曲線上でab*P=ba*Pとなるため、お互いが計算した値は同じ点を指す。この時アリスはaをボブはbを相手に公開していないので、安全に共通鍵を生成できる。 この楕円曲線を使ったDH鍵共有をbitcoin-rubyを使って書くと↓

    Rubyで楕円曲線の鍵共有(ECDH)と加算 - Develop with pleasure!
  • Diffie-Hellman鍵交換入門 - Qiita

    鍵交換とは 例えば、zipを作成するときにはパスワードを設定しますね。これは、zip作成者がパスワードを知っている人だけが中身を読めるようにするためのものです。 我々がふだん使っているセキュアな通信(TLS, SSHなど)は、送信側と受信側が同じ「鍵」を共有することで行います。実際には鍵は一定の長さのビット列(256ビットがよくありますが、暗号アルゴリズムとその設定でまちまちです)なのですが、送信者と受信者だけが鍵を知っていて、他の人は知らないというのがポイントです。 では、通信を開始するとき、送信者と受信者はどのように鍵を取り決めるのでしょうか? 通信を傍受している悪者がいたとすると、「これからこの鍵で暗号化して通信するよー!」と鍵をそのままネットワークに流しては鍵が悪者にばれてしまい、その後の通信も盗み見ることができてしまいます。しかし通信開始時には暗号化された通信経路は存在しないので

    Diffie-Hellman鍵交換入門 - Qiita
  • WebCrypto APIでECDH鍵交換を用いた暗号化を使ってみる - Qiita

    はじめに ChromeやFirefox、Opera、Edgeなどのブラウザでは、WebCrypto APIを使ってブラウザで鍵の生成や暗号化と復号、署名と検証ができるようになっていますが、今回はECDHを使った鍵共有(およびAES-GCMで暗号化)を題材として、WebCrypto APIの使い方の一例を試してみます。 ECDHでは鍵ペアの生成と鍵共有を行います ECDHを使って暗号化と復号を行うには、一般的には次のような手順となります(楕円曲線ディフィー・ヘルマン鍵共有)。 暗号化する側Aと、暗号化されたデータを復号する側Bの両方で、鍵ペア(秘密鍵・公開鍵)を生成 AとBが互いに相手の公開鍵を共有 Aは「Aの秘密鍵」と「Bの公開鍵」を使って共有鍵を生成し、この共有鍵でデータの暗号化を実行して、Bに送信 Bは「Bの秘密鍵」と「Aの公開鍵」を使って共有鍵を生成し、この共有鍵で暗号化されたデータ

    WebCrypto APIでECDH鍵交換を用いた暗号化を使ってみる - Qiita
  • 暗号スイートの暗号強度と、公開鍵のビット数の設定、及びRSAとECDHEでサーバ負荷の比較 - Apache 2.4系でHTTP/2対応サーバを構築してみるテスト。

    見ず知らずの他人同士が、リーズナブルな計算量で、秘密の通信を行うためには、公開鍵暗号と秘密鍵暗号を組み合わせる必要があります。 この暗号の組み合わせのことを「暗号スイート」と呼びます。 OpenSSLには、多くの暗号スイートが用意されています。どの暗号スイートを選べばいいのか、迷ってしまうと思います。 そして、暗号スイート全体としての暗号強度は、公開鍵の強度も関係してきます。 ここでは、総当たり攻撃の耐性を基準に、暗号スイートと公開鍵の決め方を説明していきます。 以下、私の独断と偏見ですが、なぜGoogleやFacebookが、ECDHE(256bit)-ECDSA(256bit)-AES(128bit)の暗号スイートを使用するのか、ご理解いただけると思います。 併せて、Apache Webサーバ(httpd)のECDHEのビット数の変更方法(P-256, P-386)も、説明しています。