TLS 1.3 開発日記 その8 開発メモ - あどけない話
これは、http2 Advent Calendar 2016の25日目の記事です。 この記事では、HaskellでTLS 1.3を開発した際に難しかった点をまとめます。自分のための覚書です。TLS 1.3のみをフルスクラッチで書くと、そこまで難しくないのかもしれませんが、TLS 1.2以前と共存させるのは大変です。 足らない部品 TLS 1.2のコードが存在しても、TLS 1.3では TLS 1.2で利用されてない部品が必要です： RSA PSS PSS は PKCS#1 は異なるパディング方式の署名。RSAの公開鍵/秘密鍵自体は流用できる HKDF X25519 と X448 これらは、Haskell の cryptonite にすべて揃っていたので、少し(かなり？)手を入れるだけで利用できるようになりました。 拡張の再利用 TLS 1.3では、TLS 1.2 の2つの拡張を再利用してい
TLS 1.3 開発日記 その5 Hello Retry Request - あどけない話
これは、http2 Advent Calendar 2016の12日目の記事です。 今日は、第2番目のハンドシェイクである HRR (Hello Retry Request)について説明します。HRR とは、サーバがクライアントに Hello を再要求し、フルハンドシェイクをやり直すハンドシェイクです。 以下に仕様のドラフトからHRRの図を抜粋します： Client Server ClientHello + key_share --------> <-------- HelloRetryRequest + key_share ClientHello + key_share --------> ServerHello + key_share {EncryptedExtensions} {CertificateRequest*} {Certificate*} {CertificateVerif
TLS 1.3 開発日記 その3 バージョン - あどけない話
これは、http2 Advent Calendar 2016の7日目の記事です。 今回はTLSのバージョンについて書きます。TLSのバージョンは、Client Hello と Server Hello を交換することで決めます。 Client Hello TLS 1.3 の Client Hello は、TLS 1.2 と互換性を維持するために、構造が死守されています。 TLS 1.2 の Client Hello の定義はこう： struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-2>; CompressionMethod compression_methods<1..2^8-1>; select (extension
TLS 1.3 開発日記 その2 暗号スイート - あどけない話
これは、http2 Advent Calendar 2016の3日目の記事です。 今回は暗号スイートについて書きます。TLS 1.2 の暗号スイートは、たとえば以下のような感じでした。 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 これは次のような意味です。 鍵交換は使い捨て楕円Diffie Hellman（ECDHE：EllipticCurve Diffie Hellman, Ephemeral） サーバ認証はRSA 通信の暗号化はAES 128のGCM（Galois/Counter Model）モード ハッシュ関数がSHA256 TLS 1.1 以前だと、この暗号スイートのハッシュの意味が異なるんですが、面倒なので説明は割愛します。 TLS 1.3だと、暗号スイートが以下のようになります。 TLS_AES_128_GCM_SHA256 これは以下のような意
TLS 1.3 開発日記 その1 実装状況 - あどけない話
これは、http2 Advent Calendar 2016の1日目の記事です。 現在、IETF で TLS 1.3 の標準化が大詰めを迎えています。僕も TLS 1.3 の標準化に参加しており、仕様の分かりにくい部分を直したり、TLS 1.3 を Haskell で実装したりしています。この開発日記のシリーズでは、TLS 1.3の仕組みを説明していこうと思います。 そもそも、なぜ TLS 1.3 が必要なのかは、TLSの動向をお読み下さい。なお、次のTLSのバージョンを何にするかは、現在もめていて、1.3ではなくなる可能性もあることに注意して下さい。 現在の実装 現在利用できる TLS 1.3 の実装の一覧は、Implementationsにまとまっています。僕がクライアントとしてよく使っているのは、Firefox Nightly、Chrome Canary、および picotls です
Emacs Lisp のダメなところ - あどけない話
Emacs Lisp をこよなく愛する僕の目から、Emacs Lisp がダメだと思うところをまとめておきます。 文化的な問題 Emacs Lisper の多くは、Lisp が好きで使っているのではなく、Emacs が好きだからしかたなく使っているのでしょう。本当は C で書きたいのに、無理して Lisp を利用している感じです。 そのため、Emacs に付いてくる Emacs Lisp のコードは、Lisp らしくないものがほとんどです。単に C での発想を Lisp で表現しています。 これらのコードは、読みこなせないぐらい関数が大きく、副作用のある部分とない部分が分離されていません。また高階関数を用いて、データ構造を走査するコードと実際に仕事をするコードを分離するという意識も低いようです。 Google の MapReduceという論文のお陰で、Lisp の写像関数(map)と畳込み
関数型言語での関数の基礎知識 - あどけない話
関数型言語での関数について、Haskell を用いて説明します。 関数の型 関数の型は、-> を使って書きます。例えば、Int を Char に変換する chr という関数の型は、以下のようになります。 chr :: Int -> Char 一引数の関数の型は、まぁこんなもんだと思えるでしょう。びっくりするのは、引数が増えたときです。たとえば、replicate という関数の型を見てみましょう。 replicate :: Int -> a -> [a] replicate は、第二引数で指定されたデータを第ー引数に指定された個数分用意して、リストにして返す関数です。([] は配列ではなく、リストです。) 次のように動きます。 > replicate 3 "foo" → ["foo","foo","foo"] a は型変数といって、任意の型を取れます。なじめない人は、具体的な型を当てはめてみ
制約プログラミングのススメ - あどけない話
IIJ 社内でやったチュートリアル 純粋関数型言語Haskellの紹介 〜制約プログラミングのススメ〜 の資料を公開しました。
正規表現を超える - あどけない話
まずは、Audrey さんが言った Haskell の殺し文句を思い出して頂きたい。 正規表現ベースのパーサはメンテナンスしにくいのに気づいた？ Parsec を使って 15分で Perl6 の完全なパーサを書く方法を勉強しましょう。 15分というのは誇張が入っていると思うが、正規表現が保守しにくく、Haskell の Parsec は強力で保守し易いのは事実だ。その理由を Perl と Haskell のコードを示しながら説明してみたいと思う。 Perl を愛する方に：この記事は Perl を攻撃するために書いたのではない。Perl を選んだのは、正規表現を広めた言語であり、僕がそれなりに Perl のコードを書けるためである。この記事の目的は、正規表現よりも関数型パーサー(Parsec)の方が優れていると示すことだ。 例題 この記事では例題として、IPv4 アドレスを解析する関数を書く
遅延評価だけだと出力の順番が定まらない例 - あどけない話
Haskell に関してよく見かける説明は、おおむね次のような感じだ。「遅延評価では、その値が必要になったときに初めて評価されるので、順番が大切な入出力とは相性が悪い。」 Haskellの入出力は、基本的にIOモナドを使用しないと扱えない。IOモナドは、入出力の順番を制御してくれる。だから、遅延評価は入出力と相性が悪いと言われても、実際相性の悪い例題は示せないので、納得できない。 この問題を長い間考えていたが、昨日ひらめいた。Haskellでは純粋な関数にIOを忍び込ませることは、基本的にはできないけれど、裏技がある。Debug.Traceで定義されている trace がその掟を破る。 trace は第一引数を出力し、第二引数を返す関数である。出力するにも関わらず、関数の型にはIOは現れない。 trace :: String -> a -> a trace string expr = un
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
