2017-02-09

楕円曲線暗号

今年の抱負の一つ、楕円曲線暗号を実装している。とりあえず肝の一つであるECDSAを実装し終えた。こんな感じで使える。
(import (rnrs) (crypto))

(define keypair (generate-key-pair ECDSA :ec-parameter NIST-P-521))

(define msg "this message requires digital signature")

(define ec-signer (make-cipher ECDSA (keypair-private keypair)))

(define signature (cipher-signature ec-signer (string->utf8 msg)))

(define ec-verifier (make-cipher ECDSA (keypair-public keypair)))

(cipher-verify ec-verifier (string->utf8 msg) signature)
;; -> #t
一応NISTが推奨する楕円曲線パラメータは全部実装してある。テストベクタもあるので、当然テストもしてある。おかげでテスト時間が増大した。処理が重い…SECGが推奨するパラメタも実装しないとなぁと思いつつ割と現状で満足している感もあり、既に随時追加する方向にシフトしつつある。

今となっては笑い話だが、実装している間で一番苦労したのが「正式な仕様を見つけること」だったりする。暗号系に限らず、プロトコルの実装をする際は可能な限り「正式な仕様」(RFCとか)を当たるようにしているのだが、楕円曲線暗号はこれを見つけるのに苦労した。Google先生にお伺いを立てると大抵RFCに当たるんだけど、探した限りだとRFCにはECDSAの拡張はあってもそれ自体がない。まさかWikipediaに書いてあるのをそのまま(実際正しかったんだけど)鵜呑みにするのもなぁと思い探したら、行き着いた先はANSIだったという。最終的にはX9.62でググるのが正解というのに辿り着いた。こういうの知らんと探せんなぁと思った次第。

実はこれを実装してようやくスタートラインに立ったというのが正直なところ。ここからECDH、SSHとTLSにECDSA+ECDHを追加していく予定。まだ先は長いが、今年の抱負なので、今年中に終わればいいだろうくらいな気持ちでいたりはする。

2017-02-01

ひらけ!ポンキッキ

r/lisp_jaとTwitterに以下の投稿があった。
前者がGuileで後者はR6RSで実装されている。文字列をグルグルさせるのならSRFI-13のxsubstringが使えるだろう思い、僕も書いてみた。
(import (rnrs) (srfi :13))

(define s "ひらけ!ポンキッキ")

(define-syntax do-while
  (syntax-rules ()
    ((_ ((var init ...) ...) (pred r) commands ...)
     (do ((first #t #f) (var init ...) ...)
         ((and (not first) pred) r)
       commands ...))))

(do-while ((t s (xsubstring t 1))) ((string=? s t) #t) (display t) (newline))
Cのdo ... whileを真似たdo-whileマクロは正直いらんけど…
以下は実行結果
$ sash hirake.scm
ひらけ!ポンキッキ
らけ!ポンキッキひ
け!ポンキッキひら
!ポンキッキひらけ
ポンキッキひらけ!
ンキッキひらけ!ポ
キッキひらけ!ポン
ッキひらけ!ポンキ
キひらけ!ポンキッ
毎回文字列の比較をするので、当然効率は良くないが、まぁこういうこともできるということで。

2017-01-31

一移民として

オランダに移住してそろそろ8年になる。移民の定義的(Wikipediaが正しいかは知らんが)には移民で問題ないだろう。

大統領令

さて、一移民として最近ニュースサイトから目が離せないでいる。もちろん今を賑わす時の人、第45代アメリカ大統領ドナルド・トランプ氏関係のニュースである。先日あった特定7カ国籍を持つ人のアメリカ入国拒否には大きな衝撃を与えられた。
なぜこのニュースが大きな衝撃になるのか疑問に思うかもしれない。ニュースサイトの論調はともかくとして、傍目から見ればテロリストの抑止にも見えなくない(それにしても、ビザを持っているのに入国できないという事実があったことには目を瞑る必要はあるのだが…)。一移民の視点、少なくとも僕個人の視点、から見ればこれは移民排斥の第一歩に写った。

トランプ氏は就任式の際に「アメリカ第一」と唱えている。
それと同時に大統領選挙の際のスピーチにいくつか人種差別的な発言もある。
これらのニュースから導き出された僕個人が描くトランプ像は白人アメリカ主義者というものになっている。

この「アメリカ第一」と個人的なトランプ像から、先日の大統領令はある種の試金石的な位置づけにあるのではないかと思っている。つまり、テロリスト排除という錦の御旗を掲げることでどれくらい潜在的な人種または宗教差別を隠せるか。そこから発展させて最終的には白人主義に持っていく道筋を建てようとしたのではないか。

ここまで来ると偏執病ではないかと思わなくもないが、過去にナチが存在したという事実もある。あまり考えたくないが歴史は繰り返されるものであるのであれば、ナチズムが再び起きることもありえなくない。

対岸の火事?

事件はアメリカで起きているのだ、オランダに住む僕にはあまり関係ないのではないか?と思わなくもない。っが、意外にも周りのオランダ人(国籍的に、人種的には違う)的にはトランプの大統領令を歓迎する人もいる。難民に関して言えば、ヨーロッパも難民問題に悩まされている。隣国のドイツからは難民関係の事件が絶え間なく流れてくる。
また、割と多数(少なくとも僕の周り)のオランダ人は「中東からくるイスラム系移民は全てテロリスト」と誇張を含むとはいえそれなりに真剣に言っている。

中東移民全テロリスト発言も井戸端会議で話されている程度であればまだ可愛げもあるかもしれない。しかし、それを掲げる政治家がいるとなれば話は多少違ってくる。

Geert Wildersはオランダの反イスラム主義政治家である。現状のところ反イスラム主義だけではあるが、いつ移民排斥になるかは検討がつかない。実際、彼はヨーロッパの難民受け入れ体制に反対している。(もっとも難民の多くはイスラム系なので難民の受け入れに反対なのかは判断が難しいところではあるが…)
また、彼が率いるPVV(Partij Voor de Vrijheid、訳:自由党)は2009年に議席数を150議席中32議席と大きく伸ばしている。(この年はちょうどオランダに来た年で、極右の政党が大幅に議席数を伸ばしたこのニュースはオランダに住むことを不安にさせられた。) 議席を伸ばしたということは、少なくない数のオランダ人が彼の政策に賛同しているということである。それが、反イスラム主義なのか、別の政策に大してなのかはわからないが、賛同者にとって反イスラム主義は問題にならないとも言える。

まとめ

自国を離れていると、こういうニュースには常に戦慄させられる。いつか自分がその対象になる可能性があるからだ。トランプ大統領政権下で何が起きるのか見てみたいという好奇心と、とっとと彼を引きずり下ろして心に平穏を与えてほしいという相反する2つの感情がせめぎ合っている気がする。

2017-01-22

R7RS-largeサポート

本当は日本語リリースノート的なのにするつもりだったのだが、あまりにも眠くてリリース作業だけして寝てしまったという…

Sagittariusは0.8.0からR7RS-largeのRedEditionをサポートするようになった。具体的には以下のライブラリが使用可能になる。
  • (scheme list) - SRFI-1のエイリアス
  • (scheme vector) - SRFI-133のエイリアス
  • (scheme sort) - SRFI-132のエイリアス
  • (scheme set) - SRFI-113のエイリアス
  • (scheme charset) -  SRFI-14のエイリアス 
  • (scheme hash-table) - SRFI-125のエイリアス
  • (scheme ilist) - SRFI-116のエイリアス
  • (scheme rlist) -  SRFI-101の手続きをリネーム
  • (scheme ideque) - SRFI-134のエイリアス 
  • (scheme text) -  SRFI-135のエイリアス
  • (scheme generator) -  SRFI-121のエイリアス 
  • (scheme lseq) - SRFI-127のエイリアス
  • (scheme stream) -  SRFI-41のエイリアス
  • (scheme box) -  SRFI-111のエイリアス 
  • (scheme list-queue) - SRFI-117のエイリアス
  • (scheme ephemeron) -  SRFI-124のエイリアス
  • (scheme comparator) -  SRFI-128のエイリアス
ライブラリ名等がR7RSのWikiにこそっと修正されて上がっていた。個人的にこういうのはどこかに投げてほしい、c.l.sとか。でないとマジで見落とす…

注意するところとして、
  • (scheme ilist)で作られる不変リストは通常のcar等では扱えない
  • (scheme rlist)で作られるランダムリストは、同上
  • (scheme ephemeron)は厳密にはephemeronではない(が仕様は満たしている)
くらいだろうか。

RedEditionだと単に便利ライブラリが標準に追加されたくらいの感覚しかないが、それでもR7RS-largeをフルサポートしている処理系は現状ではSagittariusだけではないだろうか。

そういえば、その昔R7RS-largeに(scheme inquery)というライブラリが追加されたことがあるのだが、これって正式に仕様になってるのかな?SRFI-112とかWG2とか見ても見つからないから、ライブラリ名は先走りだったかな?

2017-01-02

謹賀新年

年末に2016年のことを振り返る余裕がなかったので、新年の豊富とともに振り返ってみんとする。

2016年を振り返る
個人的にいろいろ激動な感があった(感があっただけで激動はしていないが) 。Amazonのオファーをキャンセルしたり、転職したり。Scheme Workshop 2016にも行ったなぁ。10月以降は現職での仕事が忙しかったのであまり何もないけど、Schemeで書いたサービス(と呼べるほどでもないが)を立ち上げたりしたか。

忙しいのと反比例してSagittariusの開発は少し停滞していた感がある。 適当にSRFIを追加した以外は特に目新しい機能もなく、といった感じである。忙しくても身は一つなので割ける時間は減るといった当たり前のことを痛感した年でもあった。

筋トレをすると言ったのだが、蓋を開けてみると志半ばで挫折した感がある。年の後半は特に時間が割けなかった。

2017年の豊富
酉年だから飛躍の年、とか言うつもりはないが、以下のことを通年でしようかなぁと
  • 筋トレ。月水金くらいで30分以上くらい自重トレ。行けたらジムにも行く。
  • ギターの練習。週末くらいで
  • 17時退勤。仕事は二の次くらいの勢いで
  • 本を読む。月一冊くらいは読みたいところ
Sagittarius的には以下をなんとかしたいと思っている
  • OAuth
  • 楕円曲線暗号(RFC6090)
  • R7RS-large対応
  • 日本語ドキュメント
最初の2つは当面という感じだが、下2つはちょいちょいやっていく感じかな。どうせ何かしら見つけて作っていくとは思うけど。

基本的には、なんとかなる、ゆるーくまったり、くらいの気持ちでいこうかなぁと思っている。ということで、今年もよろしくお願いしますm(_ _)m

2016-12-27

Anxiety

I thought I've written exactly the same blog post last year, but I guess I didn't. Maybe I was smart enough not to show this negative feeling.

It's almost the end of year. Every year, I've been thinking the same thing in this season and anxious. That is my skill, in one word. It might also be called my career path, knowledge or experience. I just don't know how I can describe what I'm worrying for.

Since 2004, I've been working as a software developer. There are couple of years of blank periods but most of my career is being Java developer, good or bad. When I started my career, I was just an ordinary newbie who had a bit of programming skill and assigned to the *deadline is already decided* project. Everything was new including somewhat deadline was there but no specification situation, and there were lots of things to learn, like how to capture screen shot and put it into excel sheet... At that moment, struts 1.0 was there and the concept of DI has just come. After 2 years, I quit the first job and became server administrator... sort of.

In year 2009, I've moved to The Netherlands. At that time, I had some blank as a Java developer. So I didn't know when CI is appeared. DI was still there but a bit brushed up. I could use Java annotation instead of writing huge application-context.xml. I still had lots of things to learn, however I just noticed that I was just learning the usage of libraries. If those libraries disappeared in 5 years, then this knowledge is just useless. Luckily, I've met Scheme and started writing own implementation to build some tools I can use on daily routine.

Writing a Scheme implementation gave me lots of challenges. I wasn't a good C programmer, well am still not, though. How function pointer works, how x86 works, how to retrieve stack area information, difference between POSIX and Windows, those were all new for me. I've never read C89 or C99 specification, so I will never be a C expert, but at least now I know where to look at if I need to find something.

If you write an implementation, then you also need to write libraries. Fortunately, or unfortunately, there's not much Scheme code. So I needed to write loads of code. If I see the code written in very first period of my Scheme life, those look ugly. I can't say I understand how Scheme works perfectly and I can write universal beautiful code. All what I know is how to write workable code and at least that works for me. Maybe I can say I also now the basic concept of paradigms which are used in Scheme programming, such as first class object and CPS.

7 years later, I'm still anxious. Maybe I feel like I know nothing essential. I know numbers of libraries and how those works. I know how to implement TLS or other network protocols. But are these essential? I only have vague idea what's essential knowledge is. It should be knowledge that I can use; even if I need to make software with a language I've never used; in the different IT field; after 20 years so on. And maybe I've already known that there's no such thing. And maybe the fact that I knew this reality makes me more anxious.

If I become a high skilled programmer, would this be gone? It might be better not to think about this and just study hard since I know I need to know more.

2016-12-25

OAuth

ちょっとしたメモ。

SagittariusはCommon Lispから移植したOAuth1.0を扱うライブラリを持っている。っが、このライブラリ将来OAuth2に対応させれるようにしたのかキーワード引数が大量にあり今一使い勝手が悪いい。っで、最近職場でOAuth2上に構築されたプロトコルの一つであるOpenID Connectを使うということが持ち上がっていることもあり、OAuth2のライブラリがいるかなぁという機運が高まってきている。

割と周知の事実だと思うが、OAuth1.0とOAuth2は互換性がない。RFC5849で定義されているOAuth1.0はRFC6749で定義されているOAuth2によって廃止されているのではあるが、名前の似た二つのプロトコルとしてみた方がよい。事実、RFC6749には以下の段落がある:
The OAuth 1.0 protocol ([RFC5849]), published as an informational document, was the result of a small ad hoc community effort. This Standards Track specification builds on the OAuth 1.0 deployment experience, as well as additional use cases and extensibility requirements gathered from the wider IETF community. The OAuth 2.0 protocol is not backward compatible with OAuth 1.0. The two versions may co-exist on the network, and implementations may choose to support both. However, it is the intention of this specification that new implementations support OAuth 2.0 as specified in this document and that OAuth 1.0 is used only to support existing deployments. The OAuth 2.0 protocol shares very few implementation details with the OAuth 1.0 protocol. Implementers familiar with OAuth 1.0 should approach this document without any assumptions as to its structure and details.
太字にした一文があるため、廃止されているとはいえ両方サポートした方がよさげな感じがしている。例えばWikipediaのList of OAuth providersのページによれば、OAuth1しかサポートしていないプロバイダーも結構ある(Bitbucket、Flickr、Tumbler辺りは個人的に使うかもしれない)。

どちらのプロトコルもクライアントを実装するだけならそんなに難しくないと思っていて、問題になるのはAPIの設計だと思っている。中身を見れば全くの別物なのだが、名前や歴史的経緯を見ると両社は密接なつながりがあるように見える。そうすると、ユーザー(クライアント)としてはシームレスに使えた方がいいかなぁとか考えてしまうわけだ。最終的にアクセストークンを使って保護されたリソースにアクセスするわけだし。そうするとこんな感じにライブラリを構成するのがいいだろうか?
  • (rfc oauth)
    • (rfc oauth v1.0)
      • client and so?
    • (rfc oauth v2.0)
      • client and so?
もしくは、無難に分けるか
  • (rfc oauth1)
  • (rfc oauth2)
無難に分けた方がいい気がするなぁ、変に統合すると混乱しそうだし。現在ある(net oauth)ライブラリはそのままにするが、deprecatedという形にすればいいかな。うまいことやれるなら新しいライブラリを下請けにする形にしたいが、そこまで手が回るかは疑問。