TLS 1.3 開発日記 その22 公開鍵暗号の動向 - あどけない話
P256とかX25519とかPSSとか聞いても、よくわからない人のための用語解説。 長い間TLSの世界では、鍵交換にも認証にもRSAが使われてきた。必要となる安全性が大きくなると、RSAの公開鍵は急激に大きくなり、したがって鍵交換や認証のコストが大きくなるという問題がある。 楕円曲線暗号(ECC: Elliptic Curve Cryptography)は、RSAやDiffie Hellmanに比べると、小さな公開鍵で同程度の安全性を実現するという特長を持つ。特許問題が不透明なせいで楕円曲線暗号は長年敬遠されてきたが、この数年で(少なくとも鍵交換に対しては)一気に普及してきた感じだ。 おおざっぱに言うと、楕円曲線暗号で実現できるのは、DH(Diffie Hellman)とDSA(Digital Signature Algorithm)であり、RSAは実現できない。 鍵交換のDHに関しては、
h2load を使おう - あどけない話
これはhttp2 Advent Calendar 2015の25日目の記事です。 これまで web サーバのスループットを図るには weighttp が定番でしたが、これから h2load を使いましょう。 h2load は、nghttp2と一緒に配布されているベンチマークツールです。以下のような特徴があります。 ApacheBench を世襲したコマンドラインオプションを提供しています。 weighttp のように、計測側のマルチコア環境を活かすことができます。 weighttp で計測できるのは HTTP/1.1 のみでしたが、HTTP/1.1 over TLS、HTTP/2、HTTP/2 over TLS も計測できます。 対象プロトコルは以下のように切り替えます。 プロトコル 平文 TLS HTTP1.1 h2load --h1 http:// h2load --h1 https:
制約プログラミングのススメ - あどけない話
IIJ 社内でやったチュートリアル 純粋関数型言語Haskellの紹介 〜制約プログラミングのススメ〜 の資料を公開しました。
はじめての Haskell - あどけない話
昨日、友達にこんなことを話しました。 Haskell でプログラミングするときは、とりあえず効率のことは忘れる。 メモリーは無限にあると考え、コンパイラーと遅延評価が頑張ってくれると信じる。 Haskell では what を記述する。 効率を考えている時点で、how である。 what と how は、同一視されがちであり、区別するには訓練が必要。 変数は初期化できるが、再代入できない。 だから、インデックスが必要な for はない。 繰り返しが本質なら、再帰で書く。 単にリストを走査したいなら map を使う。 リスト処理が得意なので、なんでもリストに落とし込む。 もう一度言うけれど、メモリーは無限にあると考えるから、リストが大きくても気にしない。 行を数えてみる ファイルの行数を数えるプログラムを考えるとします。命令型の頭で考えると、一行ずつ読み込みながらファイルの終わりまでループを
cdr の decrement - あどけない話
Lisp の car や cdr が、以下の略であることぐらい、Lisp をかじったことのある人なら知っているでしょう。 Contents of the Address part of Register number Contents of the Decrement part of Register number Lisp が最初に実装された IBM 704 の機械語には、address の部分と decrement の部分があったこともよく語られています。address はすぐに分りますが、decrement とは何でしょうか？ 長年の疑問を和田先生に聞いてみました。 和田先生の答え ループを作るときにインデックス・レジスタから decrement の部分を引く for 文に例えるなら、インデックス i から引く数であると言うのです。そうだったんですかぁ。詳しく調べてみました。 IBM
POPとIMAP - あどけない話
ようやく IMAP も普及したようで、POP から IMAP に乗り換える人が増えています。僕の周りのインターネット技術者も、ぼちぼち乗り換え始めました。(gmail が IMAP をサポートしたことが大きな要因でしょうか？) 彼らは優秀なのにも関わらず、こんな間違った表現を使います。 POP はメールをメールリーダに取ってくるもので、IMAP はサーバ側のメールを読むものだ POP だとよかったけど、IMAP は常にネットワークにつながっていないと辛い POP だとよかったけど、IMAP はフォルダ内のメールの数が多くなると辛い その度に、「そうじゃない」と言ってきたのですが、もうそう説明するのにも疲れてきました。そこで、正しいことを書いて、この説明はもう二度としないことにしようと思います。(DRY: Don't Repeat Yourself ですね。) 間違いの根源は、おそらく二つで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
