pkcs13 proposal

Uploaded from authorPOINT
Views:
 
Category: Education
     
 

Presentation Description

No description available.

Comments

Presentation Transcript

PKCS #13: Elliptic Curve Cryptography Standard: 

PKCS #13: Elliptic Curve Cryptography Standard Burt Kaliski RSA Laboratories PKCS Workshop October 7, 1998

Introduction: 

Introduction Elliptic curve cryptography is emerging as a new public-key technique Some standardization underway: ANSI X9.62,.63, IEEE P1363, ISO work PKCS #13: a profile of existing work status: in preparation, this is a proposal

ECC: Primary Choices: 

ECC: Primary Choices Underlying finite field Cryptographic schemes Point representation

Finite Field: 

Finite Field Odd characteristic: GF(p), p odd also GF(pm), e.g., for p = 3 Even characteristic: GF(2m) which field representations? Even generally faster (esp. in hardware), odd leverages existing modular arithmetic implementations

Key Agreement Schemes: 

Key Agreement Schemes Diffie-Hellman 'Unified' Diffie-Hellman MQV DH basic, 'unified' more flexible, MQV more efficient for joint static/ephemeral P1363, X9.63 draft have all three

Signature Schemes: 

Signature Schemes DSA Nyberg-Rueppel Schnorr DSA 'standard,' NR allows message recovery, Schnorr more 'provable' P1363 has first two, X9.62 has DSA

Encryption Schemes: 

Encryption Schemes Elgamal (= DH + multiplication) S/MIME approach Zheng-Seberry, Bellare-Rogaway schemes Elgamal basic, S/MIME enhanced, ZS and BR 'provable', more flexible ZS, BR submitted to P1363a BR in X9.63 draft

Point Representation: 

Point Representation Uncompressed: (x,y) y-compressed: only one bit of y x-compacted: one less bit of x x only (with algorithm changes) Size, processing tradeoffs P1363 supports uncompressed, y-compressed

Proposed Profile: 

Proposed Profile GF(p) and GF(2m), with rationale ECDH, ECDSA, P1363a ECES Uncompressed, with P1363 format Domain parameter and key generation, validation later

IP Considerations: 

IP Considerations ECC in general is not patented, but specific choices may be, e.g.: MQV key agreement point compression (app.) key validation (app.) Proposed profile is intended to be unencumbered, though some implementation techniques may be patented

Discussion: 

Discussion Are the choices appropriate? Is the profile too general? e.g., would fewer choices be better? Is it necessary? maybe IEEE P1363 Profile for PKCS Applications would be a better title? Work plan and schedule