暗号です。
通信の秘匿がサンダース校戦での勝因。
まあ、携帯メール使っただけなんですけどね。by武部沙織
個人情報がどうのこうのと世知辛い昨今、アンケート結果ひとつWebサーバーにアップするにしても、住所とか氏名があるなら漏洩の対策を考えないといかんわけですよ。
iPhoneとサーバ間とのやりとり自体は、httpsを使えば勝手に暗号化してくれるんだけど、問題は受け取った情報をサーバー側に保存する場合っす。
誰でも触れるところに保存するのは論外として、そうでなくても、あの手この手で取り出そうとする個人情報大好きっ子ちゃんはいるわけでして、実際に漏洩した場合に、暗号化してませんでした～テヘペロじゃあ、言い訳がたたんわけですな。
でまあ、そういう場合サーバー側が暗号化の面倒をみてくれる場合がほとんどなんですが…
諸所の事情でファイルの保存しかできない中継用のサーバーを立てて、そこにファイルを置かざるを得ない場合、iPhone側で暗号化しておく必要が出てくるわけです。
これに加えて、サーバー経由で情報をやりとりしようって場合、やりとりする相手はiPhoneじゃない場合が多いわけでして…
結果、暗号化アルゴリズムには、独自のものじゃなく、Win32やPHPやJavaといったメジャーどころでも扱えるものを選ぶ必要がでてきます。
暗号化アルゴリズムてのは、例えば
文章を暗号化するさいには、各文字ごとにアルファベットの順序を3文字ずらした文字を使う
といったように、暗号化するさいの手法を指します。
ここで挙げた暗号化アルゴリズムは、シーザー暗号という（ブートキャンプで紹介したの覚えてるかな～）んですが、この場合、各文字は3文字ずつずれて、それぞれ
ABCDEFGHIJKLMNOPQRSTUVWXYZ
↓
DEFGHIJKLMNOPQRSTUVWXYZABC
となり、例えば
"HELLO CIPHER"
を暗号文にすると
"KHOOR FLSKHU"
となって、ぱっとみ意味不明の文章、いわゆる暗号文になるわけです。
ちなみに暗号文に対して、暗号化される前の文を平文といいます。
え、じゃあ「暗号化アルゴリズム公開しちゃったらまずいじゃん」と思った人、大正解。まずいんですよ。
で、さすがにシーザーも、こりゃ使えね～って思ったのか軍事には使用せず、私信に用いていたそうです、Wikiによると。てか単なる遊びじゃね？2ちゃんねらーがよくやる縦読みにすると別の文章が浮き上がるたぐいの、シーザー元祖VIPPER？
まあ、そんなこんなで、使ってることがバレたら一発アウトの欠陥暗号化アルゴリズム・シーザー暗号なわけですが、だがしかし、現代の最新最強の暗号化アルゴリズムに通じる基本がすでに組み込まれているんですな。
注目すべきは「アルファベットを何文字分ずらすか」という情報っす。
先に示したシーザー暗号の「3文字ずらす」て部分を「K文字ずらす」に変えるわけですよ。
で、このKを、暗号をやり取りする者同士で決めることで、シーザー暗号化アルゴリズムを使っているとわかっても、Kがわからなければ暗号は解かれないようになるわけです。
このKのことを業界用語でキー（鍵）といいます。
え、でも「アルファベット26文字なんて、最大25種類のずらし量しか指定できないんだから、1～25のずらし量を総当りで試せば解読できるんじゃ」と思った人、大正解。解読できるんですよ。総当たり攻撃（Brute-force attack）といいます。
なんですが、このKの取り得る値の範囲を1億とか1兆、1京とかに広げられて、その値ごとに暗号文が異なるようなら、さすがに解読側もヨイショがいるわけでして、そうなると暗号化アルゴリズムが公開されても、キーがバレなければ暗号文は解かれないって理屈も通ることになるわけです。
そのためにキーの値は、ズラす量にとどまらず、平文とXORをとったりとか、暗号文を作るための、いろいろな計算式のパラメタとして使われます。
で、どれだけキーなしで暗号文から平文を再現できないようになっているか、また、どれだけキー自体が暗号文から再現できないかを競い合ってるのが、現代の暗号化アルゴリズムってことになります。
あと、どれだけ軽快（少ないメモリ、遅いマシンでも使える）に暗号・平文化できるかとかも競ってる。
ちなみに、キーを生成する種となるのが、いわゆる暗号化のさいにユーザーが入力するパスワードです。なかにはパスワードをそのままキーとして使う暗号化アルゴリズムもあるかもしれんけど、普通はワンクッションおきます。
アルゴリズムではなくキーを秘匿する。
これが現代の暗号の基本みたいっす。
なので、基本、暗号化アルゴリズム自体はバンバン公開されてます。
なかには隠してたけど漏洩したってのもあるみたいだけど…
そもそもアルゴリズムを隠したくても、アプリやライブラリ、フレームワークといったバイナリコードは公開しないと誰も使えないわけだから、暗号化された情報に億といった金が絡めば、犯罪行為だろうがなんだろうがリバースエンジニアリングされて解析されるだろうし、アルゴリズムを隠すことにはあんまり効果は期待できないでしょうな～。むしろ公開することで、第三者からアルゴリズムの欠陥の指摘なんかも期待できるんじゃないかと思われ。
まあ、それなりの数学者が作るアルゴリズムてのが前提の話だけどね。
一般プログラマが作る独自の暗号化アルゴリズムなんて、穴だらけで、アルゴリズム公開しちゃうと、簡単に暗号文からキーなしで平文が取り出されるのがオチでしょう。その場合は隠すしかないでしょうな。
というわけで、よほどの天才の自負でもない限り、独自の暗号化アルゴリズムなんかは使わずにメジャーな暗号化アルゴリズムに頼りましょう。
で、こういった場合に利用するのが
CCCrypt
というAPIでして、こいつを使うと
DES、トリプルDES、AES、CAST、RC4、RC2、Blowfish
といったメジャーな暗号化アルゴリズムでバイト列を暗号化できます。
興味がわいた人は上にあげた名前でググるといいでしょう。
てことで、次回、USA標準のAESで平文を暗号化してみる！
通信の秘匿がサンダース校戦での勝因。
まあ、携帯メール使っただけなんですけどね。by武部沙織
個人情報がどうのこうのと世知辛い昨今、アンケート結果ひとつWebサーバーにアップするにしても、住所とか氏名があるなら漏洩の対策を考えないといかんわけですよ。
iPhoneとサーバ間とのやりとり自体は、httpsを使えば勝手に暗号化してくれるんだけど、問題は受け取った情報をサーバー側に保存する場合っす。
誰でも触れるところに保存するのは論外として、そうでなくても、あの手この手で取り出そうとする個人情報大好きっ子ちゃんはいるわけでして、実際に漏洩した場合に、暗号化してませんでした～テヘペロじゃあ、言い訳がたたんわけですな。
でまあ、そういう場合サーバー側が暗号化の面倒をみてくれる場合がほとんどなんですが…
諸所の事情でファイルの保存しかできない中継用のサーバーを立てて、そこにファイルを置かざるを得ない場合、iPhone側で暗号化しておく必要が出てくるわけです。
これに加えて、サーバー経由で情報をやりとりしようって場合、やりとりする相手はiPhoneじゃない場合が多いわけでして…
結果、暗号化アルゴリズムには、独自のものじゃなく、Win32やPHPやJavaといったメジャーどころでも扱えるものを選ぶ必要がでてきます。
暗号化アルゴリズムてのは、例えば
文章を暗号化するさいには、各文字ごとにアルファベットの順序を3文字ずらした文字を使う
といったように、暗号化するさいの手法を指します。
ここで挙げた暗号化アルゴリズムは、シーザー暗号という（ブートキャンプで紹介したの覚えてるかな～）んですが、この場合、各文字は3文字ずつずれて、それぞれ
ABCDEFGHIJKLMNOPQRSTUVWXYZ
↓
DEFGHIJKLMNOPQRSTUVWXYZABC
となり、例えば
"HELLO CIPHER"
を暗号文にすると
"KHOOR FLSKHU"
となって、ぱっとみ意味不明の文章、いわゆる暗号文になるわけです。
ちなみに暗号文に対して、暗号化される前の文を平文といいます。
え、じゃあ「暗号化アルゴリズム公開しちゃったらまずいじゃん」と思った人、大正解。まずいんですよ。
で、さすがにシーザーも、こりゃ使えね～って思ったのか軍事には使用せず、私信に用いていたそうです、Wikiによると。てか単なる遊びじゃね？2ちゃんねらーがよくやる縦読みにすると別の文章が浮き上がるたぐいの、シーザー元祖VIPPER？
まあ、そんなこんなで、使ってることがバレたら一発アウトの欠陥暗号化アルゴリズム・シーザー暗号なわけですが、だがしかし、現代の最新最強の暗号化アルゴリズムに通じる基本がすでに組み込まれているんですな。
注目すべきは「アルファベットを何文字分ずらすか」という情報っす。
先に示したシーザー暗号の「3文字ずらす」て部分を「K文字ずらす」に変えるわけですよ。
で、このKを、暗号をやり取りする者同士で決めることで、シーザー暗号化アルゴリズムを使っているとわかっても、Kがわからなければ暗号は解かれないようになるわけです。
このKのことを業界用語でキー（鍵）といいます。
え、でも「アルファベット26文字なんて、最大25種類のずらし量しか指定できないんだから、1～25のずらし量を総当りで試せば解読できるんじゃ」と思った人、大正解。解読できるんですよ。総当たり攻撃（Brute-force attack）といいます。
なんですが、このKの取り得る値の範囲を1億とか1兆、1京とかに広げられて、その値ごとに暗号文が異なるようなら、さすがに解読側もヨイショがいるわけでして、そうなると暗号化アルゴリズムが公開されても、キーがバレなければ暗号文は解かれないって理屈も通ることになるわけです。
そのためにキーの値は、ズラす量にとどまらず、平文とXORをとったりとか、暗号文を作るための、いろいろな計算式のパラメタとして使われます。
で、どれだけキーなしで暗号文から平文を再現できないようになっているか、また、どれだけキー自体が暗号文から再現できないかを競い合ってるのが、現代の暗号化アルゴリズムってことになります。
あと、どれだけ軽快（少ないメモリ、遅いマシンでも使える）に暗号・平文化できるかとかも競ってる。
ちなみに、キーを生成する種となるのが、いわゆる暗号化のさいにユーザーが入力するパスワードです。なかにはパスワードをそのままキーとして使う暗号化アルゴリズムもあるかもしれんけど、普通はワンクッションおきます。
アルゴリズムではなくキーを秘匿する。
これが現代の暗号の基本みたいっす。
なので、基本、暗号化アルゴリズム自体はバンバン公開されてます。
なかには隠してたけど漏洩したってのもあるみたいだけど…
そもそもアルゴリズムを隠したくても、アプリやライブラリ、フレームワークといったバイナリコードは公開しないと誰も使えないわけだから、暗号化された情報に億といった金が絡めば、犯罪行為だろうがなんだろうがリバースエンジニアリングされて解析されるだろうし、アルゴリズムを隠すことにはあんまり効果は期待できないでしょうな～。むしろ公開することで、第三者からアルゴリズムの欠陥の指摘なんかも期待できるんじゃないかと思われ。
まあ、それなりの数学者が作るアルゴリズムてのが前提の話だけどね。
一般プログラマが作る独自の暗号化アルゴリズムなんて、穴だらけで、アルゴリズム公開しちゃうと、簡単に暗号文からキーなしで平文が取り出されるのがオチでしょう。その場合は隠すしかないでしょうな。
というわけで、よほどの天才の自負でもない限り、独自の暗号化アルゴリズムなんかは使わずにメジャーな暗号化アルゴリズムに頼りましょう。
で、こういった場合に利用するのが
CCCrypt
というAPIでして、こいつを使うと
DES、トリプルDES、AES、CAST、RC4、RC2、Blowfish
といったメジャーな暗号化アルゴリズムでバイト列を暗号化できます。
興味がわいた人は上にあげた名前でググるといいでしょう。
てことで、次回、USA標準のAESで平文を暗号化してみる！
