技術的余談

暗号技術

• 復号と復号化
  

  暗号は，第三者に内容を知られないようにする方法であり，暗号化はそのプロセスです．暗号化する前のメッセージは平文（plaintext）と呼ばれ，内容が分からないように平文を変換するプロセスが暗号化（encryption）です．暗号化されたメッセージが暗号文（cyphertext）であり，暗号文を平文に戻すプロセスが復号（decryption）です．

  復号は，「復号」自体がプロセスを表すため，状態を変える意味として「化」を付けるのは日本語として冗長です（「暗号する」とは言えないため「暗号化する」ですが，「復号する」と表現できる）．したがって，「復号化」という表現は誤りと言えます．

  暗号化に対してその対称性から無意識のうちに「復号化」が広く使われ，それが不自然に思われていないのも事実です (専門書などでは，「復号化」が使われることは稀ですが)．しかし，「暗号化」に対する正しい言葉は「復号」であり，「復号化」は使わない方が良いと思います．

• 秘密鍵で暗号化
  

  WEBサイト上の公開鍵暗号に関する解説で，以下のような記述が時々見られます．

  • 公開鍵で暗号化したものを秘密鍵で復号するのと同様に，秘密鍵で暗号化したものを公開鍵で復号できる．
  • 公開鍵暗号方式による署名は，メッセージダイジェストを秘密鍵で暗号化することで実現できる．
  
  

  これらの解説は誤りです．これらは RSA 暗号アルゴリズムを前提にしています．公開鍵と秘密鍵が対称的であり，鍵を「逆に使える」というのは RSA 暗号アルゴリズム固有の特徴であって，多くの公開鍵暗号方式はこのような性質を持ちません． RSA 暗号アルゴリズムを前提に，公開鍵暗号方式一般をこのように解説してしまうことは間違いです．公開鍵暗号の一般的な解説では，代表例として RSA 暗号が取りあげられるため (他のアルゴリズムが説明されることは少ない)，このような誤解が生まれるのだと思われます．

  なお，「秘密鍵で暗号化」と言うのは，公開鍵を持つ誰でもが復号できるという意味でそもそも「暗号化」とは言い難いと言えます (データを隠蔽する意味での暗号化ではない)．（→ 公開鍵暗号とディジタル署名）

• 公開鍵暗号方式
  

  公開鍵暗号方式というと，データの暗号化・復号機能のみ想定されがちです．これは，公開鍵暗号方式の一面しか見ていないことになります

  技術的には単に公開鍵暗号方式と言った場合，広義の意味では秘密鍵と公開鍵のペアを用いた方式 (Public Key Cryptography) であり，暗号化・復号，ディジタル署名，鍵交換などが実現できる方式を指します． 狭義の意味では秘密鍵と公開鍵を用いたデータの暗号化方式 (Public Key Encryption) で共通鍵暗号方式に対比される方式です(暗号化・復号機能のみを対象)．

  公開鍵暗号方式では，公開鍵と秘密鍵は数学的なある関係 (一方向性)を持っており，

  • 秘密鍵から公開鍵は容易に求められる．
  • 公開鍵から秘密鍵を求めるのは困難である．

  が成り立つものです．

  この秘密鍵と公開鍵の数学的な関係を用いると次の機能が実現できます．しかし，公開鍵暗号アルゴリズムにより，実現できる機能は異なります．

  • 鍵交換
    自分の秘密鍵と相手の公開鍵を使ってある演算を行うと相互に同じデータ（鍵）が作れる． これにより，通信回線を介して安全に鍵の共有が行える．
  • 暗号化・復号
    公開鍵でデータを暗号化し，秘密鍵で復号できる．（暗号化は誰でもできるが，秘密鍵を持つ者のみが復号できる．秘密鍵を持つ特定の相手に向けて秘密裏に情報を伝達できる．)
  • ディジタル署名
    秘密鍵を使い文書にディジタル署名が添付できる．確かに本人が作成した文書であることを証明できる(自分が作成したものでないとの否認もできない)．ディジタル署名の確認(検証)は，秘密鍵に対応した公開鍵で誰でも行える．
• 暗号の危殆化
  

  現在広く使われている暗号の安全性は，計算量的安全性に基づいています．すなわち，攻撃者が利用できる計算機資源を全て費やしたとしても暗号を破るまでに十分な時間がかかるということです．この状況は，計算機能力の向上や暗号の解析手段の進歩などにより変わってきます．

  暗号の危殆化(きたいか)とは，当初予定していたよりも低いコストで暗号を破られる可能性があり，暗号の安全性に問題が生じる状況を指します． 暗号の十分な安全性の目安は，「その時点での世界最速のコンピュータ」と「最新の理論とプログラム」を使っても解読に 1 年掛かることと言われています．但し，これは国家レベルの攻撃者や重要情報に対してのものです．一般的な個人の暗号化情報に対しては，そのような膨大な時間とコストをかけて暗号を解読するメリットがなく，また一般的な攻撃者にそのような計算機資源もなく，あえて解読を試みるようなことはしないと考えられます． このような意味では，暗号の危殆化の程度は，保護対象とする情報の重要性に依存しています．

  暗号の危殆化は，その利用形態や情報の重要性などの実態を十分に把握した上で，対処方法を判断する必要があります．一般的な対策は，暗号の鍵長を増やしたり，暗号アルゴリズムをより安全性の高いもの変更する方法ですが，システム内のこのような変更が容易かどうかは，システムが暗号アルゴリズムの変更を考慮に入れて設計されているかによります．暗号システムには，寿命があることを想定して設計する必要があります．

• 暗号の解読
  

  短い暗号文(らしきもの)を示して暗号を解読して下さいという質問をネット上でしばしば見かけますが，そもそも暗号というのは，第三者には知られずに通信相手にのみ秘密裡に情報を伝えるための手段です．自分宛に送られてきたのなら，送った相手にその暗号の解き方 (解読鍵など) を別途教えてもらうのが筋です．相手も知らせたい情報が本当にあるのなら，教えてくれるでしょう．そうでないなら，パズルやなぞなぞの類であり，興味があれば解くのを楽しめば良いし，興味がないなら放っておくのが良いということになります．

  このような暗号文を解読したい場合には，次のような点に留意する必要があります．まず，短い暗号文1つのみでの解読は，一般に(原理的に)不可能な場合が多いと言えます．暗号化の方法はそれこそ無数にあり，その方法の幾つかで意味ありげな情報に復号できたとしても，その中でどれが正解かを判断する手段がありません． これを推定して暗号文を解読するには，

  • 誰から誰宛へのどのような状況での暗号文か
  • 相手との関係は（友達，恋人，家族，仕事仲間など）
  • 送信相手の知識レベル

  などの情報が必要です． このような情報を提供され専門家でない個人が作った暗号であれば，過去の古典的な暗号方式などを順番に試していけば解読できる可能性は高いとは言えます．

• ZIP ファイルの暗号化
  

  ZIP ファイルは，複数のファイルを1つのファイルとしてまとめて取り扱うアーカイブファイルであり，Windows でも標準でサポートされているなど広く普及しています．ZIP には，パスワードベースの共通鍵暗号がサポートされており，ファイル内容の暗号化も可能です．

  この ZIP ファイルの暗号化に関しては，次のような注意が必要です．

  • ZIPファイルの暗号化では，ファイル名が隠蔽されません．これは ZIPファイルの仕様です．パスワードを付けて圧縮した暗号化ファイルでは，暗号化されるのはファイルの中身だけです．その中にどのようなファイル名のファイルがあるかは知られてしまいます． ZIP ファイルの暗号化を行う際は，ファイル名に重要な情報が入らないように留意しておく必要があります．
  • ZIP のパスワードは総当たりでかなり高速に解析できます (解析ツールも存在する)．オンラインでのパスワード入力のように試行回数制限もないため，8文字未満のパスワードはかなり危険です．
  • 暗号化た ZIPファイルをメールで送り，しばらくして別メールで暗号化に使用したパスワードを送ることがしばしば行われます．パスワードをメールで送ることは，セキュリティ上大きな問題です． 誤送信防止対策には多少役立つでしょうが，セキュリティ対策としては問題で，企業等における重要情報の送信にこのような安易な方法 (暗号化 ZIPファイルによる送信も含め) を採るべきではないでしょう．

コンピュータ技術

• 2038年問題
  

  一部のOSやC言語では，時刻表現としてUNIX時間 (1970年1月1日0時0分0秒からの経過秒数) を使用しています．この経過秒数を表わす型は time_t型ですが，型の範囲や精度は実装依存です．伝統的な実装ではtime_t型はintであり，符号つき32ビットです．このため最大値は (2^31 - 1) であり，2，147，483,647秒（≒ 68年）迄しか扱えません．これを前提として作成されたプログラムは，2038年1月19日3時14分7秒でこの値がオーバーフローし負と扱われるため，正しい時刻を前提としたコードは誤作動する可能性があります．

  この time_t型を64ビットなどに変更するだけならば簡単ですが，実際にはアプリケーションプログラムにおける時刻の扱い全てが正しいか否かを検証する必要があります．例えば，データ構造中で32ビット固定長として時刻が割り当てられているような場合には問題が発生します．

  最近の新しいOSやプログラムならば対応は採られているでしょうが，2038年時点でどれ位の未対策なコンピュータやプログラムが存在するかは分かりません．

• 2進接頭辞
  

  k(キロ)，M(メガ)，G(ギガ) などは，国際単位系(SI)で規定されている SI接頭辞と呼ばれる10進の倍量・分量単位を作成するためのものです．

  コンピュータの世界では，メモリやアドレスの容量を示す場合，K(大文字)，M，G などは 2進接頭辞であり，2のべき乗を表すことが一般的です． K は 2^10 (=1024) を表すなどです．

  この表記は，国際規格で認められたものではなく慣習的です．また，小文字の「k」は10^3 で，大文字の「K」は 2^10 と区別はできますが，「M」や「G」などは区別できず曖昧な表記です． このため，IEC(国際電気標準会議) は SI接頭辞と区別できる次のような 2進接頭辞を導入しています．
  　Ki (2^10), Mi (2^20), Gi (2^30)，Ti (2^40) など
  これらは，キビ，メビ，ギビ，テビなどと呼ばれますが，現状あまり普及していないようです．曖昧性を無くすためこれらを使うことが推奨されます（KiB：キビバイトなど）．

  
  
• 2進数の10進桁数
  

  暗号の鍵長などビット数で表すことが多いですが，このビット数が10進数では何桁に相当するか換算したい時があります．

  これは，次のように計算できます．2進数で n 桁の数 x は 2^(n - 1) ≦ x < 2^n で表わせます．この式は底が 2 の対数をとると n - 1 ≤ log2(x) < n となります． これに log2(x) = log10(x) / log10(2) を代入すると
  　　log10(2)×(n-1) ≤ log10(x) < log10(2)×n
  になります．

  これより，ビット数 n の2進の数値の10進での桁数は以下の範囲になります．

  　0.301×(n-1) ～ 0.301×n（小数点以下切上げ）

その他

• 長音記号
  

  技術文書における長音記号の使い方に関して，JIS Z8301では当初次のように規定していました．

  • 3音以上の単語には，語尾に長音記号を付けない（ブラウザ，プリンタ，ドライバ，フォルダなど）．
  • 2音以下の単語には，語尾に長音記号を付ける（キー、バー、エラーなど）．

  しかし，その後改正された JIS Z8301 では，「外来語の表記は，主として“外来語の表記（1991.6.28 内閣告示第2号）”による」として内閣告示に準拠することが明記されました．

  この「外来語の表記」では，

  • 原語（特に英語）のつづりの終わりの -er，-or，-ar などに当たる語は，原則としてア列の長音とし長音記号「ー」を用いて書き表す．ただし，慣用に応じて「ー」を省くことができる．

  となっています．これは，両論併記とも言える扱いであり，実際に電気・電子，情報・通信および機械分野では一部の語で語尾の長音記号を省く慣例が残っています． 現状は「原則はあるが，慣用的に使われている表記も許される」です．いずれにしろ，1つの文書の中では表記を統一することが重要です．