OpenOcean の怪文書

増田茂が書いたとされる OpenDolphin 関係の怪文書が某所で見つかり、反論の意味も兼ねて『いるかの怪文書』などが公開された。

関係者に聞いたら「小林慎治が書いた OpenOcaen 関係の怪文書もある」とのことだったので、読ませてもらった。

「いるか怪文書」とは違ってロジックがあそこまで支離滅裂ということはなかったが、主張内容がなんと言おうか・・・やはり、怪文書かな?


私がパッと感じた違和感は・・

・OpenDolphin は GPL である、というのが前提になっているが、その後の経緯を見ればわかるように、ほとんどのプロジェクトが 2018 年を境にオープンソースっぽさを失っていく。
この時期のいるか界隈のことは、私は詳しくないので、関係者からの情報発信を待ちたい。→『OpenOcean は GPL 違反?』、『小林慎治氏の OpenOcean に関する事実誤認』公開。

・README の主張を信用しすぎ。
Junzo SATO さん担当部分が再評価されてきて、ソースコード提供者が思っている以上にいることが判明しつつあった時期。著作権の問題をひとまず置くと、GPL でいうところの author は、README 記載の人物以外にもいることは明らか。 README を重視するのは不自然。

・同じ理屈で、ソースコードは全公開しておく方が適当。
まだ見つかっていない author がいる可能性があるわけだから、クローズドな形で publish しても意味がない。Junzo SATO さんの名前を出してない時点で「適切な著作権表示」とは言えない。
この観点からすると増田ファクトは GPL 違反。


これ GPL という枠組み取っ払うと「e-Dolphin の成果 + 職務著作」という内容。

職務著作の場合、個人名が著作権表記になることはほぼない。
問題になっている (C) Kazushi Minagawa は、職務著作とするとその表記はかなりおかしく、経営陣が変わった時に咎められた、と見る方がすっきりする。

(続く)

 

 

公開鍵暗号厨

ここここで話題になっている「公開鍵暗号警察」氏こと angel_p_57 だが、ここにきて「ネットワークエンジニアのような人ではないか?」や「若い頃、官公庁系の仕事をして、その後は起業。もうコーディングなど一切せず、実体のないコンサルや講演・翻訳などで食っている IT業界人では?」という説が出て、なんか変な安堵感のようなものが広がっている。

もちろん、ネット上の匿名垢の職業をピンポイントで当てることなんてできないし、こういった説も間違っている可能性が大なのだが、大事なのは「そういった人なんではないか」というもっともらしい類推だ。

「幽霊の正体みたり」ではないが、人間はまったくの未知の対象にはある種の感情を掻き立てられるが、ある程度その正体のアタリがついてくるとそういった感情は消えてしまう。

突破口

なんで、こんな類推が出るようになったかといえば、彼のチグハグな言動からだ。
その代表例はこれ(↓)。

「秘密鍵で暗号化」という処理が(RSAでの)署名処理を連想させるため、一瞬釣られた人も多いようなんだが、この問題は署名に関しては何も訊いていない。
物議を醸している d に関しては「秘密鍵で変換したメッセージを、さらに公開鍵で変換すると元のメッセージに戻るか?」と訊いているだけ。
問題文の意図がわかれば、正解は a, b, d となるし、出題側が用意した解答もそれである。

「秘密鍵でのメッセージの変換」を「暗号化」と呼んではいけない何か一般的な理論がどこかにあるのかもしれないが、それはもうその理論の定義による事柄だろう。
(ちなみに「秘密鍵暗号」とでも訳せばいいのだろうか prvate key cryptography という言い方は英語圏ではある。大抵の場合、共通鍵暗号を指しているようだ)
だいいち、設問文や選択肢で「公開鍵で暗号化したメッセージ」・「秘密鍵で暗号化したメッセージ」と言っているのだから、少なくともこの問題では「秘密鍵で暗号化」できる方式を採用したことが前提になっていると考えるのが自然だろう。公開鍵暗号の一般的性質を聞いているのはでない。

公開鍵暗号の暗号化↔︎復号化の話をしているだけなのに、勝手に署名の話を持ち込んできて、聞かれてもいないのに「この言い方は間違っている」と自らのご高説をぶち上げる。
チグハグだ、と書いたのはそうした理由による。

プロファイリング

では、なんでネットワークエンジニアみたいな類推が出てきたかといえば、根拠は主に二つ。
・コーディング実務ガチめの人はまずこういう概念の混交をおこさない
(もし、おこしたとしても、気がついたら早めに謝罪する)
・仕様の定義などサーバプログラムの設定時に役立ちそうな知識(だけ)はある
から。
後者は、ここの質疑応答を参照。「SSH サーバのここがこうで・・」みたいな話は私も全然ついていけないが、仕様の定義みたいなことに関しては知識はあることが窺える。
前者に関して細かい話は割愛するが、「暗号・復号と署名は別の道具・概念」などと主張している当の本人が、簡単な設問文程度で両者の混同するのはおかしく、現場で実業務として取り組んだことがないのでは?みたいな話です。

この二つでは、ネットワークエンジニア以外にもあるだろう?というツッコミが聞こえてきそうだが、それはその通り。
ネットワークエンジニアの他には「現場を知らないセキュリティ関連の学会委員」、「講演や翻訳ばっかりやっているアカデミアの人」なんて類推もあった。
大枠としては、「公開鍵暗号に関する実務的なコードを書いた経験はほとんどないが、関連知識だけはある人」というイメージ。

繰り返しになるが、当たったか外れたかは重要ではない。大事なのは、大体どういう人なのかを推量することだ。
ネットでは、思ってもみなかった方角から、どこの誰かもわからない輩が発した批判が飛んでくる。その際、その全てを時間をかけて仔細に検討、なんてできるわけもなく、ある程度は「どういう人が言ったのか」で計量するしかないからだ。

実際、


コイツのITの話は 誤解や曲解があるだけじゃなく 頭が悪い書き方するので読むだけ時間の無駄。

なんて辛辣な評もある。出典: ここ

認知症入っているのでは?みたいな意見もあったが、私、今、それ関係で食っているのでこれに関してはノーコメント。

特定班

プロファイルなんてものではなく、特定を試みる猛者たちもいた。

彼らによれば「angel_p_57 = 稲村雄(か、それに近い人)」らしい。

手がかりは彼が参照したリンクで、確かにこのページの主張は彼がその後繰り返すことになる主張とそっくりだ。
で、このページの作者は稲村雄氏。

しかし、フレームの使い方や文字コードの指定などもうちょっとなんとかならなかったものか・・・見にくい。

稲村雄氏とするなら、2025 年現在、彼は、65歳になるはずで、その歳であそこまでクセのある言動をするかなあという疑問は残る。

稲村雄氏の書き物を元ネタに挑発的な言動を繰り返すかまってちゃん、という可能性の方が高いだろうか?

上から目線で、セキュリティ関係の初学者が気になるようなネタ(「『署名=秘密鍵で暗号化』は誤り」など)を強めに主張して、気をひいて気をひいて・・・ついには、気をひくだけが目的になっちゃった人と言ったらいいんだろうか。

X に「稲村 雄」氏 @inamura_you はいて、angel_p_57 のまとめ記事にコメントしていた。

ただ、Qiita の記事や GitHub リポジトリに収載されているプロジェクトを見る限り、稲村氏のアイディアを大きく超えるようなプロジェクトはないように思う。
(例外的に Elgamal 暗号に関する記事やサンプルコードは、教育的でいいと思う。主語の大きな主張しなければいいんでないか?)

おわりに

以上、「公開鍵暗号警察」氏について取り上げた。
情報が入ってくるたびに思ったのは、「これは、新規なものではなく、よくある XX 警察と同じパターンかあ」というもの。情報分野でもマスク警察と同じような案件があるもんなんだなと。
ただ、マスク警察の場合は、個人的なバックグランドから判断は割と簡単にできて余裕は保てたが、日常的になじみのない分野では苦労するものなんだなというのがここまでの感想。
ネットとの付き合い方の難しいところです。

 

参考でもなんでもない単なるメモ的リンク

New Directions in Cryptography
稲村雄とかいう人のホムペの残骸
HPKI 署名用カードドライバ・chrome 拡張デモページ』アイキャッチの図はここから
署名はハッシュしてから復号?』東工大・尾形わかは研究室のコンテンツの一部。必ずしも「専門家は『署名=秘密鍵で暗号化』を認めていない」わけではない状況がわかるかと。一番わかりやすいのでは?

 

pathComponents

pathComponents

NSString のインスタンスメソッド。

何をやっているかは公式の説明と図がわかりやすいでしょう。

The strings in the array appear in the order they did in the receiver. If the string begins or ends with the path separator, then the first or last component, respectively, will contain the separator.

 

Nitrogen の謎

使うばかりではアレなので、HorliX/Horos/OsiriX のソースコードを読む。

早速、AppController(現在でいうところの AppDelegate です)の init メソッド内の以下のところでつっかかる。

AppController.m

[[NSFileManager defaultManager] removeItemAtPath:[[NSFileManager defaultManager] tmpDirPath] error:NULL];

なんだよ tmpDirPath って(笑)。

もちろん、ノーマル NSFileManager にこんなメソッドはなく、おそらくどこかで拡張してんだろうなあと物色したら、Nitrogen というフォルダ(のサブフォルダ)に収められていた。

しかし、なんだろ、Nitrogen って?

Objective-C におけるクラスの拡張(というのだろうか?オーバーライドといっていい)は、カテゴリを使うという手法があるようだ。
カテゴリによって新たにつくられたクラスは、慣例的に「元のクラス+特徴」というファイル名を持つ。

だから、上の例では NSFileManager+N2.h と NSFileManager+N2.m で NSFileManager の拡張機能を担っている。

この N が Nitrogen から来ているのでは?と想像はつくが、なぜ Nitrogen というネーミングにしたんだろうねと疑問に思ったという次第です。