RFC1115 日本語訳

Network Working Group                                            J. Linn
Request for Comments:  1115                                          DEC
                                                  IAB Privacy Task Force
                                                             August 1989

コメントを求めるワーキンググループJ.リンの要求をネットワークでつないでください: 1115 1989年12月のIABプライバシー特別委員会8月

           Privacy Enhancement for Internet Electronic Mail:
             Part III -- Algorithms, Modes, and Identifiers

インターネット電子メールのためのプライバシー増進: パートIII--アルゴリズム、モード、および識別子

STATUS OF THIS MEMO

このメモの状態

   This RFC suggests a draft standard elective protocol for the Internet
   community, and requests discussion and suggestions for improvement.
   This RFC provides definitions, references, and citations for
   algorithms, usage modes, and associated identifiers used in RFC-1113
   and RFC-1114 in support of privacy-enhanced electronic mail.
   Distribution of this memo is unlimited.

このRFCはインターネットコミュニティのために草稿規格選挙のプロトコルを勧めて、議論と改善提案を要求します。 このRFCはプライバシーで高められた電子メールを支持してアルゴリズム、用法モード、RFC-1113で使用される関連識別子、およびRFC-1114に定義、参照、および引用を供給します。 このメモの分配は無制限です。

ACKNOWLEDGMENT

承認

   This RFC is the outgrowth of a series of IAB Privacy Task Force
   meetings and of internal working papers distributed for those
   meetings.  I would like to thank the following Privacy Task Force
   members and meeting guests for their comments and contributions at
   the meetings which led to the preparation of this RFC: David
   Balenson, Curt Barker, Jim Bidzos, Matt Bishop, Morrie Gasser, Russ
   Housley, Steve Kent (chairman), Dan Nessett, Mike Padlipsky, Rob
   Shirey, and Steve Wilbur.

このRFCは一連のIAB Privacy Task Forceミーティングとそれらのミーティングのために配布された内部の働く書類の派生物です。 このRFCの準備につながったミーティングで彼らのコメントと貢献について以下のPrivacy Task Forceメンバーとミーティング客に感謝申し上げます: デヴィッドBalenson、そっけないバーカー、ジム・ビゾス、マットラスHousley司教(モーリー・ガッサー)、スティーブ・ケント(議長)、ダンNessett(マイクPadlipsky)はShirey、およびスティーブ・ウィルバーから略奪します。

Table of Contents

目次

   1.  Executive Summary                                             2
   2.  Symmetric Encryption Algorithms and Modes                     2
   2.1.  DES Modes                                                   2
   2.1.1.  DES in ECB mode (DES-ECB)                                 2
   2.1.2.  DES in EDE mode (DES-EDE)                                 2
   2.1.3.  DES in CBC mode (DES-CBC)                                 3
   3.  Asymmetric Encryption Algorithms and Modes                    3
   3.1.  RSA                                                         3
   4.  Integrity Check Algorithms                                    3
   4.1.  Message Authentication Code (MAC)                           4
   4.2.  RSA-MD2 Message Digest Algorithm                            4
   4.2.1.  Discussion                                                4
   4.2.2.  Reference Implementation                                  5
   NOTES                                                             7

1. 要約2 2。 左右対称の暗号化アルゴリズムとモード2 2.1。 DESモード2 2.1.1。 ECBモード(DES-ECB)2 2.1.2におけるDES。 EDEモード(DES-EDE)2 2.1.3におけるDES。 CBCモード(DES-CBC)3 3におけるDES。 非対称の暗号化アルゴリズムとモード3 3.1。 RSA3 4。 保全チェックアルゴリズム3 4.1。 メッセージ立証コード(MAC)4 4.2。 RSA-MD2メッセージダイジェストアルゴリズム4 4.2.1。 議論、4 4.2 .2。 リファレンスインプリメンテーション5注意7

Linn                                                            [Page 1]

RFC 1115                Mail Privacy: Algorithms             August 1989

リン[1ページ]RFC1115はプライバシーを郵送します: アルゴリズム1989年8月

1.  Executive Summary

1. 要約

   This RFC provides definitions, references, and citations for algorithms,
   usage modes, and associated identifiers used in RFC-1113 and RFC-1114
   in support of privacy-enhanced electronic mail in the Internet
   community.  As some parts of this material are cited by both RFC-1113
   and RFC-1114, and as it is anticipated that some of the definitions
   herein may be changed, added, or replaced without affecting the citing
   RFCs, algorithm-specific material has been placed into this separate
   RFC.  The text is organized into three primary sections; dealing with
   symmetric encryption algorithms, asymmetric encryption algorithms, and
   integrity check algorithms.

このRFCはインターネットコミュニティのプライバシーで高められた電子メールを支持してアルゴリズム、用法モード、RFC-1113で使用される関連識別子、およびRFC-1114に定義、参照、および引用を供給します。 この材料のいくつかの一部分がRFC-1113とRFC-1114の両方によって引用されて、定義のいくつかがここに変えられるかもしれないと予期されるとき、加えられたか、取り替えられたRFCsの、そして、アルゴリズム特有の引用に影響しないで材料はこの別々のRFCに置かれました。 テキストは3つの第一のセクションへまとめられます。 左右対称の暗号化アルゴリズムに対処する、非対称の暗号化アルゴリズム、および保全はアルゴリズムをチェックします。

2.  Symmetric Encryption Algorithms and Modes

2. 左右対称の暗号化アルゴリズムとモード

   This section identifies alternative symmetric encryption algorithms
   and modes which may be used to encrypt DEKs, MICs, and message text,
   and assigns them character string identifiers to be incorporated in
   encapsulated header fields to indicate the choice of algorithm
   employed.  (Note: all alternatives presently defined in this category
   correspond to different usage modes of the DEA-1 (DES) algorithm,
   rather than to other algorithms per se.)

このセクションは、代替の左右対称の暗号化アルゴリズムとDEKs、MICs、およびメッセージ・テキストをコード化するのに使用されるかもしれないモードを特定して、使われたアルゴリズムの選択を示すために要約のヘッダーフィールドに取り入れられるために文字列識別子を彼らに割り当てます。 (注意: 現在このカテゴリで定義されているすべての選択肢がそういうものとして他のアルゴリズムにというよりむしろDEA-1(DES)アルゴリズムの異なった用法モードに対応しています。)

2.1.  DES Modes

2.1. DESモード

   The Block Cipher Algorithm DEA-1, defined in ANSI X3.92-1981 [3] may
   be used for message text, DEKs, and MICs.  The DEA-1 is equivalent to
   the Data Encryption Standard (DES), as defined in FIPS PUB 46 [4].
   The ECB and CBC modes of operation of DEA-1 are defined in ISO IS 8372
   [5].

ANSI X3.92-1981で定義されたBlock Cipher Algorithm DEA-1[3]はメッセージ・テキスト、DEKs、およびMICsに使用されるかもしれません。 DEA-1はFIPS PUB46[4]で定義されるようにデータ暗号化規格(DES)に同等です。 DEA-1のECBとCBC運転モードはISO IS8372[5]で定義されます。

2.1.1.  DES in ECB mode (DES-ECB)

2.1.1. ECBモードによるDES(デス-ECB)

   The string "DES-ECB" indicates use of the DES algorithm in Electronic
   Codebook (ECB) mode.  This algorithm/mode combination is used for DEK
   and MIC encryption.

ストリング「デス-ECB」は電子符号表(ECB)モードにおけるデスアルゴリズムの使用を示します。 このアルゴリズム/モード組み合わせはDEKとMIC暗号化に使用されます。

2.1.2.  DES in EDE mode (DES-EDE)

2.1.2. EDEモードによるDES(デス-エーデ)

   The string "DES-EDE" indicates use of the DES algorithm in
   Encrypt-Decrypt-Encrypt (EDE) mode as defined by ANSI X9.17 [2] for
   key encryption and decryption with pairs of 64-bit keys.  This
   algorithm/mode combination is used for DEK and MIC encryption.

ストリング「デス-エーデ」が中にデスアルゴリズムの使用を示す、コード化、解読する、コード化、主要な暗号化と復号化のために組の64ビットのキーでANSI X9.17[2]によって定義される(エーデ)モード。 このアルゴリズム/モード組み合わせはDEKとMIC暗号化に使用されます。

Linn                                                            [Page 2]

RFC 1115                Mail Privacy: Algorithms             August 1989

リン[2ページ]RFC1115はプライバシーを郵送します: アルゴリズム1989年8月

2.1.3.  DES in CBC mode (DES-CBC)

2.1.3. CBCモードによるDES(デス-CBC)

   The string "DES-CBC" indicates use of the DES algorithm in Cipher
   Block Chaining (CBC) mode.  This algorithm/mode combination is used
   for message text encryption only.  The CBC mode definition in IS 8372
   is equivalent to that provided in FIPS PUB 81 [6] and in ANSI X3.106-
   1983 [7].

ストリング「デス-CBC」は暗号ブロック連鎖(CBC)モードにおけるデスアルゴリズムの使用を示します。 このアルゴリズム/モード組み合わせはメッセージ・テキスト暗号化だけに使用されます。 中のCBCモード定義は8372がFIPS PUB81[6]とANSI X3.106 1983[7]に提供されたそれに同等であるということです。

3.  Asymmetric Encryption Algorithms and Modes

3. 非対称の暗号化アルゴリズムとモード

   This section identifies alternative asymmetric encryption algorithms and
   modes which may be used to encrypt DEKs and MICs, and assigns them
   character string identifiers to be incorporated in encapsulated
   header fields to indicate the choice of algorithm employed.  (Note:
   only one alternative is presently defined in this category.)

このセクションは、代替の非対称の暗号化アルゴリズムとDEKsとMICsをコード化するのに使用されるかもしれないモードを特定して、使われたアルゴリズムの選択を示すために要約のヘッダーフィールドに取り入れられるために文字列識別子を彼らに割り当てます。 (注意: 1つの選択肢だけが現在、このカテゴリで定義されます。)

3.1.  RSA

3.1. RSA

   The string "RSA" indicates use of the RSA public-key encryption
   algorithm, as described in [8].  This algorithm is used for DEK and
   MIC encryption, in the following fashion: the product n of a
   individual's selected primes p and q is used as the modulus for the
   RSA encryption algorithm, comprising, for our purposes, the
   individual's public key.  A recipient's public key is used in
   conjunction with an associated public exponent (either 3 or 1+2**16)
   as identified in the recipient's certificate.

ストリング"RSA"は[8]で説明されるようにRSA公開カギ暗号化アルゴリズムの使用を示します。 このアルゴリズムは以下のファッションにおけるDEKとMIC暗号化に使用されます: n個人が選択した製品はpを用意します、そして、qはRSA暗号化アルゴリズムに係数として使用されます、私たちの目的のために個人の公開鍵を包括して。 受取人の公開鍵は受取人の証明書で特定されるように関連公共の解説者(3か1+2**16)に関連して使用されます。

   When a MIC must be padded for RSA encryption, the MIC will be
   right-justified and padded on the left with zeroes.  This is also
   appropriate for padding of DEKs on singly-addressed messages, and for
   padding of DEKs on multi-addressed messages if and only if an exponent
   of 3 is used for no more than one recipient.  On multi-addressed
   messages in which an exponent of 3 is used for more than one recipient,
   it is recommended that a separate 64-bit pseudorandom quantity be
   generated for each recipient, in the same manner in which IVs are
   generated.  (Reference [9] discusses the rationale for this
   recommendation.)  At least one copy of the pseudorandom quantity should
   be included in the input to RSA encryption, placed to the left of the
   DEK.

RSA暗号化のためにMICを水増ししなければならないとき、MICは左でゼロでまさしく正当であって、そっと歩くようになるでしょう。 そして、また、単独で記述されたメッセージにおけるDEKsの詰め物、およびマルチ記述されたメッセージにおけるDEKsの詰め物に、これも適切である、3の解説者が1人未満の受取人に使用される場合にだけ。 3の解説者が1人以上の受取人に使用されるマルチ記述されたメッセージでは、別々の64ビットの擬似ランダム量が各受取人のために発生するのは、お勧めです、IVsが発生するのと同じ方法で。 (参照[9]はこの推薦のために原理について議論します。) 擬似ランダム量のコピー少なくとも1部は入力でDEKの左に置かれたRSA暗号化に含められるべきです。

4.  Integrity Check Algorithms

4. 保全チェックアルゴリズム

   This section identifies the alternative algorithms which may be used
   to compute Message Integrity Check (MIC) and Certificate Integrity
   Check (CIC) values, and assigns the algorithms character string
   identifiers for use in encapsulated header fields and within
   certificates to indicate the choice of algorithm employed.

このセクションは、Message Integrity Check(MIC)とCertificate Integrity Check(CIC)値を計算するのに使用されるかもしれない代替のアルゴリズムを特定して、要約のヘッダーフィールドと証明書の中の使用が使われたアルゴリズムの選択を示すように、文字列識別子をアルゴリズムに割り当てます。

Linn                                                            [Page 3]

RFC 1115                Mail Privacy: Algorithms             August 1989

リン[3ページ]RFC1115はプライバシーを郵送します: アルゴリズム1989年8月

   MIC algorithms which utilize DEA-1 cryptography are computed using a key
   which is a variant of the DEK used for message text encryption.  The
   variant is formed by modulo-2 addition of the hexadecimal quantity
   F0F0F0F0F0F0F0F0 to the encryption DEK.

DEA-1暗号を利用するMICアルゴリズムが、メッセージ・テキスト暗号化に使用されるDEKの異形であるキーを使用することで計算されます。 異形は16進量のF0F0F0F0F0F0F0F0の暗号化DEKへの法-2添加で形成されます。

   For compatibility with this specification, a privacy-enhanced mail
   implementation must be able to process both MAC (Section 2.1) and
   RSA-MD2 (Section 2.2) MICs on incoming messages.  It is a sender option
   whether MAC or RSA-MD2 is employed on an outbound message addressed to
   only one recipient.  However, use of MAC is strongly discouraged for
   messages sent to more than a single recipient.  The reason for this
   recommendation is that the use of MAC on multi-addressed mail fails to
   prevent other intended recipients from tampering with a message in a
   manner which preserves the message's appearance as an authentic message
   from the sender.  In other words, use of MAC on multi-addressed mail
   provides source authentication at the granularity of membership in the
   message's authorized address list (plus the sender) rather than at a
   finer (and more desirable) granularity authenticating the individual
   sender.

この仕様との互換性において、プライバシーで高められたメール実現はMAC(セクション2.1)とRSA-MD2(セクション2.2)MICsの両方を入力メッセージに処理できなければなりません。 MACかRSA-MD2が1人の受取人だけまで記述された外国行きのメッセージで使われるか否かに関係なく、それは送付者オプションです。 しかしながら、MACの使用は独身の受取人以上に送られたメッセージのために強くお勧めできないです。 この推薦の理由はマルチ記述されたメールにおけるMACの使用が、送付者から他の意図している受取人が正統のメッセージとしてメッセージの外観を保持する方法によるメッセージをいじるのを防がないということです。 言い換えれば、マルチ記述されたメールにおけるMACの使用は、よりすばらしくて(より望ましい)の粒状でというよりむしろメッセージの認可された住所録(送付者)の会員資格が認証される粒状におけるソース認証に個々の送付者を提供します。

4.1.  Message Authentication Code (MAC)

4.1. メッセージ立証コード(Mac)

   A message authentication code (MAC), denoted by the string "MAC", is
   computed using the DEA-1 algorithm in the fashion defined in FIPS PUB
   113 [1].  This algorithm is used only as a MIC algorithm, not as a CIC
   algorithm.

ストリング「Mac」によって指示された認証子(MAC)がファッションでDEA-1アルゴリズムを使用することで計算されるというメッセージはFIPSパブで113[1]を定義しました。 このアルゴリズムはCICアルゴリズムとして使用されるのではなく、単にMICアルゴリズムとして使用されます。

   As noted above, use of the MAC is not recommended for multicast
   messages, as it does not preserve authentication and integrity among
   individual recipients, i.e., it is not cryptographically strong enough
   for this purpose.  The message's canonically encoded text is padded at
   the end, per FIPS PUB 113, with zero-valued octets as needed in order to
   form an integral number of 8-octet encryption quanta.  These padding
   octets are inserted implicitly and are not transmitted with a message.
   The result of a MAC computation is a single 64-bit value.

上で個々の受取人の中に認証と保全を保持しないときMACの使用がマルチキャストメッセージのために推薦されないで、またすなわち、それが暗号でそうでないことにこのために十分強い状態で注意するので。 メッセージの正準なコード化されたテキストは、FIPS PUB113あたりの終わりに整数の8八重奏の暗号化量子を形成するために必要に応じて無評価された八重奏で水増しされます。 八重奏を水増しするこれらが、それとなく挿入されて、メッセージで伝えられません。 MAC計算の結果はただ一つの64ビットの値です。

4.2.  RSA-MD2 Message Digest Algorithm

4.2. RSA-MD2メッセージダイジェストアルゴリズム

4.2.1.  Discussion

4.2.1. 議論

   The RSA-MD2 Message Digest Algorithm, denoted by the string "RSA-MD2",
   is computed using an algorithm defined in this section.  It has been
   provided by Ron Rivest of RSA Data Security, Incorporated for use in
   support of privacy-enhanced electronic mail, free of licensing
   restrictions.  This algorithm should be used as a MIC algorithm
   whenever a message is addressed to multiple recipients.  It is also
   the only algorithm currently defined for use as CIC.  While its
   continued use as the standard CIC algorithm is anticipated, RSA-MD2

RSA-MD2 Message Digest Algorithmの、そして、ストリングで指示された「RSA-MD2"はアルゴリズムがこのセクションで定義した計算された使用です」。 それはRSA Data SecurityのロンRivestによって提供されました、プライバシーで高められた電子メールを支持した使用のためのIncorporated、制限を認可するのから、自由です。 メッセージが複数の受取人に記述されるときはいつも、このアルゴリズムはMICアルゴリズムとして使用されるべきです。 また、それは現在使用のためにCICと定義されている唯一のアルゴリズムです。 RSA-MD2、標準のCICアルゴリズムとしての継続的な使用は予期されますが

Linn                                                            [Page 4]

RFC 1115                Mail Privacy: Algorithms             August 1989

リン[4ページ]RFC1115はプライバシーを郵送します: アルゴリズム1989年8月

   may be supplanted by later recommendations for MIC algorithm
   selections.

MICアルゴリズム選択のための後の推薦で取って代わられるかもしれません。

   The RSA-MD2 message digest algorithm accepts as input a message of any
   length and produces as output a 16-byte quantity.  The attached
   reference implementation serves to define the algorithm; implementors
   may choose to develop optimizations suited to their operating
   environments.

RSA-MD2メッセージダイジェストアルゴリズムは、どんな長さに関するメッセージも入力するとき受け入れて、16バイトの量を出力するとき、作成されます。 付属参照実現は、アルゴリズムを定義するのに役立ちます。 作成者は、彼らの操作環境に合う最適化を開発するのを選ぶかもしれません。

4.2.2.  Reference Implementation

4.2.2. リファレンスインプリメンテーション

/* RSA-MD2 Message Digest algorithm in C  */
/*  by Ronald L. Rivest 10/1/88  */

ロナルドL.Rivest10/1/88*/によるC*//*の/*RSA-MD2 Message Digestアルゴリズム

#include <stdio.h>

#<stdio.h>を含めてください。

/**********************************************************************/
/* Message digest routines:                                           */
/* To form the message digest for a message M                         */
/*    (1) Initialize a context buffer md using MDINIT                 */
/*    (2) Call MDUPDATE on md and each character of M in turn         */
/*    (3) Call MDFINAL on md                                          */
/* The message digest is now in md->D[0...15]                         */
/**********************************************************************/
/* An MDCTX structure is a context buffer for a message digest        */
/*  computation; it holds the current "state" of a message digest     */
/*  computation                                                       */
struct MDCTX
{
   unsigned char  D[48];   /* buffer for forming digest in */
                           /* At the end, D[0...15] form the message */
                           /*  digest */
   unsigned char  C[16];   /* checksum register */
   unsigned char  i;       /* number of bytes handled, modulo 16 */
   unsigned char  L;       /* last checksum char saved */
};
/* The table S given below is a permutation of 0...255 constructed    */
/*  from the digits of pi.  It is a ``random'' nonlinear byte         */
/*  substitution operation.                                           */
int S[256] = {
        41, 46, 67,201,162,216,124,  1, 61, 54, 84,161,236,240,  6, 19,
        98,167,  5,243,192,199,115,140,152,147, 43,217,188, 76,130,202,
        30,155, 87, 60,253,212,224, 22,103, 66,111, 24,138, 23,229, 18,
       190, 78,196,214,218,158,222, 73,160,251,245,142,187, 47,238,122,
       169,104,121,145, 21,178,  7, 63,148,194, 16,137, 11, 34, 95, 33,
       128,127, 93,154, 90,144, 50, 39, 53, 62,204,231,191,247,151,  3,
       255, 25, 48,179, 72,165,181,209,215, 94,146, 42,172, 86,170,198,
        79,184, 56,210,150,164,125,182,118,252,107,226,156,116,  4,241,

メッセージダイジェスト..ルーチン */ /* To form the message digest for a message M */ /* (1) Initialize a context buffer md using MDINIT */ /* (2) Call MDUPDATE on md and each character of M in turn */ /* (3) Call MDFINAL on md */ /* The message digest is now in md->D[0...15] */ /**********************************************************************/ /* An MDCTX structure is a context buffer for a message digest */ /* computation; それはメッセージダイジェスト*//*計算*/struct MDCTXの現在の「状態」を保持します。{無記名の炭のD[48]; *//*でダイジェストを終わりに形成するための/*バッファ、D[0...15]は/*バイト数が扱ったメッセージ*//*ダイジェスト*/無記名の炭のC[16](/*チェックサムレジスタ*/無記名の炭i)を形成します、法16*/無記名の炭L; 最後のチェックサム炭が*/を救った/*}。 /*は下が0の…順列であるというテーブルS当然のことです。255はパイのケタからの*//*を組み立てました。 それは非線形の「無作為」のバイト*//*代替操作です。 */int S256が等しい、41、46、67兆2011億6221万6124、1、61、54、841億6123万6240、6、19、9万8167、52亥4319京2199兆1151億4015万2147、4321万7188、7613万202、3万155、87、602億5321万2224、2万2103、6万6111、2万4138、2万3229、18、190、7京8196兆2142億1815万8222、7京3160兆2512億4514万2187、4万7238; 122, 169,104,121,145, 21,178, 7, 63,148,194, 16,137, 11, 34, 95, 33, 128,127, 93,154, 90,144, 50, 39, 53, 62,204,231,191,247,151, 3, 255, 25, 48,179, 72,165,181,209,215, 94,146, 42,172, 86,170,198, 79,184, 56,210,150,164,125,182,118,252,107,226,156,116, 4,241,

Linn                                                            [Page 5]

RFC 1115                Mail Privacy: Algorithms             August 1989

リン[5ページ]RFC1115はプライバシーを郵送します: アルゴリズム1989年8月

        69,157,112, 89,100,113,135, 32,134, 91,207,101,230, 45,168,  2,
        27, 96, 37,173,174,176,185,246, 28, 70, 97,105, 52, 64,126, 15,
        85, 71,163, 35,221, 81,175, 58,195, 92,249,206,186,197,234, 38,
        44, 83, 13,110,133, 40,132,  9,211,223,205,244, 65,129, 77, 82,
       106,220, 55,200,108,193,171,250, 36,225,123,  8, 12,189,177, 74,
       120,136,149,139,227, 99,232,109,233,203,213,254, 59,  0, 29, 57,
       242,239,183, 14,102, 88,208,228,166,119,114,248,235,117, 75, 10,
        49, 68, 80,180,143,237, 31, 26,219,153,141, 51,159, 17,131, 20,
};
/*The routine MDINIT initializes the message digest context buffer md.*/
/* All fields are set to zero.                                        */
void MDINIT(md)
  struct MDCTX *md;
  { int i;
    for (i=0;i<16;i++) md->D[i] = md->C[i] = 0;
    md->i = 0;
    md->L = 0;
  }
/* The routine MDUPDATE updates the message digest context buffer to  */
/*  account for the presence of the character c in the message whose  */
/*  digest is being computed.  This routine will be called for each   */
/*   message byte in turn.                                            */
void MDUPDATE(md,c)
  struct MDCTX *md;
  unsigned char c;
  { register unsigned char i,j,t,*p;
    /**** Put i in a local register for efficiency ****/
       i = md->i;
    /**** Add new character to buffer ****/
       md->D[16+i] = c;
       md->D[32+i] = c ^ md->D[i];
    /**** Update checksum register C and value L ****/
       md->L = (md->C[i] ^= S[0xFF & (c ^ md->L)]);
    /**** Increment md->i by one modulo 16 ****/
       i = md->i = (i + 1) & 15;
    /**** Transform D if i=0 ****/
       if (i == 0)
         { t = 0;
           for (j=0;j<18;j++)
             {/*The following is a more efficient version of the loop:*/
               /*  for (i=0;i<48;i++) t = md->D[i] = md->D[i] ^ S[t]; */
               p = md->D;
               for (i=0;i<8;i++)
                 { t = (*p++ ^= S[t]);
                   t = (*p++ ^= S[t]);
                   t = (*p++ ^= S[t]);
                   t = (*p++ ^= S[t]);
                   t = (*p++ ^= S[t]);

69,157,112, 89,100,113,135, 32,134, 91,207,101,230, 45,168, 2, 27, 96, 37,173,174,176,185,246, 28, 70, 97,105, 52, 64,126, 15, 85, 71,163, 35,221, 81,175, 58,195, 92,249,206,186,197,234, 38, 44, 83, 13,110,133, 40,132, 9,211,223,205,244, 65,129, 77, 82, 106,220, 55,200,108,193,171,250, 36,225,123, 8, 12,189,177, 74, 120,136,149,139,227, 99,232,109,233,203,213,254, 59, 0, 29, 57, 242,239,183, 14,102, 88,208,228,166,119,114,248,235,117, 75, 10, 49, 68, 80,180,143,237, 31, 26,219,153,141, 51,159, 17,131, 20, }; *通常のMDINITはメッセージダイジェストの文脈の、よりもみ皮製のMdを初期化します。/、*すべてがさばく//*はゼロに設定されます。 */空間MDINIT(Md)struct MDCTX*Md。 int i。 (i=0; i<16; i++)Md->D[i]=Md->に関しては、C[i]は0と等しいです。 Md>i=0。 Md>L=0。 } /、*通常のMDUPDATEは*//*ダイジェストが計算されているメッセージでのキャラクタcの存在のために*//*アカウントにメッセージダイジェスト文脈バッファをアップデートします。 このルーチンはそれぞれの*//*メッセージバイト単位で順番に求められるでしょう。 */空間MDUPDATE(Md、c)struct MDCTX*Md。 無記名の炭c。 無記名の炭i、j、t、*pを登録してください。 /****は効率*のためのローカルのレジスタにiを入れました。***/iはMd>iと等しいです。 /****は***Md*/>D[16+i]=cをバッファリングするように新しいキャラクタを加えます。 Md>D[32+i]がc^Md->と等しい、D[i]。 /****アップデートチェックサムレジスタCと値L***Md*/>Lが等しい、(Md、->C[i]^はS[0xFFと(c^Md>L))と等しいです。 1法16****/i=Md>i=(i+1)と15による/****増分Md>i。 /**** Transform D if i=0 ****/ if (i == 0) { t = 0; for (j=0;j<18;j++) {/*The following is a more efficient version of the loop:*/ /* for (i=0;i<48;i++) t = md->D[i] = md->D[i] ^ S[t]; */ p = md->D; for (i=0;i<8;i++) { t = (*p++ ^= S[t]); t = (*p++ ^= S[t]); t = (*p++ ^= S[t]); t = (*p++ ^= S[t]); t = (*p++ ^= S[t]);

Linn                                                            [Page 6]

RFC 1115                Mail Privacy: Algorithms             August 1989

リン[6ページ]RFC1115はプライバシーを郵送します: アルゴリズム1989年8月

                   t = (*p++ ^= S[t]);
                 }
               /* End of more efficient loop implementation */
               t = t + j;
             }
         }
  }
/* The routine MDFINAL terminates the message digest computation and  */
/* ends with the desired message digest being in md->D[0...15].       */
void MDFINAL(md)
  struct MDCTX *md;
  { int i,padlen;
    /* pad out to multiple of 16 */
       padlen  = 16 - (md->i);
       for (i=0;i<padlen;i++) MDUPDATE(md,(unsigned char)padlen);
    /* extend with checksum */
    /* Note that although md->C is modified by MDUPDATE, character    */
    /* md->C[i] is modified after it has been passed to MDUPDATE, so  */
    /* the net effect is the same as if md->C were not being modified.*/
    for (i=0;i<16;i++) MDUPDATE(md,md->C[i]);
  }

t = (*p++ ^= S[t]); } より効率的な輪の実現*/tの/*終わりはt+jと等しいです。 } } } /、*通常のMDFINALはMdにはある必要なメッセージダイジェストで>D[0...15]を終わらせてメッセージダイジェスト計算と*//*を終えます。 */空間MDFINAL(Md)struct MDCTX*Md。 int i、padlen。 16*/padlenの倍数への/*パッド=16--(Md>i)。 (i=0; i<padlen; i++)MDUPDATE(Md、(無記名の炭)padlen)のために。 */*がMd>CがMDUPDATEによって変更されますが、それがMDUPDATEに通過された後にキャラクタ/*Md*/>C[i]が変更されているというチェックサム*//*メモと共に広がっているのでまるでMd>Cが変更されていないかのようにネットが作用する//*が同じである、(i=0; i<16; i++)MDUPDATEのための*/、(Md、Md>C、[i])。 }

/**********************************************************************/
/* End of message digest implementation                               */
/**********************************************************************/

/**********************************************************************/ /* End of message digest implementation */ /**********************************************************************/

NOTES:

注意:

  [1]  Federal Information Processing Standards Publication 113,
       Computer Data Authentication, May 1985.

[1] 公表113(コンピュータのデータ認証)が1985にそうするかもしれない連邦政府の情報処理規格

  [2]  ANSI X9.17-1985, American National Standard, Financial
       Institution Key Management (Wholesale), American Bankers
       Association, April 4, 1985, Section 7.2.

[2]ANSI X9.17-1985、米国標準規格、金融機関Key Management(大量の)、アメリカ銀行家協会、1985年4月4日、セクション7.2。

  [3]  American National Standard Data Encryption Algorithm (ANSI
       X3.92-1981), American National Standards Institute, Approved 30
       December 1980.

[3] 米国標準規格データ暗号化アルゴリズム(ANSI X3.92-1981)、American National Standards Institut、承認された1980年12月30日。

  [4]  Federal Information Processing Standards Publication 46,  Data
       Encryption Standard, 15 January 1977.

[4] 連邦政府の情報処理規格、公表46、データ暗号化規格、1977年1月15日。

  [5]  Information Processing Systems: Data Encipherment: Modes of
       Operation of a 64-bit Block Cipher.

[5] 情報処理システム: データ暗号文: 64ビットのブロックの運転モードは解かれます。

  [6]  Federal Information Processing Standards Publication 81,
       DES Modes of Operation, 2 December 1980.

[6] 連邦政府の情報処理規格、公表81、DES運転モード、1980年12月2日。

Linn                                                            [Page 7]

RFC 1115                Mail Privacy: Algorithms             August 1989

リン[7ページ]RFC1115はプライバシーを郵送します: アルゴリズム1989年8月

  [7]  American National Standard for Information Systems - Data
       Encryption  Algorithm - Modes of Operation (ANSI X3.106-1983),
       American National Standards Institute - Approved 16 May 1983.

[7] 情報システムのための米国標準規格--データ暗号化アルゴリズム--運転モード(ANSI X3.106-1983)、American National Standards Institut--承認された1983年5月16日。

  [8]  CCITT, Recommendation X.509, "The Directory: Authentication
       Framework", Annex C.

[8]CCITT、推薦X.509、「ディレクトリ:」 「認証枠組み」、別館C。

  [9]  Moore, J., "Protocol Failures in Cryptosystems",
       Proceedings of the IEEE, Vol. 76, No. 5, Pg. 597, May 1988.

[9] ムーア、J.、「暗号系におけるプロトコル失敗」、IEEEの議事、Vol.76、No.5、Pg。 597 1988年5月。

Author's Address

作者のアドレス

       John Linn
       Secure Systems
       Digital Equipment Corporation
       85 Swanson Road, BXB1-2/D04
       Boxborough, MA  01719-1326

DEC85スワンソンRoad、BXB1-2/D04 Boxborough、ジョン・リンSecureのSystems MA01719-1326

       Phone: 508-264-5491

以下に電話をしてください。 508-264-5491

       EMail: Linn@ultra.enet.dec.com

メール: Linn@ultra.enet.dec.com

Linn                                                            [Page 8]

リン[8ページ]