2017/12/27

ECDSAの署名+αで公開鍵が算出できるらしい

年末なので、調整モードです(?)。


Bitcoinに関係してるような、してないような実装をやっている。
残念ながら、私は自分で理論を構築できるタイプではないので、誰かが考えた仕様を読んで実装している。
困るのは、そういう人は「当然知ってるよね?」といわんばかりの態度で、何だかわからないことを書いてくるのだ。


今回出てきたのは「ECDSAの署名に、リカバリー用のIDを載せたデータを作る」という文章。
なんか説明が出てくるだろうと読み進めていったが、特にない。
テストデータを見ていくと、どうやら、これらから公開鍵が計算できるらしい。
ナンダッテー!


elliptic curves - How does recovering the public key from an ECDSA signature work? - Cryptography Stack Exchange
たぶん、これなのだと思うが・・・読んでもさっぱりわからん、というか、読めない。
一番上の回答は項目が3つだけしかないのだが、息苦しい。。。

誰か実装してないか探しているのだが、OpenSSLにはあるようだし、Pythonにもあるようだったが、私が使っているライブラリにはAPIがないのだ。
じゃあ、これ読んで実装するしかないのか、私は・・・?

2017/12/26

期待したアプリがポートで待ち受けているかどうか

前回の続きみたいなものだ。

netcatを使って、ファイアウォールではポートを閉じていないことはわかった。
しかし、そのときにやりたかったことは相手のアプリと通信することで、それはうまくいっていなかったのだ。
結果としては、アプリの設定が足りず、開いていたポートは別の用途で使うためのものだった、というだけであった。

もしそのとき、アプリがどのポートを開けているのかわかっていれば、設定が足りていなかったということがわかったので、その方法を知っておきたい。


$ netstat -nap

Ubuntuだと、これでプロセス名付きで出してくれる。
WSLではダメだったから、なんかあるのかもしれん。


たとえば、

tcp        0      0 127.0.0.1:18332         0.0.0.0:*               LISTEN      1196/bitcoind

だと、bitcoindというプロセスがlocalhostの18332というポートで待ち受けていることが分かる。

tcp        0      0 0.0.0.0:18333           0.0.0.0:*               LISTEN      1196/bitcoind

これは、localhost以外からも待ち受けている場合だろう。
外部から接続したいときは、このポート番号を使えばよいということがわかる。

たしかtestnetのbitcoindは、18333がP2P用で、18332がJSON-RPC用だったはずだ。
通常、JSON-RPCはlocalhostにしか公開していないのでこうなる(bitcoin.confで公開するIPアドレスを指定可能)。


こんな感じで、待ち受けている様子だけは見ることができるが、何のために開けているのかはわからないので、そこからは自分で調べることになるのだ。

2017/12/22

ファイアウォールの設定ではじかれているのかどうか

まったくの個人メモだ。


いま、MicrosoftのAzureにUbuntu VMを立てて、手元のUbuntu PCと通信するテストをしている。
プロトコルの仕様があって、それを実装している相手と、自分で実装したアプリを通信させようとしているのだ。

相手はクラウド上なので、Azureの設定でファイアウォールがきっちり設定されているから、穴を開けなくてはいかん。
自アプリは手元のPCなので、192.168.x.xみたいなローカルアドレスだから、クラウドから自アプリに接続させることはできず、自アプリから接続させなくてはならない。


で、ここからが本題だ。
つまり、うまくいっていない。

  • 自アプリからクラウド側にsocketを張りにいって、その接続はできている
  • 一応、telnetで確認したが、指定したIPアドレスとポート番号は空いているようだ
  • しかし、自アプリからデータを送信して、それが正しければ相手から返ってくるはずなのだが、それが返ってこない
  • 困ったことに、相手のアプリがどうログを出すのかがわかっていない

というところだ。

まあ、これから悩むのは私の仕事なのだが、socketが張れたのに、送受信がファイアウォールなどで止められることがあるのだろうか?という、すごく初歩的なところで悩んでいた。
悩むというか、わからんので失敗する理由から除外して良いかどうか判断できなかったのだ。


そういえば、JSON-RPCを使ったアプリの動作確認をするときにコマンドを使ったことを思い出した。
netcatだ。

catコマンドみたいに、といってよいかどうかわからんが、標準入力で受け取ったデータを指定したIPアドレス:ポート番号に流してくれるようだ。
今回は、こちらを読んでやった。

netcatってなんじゃらほい - マイペースマイライフ

今回、クラウド側が受ける方なので、そちらは -l オプションでポート指定した待ち状態にしておき、手元のPCから-l無しで実行すると入力待ちになるので、標準入力から打ち込んでリターンを押すと相手に転送される(標準入力は、デフォルトではトリガが何かないとキャッシュされるため)。

以前であれば、socketでbindやらconnectやら使っていたかもしれないが、コマンドを知ってしまえば楽ちんというか、手間が省略されるし、確実だ。


そして・・・困っている環境でやってみたのだが、うん、普通に送信できてるし、受信できてるね。
ってことは、ファイアウォールとかの問題ではなく、少なくともアプリより下では問題ないのだろう。
はあ、問題がよくわからなくなっただけではあるが・・・わからないということがわかっただけでもよしとしよう。

2017/12/13

[lmdb]putに成功してもgetに失敗したのはcommitエラーだった

lmdbで、mdb_get()してキーが無かったらmdb_put()する、という処理にしていた。
それは動いていたのだが、ずっと動かしていると急に、mdb_get()→失敗してmdb_put()→成功→同じキーでmdb_get()→失敗、という動作をするようになってしまった。
今まで動いていたので、APIの使い方を間違っているとか、lmdbの仕様を確認してなかったとかだろうと思ったのだが、どうにもわからない。。。


あれこれ考えていると、mdb_txn_commit()も戻り値があることに気付いた。
いや、commitで失敗してもやれることがないだろうと思って、チェックしていなかったのだ。

そうすると、一覧にないエラーが起きていた。

MDB_MAP_FULL

見ていくと、mdb_env_set_mapsize()にたどり着いた。
えー、これってmdb_put()で返すように書いてあるけど、mdb_txn_commit()のタイミングで返すの。。。
まあ、commitするまで反映しないということからすると、その方が自然なのか。。。


どうやら、mapsizeがDBに保存できるサイズの上限らしい。
たしかに今回は、初めて実動作させて大量のデータを保存させていたのだ。

DBって、ディスク容量に制限されるだけかと思っていたのだが、処理の都合でいろいろあるということがわかった。
SQLとか使うほどじゃないから軽いやつにしよう、くらいで選択してはよくないのかもしれんな。

2017/12/11

[lmdb]トランザクションのネスト

lmdbのトランザクションはmdb_txn_begin()で始まるが、ネストはできるのだろうか?

LMDB: Getting Started

Transactions may be read-write or read-only, and read-write transactions may be nested. A transaction must only be used by one thread at a time. Transactions are always required, even for read-only access.

R/Wであればネストでき... may beって?
Google翻訳だと「入れ子になっている可能性があります」と訳されたんだけど、「入れ子にすることもできる」の方が正しいのかな。


では、とmdb_txn_begin()をR/Wで2回呼んだのだが、2回目で止まってしまった。
話が違うでは無いか!
2回目のオプションでMDB_RDONLYを付けるといけるのだが、そういう意味でネストできると書いているのだろうか?
いや、今作っているプログラムで2回呼び出して書込んでいるルートがあったので、こうやって心配になって確認しているのだ。
心配だったので回避させたのだが、もしかしたら別スレッドからだったのでロックしなかっただけかもしれない。

スレッドごとに別トランザクションが発生するのは、使い方はよろしくないかもしれない。

A transaction must only be used by one thread at a time.

これは・・・一度作ったトランザクションをスレッド間で使い回すな、という意味だろうか。
「be used」なので、使い回すのはダメだけどbegin()すること自体は問題ない、と捉えてよいのか。。。


ちなみに、straceでロックするところを見てみると、futex(FUTEX_WAIT)を最後に実行していた。
lmdbはPOSIXのlock fileを使うと書いてあったので、ファイルロックしていたからfutexで変化するのを待っているのか?


結果として、何も分からんかった、ということになる。
最初のbegin()がR/Wで、2回目がReadOnlyであればいけることはわかった、というくらいだ。

データ保存はDBにお任せ、と気楽に考えて作っていたのだが、高速性を売りにしているということは管理をアプリ側である程度はやるのが前提なのだろう。
まあ、考えてみれば、そうなるな。

2017/12/04

[vscode]WSLのターミナルが赤くなった(解決)

Visual Studio CodeをWindowsで使っている。
統合ターミナルというものでWSL(うちはUbuntu)が使えるので、そうやって設定していた。

今まで普通に使っていたつもりだが、今朝起動させるとこんな感じだった。

image

名前やフォルダ名が入っているのでぼやかしたが、ホスト名部分は普通の配色なのだが、パス名のところから急に背景色が赤くなってしまった。
しかも、これがずっと引き継がれてしまい、何をやっても背景が赤。
さすがに見づらい。
PowerShellの方は問題なさそうだし、オリジナルのターミナルやwsl-temirnalは問題ないので、vscodeのWSLだけだ。


vscode settings - Color theme for VS Code integrated terminal - Stack Overflow
これを試したが、背景色は変わるものの、文字の背景色には反映されなかった。


この部分だと$PS1かと思ったのだが、変更した記憶が無いし、オリジナルのコンソールを開いて$PS1を見ても値が同じだ。
では、とPS1を.bashrcで"$ "だけにしてみたのだが、これでもダメ。
"$ "までは色が付かず、次に入力した文字も大丈夫だったのだが、実行した結果の背景色が赤くなり、それ以降は赤だ。


再起動したら直る、というパターンか?


2017/12/05

再起動してもダメだった。

どうも、この現象のようだ。
TERMINAL background color issue · Issue #39222 · Microsoft/vscode

あー、こんな感じこんな感じ。
最近追加されたissueみたいだから、これからか。。。


2017/12/16

なんか、上記のissueはcloseされていたけど、思っていたのと違うみたいだ。
VScodeがアップデートされたので期待したけど、やっぱり赤い。
また新しく同じようなissueが出ているから、

VSCode Integrated terminal text color goes crazy after npm or gulp commands · Issue #40327 · Microsoft/vscode

設定が変わったのかもしれんと思ったが、最新版ドキュメントでも同じだった。

https://code.visualstudio.com/docs/editor/integrated-terminal#_windows

Extensionも無効にしたが、変わらず。

うーん、使わなければよいだけなのだが、他のPCではうまく表示できているだけに悔しい。
Ubuntuをアンインストールして、またインストールし直したが、やはりダメか。

問題ないPCもあるから、何かの環境だとは思うんだけどねぇ。


2017/12/29

v1.19.1になったが、変わらんな。
来年になると忘れそうだから、現在のスクリーンショットを残しておこう。

image

「こんなxxxはいやだ」みたいな画面だ。

背景色じゃなくて、テキストの背景色というところがどうしようもないのだな・・・。


2018/02/24

まだ、赤い。
今回は、統合コンソールを立ち上げたときに、どこから赤くなるのかを載せてみよう。

image

このタイミングだ。

.bashrcでPS1をシンプルにすると、初っぱなは赤くならないのだが、次の段階ではもう赤くなる。

export PS1='$ '

image



Microsoft Storeからubuntuをインストールした場合、UsersのAppData/Localにあるubuntu.exeを動かすようなので、system32のbash.exeから変更してみたのだが、同じだった。


2018/03/14

まだ赤い。


不思議なことが分かった。
bashコマンドだと、大丈夫なのだ。
echoやcdだと現象が起きないみたい。

image

だから?といわれそうだし、私も何か分かるわけではないのだが。。。

この現象、起きないPCは起きないし、起きるPCはWSLを再インストールしようがvscodeを再インストールしようが元に戻らないから、時間がかかりそうな気がする。


2018/04/08

まだ赤い。


今回は、Ubuntuではなく、Debianをインストールしてみた。
"terminal.integrated.shell.windows"には、"AppData\\Local\\Microsoft\\WindowsApps\\debian.exe"のようなパスで指定してやらんといかんかった。
デフォルトがどれになるのかは、インストールした順番によるのだろうか?
試しにUbuntuをアンインストールすると、System32のbash.exeで起動した。


そして結果は・・・・

image

少し期待したのだが、やはりダメか。


GitHubを見てみよう。
https://github.com/Microsoft/vscode/issues/40327

Openのままだ。


vscodeをアンインストールしてやり直しても、RoamingにあるCodeを削除してやり直してもダメだったから、どこかにある設定を呼んでいそうな気がする。
テーマを変更すると色も変わるから、vscode自身が表示させていると思うのだが、うーむ。。。


2018/04/14

まだ赤い・・・赤かった!
しかし、とうとう解決したのだ!!


何をしたかというと、ColorToolというツールを動かした。
https://news.mynavi.jp/article/bashonwindows-58/

正直なところ、何がどう効いたのかはよくわからない。
元々、コンソールの配色を変更するツールなのだ。

試しに solarized_darkにしてみると、なぜか真っ赤になってしまった。
そう、vscodeでWSLのターミナルを開いたような、あんな真っ赤さだ。
PowerShellで実行したのが悪かったのかもしれんが、どれを指定しても色があり得ないだろう配色になっている。
cmdで実行し直したり、プロパティ見たり、vscodeのWSLから実行したりしていると、いつの間にか直っていた、というわけだ。


気にはなるが、直ればよかろうなのだ。

2017/12/01

[vscode]WSL用の設定

今まで、Linux環境にVisual Studio Codeをインストールして、VNC経由で使っていたのだが、Windows10のFall Creator UpdateからWSLが正式になったので、けっこうな部分がWSL環境でも動くようになっていた。

じゃあ、WindowsにVisual Studio Codeをインストールして、ビルドだけWSLに任せればいいんじゃないの?と思ってしまうだろう。
思ってしまうものなのだ。
ただ、includeパスの設定は何とかできたとしても、通常のLinuxにあるようなものは無理なんだろうな・・・
と思っていたら、ちゃんと資料があった。

https://github.com/Microsoft/vscode-cpptools/blob/master/Documentation/Debugger/gdb/Windows%20Subsystem%20for%20Linux.md

これを追加すると、設定として「WSL」が増える。
もし切り替わっていなければ、画面右下にあるOS種別っぽいところをクリックして選択するとよかろう。


vscodeは毎月進化しているので、追っていくのが難しいな。