RFC1969 日本語訳
1969 The PPP DES Encryption Protocol (DESE). K. Sklower, G. Meyer. June 1996. (Format: TXT=20383 bytes) (Obsoleted by RFC2419) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Sklower
Request for Comments: 1969 University of California, Berkeley
Category: Informational G. Meyer
Spider Systems
June 1996
Sklowerがコメントのために要求するワーキンググループK.をネットワークでつないでください: 1969年のカリフォルニア大学バークレイ校カテゴリ: 情報のG.マイヤークモのシステム1996年6月
The PPP DES Encryption Protocol (DESE)
ppp DES暗号化プロトコル(DESE)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。
The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links.
PPP Encryption Controlプロトコル(ECP)[2]はリンクであるとカプセル化されたPPPの上で暗号化プロトコルを交渉して、利用するメソッドを提供します。
This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets.
このドキュメントはパケットであるとカプセル化されたPPPを暗号化するDES規格[5、6]の使用のための特定の詳細を明らかにします。
Acknowledgements
承認
The authors extend hearty thanks to Fred Baker of Cisco for helpful improvements to the clarity of the document.
作者はシスコのフレッド・ベイカーのおかげでドキュメントの明快への役立っている改良において心からで広がります。
Table of Contents
目次
1. Introduction ................................................ 2 1.1. Motivation ................................................ 2 1.2. Conventions ............................................... 2 2. General Overview ............................................ 2 3. Structure of This Specification ............................. 3 4. DESE Configuration Option for ECP ........................... 4 5. Packet Format for DESE ...................................... 5 6. Encryption .................................................. 6 6.1. Padding Considerations .................................... 6 6.2. Generation of the Ciphertext .............................. 7 6.3. Retrieval of the Plaintext ................................ 8 6.4. Recovery after Packet Loss ................................ 8 7. MRU Considerations .......................................... 8 8. Security Considerations ..................................... 9
1. 序論… 2 1.1. 動機… 2 1.2. コンベンション… 2 2. 概要… 2 3. この仕様の構造… 3 4. ECPのためのDESE設定オプション… 4 5. DESEのためのパケット形式… 5 6. 暗号化… 6 6.1. 問題を水増しします… 6 6.2. 暗号文の世代… 7 6.3. 平文の検索… 8 6.4. パケット損失の後の回復… 8 7. MRU問題… 8 8. セキュリティ問題… 9
Sklower & Meyer Informational [Page 1] RFC 1969 PPP DES Encryption June 1996
[1ページ]RFC1969ppp DES暗号化1996年6月の情報のSklowerとマイヤー
9. References .................................................. 9 10. Authors' Addresses ......................................... 10 11. Expiration Date of this Draft .............................. 10
9. 参照… 9 10. 作者のアドレス… 10 11. このDraftの満了Date… 10
1. Introduction
1. 序論
1.1. Motivation
1.1. 動機
The purpose of this memo is two-fold: to show how one specifies the necessary details of a "data" or "bearer" protocol given the context of the generic PPP Encryption Control Protocol, and also to provide at least one commonly-understood means of secure data transmission between PPP implementations.
このメモの目的は二面です: ジェネリックPPP Encryption Controlプロトコルの文脈を考えて、1つがどう「データ」か「運搬人」プロトコルの必要な詳細を指定するかを示していて、また、提供するために、少なくともあるものは一般的にPPP実装の間の安全なデータ伝送の手段を理解していました。
The DES encryption algorithm is a well studied, understood and widely implemented encryption algorithm. The DES cipher was designed for efficient implementation in hardware, and consequently may be relatively expensive to implement in software. However, its pervasiveness makes it seem like a reasonable choice for a "model" encryption protocol.
DES暗号化アルゴリズムはよく研究された、理解されている、広く実装している暗号化アルゴリズムです。 DES暗号は、ハードウェアの効率的な実装のために設計されて、その結果、ソフトウェアで実装するために比較的高価であるかもしれません。 しかしながら、普及は「モデル」暗号化プロトコルのための正当な選択のように見えるようにします。
Source code implementing DES in the "Electronic Code Book Mode" can be found in [7]. US export laws forbid the inclusion of compilation-ready source code in this document.
[7]で「電子コードブックモード」でDESを実装するソースコードは見つけることができます。 米国輸出法は本書では編集持ち合わせのソースコードの包含を禁じます。
1.2. Conventions
1.2. コンベンション
The following language conventions are used in the items of specification in this document:
以下の言語コンベンションは仕様に関する条項で本書では使用されます:
o MUST, SHALL or MANDATORY -- the item is an absolute requirement
of the specification.
o SHALLかMANDATORY--項目は仕様に関する絶対条件であるに違いありません。
o SHOULD or RECOMMENDED -- the item should generally be followed
for all but exceptional circumstances.
o SHOULDかRECOMMENDED--一般に、商品はほとんど例外的な事情のために従われるべきです。
o MAY or OPTIONAL -- the item is truly optional and may be
followed or ignored according to the needs of the implementor.
o 5月かOPTIONAL--作成者の必要性に従って、商品は、本当に、任意であり、従われているか、または無視されるかもしれません。
2. General Overview
2. 概要
The purpose of encrypting packets exchanged between two PPP implementations is to attempt to insure the privacy of communication conducted via the two implementations. The encryption process depends on the specification of an encryption algorithm and a shared secret (usually involving at least a key) between the sender and receiver.
2つのPPP実装の間で交換されたパケットを暗号化する目的は2つの実装で行われたコミュニケーションのプライバシーを保障するのを試みることです。 暗号化プロセスは送付者と受信機の間で暗号化アルゴリズムの仕様と共有秘密キーによります(通常、少なくともキーにかかわります)。
Sklower & Meyer Informational [Page 2] RFC 1969 PPP DES Encryption June 1996
[2ページ]RFC1969ppp DES暗号化1996年6月の情報のSklowerとマイヤー
Generally, the encryptor will take a PPP packet including the protocol field, apply the chosen encryption algorithm, place the resulting cipher text (and in this specification, an explicit sequence number) in the information field of another PPP packet. The decryptor will apply the inverse algorithm and interpret the resulting plain text as if it were a PPP packet which had arrived directly on the interface.
一般に、暗号化する人はプロトコル分野を含むPPPパケットを持って行って、選ばれた暗号化アルゴリズムを適用してください、そして、結果として起こる暗号テキスト(この仕様の明白な一連番号)を別のPPPパケットの情報フィールドに置いてください。 decryptorはまるでそれが直接インタフェースで到着したPPPパケットであるかのように、逆さのアルゴリズムを適用して、結果として起こるプレーンテキストを解釈するでしょう。
The means by which the secret becomes known to both communicating elements is beyond the scope of this document; usually some form of manual configuration is involved. Implementations might make use of PPP authentication, or the EndPoint Identifier Option described in PPP Multilink [3], as factors in selecting the shared secret. If the secret can be deduced by analysis of the communication between the two parties, then no privacy is guaranteed.
秘密がともに要素を伝えるのに知られるようになる手段はこのドキュメントの範囲を超えています。 通常、何らかのフォームの手動の構成はかかわります。 実装はPPP認証、またはPPP Multilink[3]で説明されたEndPoint Identifier Optionを利用するかもしれません、共有秘密キーを選択する要素として。 2回のパーティーのコミュニケーションの分析で秘密を推論できるなら、プライバシーは全く保証されません。
While the US Data Encryption Standard (DES) algorithm [5, 6] provides multiple modes of use, this specification selects the use of only one mode in conjunction with the PPP Encryption Control Protol (ECP): the Cipher Block Chaining (CBC) mode. In addition to the US Government publications cited above, the CBC mode is also discussed in [7], although no C source code is provided for it per se.
米国データ暗号化規格(DES)アルゴリズム[5、6]は使用の複数の方法を提供しますが、この仕様はPPP Encryption Control Protol(ECP)に関連して1つのモードだけの使用を選択します: Cipher Block Chaining(CBC)モード。 また、上で引用された米国政府刊行物に加えて、[7]でCBCモードについて議論します、そういうものとしてCソースコードを全くそれに提供しませんが。
The initialization vector for this mode is deduced from an explicit 64-bit nonce, which is exchanged in the clear during the negotiation phase. The 56-bit key required by all DES modes is established as a shared secret between the implementations.
このモードのための初期化ベクトルは明白な64ビットの一回だけから推論されます。(それは、交渉段階の間の明確で交換されます)。 すべてのDESモードによって必要とされた56ビットのキーは実装の間の共有秘密キーと書き立てられます。
One reason for choosing the chaining mode is that it is generally thought to require more computation resources to deduce a 64 bit key used for DES encryption by analysis of the encrypted communication stream when chaining mode is used, compared with the situation where each block is encrypted separately with no chaining. Further, if chaining is not used, even if the key is never deduced, the communication may be subject to replay attacks.
推論モードを選ぶ1つの理由は推論モードが状況と比べて使用されるとき、一般に、各ブロックが別々に推論なしでどこに暗号化されるかがDES暗号化に暗号化通信ストリームの分析で使用される64ビットのキーを推論するために、より多くの計算リソースを必要とすると考えられるということです。 さらに、キーが決して推論されないでも推論が使用されていないなら、コミュニケーションは反射攻撃を受けることがあるかもしれません。
However, if chaining is to extend beyond packet boundaries, both the sender and receiver must agree on the order the packets were encrypted. Thus, this specification provides for an explicit 16 bit sequence number to sequence decryption of the packets. This mode of operation even allows recovery from occasional packet loss; details are also given below.
しかしながら、推論がパケット境界を超えて広がるつもりであるなら、送付者と受信機の両方が、オーダーのときにパケットが暗号化されたのに同意しなければなりません。 したがって、この仕様は16ビットの明白な一連番号にパケットの系列復号化に備えます。 この運転モードは時々のパケット損失からの回復を許しさえします。 また、詳細は以下に述べられます。
3. Structure of This Specification
3. この仕様の構造
The PPP Encryption Control Protocol (ECP), provides a framework for negotiating parameters associated with encryption, such as choosing the algorithm. It specifies the assigned numbers to be used as PPP
PPP Encryption Controlプロトコル(ECP)、アルゴリズムを選ぶことなどの暗号化に関連しているパラメタを交渉するのにフレームワークを提供します。 それは、PPPとして使用されるために規定番号を指定します。
Sklower & Meyer Informational [Page 3] RFC 1969 PPP DES Encryption June 1996
[3ページ]RFC1969ppp DES暗号化1996年6月の情報のSklowerとマイヤー
protocol numbers for the "data packets" to be carried as the associated "data protocol", and describes the state machine.
「データ・パケット」が関連「データプロトコル」として運ばれるために数について議定書の中で述べて、州のマシンについて説明します。
Thus, a specification for use in that matrix need only describe any additional configuration options required to specify a particular algorithm, and the process by which one encrypts/decrypts the information once the Opened state has been achieved.
したがって、そのマトリクスにおける使用のための仕様は特定のアルゴリズムを指定するのに必要である追加設定オプションについて説明するだけでよくて、どれが、かつて情報がOpened状態であると暗号化するか、または解読するかによってプロセスは実現されました。
4. DESE Configuration Option for ECP
4. ECPのためのDESE設定オプション
Description
記述
The ECP DESE Configuration Option indicates that the issuing
implementation is offering to employ this specification for
decrypting communications on the link, and may be thought of as
a request for its peer to encrypt packets in this manner.
ECP DESE Configuration Optionは、発行実装がリンクに関するコミュニケーションを解読するためのこの仕様を使うと申し出ていて、同輩がこの様にパケットを暗号化するという要求として考えられるかもしれないのを示します。
The ECP DESE Configuration Option has the following fields,
which are transmitted from left to right:
ECP DESE Configuration Optionには、以下の野原がいます:(その野原は、左から右まで伝えられます)。
Figure 1: ECP DESE Configuration Option
図1: ECP DESE設定オプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Initial Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 一回だけに頭文字をつけてください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
1, to indicate the DESE protocol.
1 DESEプロトコルを示すために。
Length
長さ
10
10
Initial Nonce
初期の一回だけ
This field is an 8 byte quantity which is used by the peer
implementation to encrypt the first packet transmitted
after the sender reaches the opened state.
この分野は同輩実装によって使用される、送付者が開かれた状態に着いた後に伝えられた最初のパケットを暗号化する8バイトの量です。
To guard against replay attacks, the implementation SHOULD
offer a different value during each ECP negotiation. An
反射攻撃に用心するために、実装SHOULDはそれぞれのECP交渉の間、異価を提供します。 1
Sklower & Meyer Informational [Page 4] RFC 1969 PPP DES Encryption June 1996
[4ページ]RFC1969ppp DES暗号化1996年6月の情報のSklowerとマイヤー
example might be to use the number of seconds since Jan
1st, 1970 (GMT/UT) in the upper 32 bits, and the current
number of nanoseconds relative to the last second mark in
the lower 32 bits.
例が1970年1月1日以来の秒数を使用することであるかもしれない、(グリニッジ標準時の/、ユタ) 上側の32ビット、および低級32ビットでの最後の瞬間のマークに比例した数ナノ秒の最新号で。
Its formulaic role is described in the Encryption section
below.
公式の役割は下のEncryption部で説明されます。
5. Packet Format for DESE
5. DESEのためのパケット・フォーマット
Description
記述
The DESE packets themselves have the following fields:
DESEパケット自体には、以下の分野があります:
Figure 2: DES Encryption Protocol Packet Format
図2: DES暗号化プロトコルパケット・フォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | Control | 0000 | Protocol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq. No. High | Seq. No. Low | Ciphertext ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス| コントロール| 0000 | プロトコルID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq。 いいえ 高値| Seq。 いいえ 安値| 暗号文… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address and Control
アドレスとコントロール
These fields MUST be present unless the PPP Address and
Control Field Compression option (ACFC) has been
negotiated.
PPP AddressとControl Field Compressionオプション(ACFC)が交渉されていない場合、これらの分野は存在していなければなりません。
Protocol ID
プロトコルID
The value of this field is 0x53 or 0x55; the latter
indicates that ciphertext includes headers for the
Multilink Protocol, and REQUIRES that the Individual Link
Encryption Control Protocol has reached the opened state.
The leading zero MAY be absent if the PPP Protocol Field
Compression option (PFC) has been negotiated.
この分野の値は、0×53か0×55です。 後者は、暗号文がMultilinkプロトコルのためのヘッダーを含んでいるのを示します、そして、Individual Link Encryption ControlプロトコルにはあるREQUIRESは開かれた状態に達しました。 PPPプロトコルField Compressionオプション(PFC)が交渉されたなら、先行ゼロは欠けているかもしれません。
Sequence Number
一連番号
These 16-bit numbers are assigned by the encryptor
sequentially starting with 0 (for the first packet
transmitted once ECP has reached the opened state.
0から始まって、これらの16ビットの数は暗号化する人によって連続して割り当てられます。(一度伝えられた最初のパケットに関しては、ECPは開かれた状態に達しました。
Sklower & Meyer Informational [Page 5] RFC 1969 PPP DES Encryption June 1996
[5ページ]RFC1969ppp DES暗号化1996年6月の情報のSklowerとマイヤー
Ciphertext
暗号文
The generation of this data is described in the next
section.
このデータの世代は次のセクションで説明されます。
6. Encryption
6. 暗号化
Once the ECP has reached the Opened state, the sender MUST NOT apply the encryption procedure to LCP packets nor ECP packets.
一度ECPはOpened状態に達したことがあって、送付者は暗号化手順をLCPパケットに適用してはいけません。または、ECPパケット。
If the async control character map option has been negotiated on the link, the sender applies mapping after the encryption algorithm has been run.
async制御文字地図オプションがリンクに関して交渉されたなら、暗号化アルゴリズムを実行してある後に送付者はマッピングを適用します。
The encryption algorithm is generally to pad the Protocol and Information fields of a PPP packet to some multiple of 8 bytes, and apply DES in Chaining Block Cipher mode with a 56-bit key K.
暗号化アルゴリズムは、一般に、PPPパケットのプロトコルと情報分野を8バイトの何らかの倍数に水増しして、56ビットの主要なKでChaining Block CipherモードでDESを適用することです。
There are a lot of details concerning what constitutes the Protocol and Information fields, in the presence or non-presence of Multilink, and whether the ACFC and PFC options have been negotiated, and the sort of padding chosen.
何がMultilinkの存在か非前のプロトコルと情報分野を構成するか、そして、ACFCとPFCオプションが交渉されたかどうかに関する多くの詳細、および選ばれる状態でそっと歩く種類があります。
Regardless of whether ACFC has been negotiated on the link, the sender applies the encryption procedure to only that portion of the packet excluding the address and control field.
ACFCがリンクに関して交渉されたかどうかにかかわらず、送付者はアドレスと制御フィールドを除いたパケットのその一部だけに暗号化手順を適用します。
If the Multilink Protocol has been negotiated and encryption is to be construed as being applied to each link separately, then the encryption procedure is to be applied to the (possibly extended) protocol and information fields of the packet in the Multilink Protocol.
暗号化手順は暗号化がMultilinkプロトコルが交渉されて、別々にそれぞれリンクするために適用されるのに理解されることであるならMultilinkプロトコルでパケットの(ことによると広げられます)のプロトコルと情報フィールドに適用されることです。
If the Multilink Protocol has been negotiated and encryption is to be construed as being applied to the bundle, then the multilink procedure is to be applied to the resulting DESE packets.
マルチリンク手順は暗号化がMultilinkプロトコルが交渉されて、バンドルに適用されるのに理解されることであるなら結果として起こるDESEパケットに適用されることです。
6.1. Padding Considerations
6.1. 問題を水増しします。
Since the DES algorithm operates on blocks of 8 octets, packets which are of length not a multiple of 8 octets must be padded. This can be injurious to the interpretation of some protocols which do not contain an explicit length field in their protocol headers. (Additional padding of the ciphered packet for the purposes of transmission by HDLC hardware which requires an even number of bytes should not be necessary since the information field will now be of length a multiple of 8, and whether or not the packet is of even length can be forced by use or absence of a leading zero in the
DESアルゴリズムが8つの八重奏のブロックを作動させるので、倍数ではなく、8つの八重奏の長さのものであるパケットを水増ししなければなりません。 これは彼らのプロトコルヘッダーに明白な長さの分野を含まないいくつかのプロトコルの解釈に有害である場合があります。 (現在情報フィールドが8の長さのa倍数のものになるので、バイトの偶数を必要とするHDLCハードウェアによるトランスミッションの目的のための解かれたパケットの追加詰め物は必要であるべきでなくて、先行ゼロの使用か欠如でパケットが長ささえのものであるかどうか中に強制できます。
Sklower & Meyer Informational [Page 6] RFC 1969 PPP DES Encryption June 1996
[6ページ]RFC1969ppp DES暗号化1996年6月の情報のSklowerとマイヤー
protocol field).
プロトコル分野)
For protocols which do have an explicit length field, such as IP, IPX, XNS, and CLNP, then padding may be accomplished by adding random trailing garbage. Even when performing the Multilink protocol, if it is only being applied to packets with explicit length fields, and if care is taken so that all non-terminating fragments (i.e., those not bearing the (E)nd bit) are of lengths divisible by 8; then no ill effects will happen if garbage padding is applied only to terminating fragments.
そして、IPや、IPXや、XNSや、CLNPなどの明白な長さの分野を持っているプロトコルにおいて、詰め物は、無作為の引きずっているゴミを加えることによって、実行されるかもしれません。 すべての非の終わりが働くときさえ、Multilinkは議定書を作ります、それが明白な長さの分野でパケットに適用された、唯一の存在であり、注意するなら断片化する、(すなわち、(E)に堪えないもの、ビット) 第8で分割可能な長さがあります。 そして、ゴミ詰め物が断片を終えるだけに適用されると、害は全く起こらないでしょう。
For certain cases, such as the PPP bridging protocol when the trailing CRC is forwarded or when any bridging is being applied to protocols not having explicit length fields, adding garbage changes the interpretation of the packet. The self-describing padding option [4] permits unambiguous removal of padded bytes; although it should only be used when absolutely necessary as it may inadvertently require adding as many as 8 octets to packets that could otherwise be left unaltered.
引きずっているCRCを進めるとき、PPPのブリッジすることなどのあるケースが議定書を作るか、またはどんなブリッジすることが明白な長さの分野を持っていないプロトコルに適用されているとき、ゴミを加えると、パケットの解釈は変化します。 自己について説明する詰め物オプション[4]はそっと歩いているバイトの明白な取り外しを可能にします。 絶対に必要であるときにだけ、最大8つの八重奏をパケットに加えるのがうっかり必要であるときに、それは使用されるべきでしたが、そうでなければ、非変更されるようにそれを残すことができました。
Consider a packet, which by unlucky circumstance is already a
multiple of 8 octets, but terminates in the sequence 0x1, 0x2.
Self-describing padding would otherwise remove the trailing two
bytes. For purposes of coexistence with archaic HDLC chips where
it is necessary to transmit packets of even length, one would
normally only have to add an additional two octets (0x1, 0x2),
which could then be removed. However, since the packet was
initially a multiple of 8 bytes, an additional 8 bytes would need
to be added.
パケットを考えてください。(不運の状況で、それは、既に8つの八重奏の倍数ですが、系列0×1、0x2で終わります)。 そうでなければ、そっと歩くと自己に説明するのが引きずることを2バイト取り除くでしょう。 長ささえのパケットを伝えるのが必要である古風なHDLCチップとの共存の目的のために、通常、人は追加2つの八重奏(0×1、0×2)を加えるだけでよいでしょう。(次に、八重奏を取り除くことができました)。 しかしながら、初めはパケットがそうであったので、8バイトの倍数、追加8バイトは、加えられる必要があるでしょう。
6.2. Generation of the Ciphertext
6.2. 暗号文の世代
In this discussion, E[k] will denote the basic DES cipher determined by a 56-bit key k acting on 64 bit blocks. and D[k] will denote the corresponding decryption mechanism. The padded plaintext described in the previous section then becomes a sequence of 64 bit blocks P[i] (where i ranges from 1 to n). The circumflex character (^) represents the bit-wise exclusive-or operation applied to 64-bit blocks.
この議論では、E[k]は64ビットのブロックD[k]に影響する56ビットのキーkが対応する復号化メカニズムを指示することを決定している基本的なDES暗号を指示するでしょう。 その時前項で説明されたそっと歩いている平文は64ビットのブロックP[i](iが1〜nまで及ぶところ)の系列になります。 曲折アクセントのキャラクタ(^)は64ビットのブロックに適用されたビット的な排他的論理和操作を表します。
When encrypting the first packet to be transmitted in the opened state let C[0] be the result of applying E[k] to the Initial Nonce received in the peer's ECP DESE option; otherwise let C[0] be the final block of the previously transmitted packet.
開かれた状態で伝えられるべき最初のパケットを暗号化するときには、C[0]が同輩のECP DESEオプションで受け取られたInitial NonceにE[k]を適用するという結果であることをさせてください。 さもなければ、C[0]が以前に伝えられたパケットの最終的なブロックであることをさせてください。
Sklower & Meyer Informational [Page 7] RFC 1969 PPP DES Encryption June 1996
[7ページ]RFC1969ppp DES暗号化1996年6月の情報のSklowerとマイヤー
The ciphertext for the packet is generated by the iterative process
パケットのための暗号文は繰り返し作業で生成されます。
C[i] = E[k](P[i] ^ C[i-1])
C[i]はE[k]と等しいです。(P[i]^C[i-1])
for i running between 1 and n.
1とnの間稼働するiのために。
6.3. Retrieval of the Plaintext
6.3. 平文の検索
When decrypting the first packet received in the opened state, let C[0] be the result of applying E[k] to the Initial Nonce transmitted in the ECP DESE option. The first packet will have sequence number zero. For subsequent packets, let C[0] be the final block of the previous packet in sequence space. Decryption is then accomplished by
開かれた状態に受け取られた最初のパケットを解読するときには、C[0]がECP DESEオプションで伝えられたInitial NonceにE[k]を適用するという結果であることをさせてください。 最初のパケットには、一連番号ゼロがあるでしょう。 その後のパケットに関しては、系列スペースでC[0]が前のパケットの最終的なブロックであることをさせてください。 そして、復号化は達成されます。
P[i] = C[i-1] ^ D[k](C[i]),
P[i]が^C[i-1]D[k]と等しい、(C[i])
for i running between 1 and n.
1とnの間稼働するiのために。
6.4. Recovery after Packet Loss
6.4. パケット損失の後の回復
Packet loss is detected when there is a discontinuity in the sequence numbers of consecutive packets. Suppose packet number N - 1 has an unrecoverable error or is otherwise lost, but packets N and N + 1 are received correctly.
連続したパケットの一連番号に不連続があるとき、パケット損失は検出されます。 パケット番号であるなら、N--1を回復不能エラーを持っているか、または別の方法で失いますが、正しくパケットNとN+1を受け取ります。
Since the algorithm in the previous section requires C[0] for packet N to be C[last] for packet N - 1, it will be impossible to decode packet N. However, all packets N + 1 and following can be decoded in the usual way, since all that is required is the last block of ciphertext of the previous packet (in this case packet N, which WAS received).
前項のアルゴリズムが[最後に]パケットNがパケットN--1のためのCであるためにC[0]を必要とするので、不断のとおりパケットN.However、すべてのパケットN+1、および次の事柄を解読するのを解読できるのは不可能でしょう、必要であるすべてが前のパケット(この場合受け取られたパケットN)の暗号文の最後のブロックであるので。
7. MRU Considerations
7. MRU問題
Because padding can occur, and because there is an additional protocol field in effect, implementations should take into account the growth of the packets. As an example, if PFC had been negotiated, and if the MRU before had been exactly a multiple of 8, then the plaintext resulting combining a full sized data packets with a one byte protocol field would require an additional 7 bytes of padding, and the sequence number would be an additional 2 bytes so that the information field in the DESE protocol is now 10 bytes larger than that in the original packet. Because the convention is that PPP options are independent of each other, negotiation of DESE does not, by itself, automatically increase the MRU value.
詰め物が起こることができて、事実上、追加議定書分野があるので、実装はパケットの成長を考慮に入れるべきです。 例、PFCが交渉されていて、MRUである、以前、まさに8の倍数、次に追加2がDESEプロトコルの情報フィールドがオリジナルのパケットのそれより10バイト大きい現在ためのバイトであったなら1バイトのプロトコル分野があるパケットがそっと歩きながら追加7バイトを必要とする完全な大きさで分けられたデータ、および一連番号を結合しながら結果として生じる平文はそうです。 コンベンションがPPPオプションが互いから独立しているということであるので、DESEの交渉自体は自動的にMRU値を増強しません。
Sklower & Meyer Informational [Page 8] RFC 1969 PPP DES Encryption June 1996
[8ページ]RFC1969ppp DES暗号化1996年6月の情報のSklowerとマイヤー
8. Security Considerations
8. セキュリティ問題
Security issues are the primary subject of this memo. This proposal relies on exterior and unspecified methods for authentication and retrieval of shared secrets.
安全保障問題はこのメモのプライマリ対象です。 この提案は共有秘密キーの認証と検索のための外の、そして、不特定のメソッドを当てにします。
It proposes no new technology for privacy, but merely describes a convention for the application of the DES cipher to data transmission between PPP implementation.
それは、プライバシーのために新技術を全く提案しませんが、DES暗号の応用のために単にPPP実装の間のデータ伝送にコンベンションについて説明します。
Any methodology for the protection and retrieval of shared secrets, and any limitations of the DES cipher are relevant to the use described here.
共有秘密キーの保護と検索、およびDES暗号のどんな制限のためのどんな方法論もそうです。ここで説明された使用に関連しています。
9. References
9. 参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, Daydreamer, July 1994.
[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、空想家、1994年7月。
[2] Meyer, G., "The PPP Encryption Protocol", RFC 1968, Spider
Systems, June 1996.
[2] マイヤー、G.、「ppp暗号化プロトコル」、RFC1968、クモのシステム、1996年6月。
[3] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The PPP
Multilink Protocol (MP)", RFC 1717, UC Berkeley, November 1994.
[3] Sklower、K.、ロイド、B.、マクレガー、G.、およびD.カー、「pppマルチリンクは(MP)について議定書の中で述べます」、RFC1717、UCバークレー1994年11月。
[4] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer,
January 1994.
[4] シンプソン、W.、エディタ、「ppp LCP拡張子」、RFC1570、空想家、1994年1月。
[5] National Bureau of Standards, "Data Encryption Standard", FIPS
PUB 46 (January 1977).
[5]規格基準局、「データ暗号化規格」、FIPSパブ46(1977年1月)。
[6] National Bureau of Standards, "DES Modes of Operation", FIPS PUB
81 (December 1980).
[6]規格基準局、「DES運転モード」、FIPSパブ81(1980年12月)。
[7] Schneier, B., "Applied Cryptography - Protocols Algorithms, and
source code in C", John Wiley & Sons, Inc. 1994. There is an
errata associated with the book, and people can get a copy by
sending e-mail to schneier@counterpane.com.
[7] シュナイアー、B.、「適用されたCryptography--プロトコルAlgorithms、およびC」、ジョン・ワイリー、およびソンスInc.1994におけるソースコード。 本に関連している誤字があります、そして、人々はメールを schneier@counterpane.com に送ることによって、コピーを手に入れることができます。
Sklower & Meyer Informational [Page 9] RFC 1969 PPP DES Encryption June 1996
[9ページ]RFC1969ppp DES暗号化1996年6月の情報のSklowerとマイヤー
10. Authors' Addresses
10. 作者のアドレス
Keith Sklower Computer Science Department 384 Soda Hall, Mail Stop 1776 University of California Berkeley, CA 94720-1776
キースSklowerコンピュータ理学部384ソーダホール、1776カリフォルニア大学バークレー、メールStopカリフォルニア94720-1776
Phone: (510) 642-9587 EMail: sklower@CS.Berkeley.EDU
以下に電話をしてください。 (510) 642-9587 メールしてください: sklower@CS.Berkeley.EDU
Gerry M. Meyer Spider Systems Stanwell Street Edinburgh EH6 5NG Scotland, UK
ゲリー・M.マイヤー・Spider Systems Stanwell通りエディンバラEH6 5NGスコットランド、イギリス
Phone: (UK) 131 554 9424 Fax: (UK) 131 554 0649 EMail: gerry@spider.co.uk
以下に電話をしてください。 (イギリス) 131 554、9424Fax: (イギリス) 0649年の131 554メール: gerry@spider.co.uk
Sklower & Meyer Informational [Page 10]
SklowerとマイヤーInformationalです。[10ページ]
一覧
スポンサーリンク
