標準的な暗号のフォーマット(書式)

以前、暗号自体は米国標準のAES暗号であるが、出力ファイルは独自形式のファイルを出力するプログラムを作った。

しかし、よくよく調べてみると、暗号化ファイルにも、『標準』が存在した。
問題は、基本形式やら、拡張形式やら、アルゴリズムやらでドキュメントが多岐に渡って分散しており、しかも全部、英文な事だ。
出来る事なら、標準化されているのであれば、標準の形式（PKCS#7／CMS）で吐きたい。

そこで、とりあえず、解ったところまでまとめてみる。

■Cryptographic Message Syntax（CMS）
━━━━━━━━━━━━━━━━━━━━
暗号の標準的なフォーマットとしては、このCMSで定義される。
仕様書は、度々改訂されており、気に留めておくのは、以下の版だろうか？

RFC-2315　…(1998. 3) このヴァージョンは、"PKCS#7"に相当する。
RFC-5652　…(2009. 9) 現在の最新版？。PKCS#7の上位互換。

これによると、PKCS#7/CMS形式では、以下の５つに対応しているらしい。

(1) Signed-data　（電子署名）

(2) Enveloped-Data　（封筒化データ）
　これは、主に以下の情報等で構成される。
　・共通鍵方式で暗号化された、元データ
　・受信者のデータ（人数分）
　　※この受信者情報の中には、受信者の公開鍵で暗号化された、共通鍵等も含まれる。

(3) Digested-Data　（ハッシュデータ）

(4) Encrypted-Data　（暗号データ）
　共通鍵方式で暗号化されたデータのみ。
　従い、共通鍵は含まないので、別途に鍵を用意しなければならない。
　例えば、パスワードなど。

(5) Authenticated-Data　（認証データ）
　証明書

とりあえず、暗号データだけを入れたいのであれば、(4)のEncrypted-Dataだろうか？
問題は、暗号アルゴリズムを何を使うかとか、ハッシュアルゴリズムは何を使うとか『規定されてない』ので、使うアルゴリズムの「標準類」をRFCから探さないといけないわけです。
(2) Enveloped-Dataは、これを作るのはややこしいと思う。受信者の公開鍵を入手しないといけないし。
（でも、受信者が限られているのであれば、この形式のデータをやり取りするほうが絶対に良いと思う。）

そして、基本フォーマットは、"ASN.1"という規格らしい。
また、英文のドキュメントを読まないといけない訳だ。
しかも、これはデータの記述法を定義する規格で、
更に、これをエンコードする規格が幾つかあるそうで。
・「基本」形式、　… バイナリー(基本)。
・「mime」形式、　… e-mailで送信する為の、AscII codeで表現されたデータ。
・etc...
それぞれに、英文の標準類がある・・・。

日本人に対するイジメカ？

■Cryptographic Message Syntax Algorithms
━━━━━━━━━━━━━━━━━━━━
これは、CMSに使用可能なアルゴリズムが定義されている。
RFC-3370

これで定義されるのは、
(1) ハッシュ関数
　・SHA-1
　・MD5
(2) 署名アルゴリズム
　・DSA
　・RSA
(3) 暗号アルゴリズム
　・3-DES-CBC
　・RC2-CBC
等など。

AESや、SHA-2は、ここでは定義されない。
これらは、拡張規格なので、また別に標準類が存在する。

■Cryptographic Message Syntax　拡張規格？？？
━━━━━━━━━━━━━━━━━━━━

RFC-3565 … AES with CMS　　／　CMS形式で、AES暗号を使う為の標準類
RFC-5754 … SHA-2 with CMS　／　CMS形式で、SHA-2ハッシュを使う為の標準類

流石に、英文読むの飽きてきましたよ？？？