RFC1824 日本語訳
1824 The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange(E.I.S.S.-Report 1995/4). H. Danisch. August 1995. (Format: TXT=45540 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group H. Danisch Request for Comments: 1824 E.I.S.S./IAKS Category: Informational August 1995
Danischがコメントのために要求するワーキンググループH.をネットワークでつないでください: 1824年のE.I.S.S./IAKSカテゴリ: 情報の1995年8月
The Exponential Security System TESS:
An Identity-Based Cryptographic Protocol
for Authenticated Key-Exchange
(E.I.S.S.-Report 1995/4)
指数のセキュリティSystemテス: 認証された主要な交換のためのアイデンティティベースの暗号のプロトコル(E.I.S.S.レポート1995/4)
Status of this Memo
この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
要約
This informational RFC describes the basic mechanisms and functions of an identity based system for the secure authenticated exchange of cryptographic keys, the generation of signatures, and the authentic distribution of public keys.
この情報のRFCは基本的機構、暗号化キーの安全な認証された交換のアイデンティティに基づいているシステムの機能、署名の生成、および公開鍵の正統の分配について説明します。
Table of Contents
目次
1. Introduction and preliminary remarks . . . . . . . . . . . . . 2
1.1. Definition of terms/Terminology . . . . . . . . . . . . 2
1.2. Required mechanisms . . . . . . . . . . . . . . . . . . 4
2. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. SKIA Setup . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. User Setup . . . . . . . . . . . . . . . . . . . . . . . 5
3. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Zero Knowledge Authentication . . . . . . . . . . . . . 7
3.2. Unilateral Authentication . . . . . . . . . . . . . . . 8
3.3. Mutual Authentication . . . . . . . . . . . . . . . . . 9
3.4. Message Signing . . . . . . . . . . . . . . . . . . . . 10
4. Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Non-Escrowed Key Generation . . . . . . . . . . . . . . 11
4.2. Hardware Protected Key . . . . . . . . . . . . . . . . . 11
4.3. Key Regeneration . . . . . . . . . . . . . . . . . . . . 12
4.4. r ^ r . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5. Implicit Key Exchange . . . . . . . . . . . . . . . . . 13
4.6. Law Enforcement . . . . . . . . . . . . . . . . . . . . 13
4.7. Usage of other Algebraic Groups . . . . . . . . . . . . 14
4.7.1 DSA subgroup SKIA Setup . . . . . . . . . . . . . 14
4.7.2 Escrowed DSA subgroup User Setup . . . . . . . . 14
4.7.3 Non-Escrowed DSA subgroup User Setup . . . . . . 15
4.7.4 DSA subgroup Authentication . . . . . . . . . . . 15
1. 序論と緒言. . . . . . . . . . . . . 2 1.1。 用語/用語. . . . . . . . . . . . 2 1.2の定義。 必要なメカニズム. . . . . . . . . . . . . . . . . . 4 2。 .52.1をセットアップしてください。 SKIAは.52.2をセットアップします。 ユーザセットアップ. . . . . . . . . . . . . . . . . . . . . . . 5 3。 認証. . . . . . . . . . . . . . . . . . . . . . . . 7 3.1。 知識認証. . . . . . . . . . . . . 7 3.2のゼロを合わせてください。 一方的な認証. . . . . . . . . . . . . . . 8 3.3。 互いの認証. . . . . . . . . . . . . . . . . 9 3.4。 メッセージ調印. . . . . . . . . . . . . . . . . . . . 10 4。 増進. . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1。 非Escrowedキー生成. . . . . . . . . . . . . . 11 4.2。 ハードウェアはキー. . . . . . . . . . . . . . . . . 11 4.3を保護しました。 主要な再生. . . . . . . . . . . . . . . . . . . . 12 4.4r^r. . . . . . . . . . . . . . . . . . . . . . . . . 13 4.5。 暗黙の主要な交換. . . . . . . . . . . . . . . . . 13 4.6。 法の執行. . . . . . . . . . . . . . . . . . . . 13 4.7。 他のAlgebraic Groups. . . . . . . . . . . . 14 4.7.1DSAサブグループSKIA Setup. . . . . . . . . . . . . 14 4.7.2Escrowed DSAサブグループUser Setup. . . . . . . . 14 4.7.3Non-Escrowed DSAサブグループUser Setup. . . . . . 15 4.7.4DSAサブグループAuthentication. . . . . . . . . . . 15の使用法
Danisch Informational [Page 1] RFC 1824 TESS August 1995
[1ページ]RFC1824テス1995年8月の情報のDanisch
5. Multiple SKIAs . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Unstructured SKIAs . . . . . . . . . . . . . . . . . . . 15
5.2. Hierarchical SKIAs . . . . . . . . . . . . . . . . . . . 16
5.3. Example: A DNS-based public key structure . . . . . . . 18
Security Considerations . . . . . . . . . . . . . . . . . . . . . 19
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
5. 複数のSKIAs.155.1。 不統一なSKIAs. . . . . . . . . . . . . . . . . . . 15 5.2。 階層的なSKIAs. . . . . . . . . . . . . . . . . . . 16 5.3。 例: DNSベースの公開鍵構造. . . . . . . 18Security Considerations. . . . . . . . . . . . . . . . . . . . . 19References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20AuthorのAddress. . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction and preliminary remarks
1. 序論と緒言
This RFC describes The Exponential Security System TESS [1]. TESS is a toolbox set system of different but cooperating cryptographic mechanisms and functions based on the primitive of discrete exponentiation. TESS is based on asymmetric cryptographical protocols and a structure of self-certified public keys.
このRFCはExponential Security Systemテス[1]について説明します。 テスは異なりましたが、協力関係を持っている暗号のメカニズムと離散的な羃法の原始に基づく機能の道具箱セットシステムです。 テスは自己に公認された公開鍵の非対称の暗号のプロトコルと構造に基づいています。
The most important mechanisms TESS is based on are the ElGamal signature [2, 3] and the KATHY protocols (KeY exchange with embedded AuTHentication), which were simultaneously discovered by Guenther [4] and Bauspiess and Knobloch [5, 6, 7].
テスが基づいている最も重要なメカニズムは、ElGamal署名[2、3]とキャシープロトコル(埋め込まれたAuTHenticationとのKeY交換)です。(そのプロトコルは同時に、グンサー[4]、Bauspiess、およびクノブロッフ[5、6、7]によって発見されました)。
This RFC explains how to create and use the secret and public keys of TESS and shows a method for the secure distribution of the public keys.
このRFCはどのようにテスの秘密と公開鍵を作成して、使用するかを説明して、公開鍵の安全な分配のための方法を示しています。
It is expected that the reader is familiar with the basics of cryptography, the Discrete Logarithm Problem, and the ElGamal signature mechanism.
読者が暗号の基礎、Discrete Logarithm Problem、およびElGamal署名メカニズムに詳しいと予想されます。
Due to the ASCII representation of this RFC the following style is choosen for mathematical purposes:
このRFCのASCII表現のために、以下のスタイルは数学の目的のためにchoosenです:
- a ^ b means the exponentiation of a to the power of b, which is
always used within a modulo context.
- ^bはbのパワーにaの羃法を意味します。(bは法文脈の中でいつも使用されます)。
- a[b] means a with an index or subscription of b.
- a[b]はbのインデックスか購読でaを意味します。
- a = b means equality or congruency within a modulo context.
- =bは法文脈の中で平等か適合を意味します。
1.1. Definition of terms/Terminology
1.1. 用語/用語の定義
Key pair
重要組
A key pair is a set of a public and a secret key which belong
together. There are two distinct kinds of key pairs, the SKIA key
pair and the User key pair. (As will be shown in the section about
hierarchical SKIAs, the two kinds of keys are not really distinct.
They are the same thing seen from a different point of view.)
主要な組はグループを成す公共のキーと秘密のキーの1セットです。 異なった2種類の主要な組、SKIA主要な組、およびUser主要な組があります。 (階層的なSKIAsに関するセクションで示されるように、2種類のキーは本当に異なっていません。 それらは異なった観点から見られた同じものです。)
Danisch Informational [Page 2] RFC 1824 TESS August 1995
[2ページ]RFC1824テス1995年8月の情報のDanisch
User
ユーザ
Any principal (human or machine) who owns, holds and uses a User
key pair and can be uniquely identified by any description (see
the Identity Descriptor below).
Userかぎを所有して、保持して、使用するどんな校長(人間かマシン)も、対にして、どんな記述でも唯一特定できます(以下のIdentity Descriptorを見ます)。
In this RFC example users are referred to as A, B, C or Alice and
Bob.
このRFCでは、例のユーザはAかBかCかアリスとボブと呼ばれます。
SKIA
SKIA
SKIA is an acronym for "Secure Key Issuing Authority". The SKIA is
a trusted local authority which generates the public and secret
part of a User key pair. It is the SKIA's duty to verify whether
the identity encoded in the key pair (see below) belongs to the
key holder. It has to check passports, identity cards, driving
licenses etc. to investigate the real world identity of the key
owner. Since every key has an implicite signature of the SKIA it
came from, the SKIA is responsible for the correctness of the
encoded identity.
SKIAは「安全な主要な発行機関」のための頭文字語です。 SKIAはUser主要な組の公共の、そして、秘密の部分を発生させる信じられた地方公共団体です。 主要な組(以下を見る)でコード化されたアイデンティティが主要な所有者のものであるかどうか確かめるのは、SKIAの義務です。 主要な所有者の本当の世界のアイデンティティを調査するようにライセンスなどに追い立てて、それはパスポート、身分証明書をチェックしなければなりません。 あらゆるキーにはそれが来たSKIAのimplicite署名があるので、SKIAはコード化されたアイデンティティの正当性に責任があります。
Since the SKIA has to check the real identity of users, it is
usually able to work within a small physical range only (like a
campus or a city). Therefore, not all users of a wide area or
world wide area network can get their keys from the same SKIA with
reasonable expense. There is the need for multiple SKIAs which
can work locally. This implies the need of a web of trust levels
and trust forwards. Communication partners with keys from the
same SKIA know the public data of their SKIA because it is part of
their own key. Partners with keys from different SKIAs have to
make use of the web to learn about the origin, the trust level,
and the public key of the SKIA which issued the other key.
SKIAがユーザの正体をチェックしなければならないので、通常、それは小さい物理的な範囲だけの中で働くことができます。 したがって、すべてではなく、広い領域か世界的な領域ネットワークのユーザは手頃な費用がある同じSKIAから彼らのキーを手に入れることができます。 局所的に働くことができる複数のSKIAsの必要があります。 これは前方に信用レベルと信用のウェブの必要性を含意します。 それがそれら自身のキーの一部であるので同じSKIAからのキーのコミュニケーションパートナーはそれらのSKIAに関する公衆データを知っています。 異なったSKIAsからのキーのパートナーは、もう片方のキーを支給したSKIAの起源、信用レベル、および公開鍵に関して学ぶのにウェブを利用しなければなりません。
Id[A] Identity Descriptor
イド[A]アイデンティティ記述子
The Identity Descriptor is a part of the public User key. It is a
somehow structured bitstring describing the key owner in a certain
way. This description of the key owner should be precise enough to
fully identify the owner of a User key. The description depends on
the nature of the owner. For a human this could be the name, the
address, the phone number, date of birth, size of the feet, color
of the eyes, or anything else. For a machine this could be the
hostname, the hostid, the internet address etc., for a fax machine
or a modem it could be the international phone number.
Identity Descriptorは公共のUserキーの一部です。 それはある方法で主要な所有者について説明するどうにか構造化されたbitstringです。 主要な所有者のこの記述はUserキーの所有者を完全に特定するほど正確であるべきです。 記述は所有者の自然によります。 人間にとって、これは、名前、アドレス、電話番号、生年月日、足のサイズ、目の色、または他の何かであるかもしれません。 マシンに関しては、これがホスト名、インターネットアドレスhostidであるかもしれないなど、ファックス装置かモデムに関して、それは国際的な電話番号であるかもしれません。
Furthermore, the description bitstring could contain key
management data as the name of the SKIA (see below) which issued
the key, the SKIA-specific serial number, the expiry date of the
その上、記述bitstringはSKIA(下を見る)というキーを支給した名前、満期がデートするSKIA特有の通し番号としてかぎ管理データを含むかもしれません。
Danisch Informational [Page 3] RFC 1824 TESS August 1995
[3ページ]RFC1824テス1995年8月の情報のDanisch
key, whether the secret part of the key is a software key or
hidden in a hardware device (see section Enhancements), etc.
キーの秘密の部分が主要であるかハードウェアデバイス(セクションEnhancementsを見る)に隠されたソフトウェアであることなどでのキー
Note that the numerical interpretation (the hash value) of the
Identity Descriptor is an essential part of the mathematical
mechanism of the TESS protocol. It can not be changed in any way
without destroying the key structure. Therefore, knowing the
public part of a user key pair always means knowing the Identity
Descriptor as composed by the SKIA which issued this key. This is
an important security feature of this mechanism.
Identity Descriptorの数字の解釈(ハッシュ値)がテスプロトコルの数学のメカニズムの不可欠の部分であることに注意してください。 主要な構造を破壊しないで、何らかの方法でそれを変えることができません。 したがって、ユーザ主要な組の公共の部分を知っているのは、いつもこのキーを支給したSKIAによって構成されるようにIdentity Descriptorを知ることを意味します。 これはこのメカニズムの重要なセキュリティ機能です。
The contents of the Identity Descriptor have to be verified by the
issuing SKIA at key generation time. The trust level of the User
Key depends on the trust level of the SKIA. A certain Identity
Descriptor must not be used more than once for creating a User
Key. There must not exist distinct keys with the same Identity
Descriptor. Nevertheless, a user may have several keys with
distinct expiration times, key lengths, serial numbers, or
security levels, which affect the contents of the Identity
Descriptor.
Identity Descriptorの内容はキー生成時に発行しているSKIAによって確かめられなければなりません。 User Keyの信用レベルはSKIAの信用レベルに依存します。 User Keyを作成するための一度よりあるIdentity Descriptorを使用してはいけません。 同じIdentity Descriptorがある異なったキーは存在してはいけません。 それにもかかわらず、ユーザはIdentity Descriptorのコンテンツに影響する異なった満了時間、キー長、通し番号、またはセキュリティー・レベルがある数個のキーを持っているかもしれません。
However, it is emphasized that there are no assumptions about the
structure of the Identity Descriptor. The SKIA may choose any
construction method depending on its purposes.
しかしながら、Identity Descriptorの構造に関する仮定が全くないと強調されます。 SKIAは目的によるどんな工法も選ぶかもしれません。
The Identity Descriptor of a certain user A is referred to as
Id[A]. Whereever the Identity Descriptor Id[A] is used in a
mathematical context, its cryptographical hash sum H(Id[A]) is
used.
確信しているユーザAのIdentity DescriptorはId[A]と呼ばれます。 Whereever Identity Descriptor Id[A]は数学の文脈、暗号の細切れ肉料理合計Hに使用されます。(使用されるイド[A])。
Encrypt(Key,Message) Decrypt(Key,Message)
(キー、メッセージ)をコード化してください、解読する。(キー、メッセージ)
Encryption and Decryption of the Message with any common cipher.
いずれも一般的のMessageの暗号化とDecryptionは解きます。
1.2. Required mechanisms
1.2. 必要なメカニズム
The protocols described in this RFC require the following submechanisms:
このRFCで説明されたプロトコルは以下の「副-メカニズム」を必要とします:
- A random number generator of cryptographic quality
- 暗号の品質の乱数発生器
- A prime number generator of cryptographic quality
- 暗号の品質の素数ジェネレータ
- A hash mechanism H() of cryptographic quality
- 暗号の品質の細切れ肉料理メカニズムH()
- An encryption mechanism (e.g. a common block cipher)
- 暗号化メカニズム(例えば、共通ブロック暗号)
Danisch Informational [Page 4] RFC 1824 TESS August 1995
[4ページ]RFC1824テス1995年8月の情報のDanisch
- An arithmetical library for long unsigned integers
- 長い符号のない整数のための算術ライブラリ
- A method for checking network identities against real-world
identities (e.g. an authority which checks human identity cards
etc.)
- 本当の世界のアイデンティティに対してネットワークのアイデンティティをチェックするための方法(例えば、身分証明書の人間のなどをチェックする権威)
2. Setup
2. セットアップ
This section describes the base method for the creation of the SKIA and the User key pairs. Enhancements and modifications are described in subsequent sections.
このセクションはベース方法をSKIAの創造とUser主要な組説明します。 増進と変更はその後のセクションで説明されます。
The main idea of the protocols described below is to generate an ElGamal signature (r,s) for an Identity Descriptor Id[A] of a user A. Id[A] and r form the user's public key and s is the users secret key. The connection between the secret and the public key is the verification equation for the ElGamal signature (r,s). Instead of checking the signature (r,s), the equation is used in 'reverse mode' to calculate r^s from public data without knowledge of the secret s.
以下で説明されたプロトコルの本旨はユーザA.のIdentity Descriptor Id[A]のために、ElGamal署名(r、s)を発生させることです。Id[A]とrはユーザの公開鍵を形成します、そして、sはユーザ秘密鍵です。 秘密と公開鍵との関係はElGamal署名(r、s)のための検証方程式です。 署名(r、s)をチェックすることの代わりに、方程式は、公衆データから秘密sに関する知識なしでr^sについて計算するのに'逆のモード'で使用されます。
The authority generating those signatures is the SKIA introduced above.
それらの署名を発生させる権威は上で導入されたSKIAです。
2.1. SKIA Setup
2.1. SKIAセットアップ
By the following steps the SKIA key pair is created:
以下のステップで、SKIA主要な組は創設されます:
- p: choose a large prime p of at least 512 bit length.
- p: 少なくとも512ビットの長さの大きい第1pを選んでください。
- g: choose a primitive root g in GF(p)
- g: GFで原始根gを選んでください。(p)
- x: choose a random number x in the range 1 < x < p-1
- x: 1<xの範囲<p-1の乱数xを選んでください。
- y:= ( g ^ x ) mod p
- y: =(g^x)モッズp
The public part of the SKIA is the triple (p,g,y), the secret part is x.
SKIAの公共の部分が三重(p、g、y)である、秘密の部分はxです。
Since the public triple (p,g,y) is needed within the verification equation for the signatures created by the SKIA, this triple is also an essential part of all user keys generated by this SKIA.
公共の三重(p、g、y)がSKIAによって作成された署名のための検証方程式の中で必要であるので、また、この三重はこのSKIAによって発生したすべてのユーザキーの不可欠の部分です。
2.2. User Setup
2.2. ユーザセットアップ
The User Setup is the generation of an ElGamal signature on the user's Identity Descriptor by the SKIA. This can be done more than once for a specific User, but it is done only once for a specific Identity Descriptor.
User SetupはSKIAによるユーザのIdentity DescriptorにおけるElGamal署名の世代です。 特定のUserのための一度よりそれ以上のことがこれにできますが、特定のIdentity Descriptorのために一度だけそれをします。
Danisch Informational [Page 5] RFC 1824 TESS August 1995
[5ページ]RFC1824テス1995年8月の情報のDanisch
To create a User key pair for a User A, the SKIA has to perform the following steps:
User AのためにUser主要な組を創設するために、SKIAは以下のステップを実行しなければなりません:
- Id[A]: Describe the key owner A in any way (name, address, etc.),
convert this description into a bit- or byte-oriented
representation, and concatenate them to form the Identity
Descriptor Id[A].
- イド[A]: (名前、アドレスなど)がこの記述を少し変換するどんな方法かバイト指向の表現でも主要な所有者Aについて説明してください、そして、それらを連結して、Identity Descriptor Id[A]を形成してください。
- k[A]: choose a random number k[A] with gcd(k[A],p-1) = 1. k[A]
must not be revealed by the SKIA.
- k[A]: 最大公約数(k[A]、p-1)=1がある乱数k[A]を選んでください。k[A]はSKIAによって明らかにされてはいけません。
- r[A] := ( g ^ k[A] ) mod p
- r[A]:=、(g^k[A] )モッズp
- s[A] := ( H(Id[A]) - x * r[A] ) * ( k[A] ^ -1 ) mod (p-1)
- s[A]:=、(H、(イド[A])--、x*r[A] )*(k[A]^-1)モッズ(p-1)
The calculated set of numbers fulfills the equation:
計算された一連の数字は方程式を実現させます:
x * r[A] + s[A] * k[A] = H(Id[A]) mod (p-1).
x*r[A]+s[A]*k[A]はHと等しいです。(イド[A])モッズ(p-1。)
The public part of the generated key of A consists of Id[A] and r[A], referenced to as (Id[A],r[A]) in the context of the triple (p,g,y). (Id[A],r[A]) always implicitely refers to the triple (p,g,y) of its parent SKIA.
公衆がId[A]とr[A]から成って、参照をつけられるAの発生しているキーを離れさせる、(イド[A](三重(p、g、y)の文脈のr[A]))。 (イド[A]、r[A]) いつもimplicitelyは親SKIAの三重(p、g、y)について言及します。
The secret part of the key is s[A].
キーの秘密の部分はs[A]です。
k[A] must be destroyed by the SKIA immediately after key generation, because User A could solve the equation and find out the SKIAs secret x if he knew both the s[A] and k[A]. The random number k must not be used twice. s[A] must not be equal to 0.
SKIAはキー生成直後k[A]を破壊しなければなりません、彼がs[A]とk[A]の両方を知っているなら、User Aが方程式を解決して、SKIAs秘密xを見つけることができるので。 二度乱数kを使用してはいけません。s[A]は0と等しいはずがありません。
Since (r[A],s[A]) are the ElGamal signature on Id[A], the connection between the SKIA public key und the User key pair is the ElGamal verification equation:
以来、(r[A]、s[A])がId[A]におけるElGamal署名である、Userが合わせるSKIA公開鍵undの間の接続はElGamal検証方程式ではありません:
r[A] ^ s[A] = ( g ^ H(Id[A]) ) * ( y ^ (-r[A]) ) mod p.
r[A]^s[A]が等しい、(g^H、(イド[A]) )*、(y^、(-r[A]) )モッズp。
This equation allows to calculate r[A] ^ s[A] from public data without knowledge of the secret s[A]. Since this equation is used very often, and for reasons of readability, the abbreviation Y[A] is used for this equation.
この方程式で、公衆データから秘密のs[A]に関する知識なしでr[A]^s[A]について計算します。 この方程式が頻繁、および読み易さの理由に使用されるので、略語Y[A]はこの方程式に使用されます。
Y[A] means to calculate the value of r[A] ^ s[A] which is
Y[A]は、そうするr[A]^s[A]の値について計算することを意味します。
( g ^ H(Id[A]) ) * ( y ^ (-r[A]) ) mod p.
(g^H、(イド[A]) )*、(y^、(-r[A]) )モッズp。
Danisch Informational [Page 6] RFC 1824 TESS August 1995
[6ページ]RFC1824テス1995年8月の情報のDanisch
Note that a given value of Y[A] is not reliable. It must have been reliably calculated from (p,g,y) and (Id[A],r[A]). Y[A] is to be understood as a macro definition, not as a value.
Y[A]の与えられた値が信頼できないことに注意してください。 そして、それが(p、g、y)から確かに計算されたに違いない、(イド[A]、r[A])。 Y[A]は値として理解されることになっているのではなく、マクロ定義として理解されることになっています。
Obviously both the SKIA and the User know the secret part of the User's key and can reveal it, either accidently or in malice prepense. The enhancements section below shows methods to avoid this.
明らかにSKIAとUserの両方が、Userのキーの秘密の部分を知って、事故か悪意計画的でそれを明らかにすることができます。 下のセクションがこれを避ける方法を示している増進。
3. Authentication
3. 認証
This section describes the basic methods of applying the User keys. They refer to online and offline communication between two users A(lice) and B(ob).
このセクションはUserキーを適用する基本的方法を説明します。 彼らは2人のユーザA(シラミ)とB(ob)とのオンラインの、そして、オフラインのコミュニケーションを示します。
The unilateral and the mutual authentications use the KATHY protocol to generate reliable session keys for further use as session encryption keys etc.
一方的な認証と互いの認証は、セッション暗号化キーなどとしてさらなる使用のための高信頼のセッションキーを発生させるのにキャシープロトコルを使用します。
3.1. Zero Knowledge Authentication
3.1. 知識認証がありません。
The "Zero Knowledge Authentication" is used if Alice wants to authenticate herself to Bob without need for a session key.
「知識認証のゼロを合わせてください」、アリスがセッションキーの必要性なしでボブに自分を認証したいなら、使用されます。
Assuming that Bob already reliably learned the (p,g,y) of the SKIA Alice got her key from, the steps are:
既にそのボブを確かに仮定するのが学んだ、(p、g、y) アリスが彼女のキーを手に入れたSKIAでは、ステップは以下の通りです。
1. Alice generates a large random number t, 1<t<p-1, where t should
have approximately the same length as p-1.
1. アリスは大きい乱数t、1<tの<p-1を発生させます。そこでは、tがp-1とほとんど同じ長さを持つべきです。
2. a := r[A] ^ t mod p
2. :=r[A]^tモッズp
3. Alice sends her public key (Id[A],r[A]) and the number a to Bob.
3. アリスが彼女の公開鍵を送る、(イド[A]、r[A])、および数、ボブへのa。
4. Bob generates a large random number c, c<p-1, where c should have
approximately the same length as p-1, and sends c to Alice.
4. ボブは大きい乱数cを発生させます、c<p-1、cがp-1とほとんど同じ長さを持つべきであり、cをアリスに送るところで。
5. Alice calculates
c' := (c * s[A] + t) mod (p-1)
and sends c' to Bob.
5. 'アリスは、c':=(c*s[A]+t)モッズ(p-1)について計算して、c'をボブに送ります。
6. Bob verifies whether
r[A] ^ c' = (Y[A] ^ c) * a mod p.
6. 'ボブは、r[A]^c'が(Y[A]^c)*と等しいかどうか確かめます。aモッズp。
This is the Beth-Zero-Knowledge protocol [8] which is based on self- certified public keys and an improvement of the DLP-Zero-Knowledge identification protocol from Chaum, Evertse, and van de Graaf [9].
これは、公開鍵であることが公認された自己に基づいているベス無Knowledgeプロトコル[8]とChaum、Evertse、およびバンdeグラーフ[9]からのDLP無Knowledge識別プロトコルの改良です。
Danisch Informational [Page 7] RFC 1824 TESS August 1995
[7ページ]RFC1824テス1995年8月の情報のDanisch
3.2. Unilateral Authentication
3.2. 一方的な認証
The "Unilateral Authentication" (or "Half Authentication") can be used in those cases:
それらの場合に「一方的な認証」(または、「半分認証」)を使用できます:
- Alice wants to authenticate herself to Bob without Bob
authenticating himself to Alice.
- ボブがアリスに自分を認証しないで、アリスはボブに自分を認証したがっています。
- Bob wants to send an encrypted message to Alice readable by her
only (offline encryption).
- ボブは彼女(オフライン暗号化)だけで読み込み可能なアリスに暗号化メッセージを送りたがっています。
A shared key is generated by the following protocol. This key can be known by Alice and Bob only.
共有されたキーは以下のプロトコルで発生します。 アリスとボブだけがこのキーを知ることができます。
Assuming that Bob already reliably learned the (p,g,y) of the SKIA Alice got her key from, the steps are:
既にそのボブを確かに仮定するのが学んだ、(p、g、y) アリスが彼女のキーを手に入れたSKIAでは、ステップは以下の通りです。
1. Alice sends her public key (Id[A],r[A]) to Bob if he does not
already know it.
1. アリスが彼女の公開鍵を送る、(イド、[A] ボブへのr[A])は彼であるなら既にそれを知りません。
2. Bob chooses a random number 1 < z[A] < p-1 and calculates
v[A] := r[A] ^ z[A] mod p
2. ボブは、乱数1<z[A]<p-1を選んで、v[A]:=r[A]^z[A]モッズpについて計算します。
3. Bob sends v[A] to Alice.
3. ボブはv[A]をアリスに送ります。
4. Alice and Bob calculate the session key:
4. アリスとボブはセッションキーについて計算します:
Alice: key[A] := v[A] ^ s[A] mod p
Bob: key[A] := Y[A] ^ z[A] mod p
アリス: 主要な[A]:=v[A]^s[A]モッズpボブ: 主要な[A]:=Y[A]^z[A]モッズp
Apply the equations of the User Key Setup section to Bob's equation to see that Alice and Bob get the very same key in step 4:
User Key Setup部の方程式をボブの方程式に適用して、アリスとボブがステップ4で全く同じキーを手に入れるのを確実にしてください:
key[A] = r[A] ^ ( s[A] * z[A] ) mod p
キー[A]がr[A]^と等しい、(s[A]*z[A] )モッズp
A third party cannot calculate key[A], because it has neither s[A] nor z[A]. Therefore, Bob can trust in the fact that only Alice is able to know the key[A] (as long as nobody else knows her secret s[A]).
s[A]もz[A]も持っていないので、第三者はキー[A]について計算できません。 したがって、ボブはアリスだけが主要な[A]を知ることができるという事実を信じることができます。(他の誰もが彼女の秘密のs[A])を知らない限り。
This protocol is based on the Diffie-Hellman scheme [10], but avoids the weakness of the missing authenticity of the public keys.
このプロトコルは、ディフィー-ヘルマン計画[10]に基づいていますが、公開鍵のなくなった信憑性の弱点を避けます。
In this protocol Bob did not verify whether Alice really knew her s[A] and was able to calculate key[A]. Therefore, a final challenge- response step should be performed in case of online communication (see the subsection below).
このプロトコルでは、ボブは、アリスが本当に彼女のs[A]を知ったかどうか確かめないで、キー[A]について計算できました。 したがって、最終的な挑戦応答ステップはオンラインコミュニケーションの場合に実行されるべきです(以下の小区分を見てください)。
Danisch Informational [Page 8] RFC 1824 TESS August 1995
[8ページ]RFC1824テス1995年8月の情報のDanisch
In case of sending encrypted messages, Bob can execute step 4 before step 3, use the key[A] to encrypt the message, and send the encrypted message together with v[A] in step 3.
暗号化メッセージを送ることの場合には、ボブは、ステップ3前にステップ4を実行して、メッセージをコード化するのにキー[A]を使用して、v[A]と共にステップ3で暗号化メッセージを送ることができます。
3.3. Mutual Authentication
3.3. 互いの認証
The "Mutual Authentication" is used for online connections where both Alice and Bob want to authenticate to each other.
アリスとボブの両方を使用されたいところで「互いの認証」はオンライン接続に使用されます。互いに、認証します。
Within this protocol description it is assumed that Alice and Bob have keys of the same SKIA and use the same triple (p,g,y). Otherwise in each step the triple has to be used which belongs to the user key it is applied to.
このプロトコル記述の中では、アリスとボブが3倍(p、g、y)同じSKIAと使用のキーを同じにすると思われます。 そうでなければ、各ステップでは、それが適用されるユーザキーに属す三重は使用されなければなりません。
The steps are as follows (where the first four steps are exactly twice the "Unilateral Authentication" and steps 5-9 form a mutual challenge-response step to find out whether the other side really got the key):
ステップは以下の通りです(最初の4ステップがちょうど「一方的な認証」の2倍であり、ステップ5-9が反対側が本当にキーを手に入れたかどうか見つけるために互いのチャレンジレスポンスステップを形成するところ):
1. Alice sends her (Id[A],r[A]) to Bob.
Bob sends his (Id[B],r[B]) to Alice.
1. アリスは彼女を送ります。(イド[A]、ボブへのr[A])。 ボブは彼のものを送ります。(イド[B]、アリスへのr[B])。
2. Bob chooses a random number z[A] < p-1
and calculates v[A] := r[A] ^ z[A] mod p
2. ボブは、乱数z[A]<p-1を選んで、v[A]:=r[A]^z[A]モッズpについて計算します。
Alice chooses a random number z[B] < p-1
and calculates v[B] := r[B] ^ z[B] mod p
アリスは、乱数z[B]<p-1を選んで、v[B]:=r[B]^z[B]モッズpについて計算します。
3. Bob sends v[A] to Alice.
Alice sends v[B] to Bob.
3. ボブはv[A]をアリスに送ります。 アリスはv[B]をボブに送ります。
4. Alice and Bob calculate the session keys:
4. アリスとボブはセッションキーについて計算します:
Alice: key[A] := v[A] ^ s[A] mod p
key[B] := Y[B] ^ z[B] mod p
アリス: 主要な[A]のp主要な[B]:=Y[B]^z[B]:=v[A]^s[A]モッズモッズp
Bob: key[B] := v[B] ^ s[B] mod p
key[A] := Y[A] ^ z[A] mod p
ボブ: 主要な[B]のp主要な[A]:=Y[A]^z[A]:=v[B]^s[B]モッズモッズp
5. Alice chooses a random number R[B]
Bob chooses a random number R[A]
5. アリスはR[B]ボブが乱数Rを選ぶ乱数を選びます。[A]
6. Alice sends Encrypt(key[B],R[B]) to Bob.
Bob sends Encrypt(key[A],R[A]) to Alice.
6. アリスはEncryptを送ります。(主要な[B]、ボブへのR[B])。 ボブはEncryptを送ります。(主要な[A]、アリスへのR[A])。
7. Alice and Bob decrypt the received messages to R'[A] and R'[B].
7. アリスとボブはR'[A]とR'[B]に受信されたメッセージを解読します。
Danisch Informational [Page 9] RFC 1824 TESS August 1995
[9ページ]RFC1824テス1995年8月の情報のDanisch
8. Alice sends Encrypt(key[A],T(R'[A])) to Bob.
Bob sends Encrypt(key[B],T(R'[B])) to Alice.
8. アリスがEncryptを送る、(キー[A]、T、(R、'ボブへの[A]))'。 ボブがEncryptを送る、(キー[B]、T、(R、'アリスへの[B]))'。
9. Alice and Bob decrypt the received messages to R''[A] and R''[B]
9. 「アリスとボブはR」[A]とRに受信されたメッセージを解読します」[B]
10. Alice verifies whether T(R[B]) = R''[B].
Bob verifies whether T(R[A]) = R''[A].
10. 「アリスが確かめる、T、(R[B])はR」[B]と等しいです。 「ボブが確かめる、T、(R[A])はR」[A]と等しいです。
T() is a simple bijective transformation function, e.g. increment().
T()は簡単なbijective変形関数、例えば、増分()です。
After step 4 Alice can trust in the fact that only Bob and herself can know key[B], but she still does not know whether she is really talking to Bob. Therefore, she forces Bob to make use of his key within steps 5-9. Alice now has checked whether she really talks to Bob. Since the scheme is symmetrical, Bob also knows that he talks to Alice.
ステップ4 アリスが事実で唯一のそのボブと自分を信じたことができた後に、キー[B]を知ることができますが、彼女は、彼女が本当にボブと話しているかどうかをまだ知っていません。 したがって、彼女はボブにステップ5-9の中で彼のキーを強制的に利用させます。 アリスは、現在、本当にボブと話すかどうかチェックしました。 計画が対称であるので、また、ボブは、彼がアリスと話すのを知っています。
3.4. Message Signing
3.4. メッセージ調印
To sign a message m (where H(m) is a cryptographic hash value of the message), the message author A generates an ElGamal signature by using his r[A] as the generator and the s[A] as his secret:
メッセージm(H(m)がメッセージの暗号のハッシュ値であるところ)にサインするために、メッセージ作者Aは彼の秘密としてジェネレータとs[A]として彼のr[A]を使用することによって、ElGamal署名を発生させます:
- A generates a random number K with gcd(K,p-1) = 1.
- Aは最大公約数(K、p-1)=1で乱数Kを発生させます。
- R := r[A] ^ K mod p
- R:=r[A]^Kモッズp
- S := ( H(m) - s[A] * R ) * (K ^ -1) mod (p-1)
- S:=(H(m)--s[A]*R)*(K^-1)モッズ(p-1)
The calculated set of numbers fulfills the equation:
計算された一連の数字は方程式を実現させます:
( s[A] * R + K * S ) = H(m) mod(p-1)
(s[A]*R+K*S)はH(m)モッズと等しいです。(p-1)
The signed message consists of (m,Id[A],r[A],R,S).
サインされたメッセージは(m、Id[A]、r[A]、R、S)から成ります。
The receiver of the message checks the authenticity of the message by calculating the hash value H(m) and verifying the equation:
メッセージの受信機はハッシュ値H(m)について計算して、方程式を確かめることによって、メッセージの信憑性をチェックします:
r[A] ^ H(m) = ( Y[A] ^ R ) * ( R ^ S ) mod p
r[A]^H(m)は(Y[A]^R)*(R^S)モッズpと等しいです。
4. Enhancements
4. 増進
This section describes several enhancements and modifications of the base protocol as well as other comments.
このセクションは他のコメントと同様にベースプロトコルのいくつかの増進と変更について説明します。
Danisch Informational [Page 10] RFC 1824 TESS August 1995
[10ページ]RFC1824テス1995年8月の情報のDanisch
4.1. Non-Escrowed Key Generation
4.1. 非Escrowedキー生成
Within the normal User Setup procedure for a User A, the SKIA gains knowledge about the secret key s[A]. The SKIA could use this key to fake signatures or decrypt messages, or to allow others to do so.
User Aに、正常なUser Setup手順の中では、SKIAは秘密鍵s[A]の周りで知識を得ます。 SKIAは、署名を見せかけるか、メッセージを解読する、または他のものがそうするのを許容するのにこのキーを使用できました。
To avoid this situation, a slight modification of the User Setup procedure may be applied. The SKIA Setup is the same as in the base protocol.
この状況を避けるために、User Setup手順のわずかな変更は適用されるかもしれません。 SKIA Setupはベースプロトコルと同じです。
Within the User Setup the SKIA does not use its primitive element g, but a generator created by the User instead.
User Setupの中では、SKIAは原始の要素gではなく、代わりにUserによって作成されたジェネレータを使用します。
The modified scheme looks like this:
変更された計画はこれに似ています:
- User A generates a random number a with gcd(a,p-1)=1
- ユーザAが乱数を発生させる、最大公約数(a、p-1)=1があるa
- User A calculates g' := g^a mod p and forwards g' to the SKIA.
- SKIAに'ユーザAはg':=gについて^モッズのpとフォワードgで計算します'。
- The SKIA generates Id[A] and k[A] as in the base protocol
- SKIAはベースプロトコルのようにId[A]とk[A]を発生させます。
- The SKIA sets r[A] := ( g' ^ k[A] ) mod p and
s'[A] := ( H(Id[A]) - x * r[A] ) * (k[A] ^ -1) mod (p-1)
- 'SKIAがr[A]:=を設定する、([A] g'の^k[A] )モッズpとs':=、(H、(イド[A])--、x*r[A] )*(k[A]^-1)モッズ、'(p-1)
- The SKIA forwards (Id[A],r[A],s'[A]) to the user A
- SKIAが進める、(イド[A]、r[A]、ユーザA'へのs'[A])
- The user A calculates his s[A] := s'[A] * (a^-1) mod (p-1)
- ユーザAは彼のs[A]:=s'[A]*(^-1)モッズ'について計算します。(p-1)
The SKIA is not able to find out the secret key s[A] of A. This protocol is based on the idea of the 'testimonial' [11].
SKIAは、A.Thisプロトコルの秘密鍵s[A]が'証明書'[11]の考えに基づいているのを見つけることができません。
The SKIA is still able to create a second key with the same Identity Descriptor (identical or at least having same contents), but with different r[A] and s[A]. If such a second key was successfully used for authentication or message signing, the real key owner can use his own key to proof the existence of two different keys with identical (equivalent) Descriptors. The existence of such two keys shows that the SKIA cannot be trusted any longer.
または、SKIAがまだ同じIdentity Descriptorによって主要な1秒を作成できる、(同じである、同じコンテンツを少なくとも持っています)、異なったr[A]とs[A] そのような2番目のキーが認証かメッセージ調印に首尾よく使用されたなら、本当のキー所有者は、同じ(同等な)記述子で2個の異なったキーの存在を検査するのに彼自身のキーを使用できます。 そのような2個のキーの存在は、もうSKIAを信じることができないのを示します。
If the key is generated by this method, it should be mentioned in the Identity Descriptor. This allows any communication partners to look up in the public part of a key whether the secret part is known to the SKIA.
キーがこの方法で発生するなら、それはIdentity Descriptorで言及されるべきです。 これで、秘密の部分がSKIAにおいて知られているか否かに関係なく、どんなコミュニケーションパートナーもキーの公共の部分を調べることができます。
4.2. Hardware Protected Key
4.2. ハードウェアはキーを保護しました。
The protocol of the previous subsection guaranteed that the SKIA does not know the user's secret key.
前の小区分のプロトコルは、SKIAがユーザの秘密鍵を知らないのを保証しました。
Danisch Informational [Page 11] RFC 1824 TESS August 1995
[11ページ]RFC1824テス1995年8月の情報のDanisch
On the other hand, the SKIA may wish that the user himself does not know his own secret key. This may be necessary because the user could otherwise reveal his secret key accidently or intentionally. Especially if untrusted hard- or software or an environment without trusted process protection is used, the secret key can be spied out. For high-level security applications this might not be acceptable. The key owner must be able to use his key without being able to read this key. This contradiction can be solved by hiding the secret part of the User Key within a protected hardware device.
他方では、SKIAは、ユーザ自身が彼自身の秘密鍵を知らないことを願うかもしれません。 ユーザが別の方法で事故か故意に彼の秘密鍵を明らかにすることができたので、これが必要であるかもしれません。 または、特に信頼されていない、困難である、信じられた過程保護のないソフトウェアか環境が使用されている、秘密鍵をかぎ出すことができます。 ハイレベルのセキュリティアプリケーションにおいて、これは許容できないかもしれません。 このキーを読むことができないで、主要な所有者は彼のキーを使用できなければなりません。 保護されたハードウェアデバイスの中にUser Keyの秘密の部分を隠すことによって、この矛盾を解決できます。
Within the SELANE project, the protocols described in this RFC were implemented for SmartCards. The User Key is created using the non- escrowed key generation procedure described in the previous section, modified such that the random number is generated inside the card. The secret s[A] exists only inside the card and does not get outside. The SmartCard is able to execute all parts of the algorithms which need access to the secret key. To make use of the SmartCard an additional password is required.
SELANEプロジェクトの中では、このRFCで説明されたプロトコルはSmartCardsのために実行されました。 User Keyは前項で説明された非escrowedされたキー生成手順を用いることで作成されます、乱数がカードの中に発生するように変更されて。 秘密のs[A]はカードだけの中に存在していて、外部を得ません。 SmartCardは秘密鍵へのアクセスを必要とするアルゴリズムのすべての部分を実行できます。 SmartCardの使用を追加パスワードにするのが必要です。
If the key is hidden in such a hardware device, it should be mentioned in the Identity Descriptor. This allows any communication partners to look up in the public part of a key whether the key is hardware protected.
キーがそのようなハードウェアデバイスに隠されるなら、それはIdentity Descriptorで言及されるべきです。 これで、どんなコミュニケーションパートナーもキーが保護されたハードウェアであるか否かに関係なく、キーの公共の部分を調べることができます。
4.3. Key Regeneration
4.3. 主要な再生
If both methods of the previous subsections are used to protect the key, neither the SKIA nor the User himself knows the secret key. This could be harmful for the User if the hardware device is lost or damaged, because the User could become unable to decrypt messages encrypted with the public key.
前の小区分の両方の方法がキーを保護するのに使用されるなら、SKIAもUser自身も秘密鍵を知りません。 ハードウェアデバイスがなくされているか、または破損するなら、Userに、これは有害であるかもしれません、Userが公開鍵でコード化されたメッセージを解読することができないようになることができたので。
To prevent such a denial of service, there are two methods:
そのようなサービスの否定を防ぐために、2つの方法があります:
- If the protection factor 'a' was choosen by the User, the User
can deposit the factor 'a' in a secure way, e.g. give it as a
shared secret to his friends. The SKIA can do the same and
deposit s'[A] somewhere else. If the SKIA and the User
cooperate, they are able to create a second hardware device
equivalent to the first.
- 防護係数'a'がUserでchoosenだったなら、Userは安全な方法で要素'a'を預けることができます、例えば、共有秘密キーとして彼の友人にそれを与えてください。 SKIAは'他のどこかの[A]'が同じ、そして、預金sにできます。 SKIAとUserが協力するなら、彼らは1日に同等な状態で2番目のハードウェアデバイスを作成できます。
- If the protection factor a was generated inside of the hardware
device, the device itself may give out the s[A] or the a in a
secure way (e.g. as a shared secret).
- aが防護係数であるなら中でハードウェアデバイスで発生していた、装置自体は安全な方法(例えば、共有秘密キーとしての)でs[A]かaを配るかもしれません。
Since the recreation of a User key defeats the property of such a key to exist only once, the SKIA should restrict this to special cases only. Furthermore it should be done only after the end of the
Userキーのレクリエーションが一度だけ存在するようにそのようなキーの特性を破るので、SKIAはこれを特別なケースだけに制限するはずです。 その上、終わりだけ以降にそれをするべきです。
Danisch Informational [Page 12] RFC 1824 TESS August 1995
[12ページ]RFC1824テス1995年8月の情報のDanisch
lifetime of the key, if its lifetime was limited.
キーの寿命は生涯なら制限されました。
4.4. r ^ r
4.4. r^r
A slight modification of the base protocol allows some speedup in the key exchange:
ベースプロトコルのわずかな変更は主要な交換における何らかのスピードアップを許容します:
- The SKIA is created as in the base protocol
- SKIAはベースプロトコルのように作成されます。
- For the User Setup the SKIA solves the equation
x * s[A] + r[A] * k[A] = H(Id[A]) mod (p-1)
which differs from the base protocol in that r and s were swapped.
- SKIAが解決するUser Setupに関して、方程式x*s[A]+r[A]*k[A]はHと等しいです。(rとsが交換されたので、ベースと異なっているイド[A])モッズ(p-1)が議定書を作ります。
- The public key allows to calculate
y ^ s[A] = ( g ^ H(Id[A]) ) * ( r[A] ^ -r[A] ) mod p
without knowing s[A]. Here the term ( r[A] ^ -r[A] ) can be
precalculated for speedup.
- 公開鍵でy^s[A]=について計算する、(g^H、(イド[A]) )*、(s[A]を知っていることのないr[A]^-r[A] )モッズp。 ここ、用語、(スピードアップのためにr[A]^-r[A] )について前計算できます。
- Bob calculates key[A] := ( g ^ H(Id[A]) * r[A] ^ -r[A] ) ^ z[A]
and v[A] := y ^ z[A] mod p
Alice gets key[A] := v[A] ^ s[A] mod p
where key[A] = y ^ (s[A] * z[A])
- ボブがキー[A]:=について計算する、(g^H、(イド[A])*r[A]^-r[A] )^z[A]とv[A]:=y^z[A]モッズ風のpアリスはキー[A]がy^と等しいところで主要な[A]:=v[A]^s[A]モッズpを手に入れます。(s[A]*z[A])
This protocol is similar to the AMV modification by Agnew et al. [12].
このプロトコルはアグニュー他でAMV変更と同様です。 [12].
4.5. Implicit Key Exchange
4.5. 暗黙の主要な交換
If the r ^ r protocol of the previous section is used, an implicit shared key can be calculated for Alice and Bob by using the Diffie- Hellman scheme:
前項のr^rプロトコルが使用されているなら、アリスとボブのためにディフィーヘルマン計画を使用することによって、内在している共有されたキーについて計算できます:
- Alice: key[A,B] = ( g ^ H(Id[B]) * r[B] ^ -r[B] ) ^ s[A] mod p
- アリス: =を合わせてください、[A、B](g^H、(イド[B])*r[B]^-r[B] )^s[A]モッズp
- Bob: key[B,A] = ( g ^ H(Id[A]) * r[A] ^ -r[A] ) ^ s[B] mod p
- ボブ: キー[B、A]=、(g^H、(イド[A])*r[A]^-r[A] )^s[B]モッズp
where key[A,B] = key[B,A] = y ^ (s[A] * s[B]).
= 主要であるところで[A、B]y[B、A]=^を合わせてください。(s[A]*s[B])。
This can not be used with Non-escrowed keys.
Non-escrowedキーと共にこれを使用できません。
4.6. Law Enforcement
4.6. 法の執行
This will be subject of a separate RFC.
これは別々のRFCにおいて受けることがあるでしょう。
Danisch Informational [Page 13] RFC 1824 TESS August 1995
[13ページ]RFC1824テス1995年8月の情報のDanisch
4.7. Usage of other Algebraic Groups
4.7. 他のAlgebraic Groupsの使用法
Within this RFC calculations were based on a specific algebraic group, the multiplicative group of integers modulo a prime number p (which is the multiplicative group of a finite field GF(p)). However, any cyclic finite group with a strong discrete logarithm problem can be used, e.g., a subgroup of the multiplicative group or elliptic curves.
このRFCの中では、計算は特定の代数的なグループに基づいて、整数法の乗法群は素数pです(有限分野GF(p)の乗法群です)。 しかしながら、強い離散対数問題があるどんな周期的な有限群も使用できます、例えば、乗法群か楕円曲線のサブグループ。
As an example the subgroup used by the DSA (Digital Signature Algorithm) of length N can be used instead of the full multiplicative group of GF(p) for speedup (in this case the Secure Hash Algorithm SHA is recommended as the hash algorithm). See [13, 14] for a description of DSA and SHA.
例として、GF(p)の完全な乗法群の代わりにスピードアップに長さNのDSA(デジタルSignature Algorithm)によって使用されたサブグループは使用できます(この場合、Secure Hash Algorithm SHAは細切れ肉料理アルゴリズムとしてお勧めです)。 DSAとSHAの記述に関して[13、14]を見てください。
4.7.1. DSA subgroup SKIA Setup
4.7.1. DSAサブグループSKIA Setup
- Generate large primes p and q such that p is at least 512 bit
long, q is 160 bit long, and q is a factor of (p-1).
- qは長さ160ビットです、そして、pが長さ少なくとも512ビットであるように、大きい盛りpとqを発生させてください、そして、qは(p-1)の要素です。
- choose a primitive root h in GF(p)
- GFで原始根hを選んでください。(p)
- g:= h^((p-1)/q)
Note that g generates a subgroup G with |G|=q
- g: gがサブグループGを発生させる=h^((p-1)/q)注意|G|=q
- x: a random number of about 160 bit.
- x: およそ160ビットの乱数。
- y:= ( g ^ x ) mod p
- y: =(g^x)モッズp
The public key of the SKIA is (p,g,y,q). (q is required for speedup only.)
SKIAの公開鍵は(p、g、y、q)です。 (qがスピードアップだけに必要です。)
The secret key of the SKIA is x.
SKIAの秘密鍵はxです。
4.7.2. Escrowed DSA subgroup User Setup
4.7.2. Escrowed DSAサブグループUser Setup
- k[A]: a random number of 160 bit length with gcd(k[A],q)=1
- k[A]: 最大公約数(k[A]、q)=1に従った160ビットの長さの乱数
- r[A]:= ( g ^ k[A] ) mod p
- r[A]: =、(g^k[A] )モッズp
- s[A]:= (H(Id[A]) + x * r[A]) * (k[A] ^ -1) mod q
- s[A]: =、(H、(イド[A])+x*r[A])*(k[A]^-1)モッズq
Again, (Id[A],r[A]) is the public key and s[A] is the secret key. Note that r[A] has the length of p and s[A] has the length of q (160 bit).
再び、(イド[A]、r[A])は公開鍵であり、s[A]は秘密鍵です。 r[A]にはpの長さがあって、s[A]にq(160ビット)の長さがあることに注意してください。
Danisch Informational [Page 14] RFC 1824 TESS August 1995
[14ページ]RFC1824テス1995年8月の情報のDanisch
4.7.3. Non-Escrowed DSA subgroup User Setup
4.7.3. 非Escrowed DSAサブグループUser Setup
- User A generates a random number h of 160 bit length.
- ユーザAは160ビットの長さの乱数hを発生させます。
- User A calculates a := g^h mod p and sends a to the SKIA.
- ユーザAは、:=g^hモッズpについて計算して、aをSKIAに送ります。
- The SKIA generates the user key with the secret key s'[A].
- SKIAは秘密鍵s'[A]'によって主要なユーザを発生させます。
- User A calculates s[A]:= s'[a] * (h^-1) mod q
- ユーザAはs[A]: =s'[a]*(h^-1)モッズq'について計算します。
4.7.4. DSA subgroup Authentication
4.7.4. DSAサブグループAuthentication
The protocols for authentication are the same as described above, except that wherever the modulus (p-1) was used the smaller modulus q is used instead, and DSA is used for message signing.
認証のためのプロトコルは上で説明されるのと同じです、係数(p-1)がどこで使用されたとしても、より小さい係数qが代わりに使用されて、DSAがメッセージ調印に使用されるのを除いて。
The abbreviation Y[A] still stands for r[A] ^ s[A], which is now (the sign of r[A] was changed for speedup)
略語Y[A]はまだr[A]^s[A]を表しています。(s[A]は現在です)。(スピードアップのためにr[A]のサインを変えました)
( g ^ H(Id[A])) * ( y ^ r[A] ) mod p
(g^H、(イド[A]))*、(y^r[A] )モッズp
and can be calculated in a faster way as
より速い方法で計算できます。
u1 * u2 mod p
u1*u2モッズp
where
どこ
u1 := g ^ ( H(Id[A]) mod q ) mod p
u2 := y ^ ( r[A] mod q ) mod p.
u1:=g^、(H(イド[A])モッズq)モッズp u2:=y^(r[A]モッズq)モッズp。
5. Multiple SKIAs
5. 複数のSKIAs
In the preceding sections it was assumed that everybody learned the (p,g,y) triple of a SKIA reliably.
先行するセクションでは、みんながSKIAの(p、g、y)三重を確かに学んだと思われました。
By default, a User reliably learns only the (p,g,y) of the SKIA which generated his own key, because he gets the triple with his key and can verify the triple with the signature verification equation.
デフォルトで、Userが確かに学ぶ唯一のa、(p、g、y) 彼が彼のキーで三重を得て、署名照合方程式で三重について確かめることができるので彼自身のキーを発生させたSKIAについて。
If the User wants to communicate with someone whose key was generated by a different SKIA, a method for authenticating the (p,g,y) of the other SKIA is needed.
Userがキーが異なったSKIA、認証のための方法で発生しただれかとコミュニケートしたがっている、(p、g、y) もう片方では、SKIAが必要です。
5.1. Unstructured SKIAs
5.1. 不統一なSKIAs
This will be subject of a separate RFC.
これは別々のRFCにおいて受けることがあるでしょう。
Danisch Informational [Page 15] RFC 1824 TESS August 1995
[15ページ]RFC1824テス1995年8月の情報のDanisch
5.2. Hierarchical SKIAs
5.2. 階層的なSKIAs
If there is a hierarchy between the SKIAs, their keys can be generated hierarchically:
SKIAsの間には、階層構造があれば、彼らのキーは階層的で発生できます:
- Every SKIA and every User has a level (expressed as a cardinal
number). The root SKIA has level 0. All Users and all other SKIAs
have levels greater than 0.
- あらゆるSKIAとあらゆるUserには、レベル(基数として、言い表される)があります。 根のSKIAには、レベル0があります。 Usersと他のすべてのSKIAsにはあるすべてが0以上を平らにします。
- Each SKIA except the root SKIA is also a User, and each User can
be a SKIA.
- また、根のSKIA以外の各SKIAはUserです、そして、各UserはSKIAであるかもしれません。
A SKIA of level n generates keys for Users of level n+1.
レベルnのSKIAはレベルnのUsersのためにキーを+1に発生させます。
A User of level n is also a SKIA of level n.
また、レベルnのUserはレベルnのSKIAです。
- Since every SKIA (except the root SKIA) is also a User, each SKIA
has an Identity Descriptor describing its Identity and perhaps its
level and its parent SKIA. There is a function parent(A) which
finds the parent SKIA for every user A. This function may use
informations stored in the Identity Descriptor.
- また、あらゆるSKIA(根のSKIAを除いた)がUserであるので、各SKIAはIdentity Descriptorに恐らくIdentity、レベル、および親SKIAについて説明させます。 あらゆるユーザA.This機能のための親SKIAがIdentity Descriptorに格納された情報を使用するかもしれないのがわかる機能parent(A)があります。
Thus, the parent() function allows to find the path to the root
SKIA for every node of the tree forming the hierarchy.
その結果()機能が木の形成のあらゆるノードのための根のSKIAへの経路が階層構造であることがわかるのを許容する親。
The root SKIA may also have an Identity Descriptor.
また、根のSKIAには、Identity Descriptorがあるかもしれません。
- The root SKIA creates itself as in the base protocol.
- 根のSKIAはベースプロトコルのようにそれ自体を作成します。
- The key for a User A of level n (n>0) is generated by the parent
SKIA of level n-1. The public part is (Id[A],r[A]), the secret
part is (s[A]).
- レベルn(n>0)のUser Aのためのキーはレベルn-1の親SKIAによって発生します。 イド[A]、r[A])、秘密の部分はそうです。公共の部分がそうである、((s[A])。
User A is automatically SKIA A:
ユーザAは自動的にSKIA A:です。
p[A] := p[parent(A)] = p of the root SKIA
g[A] := r[A]
x[A] := s[A]
y[A] := g[A] ^ x[A] = r[A] ^ s[A] = Y[A] =
( g[parent(A)] ^ H(Id[A]) ) * ( y[parent(A)] ^ -r[A]) mod p
根のSKIA g[A]:=r[A] x[A]:=s[A] y[A]:=g[A]^x[A]=r[A]^s[A]のp[A]:=p[parent(A)]=pがY[A]=と等しい、(g[parent(A)]^H、(イド[A]) )*、(y[parent(A)]^-r[A])モッズp
Therefore, the public data (p,g[A],y[A]) of the SKIA A can be
calculated by everyone from the public data of the User A and the
public data of its parent SKIA. The SKIA A itself may use the
faster method to get y[A] by calculating r[A] ^ s[A], while
everybody else has to use the slower but public method as in the
lower equation. The secret of the "SKIA A" is identical to the
secret of the "User A".
したがって、公衆データ、(p、g[A]、皆はUser Aに関する公衆データと親SKIAに関する公衆データからSKIA Aのy[A])について計算できます。 SKIA A自身は計算のr[A]^s[A]でy[A]を手に入れるより速い方法を使用するかもしれません、他の人皆が低い方程式のように、より遅い、しかし、公共の方法を使用しなければなりませんが。 "SKIA A"の秘密は「ユーザA」の秘密と同じです。
Danisch Informational [Page 16] RFC 1824 TESS August 1995
[16ページ]RFC1824テス1995年8月の情報のDanisch
Since a User A uses the very same data to act as either a user or
as a SKIA, and since message signing (subsection 3.4.) is the very
same procedure as generating a User key (in fact it is the same
thing), a user should not sign a message which could be
misunderstood as an Identity Descriptor. An attacker could
intercept the message and its signature and abuse it as a User
key. This can be avoided by the use of tags which preceed every
set of data being signed and show whether it is a message or an
Identity Descriptor.
User Aがユーザを演じるのに全く同じデータを使用するか、SKIA、およびメッセージ調印(小区分3.4)以来Userキーを発生させるのと全く同じ手順(事実上、それは同じものである)であることで、ユーザはIdentity Descriptorとして誤解できたメッセージにサインするべきではありません。 攻撃者は、メッセージとその署名を妨害して、Userキーとしてそれを乱用できました。 サインされるあらゆるセットのデータをpreceedして、それがメッセージかそれともIdentity Descriptorであるかを示すタグの使用でこれを避けることができます。
This scheme allows any two users (even users of distinct hierarchies) to communicate reliably. They need to know the public data (p,g,y) of each other's root SKIA only. There is no need for online key servers.
この計画で、どんな2人のユーザ(異なった階層構造のユーザさえ)も確かに交信できます。 彼らは、互いの根のSKIAに関する公衆データ(p、g、y)だけを知る必要があります。 オンライン主要なサーバの必要は全くありません。
The communication is the same as in the base protocols but with an extension to the method of finding Y[A] (again with Alice and Bob):
コミュニケーションはベースプロトコルにもかかわらず、拡大でY[A](再びアリスとボブがいる)を見つける方法と同じです:
- Bob reliably learned the (p,g,y) of Alice's root SKIA S(0).
- ボブが確かに学んだ、(p、g、y) アリスのものでは、SKIA S(0)を根づかせてください。
- Where Alice presented (Id[A],r[A]) only in the first step, she now
presents (Id[S],r[S]) for each SKIA/User node S in her path to her
root SKIA S(0). Since this information does not need to be
reliable or signed, it can be provided by any simple server
mechanism.
- 紹介されたWhereアリス、(イド[A]、第一歩だけにおけるr[A])、彼女が現在提示する、(イド[S]、彼女への彼女の経路のそれぞれのSKIA/ユーザノードSのためのr[S])はSKIA S(0)を根づかせます。 この情報が信頼できるかサインされている必要はないので、どんな簡単なサーバメカニズムもそれを提供できます。
- Bob iteratively calculates the public data (p,g,y) of each SKIA in
the path, starting with Alice's root SKIA, until he gets the
(p,g,y) of Alice where y is Y[Alice].
- ボブ繰り返しは経路でそれぞれのSKIAに関する公衆データ(p、g、y)について計算します、アリスの根のSKIAから始まって、彼が得るまで(p、g yがY[アリス]であるアリスのy)。
Note that Bob did not have to verify anything within the iteration. After the iteration he has a set of public SKIA data (p,g,y) to be used with Alice public key, but he still does not know whether he was spoofed with wrong data of Alice or her parent SKIAs.
ボブが繰り返しの中で何も確かめる必要はなかったことに注意してください。 繰り返しの後に、1セットのアリス公開鍵と共に使用されるべき公共のSKIAデータ(p、g、y)がありますが、彼は、アリスの間違ったデータか彼女の親SKIAsと共にだまされたかどうかをまだ知っていません。
Since the iteration Bob calculated is a chain of nested signatures, the correctness of the (p,g,y) he gets depends on every single step. If there is at least one step with a bad Id[S] or r[S], Bob will get a wrong Y[S] in this step and all following steps, and the chain doesn't work.
以来ボブが計算した繰り返しが入れ子にされた署名、正当性のチェーンである、(p、g、彼が得るy)はあらゆるシングルステップによります。 悪いId[S]かr[S]との少なくとも1ステップがあると、ボブはこのステップとすべての次のステップでY[S]を間違うでしょう、そして、チェーンは動作しません。
If the chain calculated by Bob was not completely correct for any reason, Alice cannot make use of her key: her signatures do not verify, she cannot decrypt encrypted messages and she cannot answer to the challenge response step in case of mutual authentication.
ボブによって計算されたチェーンがどんな理由でも完全に正しかったというわけではないなら、アリスは彼女のキーを利用できません: 彼女の署名が確かめない、彼女は暗号化メッセージを解読することができないで、互いの認証の場合にチャレンジレスポンスステップに対応することができません。
Danisch Informational [Page 17] RFC 1824 TESS August 1995
[17ページ]RFC1824テス1995年8月の情報のDanisch
5.3. Example: A DNS-based public key structure
5.3. 例: DNSベースの公開鍵構造
Here is a simple example of the usage of the hierarchical SKIA scheme within the DNS name space:
ここに、スペースというDNS名の中に階層的なSKIA計画の用法の簡単な例があります:
Let every domain also be a SKIA, and let the root domain be a root SKIA. Let the Identity Descriptor of any object within the name space be its name: the domain name for domains, the host name for machines, the mail address for humans and services.
また、あらゆるドメインがSKIAであることをさせてください、そして、根のドメインが根のSKIAであることをさせてください。 スペースという名前の中のどんな物のIdentity Descriptorも名前であることをさせてください: ドメインへのドメイン名、マシンのためのホスト名、人間とサービスのための郵便の宛先。
Consequently, a user with the mail address "danisch@ira.uka.de" got his key from the SKIA of the domain "ira.uka.de". This SKIA was authorized by the SKIA of "uka.de", which was authorized by the SKIA of "de", which is the root SKIA of Germany. It is assumed that everybody reliably learned the public key of the german root domain "de".
その結果、郵便の宛先" danisch@ira.uka.de "をもっているユーザはドメイン"ira.uka.de"のSKIAから彼のキーを手に入れました。 このSKIAはドイツの根のSKIAである"de"のSKIAによって認可された"uka.de"のSKIAによって認可されました。 みんながドイツ語根のドメイン"de"の公開鍵を確かに学んだと思われます。
The public key of danisch@ira.uka.de would look like:
danisch@ira.uka.de の公開鍵に似ているでしょう:
( "danisch@ira.uka.de", r[danisch@ira.uka.de] ,
"ira.uka.de" , r[ira.uka.de] ,
"uka.de" , r[uka.de]
)
(" danisch@ira.uka.de "、r[danisch@ira.uka.de]、"ira.uka.de"r[ira.uka.de]、"uka.de"r[uka.de])
For the reasons described in the previous subsection, this key is self-certified and does not need any further signature.
前の小区分で説明された理由で、このキーは、自己に公認されて、どんなさらなる署名も必要としません。
The key can be presented by danisch@ira.uka.de within online communications, be appended to signed messages, or simply be retrieved by the domain name server of ira.uka.de.
キーを danisch@ira.uka.de がオンラインコミュニケーションの中に示すか、サインされたメッセージに追加するか、またはira.uka.deのドメイン名サーバは単に検索できます。
Someone who reliably learned the (p,g,y) of the root domain .de (Germany) can now build the chain:
確かに学んだだれか、(p、g、y) 根のドメインでは、.de(ドイツ)は現在、チェーンを組立てることができます:
"de" (p,g,y)[de]
"uka.de" (p,g,y)[uka.de]
"ira.uka.de" (p,g,y)[ira.uka.de]
"danisch@ira.uka.de" (p,g,y)[danisch@ira.uka.de]
"de"(p、g、y)[de]"uka.de"(p、g、y)[uka.de]"ira.uka.de"(p、g、y)[ira.uka.de]" danisch@ira.uka.de "(p、g、y)[ danisch@ira.uka.de ]
Thus it is possible to reliably obtain the Y[danisch@ira.uka.de].
したがって、Y[ danisch@ira.uka.de ]を確かに得るのは可能です。
To communicate with the whole world, knowledge of the public keys of all root domain SKIAs only is needed. These keys can be stored within some tens of KBytes. No third party is needed for doing an authenticated key exchange.
全世界とコミュニケートするために、すべての根のドメインSKIAsの公開鍵に関する知識だけが必要です。 いくつかの10KBytesの中にこれらのキーを収納できます。 第三者は全く認証された主要な交換をするのに必要ではありません。
The whole world could also be based on a single root SKIA; in this case a single (p,g,y) is needed only.
また、全世界は独身の根のSKIAに基づくことができました。 この場合、シングル(p、g、y)が必要です。単に。
Danisch Informational [Page 18] RFC 1824 TESS August 1995
[18ページ]RFC1824テス1995年8月の情報のDanisch
In a more realistic example the Id[danisch@ira.uka.de] could contain:
より現実的な例では、Id[ danisch@ira.uka.de ]は以下を含むことができました。
creator= ira.uka.de
created= 1-Jun-1995
expiry= 31-Dec-1999
protection= non-escrowed, smartcard
type= human
name= Hadmut Danisch
email= danisch@ira.uka.de
phone= +49 721 9640018
fax= +49 721 696893
photo= <digitized compressed portrait>
=+49 721 9640018ファックス=+49 721 696893写真=<がデジタル化した danisch@ira.uka.de Hadmut Danisch人間の非escrowedされたスマートカード1999年12月31日1995年6月1日ira.uka.deが創造した創造者==満期=保護=タイプ=名前=メール=電話は肖像>を圧縮しました。
Security Considerations
セキュリティ問題
- The strength of TESS depends on the strength of the discrete
logarith problem, the strength of the ElGamal signature, and the
confidentiality of the SKIAs.
- テスの強さは離散的なlogarith問題の強さ、ElGamal署名の強さ、およびSKIAsの秘密性に依存します。
- Attention should be paid to the security considerations of the
underlying mechanisms (ElGamal, DSA, Diffie-Hellman, etc.).
- 発症機序(ElGamal、DSA、ディフィー-ヘルマンなど)のセキュリティ問題に注意を向けるべきです。
- Since the SKIA creates itself under normal circumstances, an
attacker could create his own SKIA and use it to create a User Key
with an arbitrary Identity Descriptor. This shows that the
Identity Descriptor is as reliable as the origin of the triple
(p,g,y) of the SKIA it came from. The User Key creation process is
a signature process for the Identity Descriptor and strongly
depends on the trustworthyness of the signing SKIA.
- SKIAが通常の状況下でそれ自体を作成するので、攻撃者は、任意のIdentity Descriptorと共にUser Keyを作成するのに彼自身のSKIAを作成して、それを使用できました。 これは、Identity Descriptorがそれが来たSKIAの三重(p、g、y)の起源と同じくらい信頼できるのを示します。 User Key創造の過程は、Identity Descriptorのための署名の過程であり、強く信頼できるのに調印SKIAについて依存します。
- It is the SKIA's duty to give the s[A] only to the user the
Identity Descriptor belongs to.
- Identity Descriptorがものであるユーザだけへのs[A]に与えるのは、SKIAの義務です。
- Since the very same procedure is used for signing messages and
generating user keys, it is important to distinguish between
messages and keys.
- 全く同じ手順がメッセージにサインして、ユーザキーを発生させるのに用いられるので、メッセージとキーを見分けるのは重要です。
- The authentication protocols work without an online authority.
Therefore, there is no simple way for revoking keys. For this
reason keys should have an expiration date mentioned in the
Identity Descriptor. In case of the hierarchical scheme a key
expires if any key in the path to the root SKIA expires.
- 認証プロトコルはオンライン権威なしで働いています。 したがって、キーを取り消すためのどんな簡単な方法もありません。 この理由で、キーで、Identity Descriptorで有効期限について言及するはずです。 階層的な計画の場合には、何か根のSKIAへの経路のキーが期限が切れるなら、キーは期限が切れます。
Danisch Informational [Page 19] RFC 1824 TESS August 1995
[19ページ]RFC1824テス1995年8月の情報のDanisch
References
参照
1. Th. Beth, F. Bauspiess, H.-J. Knobloch, S. Stempel, "TESS - A
Security System based on Discrete Exponentation," Computer
Communcations Journal, Vol. 17, Special Issue, No. 7, pp.
466-475 (1994).
1. 第. ベス、F.Bauspiess、H.J。 クノブロッフ、S.ステンペル、「テス--Security SystemはDiscrete Exponentationを基礎づけました」、コンピュータCommuncations Journal、Vol.17、Special Issue、No.7、ページ 466-475 (1994).
2. T. ElGamal, "A Public Key Cryptosystem and a Signature Scheme
Based on Discrete Logarithm," IEEE-Trans. Information Theory,
IT-31, pp. 469-472 (July 1985).
2. T。 ElGamal、「公開鍵暗号方式と署名は離散対数に基づいて計画する」、IEEE、-、移- 情報Theory、IT-31、ページ 469-472 (1985年7月。)
3. B. Klein, H.-J. Knobloch, "ElGamal-Signatur" in
Sicherheitsmechanismen, ed. Fries, Fritsch, Kessler, Klein, pp.
171-176, Oldenburg, Muenchen (1993).
3. B。 クライン、H.J。 クノブロッフ、Sicherheitsmechanismen、教育における"ElGamal-Signatur"。 フリーズ、フリッチュ、ケスラー、クライン、ページ 171-176、オルデンブルク、Muenchen(1993)。
4. C. G. Guenther, "An Identity-Based Key-Exchange Protocol" in
Advances in Cryptology, Proceedings of Eurocrypt '89, pp. 29-37,
Springer (1990).
4. C。 G。 グンサー、CryptologyのAdvances、Eurocrypt89年、ページのProceedingsの「アイデンティティベースの主要な交換プロトコル」 29-37 追出石(1990)。
5. B. Klein, H.-J. Knobloch, "KATHY" in Sicherheitsmechanismen, ed.
Fries, Fritsch, Kessler, Klein, pp. 252-259, Oldenburg, Muenchen
(1993).
5. B。 クライン、H.J。 クノブロッフ、Sicherheitsmechanismen、教育における「キャシー。」 フリーズ、フリッチュ、ケスラー、クライン、ページ 252-259、オルデンブルク、Muenchen(1993)。
6. F. Bauspiess, H.-J. Knobloch, "How to keep authenticity alive in a
computer network" in Advances in Cryptology, Proceedings of
Eurocrypt '89, pp. 38-46, Springer (1990).
6. F。 Bauspiess、H.J。 クノブロッフ、Cryptologyの中で「コンピュータネットワークでどう信憑性を生かし」Advances、Eurocrypt89年、ページのProceedings 38-46 追出石(1990)。
7. F. Bauspiess, "SELANE - An Approach to Secure Networks" in
Abstracts of SECURICOM '90, pp. 159-164, Paris (1990).
7. F。 Bauspiess、「SELANE--」 コネが抜き取るSECURICOM90年の安全なネットワークへのアプローチ、ページ 159-164、パリ(1990)。
8. Th. Beth, "Efficient zero-knowledge identification scheme for
smart cards" in Advances in Cryptology, Proceedings of Eurocrypt
'88, pp. 77-84, Springer (1988).
8. 第. ベス、CryptologyのAdvances、Eurocrypt88年、ページのProceedingsの「スマートカードの効率的な無知識識別計画」 77-84 追出石(1988)。
9. D. Chaum, J. H. Evertse, J. van de Graaf, "An improved protocol
for demonstrating possesion of discrete logarithms and some
generalizations" in Advances in Cryptology, Proceedings of
Eurocrypt '87, pp. 127-141, Springer (1988).
9. D。 Chaumと、J.H.Evertseと、J.バンdeグラーフと、CryptologyのAdvances、Eurocrypt87年、ページのProceedingsの「離散対数のpossesionのデモをするための改良されたプロトコルといくつかの一般化」 127-141 追出石(1988)。
10. W. Diffie, M. Hellman, "New directions in cryptography," IEEE-
Trans. Information Theory, 22, pp. 644-654 (1976).
10. W。 ディフィー、M.ヘルマン、「暗号に関する新傾向」、IEEE、移- 情報Theory、22、ページ 644-654 (1976).
11. Th. Beth, H.-J. Knobloch, "Open network authentication without an
online server" in Proc. Symposium on Comput. Security '90, pp.
160-165, Rome, Italy (1990).
11. 第. ベス、H.J。 クノブロッフ、Procの「オンラインサーバのないオープンネットワーク認証。」 Computに関するシンポジウム。 セキュリティ90年、ページ 160-165 ローマ(イタリア)(1990)。
Danisch Informational [Page 20] RFC 1824 TESS August 1995
[20ページ]RFC1824テス1995年8月の情報のDanisch
12. G. B. Agnew, R. C. Mullin, S. A. Vanstone, "Improved digital
signature scheme based on discrete exponentation," Electron.
Lett., 26, pp. 1024-1025 (1990).
12. G。 B。 アグニュー、R.C.マリン、S.A.Vanstone、「離散的なexponentationに基づく改良されたデジタル署名計画」、Electron。 レット、26、ページ 1024-1025 (1990).
13. "The Digital Signature Standard," Communications of the ACM, Vol.
35, pp. 36-40 (July 1992).
13. 「デジタル署名基準」、ACMのCommunications、Vol.35、ページ 36-40 (1992年7月。)
14. Bruce Schneier, Applied Cryptography, John Wiley & Sons (1994).
14. ブルース・シュナイアー、適用された暗号、ジョン・ワイリー、および息子(1994)。
Author's Address
作者のアドレス
Dipl.-Inform. Hadmut Danisch European Institute for System Security (E.I.S.S.) Institut fuer Algorithmen und Kognitive Systeme (IAKS)
Dipl.知らせてください。 システムセキュリティ(E.I.S.S.)のHadmut Danischのヨーロッパの研究所 Institut fuer Algorithmen und Kognitive Systeme(IAKS)
University of Karlsruhe D-76128 Karlsruhe Germany
カールスルーエD-76128カールスルーエドイツ大学
Phone: ++49 721 96400-18 Fax: ++49 721 696893 EMail: danisch@ira.uka.de WWW: http://avalon.ira.uka.de/personal/danisch.html
以下に電話をしてください。 + +49 721 96400-18Fax: + +49 721 696893メール: danisch@ira.uka.de WWW: http://avalon.ira.uka.de/personal/danisch.html
Danisch Informational [Page 21]
Danisch情報です。[21ページ]
一覧
スポンサーリンク
