cookies.txt　　　　　　.scr

ただのテキストファイルのようだ

GitHubのcommitをverifyする

github.com

1. PGP鍵が必要です。作ります。
2. Gitの、いつもSSH鍵をアップロードしている画面の下のほうに、PGP鍵アップロードするとこがあるので、します。
3. https://help.github.com/articles/signing-commits-using-gpg/を読みます
4. commitしてpushします
5. unverifiedを受けます。どうやらPGP鍵のemailと、git configのemailが一致している必要があるようです。
6. 今のnoreply github emailを使うのを通したいので、noreply email用にPGP鍵を作ることにしました。
7. 鍵をアップロードします。
8. commitします。pushします。
9. verified !!

f:id:cookie-s:20180420210430p:plain

SECCON 2017 Very smooth writeup / RustでP-1法素因数分解器を実装した話

TSG Advent Calendar 2017 14日目です。遅れました。
adventar.org

こないだSECCON CTFがありました。
素因数分解するだけ問題が2つありました。
Ps and Qsは自明で、Very smoothも自明のはずでした。

まず意味ありげなタイトルなので、smoothでググるわけですが、smooth numberなんかという単語がヒットします。
どうやら小さい素数の積ででてきているような数のことのようです。

素因数分解アルゴリズムについて若干でも知っていれば、ここからP-1法とかのあたりを連想するのは簡単なはずです。
ってかさっきWikipedia見たら、powersmoothって書いてありました。

で、p-1素因数分解は前実装した気もするんですが、無くしたので、
今回はツールでも探すかって"linux p-1 factor"みたいにググったら、gmp-ecmというのがヒットして、これP-1法もできるらしいんですが、なんかできない。
競技終了後にちゃんと見てみると、たぶんp-1法の亜種の2-phase algorithmを採用しているせいかなぁという気がしてきました。今回の場合最大の素数が5で、大きな素数は1つもないので。（天下り的ですが）
競技中はmoratoriumくんに頼んだら一瞬で素因数分解してくれました。

gmp-ecmは役に立たないことが判明したので、まあ実装し直すかーという話です。
言語は最近勉強しているRustです。
github.com

num::bigintつよい。しかしsqrtやlogはないっぽい。

ついでにFermat法も実装しました。これでSECCON 2014の4096bit合成数も素因数分解できます。
a4lg.com

P-1法はgmp-ecmでいうところのB1パラメタがあって、これによって計算時間が変わりますが、ソース中で1000となっています。
これでもrelease buildにすれば10秒以内に終わります。debug buildだと無限に終わりません。（いいえ）（3分です）
fermat法側は

gmpy.next_prime(3<<512) * gmpy.next_prime((3<<512) + (1<<265))

の素因数分解が秒くらいで終わりますというくらいですね。

おわりです。アンパサンドがたくさんになると、C言語病のせいで、特に初心のRustだと不安になるんですが、やっぱり筋の悪いコードなんですかね。

TSG slackbot sushibot

てぃーえすじー　すらっくぼっと　すしぼっと　（５７５）

f:id:cookie-s:20171204164442p:plain

TSG advent calendar 5日目です。
adventar.org
hakatashiさんがbotの流れを作ろうとしている気がするので、書くことにしました。sushi botというbotを作りました。たった36行です。

ソース

「すし」「スシ」「寿司」を含むような寿司発言に対して「🍣:sushi:🍣」 reactionをつけます。
これによって、みんな寿司が食べたくなり、日本の経済がよくなる効果が期待できます。

こういうのをつくると、くろごま氏が「スシ」という文を投稿してきて、『スシにも対応しろ』と圧力をかけてきます。
対応すると、くろごま氏が「すシ」などを投稿してきます。
対応すると、くろごま氏が「壽司」などを投稿してきます。
対応すると、くろごま氏が「鮨」などを投稿してきます。

結局、

   rtext = rtext.
            replace(/鮨/g, 'すし').
            replace(/([Ss][Uu]|[Zz][Uu]|ス|ズ|ず|寿|壽)/g, 'す').
            replace(/([Ss][Hh]?[Ii]|[Cc][Ii]|し|シ|司)/g, 'し');

とnormalizeしてから「すし」を含むものを寿司発言としました。
当然、逗子は寿司発言ではありません。




さらに、同じような戦略で実装できる追加機能として、擬akouryy発見機能もついています。
akouryy氏のつづりはなかなかむずかしいので、間違える人がよくいるとかいないとか。
そのため、擬akouryyを発見し、矯正するために、reactionをつきます。

擬akouryy発言とは、以下のnormalizeを施した後、akouryyが含まれるものです。

   rtext = rtext.
            replace(/akouryyy/g, 'akkoury').
            replace(/akouryy/g, '').
            replace(/kk/g, 'k').
            replace(/rr/g, 'r').
            replace(/y/g, 'yy');

雑実装ですね。



ついでに、僕が凍結された頃、さらなる凍結者を出さないために、「殺」「死」発見、警告機能もついています。
これのお陰で、今のところ僕を除いて凍結者はでていません。
f:id:cookie-s:20171204164746p:plain


ところで今気づいたんですが、/[Zz]/とかって/z/iでよくないですか。

初心者がつまづいたGAEの無料枠の話

この記事を何も考えずに信用されても困りますし、それによって不利益があっても僕は知りません。ちゃんと原典にあたってください。
僕はGCP初心者です。

GAEとはGoogle App Engineの略です。
Google App Engineとは、Google Cloud Platformで提供されている、おそらく典型的にはHTTPサーバをたてるような、Webアプリを動かすためのものです。Herokuみたいなものだと思っています。

今年夏、とある事情からついにGoogle Cloud Platformに登録しました。
登録から1年間、あと280日で$300のクレジットを使い切らなくてはなりません。
しかし僕はお金を使うのが本当に不得意なので、クレジットさえも消費されると悲しくなってしまいます。
ところでGCPには無料枠というのがあり、トライアル期間中かどうかに関係なくいつまでも無料で使える枠があります。
僕の感覚からすると、無料枠でだいたい収まるアプリが、たまに枠をはみ出してクレジットをじりじり削っていくくらいがいいのです。


なにが無料枠で使えるのかというと、↓ここに細かいことは抜きにしてざっとしたことがリストになっています。
cloud.google.com
この記事の焦点はGAEなわけですが、ここでGAEの欄に書かれていることの詳細は、
欄をクリックしたここにあります。

僕は頭が悪いので、この文章の解釈がぱっとできませんでした。
そのせいで10日間で\841がクレジットから飛んでいったので、その話をします。

とんでいった料金の確認

  1. まずコンソールにアクセスします https://console.cloud.google.com
  2. メニューを出して、「お支払い」を押します。クレジットの残高はここに見えます。
  3. 「料金の履歴」を押します。
  4. 各月で、いくらか請求が発生し、その分がクレジットから引かれて、実際の請求は\0となっていることが確認できます。

ちなみに、「お支払い」で「予算とアラート」から適当に予算を作って「クレジットを予算として含める」と、クレジットが減るとメールが飛んできて悲しくなれます。

GAE無料枠の使い方

フレキシブル環境とスタンダード環境

GAEには「フレキシブル環境」と「スタンダード環境」が用意されています。
僕の重大なミスは、なんとなくフレキシブル環境を使ってしまったことでした。
今から思えば、語感から考えても「フレキシブル」のが強そう=高そうなのに、なんだか弱そうに感じてしまったのでした。

ここの文章で、「無料」を含む文章は、スタンダード環境での文脈です。
このページには28インスタンス時間が無料とありますが、これはフレキシブル環境では一切関係ありません。
Scalingの設定をして1 instanceしか起動しないように設定しようとも、ここの表の通り課金されます。

これより、スタンダード環境にない、たとえばRubyやNode.jsでアプリを書いてしまった時点で、それはGAE無料枠では動きません。

Scaling

GAEのScaling手法には、Automatic, Basic, Manualの3種類があります。
ここにあるように、Automaticに関しては28インスタンス時間が無料枠になりますが、
他のBasic, Manual scalingをとった場合、無料枠は9インスタンス時間となります。

この無料インスタンス時間の違いもそうですが、scaling手法は、単にscalingがどうなるか以外にもかなり意味を持つようなので注意しましょう。
特にここが参考になります。

インスタンスクラス

GAE Standard環境には、インスタンスクラスというのがあります。
ここに列挙されていますが、
書いてある通り、scaling手法によって使えるクラスが変わったりします。

で、無料枠との兼ね合いがどうなるのかという話で、これはちゃんと検証もせず、無責任に書くことなのですが、
今のところクラスを上げると時間が減ることを匂わせるような記述には出会っていません。
無料枠を突破したあとはクラスが高いほど高額の請求が来ることは自明なんですが、
クラスによって無料枠の長さは変わらないことが期待できるかもしれません。
設定によって無料枠を突破しない自信があるなら、高いクラスを指定してみてもよいかもしれません。