1 / 13

On OAEP, PSS, and S/MIME

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)

vern
Download Presentation

On OAEP, PSS, and S/MIME

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. On OAEP, PSS, and S/MIME John Linn RSA Laboratories S/MIME WG, San Diego IETF, 13 December 2000

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. The EME-OAEP-Encode Step

  9. 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

  10. Block Diagram of Proposed PSS Encoding Operation M Hash 00 … 00 Hash(M) salt Hash 00 … 01 salt MGF xor DB MGF(H) H bc

  11. 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”

  12. 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

  13. 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?

More Related