ラップのサイズ

gss_wrap() でメッセージをラップすると、メッセージのサイズが増加します。保護されたメッセージパケットは、転送プロトコルを通過できるぐらいのサイズである必要があります。したがって、GSS-API の gss_wrap_size_limit 関数を使用して、ラップしても転送プロトコルを通過できるメッセージの最大サイズを計算します。この最大サイズを超える場合、アプリケーションは gss_wrap() を呼び出す前にメッセージを分割できます。メッセージを実際にラップする前にはラップサイズの制限値をチェックするように習慣付けましょう。

サイズの増加量は次の 2 つの影響を受けます。

• メッセージをラップするためにどの QOP (保護品質) アルゴリズムを使用するか。GSS-API の実装によってデフォルトの QOP が異なるため、デフォルトの QOP を指定した場合でも、ラップされたメッセージのサイズは異なる可能性があります。図 1–12 に、この様子を示します。

  図 1–12 ラップのサイズ (QOP が異なる場合)

  
  

• 機密性を呼び出すかどうか。機密性を適用するかどうかに関わらず、gss_wrap() は転送されるメッセージに MIC を添付するため、メッセージのサイズは増加します。しかし、メッセージを暗号化すると (機密性を適用すると)、メッセージのサイズはさらに増加します。図 1–13 に、この様子を示します。

  図 1–13 ラップのサイズ (機密性がある場合とない場合)

  
  

次に、gss_wrap_size_limit() の形式を示します。

OM_uint32 gss_wrap_size_limit (
OM_uint32          *minor_status,
const gss_ctx_id_t context_handle,
int                conf_req_flag,
gss_qop_t          qop_req,
OM_uint32          req_output_size,
OM_uint32          *max_input_size)

minor_status

実際の機構から戻される状態コード。

context_handle

データが転送されるコンテキスト。

conf_req_flag

機密性サービス (暗号化) を要求するためのフラグ。0 以外の場合、機密性と整合性の両方を要求します。0 の場合、整合性サービスだけを要求します。

qop_req

要求する QOP (保護品質)。MIC を生成するときと暗号化を行うときに使用される暗号化アルゴリズムです。移植性のためには、アプリケーションは可能な限りデフォルトの QOP を指定するべきです。つまり、この引数に GSS_C_QOP_DEFAULT を設定します。デフォルト以外の QOP の指定については、付録 C 「OID の指定」 を参照してください。

req_output_size

指定した転送プロトコルが処理できるデータ片の最大サイズ (型は int)。この情報は、ユーザーが自ら提供する必要があります。つまり、GSS-API はプロトコルに依存しないため、どのプロトコルが使用されるのかを知る方法がありません。

max_input_size

関数から戻される値。つまり、ラップしたときに req_output_size を超えないような、ラップしていないメッセージの最大サイズ。

正常に終了した場合、gss_wrap_size_limit() は GSS_S_COMPLETE を戻します。指定した QOP が有効でなかった場合、gss_wrap_size_limit() は GSS_S_BAD_QOP を戻します。gss_wrap_size_limit() でオリジナルのメッセージの最大サイズを求める例 (機密性を使用する場合と使用しない場合の両方) については、call_server()を参照してください。

この機能は gss_wrap() を呼び出した時点でのシステムリソースの可用性に依存するため、この呼び出しが正常に終了したとしても、必ずしも、gss_wrap() が max_input_size 以下のバイトの長さを持つメッセージを保護できるとは保証できません。詳細は、gss_wrap_size_limit(3GSS) のマニュアルページを参照してください。