2017年9月29日金曜日

初期費用ゼロのRFID、はじめました!

こんにちは、気が付けば9月も終わりですが今年もblogぜんぜん更新できていないことに愕然としてます、大坂です。

ところで(?)、無償版のExcel Toolとか、50アイテムまで無料で使えるMANICAタッチレンタルNFCとか、RFIDに興味を持っていただいた方に何とか最初の一歩を踏み出していただくために、あらゆるハードルを排除することを生き甲斐にしております我々ハヤト・インフォメーションですが、いよいよ初期費用ゼロで始めるRFID、という新境地を切り開くことになりました。

ハヤト・インフォメーション、初期費用ゼロ+月額1,500円で始めるRFID
「MANICAモバイル」をリリース

従来は、定置式のリーダーや業務用のハンディリーダーなど高価な機器が必要とされていたRFIDの導入プロセスにおいて、スマートフォンベースのシンプルかつ導入初期費用を抑えたソリューションを提供することで、規模の大小にかかわらず、より多くのお客様がRFIDを活用した業務改善を楽しめるプラットフォームとして、「MANICAモバイル」の提供を行ってまいります。(プレスリリースより抜粋)

サービスの詳細は、こちらから。

1ヶ月無償で使えるトライアル期間も設定されてます、皆様是非!






2017年9月19日火曜日

RFID とブロックチェーン その6

今回の投稿は前回のダブルハッシュの続きです。

前回は SHA-256 を2回行うダブルハッシュについて、2回目に衝突があるとその程度によっては問題なんじゃないの?ということで衝突があるのかどうなのかをやってみるというよっぽどの暇人じゃないとできないような無謀な内容でした。

単純に算出されたすべてのハッシュ値を記憶しておいて衝突がないかどうかやってたわけで、非常に効率悪いやり方でしたのでもう少し効率良さそうなやり方に変えてみました。暇人というところは違いないわけですが。

前回は0から順番にハッシュ値を計算していましたが、今回は算出されたハッシュ値を次回の入力値とするように変更しました。

で、仮に同じ値が出力されるような衝突があるとすると、


こんな風にグルグルができるはずということで、全部の出力を憶えておくんではなくて、たまに憶えておけばグルグルになったときに発見できるだろうという都合のいい考えでやってみました。

1億回計算したら値を憶えておくようにしました。
この状態で3連休ほったらかしにしておいた結果...

どーん


回数としては743億回ぐらいの計算を行ったようですがまだ見つかってないですね。

これって全体のどのくらいの量なんだろうか、バイト数で多めに見て5バイトまで完了。ということは SHA-256 は32バイトなのでえーっと、256の(32-5=)27乗分の1くらい終わってるということかー、それってどんくらい?関数電卓で計算すると

1.0531229166855718669791802768367e+65

おー、10の65乗分の1、パーセントにすると10の63乗分の1パーセントということですねー...

なんて無駄なことをやってるんでしょうか...orz

2017年9月4日月曜日

RFID とブロックチェーン その5 ダブルハッシュ

その4でご紹介した真贋判定のサービスの提供を開始しました!

  MANICAブランドプロテクション

まー、中身はほとんど Proof of Existence と同じなんですけどねー。

今回はちょっと気になった事について記述します。それは「ダブルハッシュ」です。

ブロックチェーンでは暗号学的ハッシュ関数として SHA-256 が多用されています。これは入力としてデータを与えると、出力として 256bit のデータが出てきます。どんなに短いデータ(1バイトとか)でも、どんなに長いデータ(1テラバイトとか)でも出力は 256bit です。当然ですが同じデータを入力すると同じ 256bit のデータが出力されます。で、入力データが 1bit でも違うと全然違う値の 256bit が出力されます。これで改ざんされていないかどうかを判別するわけです。

で、ブロックチェーンではハッシュを2回行うダブルハッシュというのを利用しています。1回ハッシュ値を算出して、出てきた 256bit の値をもう1回ハッシュをかけて、出力された 256bit の値を利用するわけです。

なんでこんなことしてるのか?というのが素朴な疑問なわけですね。暗号学的にセキュリティが強固になるからというように説明されているところもありますが、どうもよくわからない。計算方法を調べれば納得するかもしれないですけど面倒くさいっす。

ハッシュ1回の場合は、入力データがそれこそ無限に近い数あるわけですけど、2回目のハッシュは入力が 0 ~ (2の256乗 - 1) に限定されるわけです。それでも十分な量ありますけど、でも無限に比べたらやっぱり有限なわけで、出力されたハッシュ値の衝突がそれなりにあるとするとそれはそれで問題でないのかい?というのが今回のテーマです。

これも計算方法を調べればわかるのかもしれませんがやっぱり面倒なので本当に衝突が無いのか地道に計算させてみることにしました。

単純に0からずーっと入力して出力を溜めてって、衝突があると騒ぐというプログラムです。 List 使ってますがそもそも List にそんなにたくさんのデータ入りませんからいずれはオーバーフローするんでしょうけどまぁそんなところまでたどり着くかもわからんしとりあえず動かして土日ほったらかしてみました。

結果... どーん。


残念ながら?衝突は起きてなくてでも 0x3C 0x21 0x5B まで(約394万回)実施の結果だと。あー、先ながーい、消費メモリは1Gくらい、土日使うくらいじゃーここまでかー。

というわけで暇があったらもう少しやってみようかと思います。