On OAEP, PSS, and S/MIME

John Linn

RSA Laboratories

S/MIME WG, San Diego IETF, 13 December 2000

Presentation Goals and Scope

Discuss futures for RSA-based encryption and signature for CMS and S/MIME: Current practice based on PKCS #1 v1.5 (RFC-2313) New techniques reflect advancing state-of-art

PKCS #1 v2.0 (RFC-2437) incorporates OAEP encryption method, referenced by draft-ietf-smime-cms-rsaes-oaep-02.txt

Work underway on PSS signature method

Emphasizing characteristics, rationale, and status, not cryptomathematics

PKCS #1: History and Status

PKCS #1 v1.5 (November 1993) defines encryption and signature facilities with ad hoc padding

PKCS #1 v2.0 (October 1998) defends against encryption padding attacks (e.g., Bleichenbacher) with Optimal Asymmetric Encryption Padding (OAEP)

PKCS #1 v2.1 (draft, September 1999; 2nd draft in preparation) provides analogous defense against potential signature attacks with Probabilistic Signature Scheme (PSS)

Availability: Informational RFCs 2313 (v1.5), 2437 (v2.0), http://www.rsalabs.com

PKCS #1 (v1.5): Padding Formats and Usage

Sign: 01 || ff … ff || 00 || DER(HashAlgID,Hash(M)) Encrypt: 02 || pseudorandom PS || 00 || M Ad hoc design Widely deployed, incorporated in many Internet

standards, such as: PKIX profile TLS IPSEC S/MIME

Bleichenbacher attack on PKCS #1 v1.5 encryption

padding Adaptive chosen ciphertext attack (1998)

needs information from 100,000s of decryptions, indicating whether correct padding resulted

successful attack yields result of a specific decryption Countermeasures include

protocol-level means to ensure that information on decryptions isn’t available to attacker constraints on returned information randomize key, continue upon detected pad error

improved, plaintext-aware padding (e.g., OAEP) in cryptographic layer to prevent attack

More detailed discussion: RSA Laboratories Bulletin #7 in http://www.rsalabs.com/bulletins

OAEP Properties Technique originally published by Bellare and

Rogaway, 1994 Recent theoretical results on strengths and assumptions

of OAEP proofs discussed in cryptographic research community; properties remain strong for use with RSA

OAEP offers attractive properties, in random oracle model: Provably secure

can tie security to strength of the RSA function Plaintext-aware, given suitable construction

“can’t” generate valid ciphertext without knowing the plaintext chosen-ciphertext attacks are ineffective

RSAES-OAEP Steps

Encrypt (public key, message M, encoding parameters P): encoded message EM = EME-OAEP-Encode (M, P) ciphertext C = RSAEP (public key, EM)

Decrypt (private key, C, P): EM = RSADP (private key, C) M = EME-OAEP-Decode (EM, P)

M, C bounded, P arbitrary length (and empty by default in S/MIME proposal)

Encoding includes masked data, masked random seed

maskedDB

\xorMGF

Seed

DB

MGF\xor

maskedSeed

Padding Operation

P M

Hash

EM

The EME-OAEP-Encode Step

And, in the signature column, PSS...

What if PKCS #1 v1.5 signatures found weak? Like PKCS #1 v1.5 encryption, no proof of security,

though design is well motivated, supported by analysis exploitable attack would be surprising — but experience

demonstrates that cryptanalytic advances are unpredictable

Like OAEP, PSS offers provably secure design by Bellare and Rogaway

Block Diagram of Proposed PSS Encoding Operation

00 … 01 salt

DB MGF(H) H

Hash

M

Hash

00 … 00 Hash(M) salt

MGF

bc

xor

Patent Issues

No patents known for OAEP technique as proposed for S/MIME patents could apply to some uses of optional encoding

parameters PSS encoding method is patent pending by University

of California UC agreed to waive licensing on PSS for signatures with

appendix if adopted in IEEE standard; agreed for ANSI X9F1, ISO/IEC, NESSIE as well

for signatures with message recovery (PSS-R variant) “reasonable and nondiscriminatory licensing”

Status of OAEP and PSS in Other Standards Forums

OAEP is stable; being included compatibly in multiple specifications in PKCS #1 v2.0 in IEEE P1363, being incorporated in ANSI X9.44

Standardization of PSS being pursued in several forums; detailed alignment ongoing To be included in IEEE P1363a, PKCS #1 v2.1 Intent in ANSI X9F1 to reopen X9.31 to incorporate PSS Revision in progress to include PSS-R in ISO 9796-2

Proposed Approach

Short term: Support both PKCS #1 v. 1.5 and OAEP encryption, along with RSA algorithm MUSTs? S/MIME MUST for PKCS #1 v. 1.5, SHOULD for

OAEP? OAEP MUST or SHOULD for interactive CMS-based

applications? Longer term: Move toward PSS signatures?

upgrade in due course — e.g., along with AES algorithm, new hash functions?