RFC 7253 - The OCB Authenticated-Encryption Algorithm 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7253
タイトル : RFC 7253 - OCB Authenticated-Encryption Algorithm
翻訳編集 : 自動生成

[要約] RFC 7253は、OCB (Offset Codebook Mode) 認証付き暗号化アルゴリズムに関する文書です。このアルゴリズムは、データの機密性と真正性を同時に保証することを目的としています。高速で効率的な処理が可能であり、特にリアルタイム通信やリソースが限られた環境での利用に適しています。OCBは、暗号化と認証を一度に行うことで、従来の2段階プロセスよりも高速に動作します。関連するRFCにはRFC 7252（Constrained Application Protocol (CoAP)）などがあり、セキュリティが重要視される様々なプロトコルやアプリケーションでの利用が想定されています。

Internet Research Task Force (IRTF)                           T. Krovetz
Request for Comments: 7253                              Sacramento State
Category: Informational                                       P. Rogaway
ISSN: 2070-1721                                                 UC Davis
                                                                May 2014

The OCB Authenticated-Encryption Algorithm

OCB Authenticated-Encryption Algorithm

Abstract

概要

This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides confidentiality and authenticity for plaintexts and authenticity for associated data. This document is a product of the Crypto Forum Research Group (CFRG).

このドキュメントでは、平文の機密性と信頼性、および関連データの信頼性を提供する共有キーブロック暗号ベースの暗号化スキームであるOCBを指定しています。このドキュメントは、Crypto Forum Research Group（CFRG）の製品です。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Crypto Forum Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

この文書は、Internet Research Task Force（IRTF）の製品です。 IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適さない可能性があります。このRFCは、インターネット研究タスクフォース（IRTF）の暗号フォーラム研究グループの合意を表します。 IRSGによる公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7253.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7253で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

   1. Introduction ....................................................2
   2. Notation and Basic Operations ...................................4
   3. OCB Global Parameters ...........................................5
      3.1. Named OCB Parameter Sets and RFC 5116 Constants ............6
   4. OCB Algorithms ..................................................6
      4.1. Processing Associated Data: HASH ...........................6
      4.2. Encryption: OCB-ENCRYPT ....................................8
      4.3. Decryption: OCB-DECRYPT ....................................9
   5. Security Considerations ........................................11
      5.1. Nonce Requirements ........................................12
   6. IANA Considerations ............................................13
   7. Acknowledgements ...............................................13
   8. References .....................................................14
      8.1. Normative References ......................................14
      8.2. Informative References ....................................14
   Appendix A.  Sample Results .......................................15

1. Introduction

1. はじめに

Schemes for authenticated encryption (AE) simultaneously provide for confidentiality and authentication. While this goal would traditionally be achieved by melding separate encryption and authentication mechanisms, each using its own key, integrated AE schemes intertwine what is needed for confidentiality and what is needed for authenticity. By conceptualizing AE as a single cryptographic goal, AE schemes are less likely to be misused than conventional encryption schemes. Also, integrated AE schemes can be significantly faster than what one sees from composing separate confidentiality and authenticity means.

認証済み暗号化（AE）のスキームは、機密性と認証を同時に提供します。この目標は従来、個別の暗号化メカニズムと認証メカニズムを融合することによって達成されていましたが、それぞれ独自のキーを使用していましたが、統合AEスキームは、機密性に必要なものと信頼性に必要なものを絡み合わせています。 AEを単一の暗号化目標として概念化することにより、AEスキームは、従来の暗号化スキームよりも誤用される可能性が低くなります。また、統合されたAEスキームは、個別の機密性と信頼性の手段を構成することから見られるものよりも大幅に高速になる可能性があります。

When an AE scheme allows for the authentication of unencrypted data at the same time that a plaintext is being encrypted and authenticated, the scheme is an authenticated encryption with associated data (AEAD) scheme. Associated data can be useful when, for example, a network packet has unencrypted routing information and an encrypted payload.

プレーンテキストが暗号化および認証されると同時にAEスキームが非暗号化データの認証を許可する場合、そのスキームは関連データ付き認証暗号化（AEAD）スキームです。関連データは、たとえば、ネットワークパケットに暗号化されていないルーティング情報と暗号化されたペイロードがある場合に役立ちます。

OCB is an AEAD scheme that depends on a blockcipher. This document fully defines OCB encryption and decryption except for the choice of the blockcipher and the length of authentication tag that is part of the ciphertext. The blockcipher must have a 128-bit blocksize. Each choice of blockcipher and tag length specifies a different variant of OCB. Several AES-based variants are defined in Section 3.1.

OCBは、ブロック暗号に依存するAEADスキームです。このドキュメントでは、ブロック暗号の選択と暗号文の一部である認証タグの長さを除いて、OCBの暗号化と復号化を完全に定義しています。ブロック暗号には128ビットのブロックサイズが必要です。ブロック暗号とタグの長さを選択するたびに、OCBの異なるバリアントが指定されます。いくつかのAESベースのバリアントはセクション3.1で定義されています。

OCB encryption and decryption employ a nonce N, which must be distinct for each invocation of the OCB encryption operation. OCB requires the associated data A to be specified when one encrypts or decrypts, but it may be zero-length. The plaintext P and the associated data A can have any bitlength. The ciphertext C one gets by encrypting P in the presence of A consists of a ciphertext-core having the same length as P, plus an authentication tag. One can view the resulting ciphertext as either the pair (ciphertext-core, tag) or their concatenation (ciphertext-core || tag), the difference being purely how one assembles and parses ciphertexts. This document uses concatenation.

OCBの暗号化と復号化ではナンスNを使用します。これは、OCB暗号化操作の呼び出しごとに異なる必要があります。 OCBでは、暗号化または復号化するときに関連データAを指定する必要がありますが、長さがゼロの場合もあります。平文Pおよび関連データAは、任意のビット長を持つことができます。 Aの存在下でPを暗号化することによって得られる暗号文Cは、Pと同じ長さの暗号文コアと認証タグで構成されます。結果の暗号文は、ペア（ciphertext-core、tag）またはそれらの連結（ciphertext-core || tag）として表示できます。違いは、純粋に暗号文をアセンブルおよび解析する方法です。このドキュメントでは連結を使用しています。

OCB encryption protects the confidentiality of P and the authenticity of A, N, and P. It does this using, on average, about a + m + 1.02 blockcipher calls, where a is the blocklength of A, m is the blocklength of P, and the nonce N is implemented as a counter (if N is random, then OCB uses a + m + 2 blockcipher calls). If A is fixed during a session, then, after preprocessing, there is effectively no cost to having A authenticated on subsequent encryptions, and the mode will average m + 1.02 blockcipher calls. OCB requires a single key K for the underlying blockcipher, and all blockcipher calls are keyed by K. OCB is online. In particular, one need not know the length of A or P to proceed with encryption, nor need one know the length of A or C to proceed with decryption. OCB is parallelizable: the bulk of its blockcipher calls can be performed simultaneously. Computational work beyond blockcipher calls consists of a small and fixed number of logical operations per call. OCB enjoys provable security: the mode of operation is secure assuming that the underlying blockcipher is secure. As with most modes of operation, security degrades as the number of blocks processed gets large (see Section 5 for details).

OCB暗号化は、Pの機密性とA、N、およびPの信頼性を保護します。これは、平均で、約a + m + 1.02ブロック暗号呼び出しを使用して行われます。ここで、aはAのブロック長、mはPのブロック長です。ナンスNはカウンターとして実装されます（Nがランダムの場合、OCBは+ m + 2ブロック暗号呼び出しを使用します）。 Aがセッション中に固定されている場合、前処理の後、後続の暗号化でAを認証してもコストは事実上なく、モードは平均m + 1.02ブロック暗号呼び出しになります。 OCBは、基礎となるブロック暗号に単一のキーKを必要とし、すべてのブロック暗号呼び出しはKによってキー設定されます。OCBはオンラインです。特に、暗号化を続行するためにAまたはPの長さを知る必要はなく、復号化を続行するためにAまたはCの長さを知る必要もありません。 OCBは並列化可能です。そのブロック暗号呼び出しの大部分は同時に実行できます。ブロック暗号呼び出しを超えた計算作業は、呼び出しごとの少数の固定数の論理演算で構成されます。 OCBは証明可能なセキュリティを備えています。基盤となるブロック暗号が安全であると想定して、動作モードは安全です。ほとんどの操作モードと同様に、処理されるブロックの数が多くなるとセキュリティが低下します（詳細はセクション5を参照）。

For reasons of generality, OCB is defined to operate on arbitrary bitstrings. But for reasons of simplicity and efficiency, most implementations will assume that strings operated on are bytestrings (i.e., strings that are a multiple of 8 bits). To promote interoperability, implementations of OCB that communicate with implementations of unknown capabilities should restrict all provided values (nonces, tags, plaintexts, ciphertexts, and associated data) to bytestrings.

一般性の理由から、OCBは任意のビット文字列を操作するように定義されています。しかし、単純さと効率の理由から、ほとんどの実装では、操作される文字列はバイト文字列（つまり、8ビットの倍数である文字列）であると想定します。相互運用性を促進するために、不明な機能の実装と通信するOCBの実装は、提供されるすべての値（ノンス、タグ、プレーンテキスト、暗号文、および関連データ）をバイト文字列に制限する必要があります。

The version of OCB defined in this document is a refinement of two prior schemes. The original OCB version was published in 2001 [OCB1] and was listed as an optional component in IEEE 802.11i. A second version was published in 2004 [OCB2] and is specified in ISO 19772. The scheme described here is called OCB3 in the 2011 paper describing the mode [OCB3]; it shall be referred to simply as OCB throughout this document. The only difference between the algorithm of this RFC and that of the [OCB3] paper is that the tag length is now encoded into the internally formatted nonce. See [OCB3] for complete references, timing information, and a discussion of the differences between the algorithms. OCB was initially the acronym for Offset Codebook but is now the algorithm's full name.

このドキュメントで定義されているOCBのバージョンは、2つの従来のスキームを改良したものです。オリジナルのOCBバージョンは2001年に公開され[OCB1]、IEEE 802.11iのオプションコンポーネントとしてリストされました。 2番目のバージョンは2004年に公開され[OCB2]、ISO 19772で指定されています。ここで説明されているスキームは、モード[OCB3]を説明する2011年の論文ではOCB3と呼ばれています。このドキュメントでは、これを単にOCBと呼びます。このRFCのアルゴリズムと[OCB3]論文のアルゴリズムの唯一の違いは、タグの長さが内部的にフォーマットされたナンスにエンコードされることです。完全なリファレンス、タイミング情報、およびアルゴリズム間の違いの説明については、[OCB3]を参照してください。 OCBは当初、Offset Codebookの頭字語でしたが、現在はアルゴリズムの正式名称です。

OCB has received years of in-depth analysis previous to its submission to the CFRG and has been under review by the members of the CFRG for over a year. It is the consensus of the CFRG that the security mechanisms provided by the OCB AEAD algorithm described in this document are suitable for use in providing confidentiality and authentication.

OCBは、CFRGへの提出前に何年にもわたる詳細な分析を受けており、1年以上にわたってCFRGのメンバーによって検討されています。このドキュメントで説明されているOCB AEADアルゴリズムによって提供されるセキュリティメカニズムが機密性と認証の提供に使用するのに適していることは、CFRGの合意です。

2. Notation and Basic Operations

2. 表記と基本操作

There are two types of variables used in this specification, strings and integers. Although strings processed by most implementations of OCB will be strings of bytes, bit-level operations are used throughout this specification document for defining OCB. String variables are always written with an initial uppercase letter while integer variables are written in all lowercase. Following C's convention, a single equals ("=") indicates variable assignment and double equals ("==") is the equality relation. Whenever a variable is followed by an underscore ("_"), the underscore is intended to denote a subscript, with the subscripted expression requiring evaluation to resolve the meaning of the variable. For example, when i == 2, then P_i refers to the variable P_2.

この仕様で使用される変数には、文字列と整数の2つのタイプがあります。 OCBのほとんどの実装で処理される文字列はバイトの文字列ですが、OCBを定義するために、この仕様書全体でビットレベルの操作が使用されています。文字列変数は常に最初の大文字で書き込まれますが、整数変数はすべて小文字で書き込まれます。 Cの規則に従って、単一の等号（ "="）は変数の割り当てを示し、二重の等号（ "=="）は等価関係です。変数の後にアンダースコア（ "_"）が続く場合は常に、アンダースコアは添え字を表すことを目的としており、添え字付きの式は変数の意味を解決するために評価を必要とします。たとえば、i == 2の場合、P_iは変数P_2を参照します。

c^i The integer c raised to the i-th power.

c ^ i整数cのi乗。

bitlen(S) The length of string S in bits (e.g., bitlen(101) == 3).

bitlen（S）文字列Sの長さ（ビット）（例：bitlen（101）== 3）。

zeros(n) The string made of n zero bits.

zeros（n）n個のゼロビットで構成される文字列。

ntz(n) The number of trailing zero bits in the base-2 representation of the positive integer n. More formally, ntz(n) is the largest integer x for which 2^x divides n.

ntz（n）正の整数nの基数2表現の後続ゼロビットの数。より正式には、ntz（n）は2 ^ xがnを除算する最大整数xです。

S xor T The string that is the bitwise exclusive-or of S and T. Strings S and T will always have the same length.

S xor T SとTのビット単位の排他的論理和である文字列。文字列SとTは常に同じ長さになります。

S[i] The i-th bit of the string S (indices begin at 1, so if S is 011, then S[1] == 0, S[2] == 1, S[3] == 1).

S [i]文字列Sのi番目のビット（インデックスは1から始まるため、Sが011の場合、S [1] == 0、S [2] == 1、S [3] == 1）。

S[i..j] The substring of S consisting of bits i through j, inclusive.

S [i..j]ビットiからjまでで構成されるSの部分文字列。

S || T String S concatenated with string T (e.g., 000 || 111 == 000111).

S || T文字列Sと文字列Tを連結したもの（例：000 || 111 == 000111）。

str2num(S) The base-2 interpretation of bitstring S (e.g., str2num(1110) == 14).

str2num（S）ビット文字列Sの2進数の解釈（例：str2num（1110）== 14）。

num2str(i,n) The n-bit string whose base-2 interpretation is i (e.g., num2str(14,4) == 1110 and num2str(1,2) == 01).

num2str（i、n）ベース2の解釈がiであるnビットの文字列（たとえば、num2str（14,4）== 1110およびnum2str（1,2）== 01）。

   double(S)     If S[1] == 0, then double(S) == (S[2..128] || 0);
                 otherwise, double(S) == (S[2..128] || 0) xor
                 (zeros(120) || 10000111).

3. OCB Global Parameters

3. OCBグローバルパラメータ

To be complete, the algorithms in this document require specification of two global parameters: a blockcipher operating on 128-bit blocks and the length of authentication tags in use.

完全にするために、このドキュメントのアルゴリズムでは、2つのグローバルパラメータを指定する必要があります。128ビットブロックで動作するブロック暗号と、使用中の認証タグの長さです。

Specifying a blockcipher implicitly defines the following symbols.

ブロック暗号を指定すると、次の記号が暗黙的に定義されます。

KEYLEN The blockcipher's key length in bits.

KEYLENブロック暗号のキーの長さ（ビット単位）。

ENCIPHER(K,P) The blockcipher function mapping 128-bit plaintext block P to its corresponding ciphertext block using KEYLEN-bit key K.

ENCIPHER（K、P）KEYLENビットキーKを使用して、128ビットの平文ブロックPを対応する暗号文ブロックにマッピングするブロック暗号関数。

DECIPHER(K,C) The inverse blockcipher function mapping 128-bit ciphertext block C to its corresponding plaintext block using KEYLEN-bit key K.

DECIPHER（K、C）KEYLENビットキーKを使用して、128ビットの暗号文ブロックCを対応する平文ブロックにマッピングする逆ブロック暗号関数。

The TAGLEN parameter specifies the length of authentication tag used by OCB and may be any value up to 128. Greater values for TAGLEN provide greater assurances of authenticity, but ciphertexts produced by OCB are longer than their corresponding plaintext by TAGLEN bits. See Section 5 for details about TAGLEN and security.

TAGLENパラメータは、OCBが使用する認証タグの長さを指定し、128までの任意の値を指定できます。TAGLENの値が大きいほど、信頼性が高くなりますが、OCBによって生成される暗号文は、対応するTAGLENビットの平文よりも長くなります。 TAGLENとセキュリティの詳細については、セクション5を参照してください。

As an example, if 128-bit authentication tags and AES with 192-bit keys are to be used, then KEYLEN is 192, ENCIPHER refers to the AES-192 cipher, DECIPHER refers to the AES-192 inverse cipher, and TAGLEN is 128 [AES].

例として、128ビット認証タグと192ビットキーのAESを使用する場合、KEYLENは192、ENCIPHERはAES-192暗号を指し、DECIPHERはAES-192逆暗号を指し、TAGLENは128です。 [AES]。

3.1. Named OCB Parameter Sets and RFC 5116 Constants

3.1. 名前付きOCBパラメータセットとRFC 5116定数

The following table gives names to common OCB global parameter sets. Each of the AES variants is defined in [AES].

次の表に、一般的なOCBグローバルパラメータセットの名前を示します。各AESバリアントは[AES]で定義されています。

           +----------------------------+-------------+--------+
           | Name                       | Blockcipher | TAGLEN |
           +----------------------------+-------------+--------+
           | AEAD_AES_128_OCB_TAGLEN128 |   AES-128   |  128   |
           | AEAD_AES_128_OCB_TAGLEN96  |   AES-128   |   96   |
           | AEAD_AES_128_OCB_TAGLEN64  |   AES-128   |   64   |
           | AEAD_AES_192_OCB_TAGLEN128 |   AES-192   |  128   |
           | AEAD_AES_192_OCB_TAGLEN96  |   AES-192   |   96   |
           | AEAD_AES_192_OCB_TAGLEN64  |   AES-192   |   64   |
           | AEAD_AES_256_OCB_TAGLEN128 |   AES-256   |  128   |
           | AEAD_AES_256_OCB_TAGLEN96  |   AES-256   |   96   |
           | AEAD_AES_256_OCB_TAGLEN64  |   AES-256   |   64   |
           +----------------------------+-------------+--------+

RFC 5116 defines an interface for authenticated-encryption schemes [RFC5116]. RFC 5116 requires the specification of certain constants for each named AEAD scheme. For each of the OCB parameter sets listed above: P_MAX, A_MAX, and C_MAX are all unbounded; N_MIN is 1 byte, and N_MAX is 15 bytes. The parameter sets indicating the use of AES-128, AES-192, and AES-256 have K_LEN equal to 16, 24, and 32 bytes, respectively.

RFC 5116は、認証済み暗号化スキーム[RFC5116]のインターフェイスを定義しています。 RFC 5116では、名前付きAEADスキームごとに特定の定数を指定する必要があります。上記のOCBパラメータセットごとに、P_MAX、A_MAX、およびC_MAXはすべて無制限です。 N_MINは1バイト、N_MAXは15バイトです。 AES-128、AES-192、およびAES-256の使用を示すパラメーターセットのK_LENは、それぞれ16、24、および32バイトです。

Each ciphertext is longer than its corresponding plaintext by exactly TAGLEN bits, and TAGLEN is given at the end of each name. For instance, an AEAD_AES_128_OCB_TAGLEN64 ciphertext is exactly 64 bits longer than its corresponding plaintext.

各暗号文は対応するプレーンテキストよりも正確にTAGLENビットだけ長く、TAGLENは各名前の最後に付けられます。たとえば、AEAD_AES_128_OCB_TAGLEN64暗号文は、対応する平文よりも正確に64ビット長くなります。

4. OCB Algorithms

4. OCBアルゴリズム

OCB is described in this section using pseudocode. Given any collection of inputs of the required types, following the pseudocode description for a function will produce the correct output of the promised type.

このセクションでは、OCBについて疑似コードを使用して説明します。必要なタイプの入力のコレクションがある場合、関数の疑似コードの説明に従うと、約束されたタイプの正しい出力が生成されます。

4.1. Processing Associated Data: HASH

4.1. 関連データの処理：HASH

OCB has the ability to authenticate unencrypted associated data at the same time that it provides for authentication and encrypts a plaintext. The following hash function is central to providing this functionality. If an application has no associated data, then the associated data should be considered to exist and to be the empty string. HASH, conveniently, always returns zeros(128) when the associated data is the empty string.

OCBは、暗号化されていない関連データを認証すると同時に、認証を提供し、プレーンテキストを暗号化します。次のハッシュ関数は、この機能を提供するための中心です。アプリケーションに関連データがない場合、関連データは存在し、空の文字列であると見なされます。 HASHは、関連付けられたデータが空の文字列の場合、便利なことに常にzeros（128）を返します。

   Function name:
     HASH
   Input:
     K, string of KEYLEN bits                      // Key
     A, string of any length                       // Associated data
   Output:
     Sum, string of 128 bits                       // Hash result

Sum is defined as follows.

合計は次のように定義されます。

     //
     // Key-dependent variables
     //
     L_* = ENCIPHER(K, zeros(128))
     L_$ = double(L_*)
     L_0 = double(L_$)
     L_i = double(L_{i-1}) for every integer i > 0

     //
     // Consider A as a sequence of 128-bit blocks
     //
     Let m be the largest integer so that 128m <= bitlen(A)
     Let A_1, A_2, ..., A_m and A_* be strings so that
       A == A_1 || A_2 || ... || A_m || A_*, and
       bitlen(A_i) == 128 for each 1 <= i <= m.
       Note: A_* may possibly be the empty string.

     //
     // Process any whole blocks
     //
     Sum_0 = zeros(128)
     Offset_0 = zeros(128)
     for each 1 <= i <= m
        Offset_i = Offset_{i-1} xor L_{ntz(i)}
        Sum_i = Sum_{i-1} xor ENCIPHER(K, A_i xor Offset_i)
     end for

     //
     // Process any final partial block; compute final hash value
     //
     if bitlen(A_*) > 0 then
        Offset_* = Offset_m xor L_*
        CipherInput = (A_* || 1 || zeros(127-bitlen(A_*))) xor Offset_*
        Sum = Sum_m xor ENCIPHER(K, CipherInput)
     else
        Sum = Sum_m
     end if

4.2. Encryption: OCB-ENCRYPT

4.2. 暗号化：OCB-ENCRYPT

This function computes a ciphertext (which includes a bundled authentication tag) when given a plaintext, associated data, nonce, and key. For each invocation of OCB-ENCRYPT using the same key K, the value of the nonce input N must be distinct.

この関数は、プレーンテキスト、関連データ、ノンス、およびキーが与えられると、暗号化テキスト（バンドルされた認証タグを含む）を計算します。同じキーKを使用するOCB-ENCRYPTの呼び出しごとに、ノンス入力Nの値は異なる必要があります。

   Function name:
     OCB-ENCRYPT
   Input:
     K, string of KEYLEN bits                      // Key
     N, string of no more than 120 bits            // Nonce
     A, string of any length                       // Associated data
     P, string of any length                       // Plaintext
   Output:
     C, string of length bitlen(P) + TAGLEN bits   // Ciphertext

C is defined as follows.

Cは次のように定義されます。

     //
     // Key-dependent variables
     //
     L_* = ENCIPHER(K, zeros(128))
     L_$ = double(L_*)
     L_0 = double(L_$)
     L_i = double(L_{i-1}) for every integer i > 0

     //
     // Consider P as a sequence of 128-bit blocks
     //
     Let m be the largest integer so that 128m <= bitlen(P)
     Let P_1, P_2, ..., P_m and P_* be strings so that
       P == P_1 || P_2 || ... || P_m || P_*, and
       bitlen(P_i) == 128 for each 1 <= i <= m.
       Note: P_* may possibly be the empty string.

     //
     // Nonce-dependent and per-encryption variables
     //
     Nonce = num2str(TAGLEN mod 128,7) || zeros(120-bitlen(N)) || 1 || N
     bottom = str2num(Nonce[123..128])
     Ktop = ENCIPHER(K, Nonce[1..122] || zeros(6))
     Stretch = Ktop || (Ktop[1..64] xor Ktop[9..72])
     Offset_0 = Stretch[1+bottom..128+bottom]
     Checksum_0 = zeros(128)

     //
     // Process any whole blocks
     //
     for each 1 <= i <= m
        Offset_i = Offset_{i-1} xor L_{ntz(i)}
        C_i = Offset_i xor ENCIPHER(K, P_i xor Offset_i)
        Checksum_i = Checksum_{i-1} xor P_i
     end for

     //
     // Process any final partial block and compute raw tag
     //
     if bitlen(P_*) > 0 then
        Offset_* = Offset_m xor L_*
        Pad = ENCIPHER(K, Offset_*)
        C_* = P_* xor Pad[1..bitlen(P_*)]
        Checksum_* = Checksum_m xor (P_* || 1 || zeros(127-bitlen(P_*)))
        Tag = ENCIPHER(K, Checksum_* xor Offset_* xor L_$) xor HASH(K,A)
     else
        C_* = <empty string>
        Tag = ENCIPHER(K, Checksum_m xor Offset_m xor L_$) xor HASH(K,A)
     end if

     //
     // Assemble ciphertext
     //
     C = C_1 || C_2 || ... || C_m || C_* || Tag[1..TAGLEN]

4.3. Decryption: OCB-DECRYPT

4.3. 復号化：OCB-DECRYPT

This function computes a plaintext when given a ciphertext, associated data, nonce, and key. An authentication tag is embedded in the ciphertext. If the tag is not correct for the ciphertext, associated data, nonce, and key, then an INVALID signal is produced.

この関数は、暗号文、関連データ、ノンス、およびキーが指定されると、平文を計算します。認証タグは暗号文に埋め込まれています。タグが暗号文、関連データ、ノンス、およびキーに対して正しくない場合、INVALIDシグナルが生成されます。

   Function name:
     OCB-DECRYPT
   Input:
     K, string of KEYLEN bits                      // Key
     N, string of no more than 120 bits            // Nonce
     A, string of any length                       // Associated data
     C, string of at least TAGLEN bits             // Ciphertext
   Output:
     P, string of length bitlen(C) - TAGLEN bits,  // Plaintext
          or INVALID indicating authentication failure

P is defined as follows.

Pは次のように定義されます。

     //
     // Key-dependent variables
     //
     L_* = ENCIPHER(K, zeros(128))
     L_$ = double(L_*)
     L_0 = double(L_$)
     L_i = double(L_{i-1}) for every integer i > 0

     //
     // Consider C as a sequence of 128-bit blocks
     //
     Let m be the largest integer so that 128m <= bitlen(C) - TAGLEN
     Let C_1, C_2, ..., C_m, C_* and T be strings so that
       C == C_1 || C_2 || ... || C_m || C_* || T,
       bitlen(C_i) == 128 for each 1 <= i <= m, and
       bitlen(T) == TAGLEN.
       Note: C_* may possibly be the empty string.

     //
     // Nonce-dependent and per-decryption variables
     //
     Nonce = num2str(TAGLEN mod 128,7) || zeros(120-bitlen(N)) || 1 || N
     bottom = str2num(Nonce[123..128])
     Ktop = ENCIPHER(K, Nonce[1..122] || zeros(6))
     Stretch = Ktop || (Ktop[1..64] xor Ktop[9..72])
     Offset_0 = Stretch[1+bottom..128+bottom]
     Checksum_0 = zeros(128)

     //
     // Process any whole blocks
     //
     for each 1 <= i <= m
        Offset_i = Offset_{i-1} xor L_{ntz(i)}
        P_i = Offset_i xor DECIPHER(K, C_i xor Offset_i)
        Checksum_i = Checksum_{i-1} xor P_i
     end for

     //
     // Process any final partial block and compute raw tag
     //
     if bitlen(C_*) > 0 then
        Offset_* = Offset_m xor L_*
        Pad = ENCIPHER(K, Offset_*)
        P_* = C_* xor Pad[1..bitlen(C_*)]
        Checksum_* = Checksum_m xor (P_* || 1 || zeros(127-bitlen(P_*)))
        Tag = ENCIPHER(K, Checksum_* xor Offset_* xor L_$) xor HASH(K,A)

     else
        P_* = <empty string>
        Tag = ENCIPHER(K, Checksum_m xor Offset_m xor L_$) xor HASH(K,A)
     end if

     //
     // Check for validity and assemble plaintext
     //
     if (Tag[1..TAGLEN] == T) then
        P = P_1 || P_2 || ... || P_m || P_*
     else
        P = INVALID
     end if

5. Security Considerations

5. セキュリティに関する考慮事項

OCB achieves two security properties, confidentiality and authenticity. Confidentiality is defined via "indistinguishability from random bits", meaning that an adversary is unable to distinguish OCB outputs from an equal number of random bits. Authenticity is defined via "authenticity of ciphertexts", meaning that an adversary is unable to produce any valid nonce-ciphertext pair that it has not already acquired. The security guarantees depend on the underlying blockcipher being secure in the sense of a strong pseudorandom permutation. Thus, if OCB is used with a blockcipher that is not secure as a strong pseudorandom permutation, the security guarantees vanish. The need for the strong pseudorandom permutation property means that OCB should be used with a conservatively designed, well-trusted blockcipher, such as AES.

OCBは、機密性と信頼性という2つのセキュリティプロパティを実現します。機密性は「ランダムビットと区別できない」ことで定義されます。これは、攻撃者がOCB出力を同数のランダムビットから区別できないことを意味します。真正性は「暗号文の真正性」を介して定義されます。つまり、攻撃者はまだ取得していない有効なノンス暗号文のペアを生成できません。セキュリティの保証は、強力な疑似ランダム置換の意味で安全である基本的なブロック暗号に依存します。したがって、OCBが強力な疑似ランダム置換として安全でないブロック暗号で使用される場合、セキュリティの保証は失われます。強力な疑似ランダム置換プロパティの必要性は、OCBがAESなどの保守的に設計され、信頼性の高いブロック暗号で使用される必要があることを意味します。

Both the confidentiality and the authenticity properties of OCB degrade as per s^2 / 2^128, where s is the total number of blocks that the adversary acquires. The consequence of this formula is that the proven security disappears when s becomes as large as 2^64. Thus, the user should never use a key to generate an amount of ciphertext that is near to, or exceeds, 2^64 blocks. In order to ensure that s^2 / 2^128 remains small, a given key should be used to encrypt at most 2^48 blocks (2^55 bits or 4 petabytes), including the associated data. To ensure these limits are not crossed, automated key management is recommended in systems exchanging large amounts of data [RFC4107].

OCBの機密性と信頼性の両方のプロパティは、s ^ 2/2 ^ 128に従って低下します。ここで、sは攻撃者が取得するブロックの総数です。この式の結果、sが2 ^ 64になると、証明されたセキュリティが失われます。したがって、ユーザーはキーを使用して、2 ^ 64ブロックに近いか、それを超える量の暗号文を生成することはできません。 s ^ 2/2 ^ 128が小さいままであることを保証するために、特定のキーを使用して、関連するデータを含め、最大で2 ^ 48ブロック（2 ^ 55ビットまたは4ペタバイト）を暗号化する必要があります。これらの制限を超えないようにするために、大量のデータを交換するシステムでは自動キー管理をお勧めします[RFC4107]。

When a ciphertext decrypts as INVALID, it is the implementor's responsibility to make sure that no information beyond this fact is made adversarially available.

暗号文がINVALIDとして復号化する場合、この事実を超える情報が悪用されないようにすることは、実装者の責任です。

OCB encryption and decryption produce an internal 128-bit authentication tag. The parameter TAGLEN determines how many bits of this internal tag are included in ciphertexts and used for authentication. The value of TAGLEN has two impacts: an adversary can trivially forge with probability 2^{-TAGLEN}, and ciphertexts are TAGLEN bits longer than their corresponding plaintexts. It is up to the application designer to choose an appropriate value for TAGLEN. Long tags cost no more computationally than short ones.

OCBの暗号化と復号化により、内部の128ビット認証タグが生成されます。パラメータTAGLENは、この内部タグの何ビットが暗号文に含まれ、認証に使用されるかを決定します。 TAGLENの値には2つの影響があります。攻撃者は2 ^ {-TAGLEN}の確率で簡単に偽造でき、暗号文は対応する平文よりもTAGLENビット長くなります。 TAGLENに適切な値を選択するのはアプリケーション設計者の責任です。長いタグは短いタグよりも計算コストがかかりません。

Normally, a given key should be used to create ciphertexts with a single tag length, TAGLEN, and an application should reject any ciphertext that claims authenticity under the same key but a different tag length. While the ciphertext core and all of the bits of the tag do depend on the tag length, this is done for added robustness to misuse and should not suggest that receivers accept ciphertexts employing variable tag lengths under a single key.

通常、特定のキーを使用して単一のタグ長TAGLENで暗号文を作成し、アプリケーションは同じキーで異なるタグ長の真正性を主張する暗号文を拒否する必要があります。暗号文コアとタグのすべてのビットはタグの長さに依存しますが、これは誤用に対する追加の堅牢性のために行われ、受信者が単一のキーの下で可変のタグ長を使用する暗号文を受け入れることを示唆するべきではありません。

Timing attacks are not a part of the formal security model and an implementation should take care to mitigate them in contexts where this is a concern. To render timing attacks impotent, the amount of time to encrypt or decrypt a string should be independent of the key and the contents of the string. The only explicitly conditional OCB operation that depends on private data is double(), which means that using constant-time blockcipher and double() implementations eliminates most (if not all) sources of timing attacks on OCB. Power-usage attacks are likewise out of the scope of the formal model and should be considered for environments where they are threatening.

タイミング攻撃は正式なセキュリティモデルの一部ではないため、実装では、これが問題となる状況でそれらを軽減するように注意する必要があります。タイミング攻撃を無力にするために、文字列を暗号化または復号化する時間は、キーと文字列の内容に依存しない必要があります。プライベートデータに依存する明示的な条件付きOCB演算はdouble()のみです。つまり、一定時間のブロック暗号とdouble()実装を使用すると、OCBに対するタイミング攻撃の（すべてではないにしても）ほとんどのソースが排除されます。電力使用攻撃も同様に正式なモデルの範囲外であり、脅威にさらされている環境では考慮する必要があります。

The OCB encryption scheme reveals in the ciphertext the length of the plaintext. Sometimes the length of the plaintext is a valuable piece of information that should be hidden. For environments where "traffic analysis" is a concern, techniques beyond OCB encryption (typically involving padding) would be necessary.

OCB暗号化スキームは、平文の長さを暗号文で明らかにします。平文の長さは、隠すべき貴重な情報である場合があります。「トラフィック分析」が懸念される環境では、OCB暗号化（通常はパディングを含む）を超える技術が必要になります。

Defining the ciphertext that results from OCB-ENCRYPT to be the pair (C_1 || C_2 || ... || C_m || C_*, Tag[1..TAGLEN]) instead of the concatenation C_1 || C_2 || ... || C_m || C_* || Tag[1..TAGLEN] introduces no security concerns. Because TAGLEN is fixed, both versions allow ciphertexts to be parsed unambiguously.

OCB-ENCRYPTの結果である暗号文を、連結C_1 ||の代わりにペア（C_1 || C_2 || ... || C_m || C_ *、Tag [1..TAGLEN]）になるように定義するC_2 || ... || C_m || C_ * || Tag [1..TAGLEN]はセキュリティ上の懸念をもたらしません。 TAGLENが修正されているため、どちらのバージョンでも、暗号文を明確に解析できます。

5.1. Nonce Requirements

5.1. ノンス要件

It is crucial that, as one encrypts, one does not repeat a nonce. The inadvertent reuse of the same nonce by two invocations of the OCB encryption operation, with the same key, but with distinct plaintext values, undermines the confidentiality of the plaintexts protected in those two invocations and undermines all of the authenticity and integrity protection provided by that key. For this reason, OCB should only be used whenever nonce uniqueness can be provided with certainty. Note that it is acceptable to input the same nonce value multiple times to the decryption operation. We emphasize that the security consequences are quite serious if an attacker observes two ciphertexts that were created using the same nonce and key values, unless the plaintext and associated data values in both invocations of the encrypt operation were identical. First, a loss of confidentiality ensues because the attacker will be able to infer relationships between the two plaintext values. Second, a loss of authenticity ensues because the attacker will be able to recover secret information used to provide authenticity, making subsequent forgeries trivial. Note that there are AEAD schemes, particularly the Synthetic Initialization Vector (SIV) [RFC5297], appropriate for environments where nonces are unavailable or unreliable. OCB is not such a scheme.

暗号化するときにナンスを繰り返さないことが重要です。 OCB暗号化操作の2回の呼び出しによる同じナンスの不注意による再利用、同じキーを使用するが平文の値が異なる場合、これら2つの呼び出しで保護された平文の機密性が損なわれ、それによって提供される信頼性と整合性の保護がすべて損なわれます。キー。このため、ナンスの一意性を確実に提供できる場合にのみ、OCBを使用する必要があります。復号化操作に同じナンス値を複数回入力することは許容されることに注意してください。暗号化操作の両方の呼び出しでプレーンテキストと関連するデータ値が同一でない限り、攻撃者が同じナンスとキー値を使用して作成された2つの暗号文を観察した場合、セキュリティへの影響は非常に深刻です。まず、攻撃者が2つの平文値間の関係を推測できるため、機密性が失われます。第二に、攻撃者が真正性を提供するために使用された秘密情報を回復でき、その後の偽造を簡単にするため、真正性の喪失が起こります。 nonceが利用できない、または信頼できない環境に適したAEADスキーム、特にSynthetic Initialization Vector（SIV）[RFC5297]があることに注意してください。 OCBはそのようなスキームではありません。

Nonces need not be secret, and a counter may be used for them. If two parties send OCB-encrypted plaintexts to one another using the same key, then the space of nonces used by the two parties must be partitioned so that no nonce that could be used by one party to encrypt could be used by the other to encrypt (e.g., odd and even counters).

ナンスは秘密である必要はなく、カウンターをそれらに使用することができます。 2つのパーティが同じキーを使用してOCBで暗号化された平文を相互に送信する場合、一方のパーティが暗号化に使用できるnonceを他方が暗号化に使用できないように、2つのパーティが使用するnonceのスペースを分割する必要があります。（例えば、奇数と偶数のカウンター）。

6. IANA Considerations

6. IANAに関する考慮事項

The Internet Assigned Numbers Authority (IANA) has defined a registry for Authenticated Encryption with Associated Data parameters. The IANA has added the following entries to the AEAD Registry. Each name refers to a set of parameters defined in Section 3.1.

Internet Assigned Numbers Authority（IANA）は、Authenticated Encryptionのレジストリと、関連するデータパラメータを定義しています。 IANAは、AEADレジストリに次のエントリを追加しました。それぞれの名前は、セクション3.1で定義されたパラメーターのセットを指します。

         +----------------------------+-------------+------------+
         | Name                       |  Reference  | Numeric ID |
         +----------------------------+-------------+------------+
         | AEAD_AES_128_OCB_TAGLEN128 | Section 3.1 |     20     |
         | AEAD_AES_128_OCB_TAGLEN96  | Section 3.1 |     21     |
         | AEAD_AES_128_OCB_TAGLEN64  | Section 3.1 |     22     |
         | AEAD_AES_192_OCB_TAGLEN128 | Section 3.1 |     23     |
         | AEAD_AES_192_OCB_TAGLEN96  | Section 3.1 |     24     |
         | AEAD_AES_192_OCB_TAGLEN64  | Section 3.1 |     25     |
         | AEAD_AES_256_OCB_TAGLEN128 | Section 3.1 |     26     |
         | AEAD_AES_256_OCB_TAGLEN96  | Section 3.1 |     27     |
         | AEAD_AES_256_OCB_TAGLEN64  | Section 3.1 |     28     |
         +----------------------------+-------------+------------+

7. Acknowledgements

7. 謝辞

The design of the original OCB scheme [OCB1] was done while Rogaway was at Chiang Mai University, Thailand. Follow-up work [OCB2] was done with support of NSF grant 0208842 and a gift from Cisco. The final work by Krovetz and Rogaway [OCB3] that has resulted in this

オリジナルのOCBスキーム[OCB1]の設計は、Rogawayがタイのチェンマイ大学にいた間に行われました。フォローアップ作業[OCB2]は、NSFグラント0208842のサポートとシスコからの贈与により行われました。これをもたらしたクロベッツとロガウェイ[OCB3]による最後の作品

specification was supported by NSF grant 0904380. Thanks go to the many members of the Crypto Forum Research Group (CFRG) who provided feedback on earlier drafts. Thanks in particular go to David McGrew for contributing some text and for managing the RFC approval process, to James Manger for initiating a productive discussion on tag-length dependency and for greatly improving Appendix A, to Matt Caswell and Peter Dettman for writing implementations and verifying test vectors, and to Stephen Farrell and Spencer Dawkins for their careful reading and suggestions.

仕様はNSFグラント0904380でサポートされていました。以前のドラフトについてフィードバックを提供してくれた暗号フォーラム研究グループ（CFRG）の多くのメンバーに感謝します。特に、テキストの提供とRFC承認プロセスの管理についてはDavid McGrewに、タグ長の依存関係に関する生産的な議論を開始してくれたJames Mangerと、付録Aを大幅に改善してくれた実装と検証を行ったMatt CaswellとPeter Dettmanに感謝します。テストベクター、そして注意深く読んだり提案したりしたスティーブン・ファレルとスペンサー・ドーキンスに。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001.

[AES]米国国立標準技術研究所、「Advanced Encryption Standard（AES）」、FIPS PUB 197、2001年11月。

[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008.

[RFC5116] McGrew、D。、「認証された暗号化のためのインターフェースとアルゴリズム」、RFC 5116、2008年1月。

8.2. Informative References

8.2. 参考引用

[OCB1] Rogaway, P., Bellare, M., Black, J., and T. Krovetz, "OCB: A Block-Cipher Mode of Operation for Efficient Authenticated Encryption", ACM Conference on Computer and Communications Security 2001 - CCS 2001, ACM Press, 2001.

[OCB1] Rogaway、P.、Bellare、M.、Black、J。、およびT. Krovetz、「OCB：効率的な認証された暗号化のための操作のブロック暗号モード」、コンピューターと通信のセキュリティに関するACM会議2001-CCS 2001 、ACM Press、2001年。

[OCB2] Rogaway, P., "Efficient Instantiations of Tweakable Blockciphers and Refinements to Modes OCB and PMAC", Advances in Cryptology - ASIACRYPT 2004, Springer, 2004.

[OCB2] Rogaway、P。、「調整可能なブロック暗号の効率的なインスタンス化とモードOCBおよびPMACの改良」、暗号学の進歩-ASIACRYPT 2004、Springer、2004。

[OCB3] Krovetz, T. and P. Rogaway, "The Software Performance of Authenticated-Encryption Modes", Fast Software Encryption - FSE 2011 Springer, 2011.

[OCB3] Krovetz、T。およびP. Rogaway、「Authenticated-Encryption Modesのソフトウェアパフォーマンス」、Fast Software Encryption-FSE 2011 Springer、2011。

[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.

[RFC4107] Bellovin、S。およびR. Housley、「暗号鍵管理のガイドライン」、BCP 107、RFC 4107、2005年6月。

[RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)", RFC 5297, October 2008.

[RFC5297] Harkins、D。、「Advanced Encryption Standard（AES）を使用したSynthetic Initialization Vector（SIV）Authenticated Encryption」、RFC 5297、2008年10月。

Appendix A. Sample Results

付録A.サンプル結果

This section gives sample output values for various inputs when using OCB with AES as per the parameters defined in Section 3.1. All strings are represented in hexadecimal (e.g., 0F represents the bitstring 00001111).

このセクションでは、セクション3.1で定義されているパラメーターに従って、AESでOCBを使用する場合のさまざまな入力のサンプル出力値を示します。すべての文字列は16進数で表されます（たとえば、0Fはビット文字列00001111を表します）。

The following 16 (N,A,P,C) tuples show the ciphertext C that results from OCB-ENCRYPT(K,N,A,P) for various lengths of associated data (A) and plaintext (P). The key (K) has a fixed value, the tag length is 128 bits, and the nonce (N) increments.

次の16個の（N、A、P、C）タプルは、さまざまな長さの関連データ（A）およびプレーンテキスト（P）に対するOCB-ENCRYPT（K、N、A、P）から得られる暗号文Cを示しています。キー（K）の値は固定で、タグの長さは128ビットで、ノンス（N）の増分です。

     K : 000102030405060708090A0B0C0D0E0F

An empty entry indicates the empty string.

空のエントリは空の文字列を示します。

     N: BBAA99887766554433221100
     A:
     P:
     C: 785407BFFFC8AD9EDCC5520AC9111EE6

     N: BBAA99887766554433221101
     A: 0001020304050607
     P: 0001020304050607
     C: 6820B3657B6F615A5725BDA0D3B4EB3A257C9AF1F8F03009

     N: BBAA99887766554433221102
     A: 0001020304050607
     P:
     C: 81017F8203F081277152FADE694A0A00

     N: BBAA99887766554433221103
     A:
     P: 0001020304050607
     C: 45DD69F8F5AAE72414054CD1F35D82760B2CD00D2F99BFA9

N: BBAA99887766554433221104 A: 000102030405060708090A0B0C0D0E0F P: 000102030405060708090A0B0C0D0E0F C: 571D535B60B277188BE5147170A9A22C3AD7A4FF3835B8C5 701C1CCEC8FC3358

N：BBAA99887766554433221104 A：000102030405060708090A0B0C0D0E0F P：000102030405060708090A0B0C0D0E0F C：571D535B60B277188BE5147170A9A22C3AD7A4FF3835B8C5 701C1CCEC8FC3358

     N: BBAA99887766554433221105
     A: 000102030405060708090A0B0C0D0E0F
     P:
     C: 8CF761B6902EF764462AD86498CA6B97
     N: BBAA99887766554433221106
     A:
     P: 000102030405060708090A0B0C0D0E0F
     C: 5CE88EC2E0692706A915C00AEB8B2396F40E1C743F52436B
        DF06D8FA1ECA343D

     N: BBAA99887766554433221107
     A: 000102030405060708090A0B0C0D0E0F1011121314151617
     P: 000102030405060708090A0B0C0D0E0F1011121314151617
     C: 1CA2207308C87C010756104D8840CE1952F09673A448A122
        C92C62241051F57356D7F3C90BB0E07F

     N: BBAA99887766554433221108
     A: 000102030405060708090A0B0C0D0E0F1011121314151617
     P:
     C: 6DC225A071FC1B9F7C69F93B0F1E10DE

     N: BBAA99887766554433221109
     A:
     P: 000102030405060708090A0B0C0D0E0F1011121314151617
     C: 221BD0DE7FA6FE993ECCD769460A0AF2D6CDED0C395B1C3C
        E725F32494B9F914D85C0B1EB38357FF

     N: BBAA9988776655443322110A
     A: 000102030405060708090A0B0C0D0E0F1011121314151617
        18191A1B1C1D1E1F
     P: 000102030405060708090A0B0C0D0E0F1011121314151617
        18191A1B1C1D1E1F
     C: BD6F6C496201C69296C11EFD138A467ABD3C707924B964DE
        AFFC40319AF5A48540FBBA186C5553C68AD9F592A79A4240

     N: BBAA9988776655443322110B
     A: 000102030405060708090A0B0C0D0E0F1011121314151617
        18191A1B1C1D1E1F
     P:
     C: FE80690BEE8A485D11F32965BC9D2A32

     N: BBAA9988776655443322110C
     A:
     P: 000102030405060708090A0B0C0D0E0F1011121314151617
        18191A1B1C1D1E1F
     C: 2942BFC773BDA23CABC6ACFD9BFD5835BD300F0973792EF4
        6040C53F1432BCDFB5E1DDE3BC18A5F840B52E653444D5DF

N: BBAA9988776655443322110D A: 000102030405060708090A0B0C0D0E0F1011121314151617 18191A1B1C1D1E1F2021222324252627 P: 000102030405060708090A0B0C0D0E0F1011121314151617 18191A1B1C1D1E1F2021222324252627 C: D5CA91748410C1751FF8A2F618255B68A0A12E093FF45460 6E59F9C1D0DDC54B65E8628E568BAD7AED07BA06A4A69483 A7035490C5769E60

N：BBAA9988776655443322110D A：000102030405060708090A0B0C0D0E0F1011121314151617 18191A1B1C1D1E1F2021222324252627 P：000102030405060708090A0B0C0D0E0F1011121314151617 18191A1B1C1D1E1F2021222324252627 C：D5CA91748410C1751FF8A2F618255B68A0A12E093FF45460 6E59F9C1D0DDC54B65E8628E568BAD7AED07BA06A4A69483 A7035490C5769E60

     N: BBAA9988776655443322110E
     A: 000102030405060708090A0B0C0D0E0F1011121314151617
        18191A1B1C1D1E1F2021222324252627
     P:
     C: C5CD9D1850C141E358649994EE701B68

N: BBAA9988776655443322110F A: P: 000102030405060708090A0B0C0D0E0F1011121314151617 18191A1B1C1D1E1F2021222324252627 C: 4412923493C57D5DE0D700F753CCE0D1D2D95060122E9F15 A5DDBFC5787E50B5CC55EE507BCB084E479AD363AC366B95 A98CA5F3000B1479

N：BBAA9988776655443322110F A：P：000102030405060708090A0B0C0D0E0F1011121314151617 18191A1B1C1D1E1F2021222324252627 C：4412923493C57D5DE0D700F753CCE0D1D2D95060122E5BB500E5500A5500B366E5500B500E5706B366E5706B366E5706B3500E5BEB500E5BEABE5050A75B3500E5B500E5500B3500E5B3C0E5E540A5500B3500E5B3C3E0E0E0F0

Next are several internal values generated during the OCB-ENCRYPT computation for the last test vector listed above.

次に、上記の最後のテストベクトルのOCB-ENCRYPT計算中に生成されるいくつかの内部値を示します。

     L_*       : C6A13B37878F5B826F4F8162A1C8D879
     L_$       : 8D42766F0F1EB704DE9F02C54391B075
     L_0       : 1A84ECDE1E3D6E09BD3E058A8723606D
     L_1       : 3509D9BC3C7ADC137A7C0B150E46C0DA
     bottom    : 15 (decimal)
     Ktop      : 9862B0FDEE4E2DD56DBA6433F0125AA2
     Stretch   : 9862B0FDEE4E2DD56DBA6433F0125AA2FAD24D13A063F8B8
     Offset_0  : 587EF72716EAB6DD3219F8092D517D69
     Offset_1  : 42FA1BF908D7D8D48F27FD83AA721D04
     Offset_2  : 77F3C24534AD04C7F55BF696A434DDDE
     Offset_*  : B152F972B3225F459A1477F405FC05A7
     Checksum_1: 000102030405060708090A0B0C0D0E0F
     Checksum_2: 10101010101010101010101010101010
     Checksum_*: 30313233343536379010101010101010

The next tuple shows a result with a tag length of 96 bits and a different key.

次のタプルは、96ビットのタグ長と異なるキーの結果を示しています。

     K: 0F0E0D0C0B0A09080706050403020100

N: BBAA9988776655443322110D A: 000102030405060708090A0B0C0D0E0F1011121314151617 18191A1B1C1D1E1F2021222324252627 P: 000102030405060708090A0B0C0D0E0F1011121314151617 18191A1B1C1D1E1F2021222324252627 C: 1792A4E31E0755FB03E31B22116E6C2DDF9EFD6E33D536F1 A0124B0A55BAE884ED93481529C76B6AD0C515F4D1CDD4FD AC4F02AA

N：BBAA9988776655443322110D A：000102030405060708090A0B0C0D0E0F1011121314151617 18191A1B1C1D1E1F2021222324252627 P：000102030405060708090A0B0C0D0E0F1011121314151617 18191A1B1C1D1E1F2021222324252627 C：1792A4E31E0755FB03E31B22116E6C2DDF9EFD6E33D536F1 A0124B0A55BAE884ED93481529C76B6AD0C515F4D1CDD4FD AC4F02AA

The following algorithm tests a wider variety of inputs. Results are given for each parameter set defined in Section 3.1.

次のアルゴリズムは、さまざまな入力をテストします。結果は、セクション3.1で定義された各パラメーターセットに対して与えられます。

      K = zeros(KEYLEN-8) || num2str(TAGLEN,8)
      C = <empty string>
      for i = 0 to 127 do
         S = zeros(8i)
         N = num2str(3i+1,96)
         C = C || OCB-ENCRYPT(K,N,S,S)
         N = num2str(3i+2,96)
         C = C || OCB-ENCRYPT(K,N,<empty string>,S)
         N = num2str(3i+3,96)
         C = C || OCB-ENCRYPT(K,N,S,<empty string>)
      end for
      N = num2str(385,96)
      Output : OCB-ENCRYPT(K,N,C,<empty string>)

Iteration i of the loop adds 2i + (3 * TAGLEN / 8) bytes to C, resulting in an ultimate length for C of 22,400 bytes when TAGLEN == 128, 20,864 bytes when TAGLEN == 192, and 19,328 bytes when TAGLEN == 64. The final OCB-ENCRYPT has an empty plaintext component, so serves only to authenticate C. The output should be:

ループの反復iは、Cに2i +（3 * TAGLEN / 8）バイトを追加します。その結果、Cの最終的な長さは、TAGLEN == 128の場合は22,400バイト、TAGLEN == 192の場合は20,864バイト、TAGLEN ==の場合は19,328バイトになります。 64.最後のOCB-ENCRYPTには空のプレーンテキストコンポーネントがあるため、Cを認証するためだけに機能します。出力は次のようになります。

AEAD_AES_128_OCB_TAGLEN128 Output: 67E944D23256C5E0B6C61FA22FDF1EA2 AEAD_AES_192_OCB_TAGLEN128 Output: F673F2C3E7174AAE7BAE986CA9F29E17 AEAD_AES_256_OCB_TAGLEN128 Output: D90EB8E9C977C88B79DD793D7FFA161C AEAD_AES_128_OCB_TAGLEN96 Output : 77A3D8E73589158D25D01209 AEAD_AES_192_OCB_TAGLEN96 Output : 05D56EAD2752C86BE6932C5E AEAD_AES_256_OCB_TAGLEN96 Output : 5458359AC23B0CBA9E6330DD AEAD_AES_128_OCB_TAGLEN64 Output : 192C9B7BD90BA06A AEAD_AES_192_OCB_TAGLEN64 Output : 0066BC6E0EF34E24 AEAD_AES_256_OCB_TAGLEN64 Output : 7D4EA5D445501CBE

AEAD_AES_128_OCB_TAGLEN128出力：67E944D23256C5E0B6C61FA22FDF1EA2 AEAD_AES_192_OCB_TAGLEN128出力：F673F2C3E7174AAE7BAE986CA9F29E17 AEAD_AES_256_OCB_TAGLEN128出力：D90EB8E9C977C88B79DD793D7FFA161C AEAD_AES_128_OCB_TAGLEN96出力：77A3D8E73589158D25D01209 AEAD_AES_192_OCB_TAGLEN96出力：05D56EAD2752C86BE6932C5E AEAD_AES_256_OCB_TAGLEN96出力：5458359AC23B0CBA9E6330DD AEAD_AES_128_OCB_TAGLEN64出力：192C9B7BD90BA06A AEAD_AES_192_OCB_TAGLEN64出力：0066BC6E0EF34E24 AEAD_AES_256_OCB_TAGLEN64出力：7D4EA5D445501CBE

Authors' Addresses

著者のアドレス

Ted Krovetz Computer Science Department California State University, Sacramento 6000 J Street Sacramento, CA 95819-6021 USA

テッドクロベッツコンピュータサイエンス学部カリフォルニア州立大学サクラメント6000 Jストリートサクラメント、カリフォルニア95819-6021米国

   EMail: ted@krovetz.net

Phillip Rogaway Computer Science Department University of California, Davis One Shields Avenue Davis, CA 95616-8562 USA

フィリップロガウェイコンピュータサイエンス学部カリフォルニア大学デイビスワンシールドアベニューデイビスCA 95616-8562アメリカ

   EMail: rogaway@cs.ucdavis.edu