『暗号技術入門』よりメッセージ認証コード、デジタル署名について

結城浩『暗号技術入門第3版 秘密の国のアリス』の一部をまとめました。

メッセージ認証コード・デジタル署名は、どちらもメッセージが書き換えられていないことを示す正真性(完全性)を確保するためや、メッセージが正しい送信者からのものであることを示す認証を実現するために用いられます。

一方、無関係な第三者に漏洩しないという、機密性を確保することはできません。

メッセージ認証コードとは

Message Authentication Code で、MACともいわれます。

コードというと第一印象は何かしらの文字列ですが、そうではなく

鍵に依存した一方向ハッシュ関数

です。メッセージをそのハッシュ関数にかけると、MAC値が得られます。

実際の使い方は以下になります。

  1. 送信者アリスと、受信者ボブは、同じ鍵を持っているとします。

  2. アリスは鍵を使い、メッセージのMAC値を計算します。

  3. アリスはメッセージとMAC値をボブに送信します。

  4. ボブはメッセージと自分が持つ鍵からMAC値を計算し、両者が一致すれば認証成功です。

デジタル署名とは

単語のイメージからは、自分の名前をサインしたものをデジタル上で表現するものと思われます。

実際は、自らの秘密鍵で暗号化したメッセージ*1そのものです。メッセージ全体が暗号化されることがあります。逆に、メッセージ自体は暗号化しない場合のデジタル署名をクリア署名といいます。

簡単に、デジタル署名の使用手順を記載します。

  1. 送信者アリスは、一方向ハッシュ関数*2でメッセージのハッシュ値を計算します。

  2. アリスは、自分の秘密鍵ハッシュ値を暗号化します。これが署名になります。

  3. アリスは、メッセージを署名を受信者ボブに送信します。

  4. ボブは、受信した署名をアリスの公開鍵で復号し、ハッシュ値を得ます。

  5. ボブは、受信したメッセージからハッシュ値を計算し、前の手順から得たハッシュ値と比較します。両者が一致すれば認証成功です。

メッセージ認証コードと、デジタル署名は役割や使い方が近いことが分かります。

メッセージ認証コードと、デジタル署名の使い分け

メッセージ認証コードは、第三者による証明と、否認防止ができません*3。一方、デジタル署名は誰でも検証できますし、否認防止ができます。

ならば、デジタル署名はメッセージ認証コードの上位互換なのでしょうか。

おそらくそれは違っていて、理由は対称暗号が公開鍵暗号より優れているポイントと同じです。

すなわちパフォーマンスが違います。

とはいえここからは個人の感想ですが、デジタル署名はハッシュ値に対して暗号化をかけているわけだし、パフォーマンスもそこまで問題にならなさそうな気がします。

*1:もしくはハッシュ化したメッセージを暗号化したもの

*2:鍵に依存しないのでメッセージ認証コードで使っているものとは別物

*3:どちらも、送信者と受信者が同じ鍵を持つので、どっちかそれを使ったかが証明できないため

HackerRankというサービスに登録した

とある縁でHackerRankというサイトに登録したので説明しようと思います。

どんなサイトか?

www.hackerrank.com

Practice coding, prepare for interviews, and get hired.

とあるようにプログラミングの練習問題、コーディング試験対策、求人応募ができます。しかし、求人応募はアメリカと一部のヨーロッパに限られます。

サイトはすべて英語です。

練習問題

登録すると、ダッシュボードにテーマ別の練習問題が表示されます。一番左の「Problrem Solving」が一番豊富にそろっている印象。 f:id:alek3:20190303152118p:plain

解き始めると、ダッシュボードで進捗が表示されます。たくさん解くとレベルアップする感じでしょうかね。 f:id:alek3:20190303152008p:plain

問題の特色

ブラウザ上にコードを貼って、解答を提出するのですが、標準入出力については、すでにコードが記載されています。

なので、回答者である我々は、問題を解くロジックのみを考えればよいことになります。

まとめ

プログラミングの問題を解答できるサイトは、AtCoderやPaizaなど、様々なものがあると思いますが、以下のニーズに対してはHackerRankが適していると思います。

最後については補足が必要ですが、WEB上でコーディングテストを受ける際に、このサイトが使われいているそうです。

参考

他のレビュー投稿です。

HackerRankのアルゴリズム厳選20問でコーディング面接をハックする - 港区で苦しむデータサイエンティストのメモ帳

HackerRankでプログラミングを勉強する - Qiita

HackerRankで問題を解いてみよう! - Takahiro Octopress Blog

*1:ただし、サイトを見た感じC、C++JavaPythonRubyJavaScriptしかないような感じがする

[AWS]EC2インスタンスにPuTTYでSSHログインしようとして、「Disconnected: No supported authentication methods available」、「Server refused our key 」というエラー発生時の対処法

タイトルが長くなってしまったが、削れないのでこれで。

症状

いつものようにPuTTYでEC2インスタンスにログインしようとしたところ、以下のエラーが発生して入れなくなった。

Disconnected: No supported authentication methods available (server sent: publickey,gssapi-keyex,gssapi-with-mic)

PuTTY側の画面は以下の通り f:id:alek3:20190218110928p:plain

対処法

公式に書いてあったのでその通りに実行したら直った。 aws.amazon.com

手順7は、ENTER YOUR PUBLIC KEY HERE ... のところを書き換えれば他はそのままでOK

根本原因

わかっていない。上記公式サイトで挙げられているもののうちのどれかが該当しそうな気はするが・・・

教訓

検索するエラーメッセージを変えてみるのも一手。

PuTTY側のエラーメッセージで検索しても有効な対処法は見つからなかったが、コンソールのエラーメッセージ「server refused our key」で検索したらすぐに対処法の書いてあるページが見つかった。

ipaファイルをアーカイブしようとして「No signing certificate “iOS Development” found」エラーがでたときの対処法

いつものようにXCodeipaファイルを作成しようと思ったらエラーが発生しました。

少し前はできていました。すなわち開発者証明書および秘密鍵は準備できています。

慌てずエラーを見ると以下のような文章でした。

No "iOS Development" signing certificate matching team ID with a private key was found.  
(中略)  
Code Signing Error: Code signing is required for product type 'Application' in SDK 'iOS 11.4

認証ができていないっぽいので、XCodeでの設定画面を見ます。

general > signingのところです。

すると、エラーっぽくなっていました。(スクショはとりそびれました)

設定を完了すると以下のようになります。

f:id:alek3:20190216231613p:plain

参考

dev.classmethod.jp

出てきたけどこんなに高度なのは必要ありませんでした。

読了:『ファクトフルネス』

最近読書のペースが早くなっているような気がしていてうれしいです。

今回は『ファクトフルネス』です。

ファクトフルネスの大まかなルール

「ファクトフルネス」はなにかというと、事実に基づいて物事を判断する態度であり、それを妨げる自らの本能に自覚的であることです。

まずは要約として、「ファクトフルネスの大まかなルール」を以下に挙げます。

  • 分断本能を抑えるには…
    • 大半の人がどこにいるかを探そう
  • ネガティブ本能を抑えるには…
    • 悪いニュースのほうが広まりやすいと覚えておこう
  • 直線本能を抑えるには…
    • 直線もいつかは曲がることを知ろう
  • 恐怖本能を抑えるには…
    • リスクを計算しよう
  • 課題視本能を抑えるには…
    • 数字を比較しよう
  • パターン化本能を抑えるには…
    • 分類を疑おう
  • 宿命本能を抑えるには…
    • ゆっくりとした変化でも変化していることを心に留めよう
  • 純化本能を抑えるには
    • ひとつの知識がすべてに応用できないことを覚えておこう
  • 犯人探し本能を抑えるには…
    • 誰かを責めても解決しないと肝に銘じよう
  • 焦り本能を抑えるには…
    • 小さな一歩を重ねよう

これだけでも、なんとなく人間には厄介な本能がいくつもありそうだなと感じられると思います。

それぞれの詳細について興味を持ったなら、本書で確認することをおすすめします。

以降は考えたことをつらつら書きます。

事実を集める大変さ

私はTwitterをしょっちゅう閲覧しています。私が見るTLでは、様々なニュースや意見が発せられ、リツイートされています。

本書では、それらの情報は分断や恐怖を煽り、ネガティブすぎるため、実際の統計データ、すなわちファクトにあたることが重要だと述べられています。

しかし、いざ実際はどうなっているのかを自分で調べようと思うと、なかなか重い腰が上がらないということに気づきました。特別に興味を持ったトピック以外、能動的に調べることはなかなかないんじゃないかと思っています。

それを思うと、日々ファクト(統計)を作っている人たち*1、それを分析している専門家には頭が下がります。

マスコミに期待しすぎてはいけない

日本各地や世界で何が起きているかを知らせてくれるのがマスコミです。テレビやSNSを見れば何が起きているのか大まかに掴むことができます。

私のTLではしばしばマスコミが批判されています。例えば、偏っているとか、犯人探しをしているとか、恐怖を煽っているとか、専門家から見るとトンチンカンなことを言っているとかですね。

本書では、マスコミは売れなければならないため、ネガティブな、インパクトのある、すなわち本能に訴える個別事象を取り上げがちになってしまうと指摘しています。

これはそのとおりだと思っていて、マスコミは情報の一つで、専門家の意見や、統計データを参照するとより正確な姿に近づけると思っています。

先程のマスコミへの批判はもっともですが、批判しても自分が気持ちいいだけでマスコミはすぐにそこまで大きく変わっていかないと思います。

本能に気づくための本書

本書では、ファクトフルネスでない10の本能があるから抑えていこうね、という内容になっています。

私が思うに、大事なのは本能で感じ取ったあとに、本書の内容を生かしてその判断や行動を修正していくことです。

ファクトフルネスとはなにかという知識があれば、事実を見誤らせる本能に気づきやすくなるでしょう。

例えは悪いかもしれませんが、ナンパの手順を知っていればそれに引っかかりにくくなることと同じです。

*1:最近の統計偽装には失望していますが……。

ブログを毎週書くコミュニティに参加して3ヶ月が経った #write_blog_every_week

週1回技術ブログを書こうという、#write_blog_every_week というコミュニティに参加して3ヶ月が経った。今日はその振り返りをしようと思う。

どんなコミュニティ?

主な活動はslackで行われいて、現在30人ほどが参加している。

ブログ記事を投稿するとslackに連携される。

サボっているとチームから追い出されてしまうというルールがある。

中心メンバーのよしたくさん作のサイトはこちら↓ write-blog-every-week.netlify.com

加入のきっかけ

私が加入したのは、コミュニティができて2ヶ月近くたってからだ。私自身も、その少し前から週1でブログを書く習慣を続けていた。何人かで一緒に始めていたのだが、いかんせん人数が少なすぎるという問題があった。

このままではいつ挫折するかわからない。そのような問題意識の中、毎週ブログを書いているこのコミュニティの存在を思い出した。自分を変えるには環境を変えるのが大事だ。知り合いもほとんどいなかったが飛び込んでみることにした。

実績

3ヶ月間、引き続き毎週ブログを書き続けている。はてなブログは継続期間を知らせてくれるが、30週間継続しているようだ。

良かったところ

  • 技術情報が入ってくる。 30人くらいが毎週ブログを書いているためいろいろなテーマの技術情報が入ってくる。細かいところまでは分からずとも、キーワードを頭の中にストックできる。

  • 読者数が増えた。 10人が19人になった。

  • 読書のペースが上がった。 1月だけで書籍レビューを3つ書いた。*1

課題

私個人の課題・改善点を挙げる。

  • 他の人のブログ記事を読んでいない。

一番課題だと感じていること。せっかくコミュニティに所属しているのだから、私なりにフィードバックしてメンバーのモチベーションになれたらと思っている。

また、「○○さんはこういう事柄に強い・関心がある」といったことをもう少し頭に入れておきたい。

  • 質を上げたい。

なんとなく、もっと質の高い記事を書きたいと思っているが、何をもって質を上げたと言えるかどうかもよくわかっていない状態である。

  • アクセスが伸びない。

月500PVくらい。最近は見ていない。

その他

昨日もくもく会に参加した。末広町のとらLabでの開催だった。駅近であり、ちょうどいい広さで非常に快適だった。10人前後でイベント開くなら有力な選択肢になると思う。

参加者の皆さまが買ってくださったお菓子をありがたくいただくだけの存在と化していた。次回があれば私も何か買っていきます。*2

*1:タブレットを買って電子書籍を読むようになったせいかも

*2:飲み物は持参してくるので意外と需要が小さそうだった

『アジャイルサムライ』はアジャイルの第1歩

アジャイルサムライ』を読了したのでレビューを書きます。

入門書としての3つの特色

アジャイルサムライは特に入門書と知っていて読んだわけではないのですが、アジャイル関連の入門書籍としてぴったりな理由が3つあります。

  • 過不足ない分量
  • カジュアルな語り口
    • 「マスター・センセイと熱心な弟子」という謎のコーナーがある
  • たくさんのわかりやすい図

ちなみに私が一番好きなのは荒ぶる四天王*1の図です。

毎週価値を届けよ

海外の書籍にありがちなのは、同じ主張を何度も繰り返すということです。『アジャイルサムライ』も例に漏れず、あることの重要性を繰り返しています。

それは、見出しに挙げたとおり、「毎週お客さんに価値を届けること」です。

実際、やろうとしたら大変

上記「毎週お客さんに価値を届ける」にはいくつか必要なことがありますが、特に私の印象に残ったのは、「成果責任を果たす」ことです。具体的には以下のことをやる必要があると述べられています。

  • 君は、仕事の質に責任を持たなきゃならない。
  • 君は、スケジュールを守らなきゃならない。
  • 君は、お客さんの期待をマネジメントしなきゃならない。
  • 君は、身銭を切るかのような覚悟でお客さんの資金を扱わなきゃならない。

文章にすると当たり前なような気がしますが、実際やろうとすると結構な覚悟が要りそうな印象があります。

カイゼン・ジャーニー』を読んだときも思ったのですが、読み物としては楽しくても、実際にやろうとなるとめちゃくちゃ大変だ……という感想を持ちました。

疑問……お客さんはだれ?

本書は非常に読みやすいですが、わからなかったところもあります。

例えば、本書では、建設会社で使うシステムの例が多く使われていました。この場合は、誰がお客さんかわかりやすいと思います。

一方、パッケージ製品など、お客さんがたくさんいる場合、本書でいう開発に参加する「お客さん」は誰なのか、ちょっとよくわかりませんでした。おそらく、それを売っていくであろう事業部なのだろうなとは思いましたが。

アプリケーション開発への参加を促すべき「お客さん」が誰かは、もう少し掘り下げられていても良かったなと思いました。*2

まとめ

現在私はアプリケーションの開発に従事していますが、その進め方を客観的に見つめ直す上で、本書は非常に役立ちました。

2011年に日本語訳の初版が発売されましたが、あまり古さを感じませんでした。

プロジェクトにより状況は様々でしょうが、どんな人でも面白く読めると思います。

最後に目次を挙げて終わりとします。

目次

※目次は以下のサイトを参照しました。

『アジャイルサムライ』の書影と主な目次が出てこないから自分で貼るよ - 角谷HTML化計画(2011-07-02)

*1:時間、予算、品質、スコープ

*2:プロジェクトにおいてお客さんが誰かというのはプロジェクト参加者が認識を揃えるべき重要事項です。