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),

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

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

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 … 01salt DB  MGF(H) H Hash M 00 … 00Hash(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

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?