  |
はてなキーワード: gcmとは
かざぐるまのように棒の先端に回転するものがついています。但し風の抵抗を受けないように羽ではなく円盤がついているとしましょう。
円盤を勢いよく回します。円盤は摩擦がなければそのまま回り続けます。そして今度はそのまま棒を動かしましょう。円盤の回転面に対して上下でも、左右でも構いません。この棒の動きは円盤の回転に影響を与えないことを理解してください。
クランク軸の一方の端 (A) に円盤がついているとします。前と同じように円盤をまわしましょう。そして今度はクランク軸自身をクランク軸の他方 (B) を中心に回しましょう。円盤はクランク軸 (B) を中心に公転しますが、やはり円盤自身の回転は影響されません。
さて、円盤は回転している。クランク軸も回転している。その時、円盤の回転速度を少しゆっくりにしてみましょう。クランク軸が一回転する間に円盤も一回転する速さにしましょう。そしてクランク軸の回転を急激に止めるとしましょう。円盤は・・・元の回転数で回転を続けるはずですよね。これが慣性です。
また、逆に円盤もクランク軸も静止しています。そしてクランク軸をまわし始めると・・・円盤は回転しないで止まったままクランク軸の周りに公転します。これも円盤の慣性によるものです。
もうお分かりになったかと思いますが、円盤はナット、クランク軸はタイヤ (ホイール) です。タイヤが一定速度で回転しているときにブレーキをかけるとナットは回転を続けようとします。これがナットを締めたり緩めたりする力になります。反対に車が発進するときにはタイヤは回転をし始めますが、ナットは静止しようとしていますので、ブレーキ時とは逆方向に回転力がかかります。加速、減速するときだけナットに回転力がかかります。一定速度で走っているときにはナットに回転力は発生しません。
トラックが静止から60km/hまで30秒で加速するときと、60km/hから3秒で止まるときとではナットにかかる回転力はそれぞれ逆方向に働きますがその値は10倍違います。ブレーキ時のほうが大きくなります。だから左側は左ネジがいい・・・と、ここまではいいのですが、問題はその値です。
いくらなのか簡単に計算できます。大きく見積もってもわずか数gcmです。子供がナットに指2本をかけてまわす程度です。ナットの締付トルクの100万分の1です。
私はこの値を言わないで左側に逆ネジを使用しないのが問題だという記者を信用できません。ニュース、ネットでタイヤの回転とねじの回転を図示して説明しているのを見かけますがあれで説明できていると考えること自体が問題だと思います。もちろんJISとISOの違いは右ネジ左ネジの違いだけではないのでISOに問題がないとは言いませんが、規格の適用に携わった人たちはこの程度のことは十分承知していると思います。
振動によるゆるみはネジを使う以上避けられません。しかし、右ネジ、左ネジでその挙動が異なるとは考えにくいと思います。先の慣性によるトルクとの合わせ技で右ネジが問題という考え方もできますが、それは実験で確かめるほかないでしょう。
トラックと乗用車との違いで考えなければならないのはナットの大きさ (慣性) とタイヤ径と運動性能です。慣性はトラック用のナットのほうが大きいので発生トルクは大きくなる。タイヤ径は乗用車のほうが小さく回転数が高いので発生トルクは大きくなる。運動性能は乗用車のほうが優れている=急発進、急ブレーキが利くので発生トルクは大きくなる。
ということで必ずしもトラックのほうがナットの発生トルクが大きくなるわけではありません。条件次第では乗用車のほうが大きくなる場合があります。
{ 'transaction':[ 'key':'some_token_like_SHA-2', 'descriiption': 'bar', 'from_wallet': 1234567890, 'to_wallet': 0987654321, 'total_amount': 9999999999999, 'tax_amount': 999999999999, 'timestamp': yyyymmddhhmmss ] }
http://developers.linecorp.com/blog/ja/?p=3591
Letter Sealing って何でしょうか。私気になります。
必要な範囲で、原文を引用しています。原文は先に引用元のアドレスと閲覧日時を記し、引用記法によって地の文と識別できるようにしています。
ECDHとAES256-CBC 使ってみた。通信相手の認証については読み取れない。
図2 において、 Server のところで Re-Encryption (一度復号されて、再度暗号化されている) ことが明示されています。
この図を素直に読むと、送信者からサーバーまでの通信路は暗号化されているものの LINE のサーバーが受信したところで復号されて平文で保存され、サーバーから受信者までの通信路は暗号化されていると理解できます。文脈から、この流れを変えたいのであると推測できます。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
加えて、LINEでは、仮に通信ネットワークの傍受が行われたとしてもメッセージを覗くことができないように、公開鍵暗号(public key encryption)方式を使っています。ユーザーに対してLINEアプリを提供する際、暗号化ができる公開鍵のみをアプリに入れて提供し、ユーザー端末とサーバが接続されたときだけLINEサーバでのみ解析できる暗号化された安全なチャネルを作ります。こうすることで、SSL(Secure Socket Layer)より軽く、LINEの全バージョンで使用できる安全な暗号化を実現できます。
SSL はすでに時代遅れの代物で、 2015年秋現在は皆さん TLS を利用されていることでしょう。 Web ブラウザで SSL 2.0 や SSL 3.0 を有効にしているそこのあなた、今すぐ無効にしましょう。
TLS では、公開鍵暗号方式や共通鍵暗号方式、電子証明書、暗号学的ハッシュ関数といった複数の暗号技術要素を組み合わせて安全な通信路を確保しています。
RSA に代表される公開鍵暗号方式は一般的に AES に代表される共通鍵暗号方式と比べて計算量が大きい、つまり重たい処理となります。
このため TLS では、通信路を流れるデータの暗号化に共通鍵暗号を用いて、共通鍵の共有や相手の認証のために公開鍵暗号方式を用いるのが一般的です。
仮にメッセージの暗号化に RSA を用いているとしたら、 SSL より軽いという点をどのように実装しているのか気になります。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
ユーザー側のLINEアプリ(クライアント)には、サーバが発行したRSA鍵を使用してデータの暗号化に使う暗号化鍵値を共有します。この鍵を利用してデータを暗号化すると、第三者はメッセージを見ることができなくなります。
これは上で説明したとおり SSL や TLS でも行っていることです。
RSA を用いているので安全であるという主張をしていますが、メッセージの暗号化に用いられている暗号スイート（アルゴリズムの種類、鍵の長さ、ブロック暗号の場合は暗号利用モード、そしてハッシュアルゴリズムの種類）は、その通信路が安全であると判断できるか否かを決める大切な情報です。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
既存のRSA方式も秘密データの共有に使う安全な方式ではありますが、鍵管理の面から見ると、ユーザー側の端末でそれぞれのRSA鍵をすべて管理しなければならないという問題があり、その代替手段としてDHを使用するようになりました。
DH および ECDH による共通鍵暗号に用いる鍵の交換は SSL や TLS でも実装されており近年では広く使われています。 SSL より軽いと主張し、 SSL や TLS が公開鍵暗号方式以外の要素によって担保している安全性をどのように確保しているか不明な実装に比べると、大きな改善です。
なお SSL や TLS においては通信相手の公開鍵を全て管理する必要がないように、上で説明した電子証明書による公開鍵基盤 (PKI) の仕組みを利用しています。
つまり共通鍵暗号に用いる鍵の交換にどのような手段を用いるかは、鍵管理とは（ほぼ）独立です。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
ここでメッセージの暗号化に使用している暗号化アルゴリズムはAES-CBC-256という方式で、現在一般に使われている暗号化アルゴリズムの中で最も強度が高いと評価されています。
メッセージ認証と組み合わせない CBC はビット反転攻撃に弱いことが知られています。 GCM ではデータの暗号化と認証を同時に行うためビット反転攻撃に耐性があります。 AESを GCM で利用するのは、 最近の TLS の実装では広く用いられており、 Google や twitter も利用しています。
CBC も CBC-MAC のようにメッセージ認証と組み合わせることでビット反転攻撃に強くなります。
図6 のとおり、 ECDH で共通鍵暗号に用いる鍵の交換を行うにしても通信相手の公開鍵は必要です。 上で説明したとおり鍵管理という問題への解決策になりません。また公開鍵が本当に通信相手のものであることをどのように検証するのかについても不明です。通信相手の検証は、送信側では秘密の話を他の人に知られないように、受信側では他の人になりすまされないように、双方にて必要です。
ここからは安易なパターンの想像ですが、通信相手の公開鍵情報は LINE ユーザー情報の一部として LINE サーバーで管理されており、必要に応じて安全な通信路を用いて LINE サーバーから取得するようなものではないかと思います。公開鍵情報のやりとりに用いられる通信路に正しく実装された TLS が用いられていて、サーバーとクライアントの両方が認証されていて、現在の水準から見て妥当なレベルの暗号スイートが用いられていることを願うばかりです。
公開鍵と秘密鍵がどこでどのように保管されているのか気になります。各端末で保管するのが安全ですが、サービスの要求として端末を乗り換えてもメッセージが読めるという条件を安易に満たすために秘密鍵を LINE サーバーに預託していないことを祈るばかりです。
ECDH 鍵の生成は計算量が大きい処理であり質の良い乱数を必要とします。 PC に比べると非力なスマートフォンで生成した鍵の質をどのように担保しているのか気になります。
先ほど閲覧したところ、上記引用箇所の多くは削除されていました。公開鍵が本当に通信相手のものであることをどのように検証するのかについては明らかではないようです。 LINE サーバーが介在する形であれば、鍵をすり替えることで別のユーザーになりすますことが可能でしょう。または、 LINE アプリに何か細工をする方がより簡単でしょう。
ECDH 鍵はその場限り (ephemeral) という説明がないので Perfect Forward Secrecy ではないと考えられ、望ましくないという意見もあるようです。 LINE サーバーとの間に安全な通信路を確立する目的で ECDH 鍵を用いる場合、 LINE サーバーが用いる秘密鍵の漏洩は全てのユーザーに影響を与えうるため PFS は非常に重要です (TLS を用いた Web サーバーでも同様です) 。一方ユーザー間でメッセージを暗号化する場合、ユーザー所有の ECDH 鍵についてはそのユーザーに影響が限定されます。通信相手ごとに必要なその場限りの鍵生成とユーザー所有の ECDH 鍵を利用した鍵交換にかかる計算量と ECDH 鍵漏洩のリスクを天秤にかけて PFS を採用しないという判断かもしれません。
通信の秘密という観点ではメッセージの内容だけではなく誰と通信したか (または、していないか) という情報も守りたくなります。宛先を LINE サーバーで確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます。
今GoogleI/O見ててエンジニアの隠しきれないオタク感がなんとなくやばい。
っでなんとなく思ったのだけど、
そんな代物になったんじゃない？
ほんとの素人って方も少なくて、
いらっしゃらなかったんだよ、きっと。
Androidの開発でGoogleのチュートリアルは時々見るが、
さっき紹介してたGCMとか、あらかた使い方覚えてAPI表みたら
確かにプラスα要素多くて丁寧そうに見えるんだけど
それ理解できるようになったらチュートリアル本編はいらないって
まぁ大体そんな感じ。
なんかその辺が全くの初心者に対していきなり知ってることすべて説明しようとして
説明できることと技術があることは別やねんと
日本人はとりわけこの傾向が強いのだが成功術や幸福術に対して猜疑的と言えるほどに否定・反発する風潮が広くみられる。
また、より一般的な話になるが現代人に広く見られる傾向として、絶対的価値観に対する無条件の反発のようなものも広くみられる。
ひるがえって、近代科学が知識人たちにもたらした仮説思考とは、集めた情報、持ちうる情報から検証を重ねて一定以上の確率で正しいと推論される主張を「さしあたり」支持するというものである。
だから、何もその主張を絶対的に支持するわけではないが、「さしあたっては」絶対的に支持しているような「素振り」をとっている、と言えないこともない。
そういったものに対しても、「自分の考えを正しいと信じて疑わない」「自分以外はみんな間違ってると思ってるよアイツ」みたいな言い方を平気で出来てしまうのである彼らは。
いわば、絶対性アレルギーとでも言うか、「絶対なんて絶対ない」から感じる滑稽さに近しいものを感じざるを得ない。
むろん、彼らも絶対的に絶対性を否定しているわけではなく、あくまで「素振り」であると断じてしまうことは簡単である。
しかしながら、素振りであるにしても、幸福術に対するアレルギー反応を観察していると、これは人生簡単にいく方法なんてないから簡単な方法を否定しているといった人生の構造そのものの難しさにだけ帰着できる問題というより、
もはやこれはアレルギー反応を起こす人々に特有な精神性に問題があるのだなあと私は考えるのである。
バイト先の近くのローソンに過剰なサービスを提供するありがた迷惑な店員がいるのだが、最初それは店側の意向なのかと思っていた。
通常おかしな店員がいれば他の店員が注意したり客が苦情を申し立てたりするはずで、とっくに修正されているはずであるから、店側の方針と考えるのは自然なことである。
だが、その店に通い詰めるにつれて、明らかにその店員だけ特殊であることに気づき、これは誰も注意しないだけなんだと判明した。
すると不思議なのが何故注意しないのかである。その店員がおかしいと思っているのは俺だけなのか？いやそんなはずはない。では何故注意しない？
結局導き出された結論は、誰もがそんな些細なことはスルーしているのだ。彼は法をおかしているわけでもなく、あからさまに害を及ぼしているわけでもない。ただちょっとウザイだけである。
仕方ないのだ、そういうキャラなんだから。たまには迷惑そうにする客もいるだろう。実際、おかしな顔で彼をにらんでる女性客を見かけたことはある。「なんだこの馴れ馴れしいヤロウは」みたいなｗ
だが、否定派の俺が見ても彼はイケメンだから注意する女性も少ないのかもしれない。結局、ハルヒじゃないが最初は「なんだこいつ」と思う人が多いだろうが
「まいっか」の精神で最大公約数的な答えに落ち着いているのだろう。思えば世の中にはGCMを計算してくれる既成のプロパガンダやプロパガンダ機能を有するサービス・機関があふれかえっている。
「こまけーこたぁいいんだよ」とばかりに様々な無数の懸念事項を隅田川に勝手に不法投棄し、東京の街は成り立っている。
表向きは綺麗に見せかけているが水中では足をばたつかせている白鳥のように、クローゼット突っ込み整理術のように、強引に人々の心のゴミを片付け、夢を見させる。
言うなれば、その延長に絶対性への拒絶反応や幸せに生きる方法に対する無条件な否定や猜疑的反発や神経症的激怒があるのだろう。
心のどこかでは幸せに生きたいと願いつつも、その思いは叶わないから「ゴミ」であって削除されなければならないのだ。彼らの中では。
そこで手っ取り早くゴミを片付けて（結局それは先送りしてるだけで片付けには成功してないのだが）夢を見させてくれる既成プロパガンダにしがみつく。
そしてテキトーに組み合わせて自分のためのつぎはぎだらけの不格好な体系をこしらえる。それが彼らの声帯なのだ。
なぜこれが深刻な問題にならないかというと人々はそれなりに幸せだと思い込むことが出来ているからである。いろいろ不平不満を表面では言いつつも、実は大して彼らは困っていない。
しかし、こうも考えられないだろうか？中には本当に困っている人もいると。あるいはまた、困ってはないがもっと幸せになりたいと願っている人もいると。
だから日本に生きる人たちは気をつけないといけない。自分がその該当者だとしたら現実から目を背けてインスタントなツギハギプロパガンダの夢を見るのは得策ではない。
そういった人たちが既成の幸福術を実践したところで、ツギハギプロパガンダの悪影響を強く受けてしまうから失敗に終わることが多いのだ。
そして明日には二の轍を踏むかもしれない人間が平気でそういった人たちをつかまえて、だから無理って言っただろと非難する。そういう構造になっているわけである。
科学を篤く信奉する我々は、彼らの永遠なるごっこ遊びを真似してはいけない。毅然とした大人の態度で、GCM計算から一歩置く必要がある。
絶対なんて絶対ないと言いながらGCMのトリコになってる彼らとは違う。科学者の言う相対主義とは、仮説思考であり、方程式の適用限界の確認である。
ほにゃらかほにゃらかだと念仏のようにとなえるだけではだめで、直接話法を使いなさい。「「おっぽれだからほにゃらかだ」と思う」と言わないとダメ。カッコつけずに括弧をつけろと高校数学で習っただろ？
