1 / 35

PKCS #1 v2.1: RSA Cryptography Standard

PKCS #1 v2.1: RSA Cryptography Standard. Burt Kaliski, RSA Laboratories PKCS Workshop, 5 October 2000. History of PKCS #1. June 1991: PKCS #1 v1.4 initial RSA encryption, signature schemes Nov. 1993: PKCS #1 v1.5 minor editorial revisions

charla
Download Presentation

PKCS #1 v2.1: RSA Cryptography Standard

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. PKCS #1 v2.1:RSA Cryptography Standard Burt Kaliski, RSA Laboratories PKCS Workshop, 5 October 2000

  2. History of PKCS #1 • June 1991: PKCS #1 v1.4 • initial RSA encryption, signature schemes • Nov. 1993: PKCS #1 v1.5 • minor editorial revisions • wide deployment, in parallel with increased understanding of security of RSA-based techniques • July 1998: PKCS #1 v2.0 • adds RSA-OAEP encryption scheme • (M. Bellare and P. Rogaway, Eurocrypt ’94) • Sept. 1999: PKCS #1 v2.1 draft 1 • adds RSA-PSS signature scheme • (M. Bellare and P. Rogaway, Eurocrypt ’96)

  3. History of PKCS #1 (cont’d) • July 2000: PKCS #1 v2.0 Amd. 1 • adds “multi-prime” RSA • soon: PKCS #1 v2.1 draft 2 • updates RSA-PSS to align with related standards • (for a preview, see IEEE P1363a D5)

  4. What is PSS? • PSS stands for Probabilistic Signature Scheme • Published in 1996 by M. Bellare and P. Rogaway • “Encoding method” for signatures with appendix in the integer factorization (IF) family, including RSA signatures • Provable security in the random oracle model • PSS-R variant provides message recovery

  5. General Model for Signature Schemes • Following IEEE P1363 classification • Primitives are mathematical operations on integers, field elements • Schemes are sets of operations on messages • Schemes are built up from primitives, “encoding methods” mapping between messages, integers • Note: in PKCS #1 v2.1 encoding methods map to strings, which are then converted to integers; this detail omitted here for simplicity

  6. IF Family • Cryptography based on the difficulty of the integer factorization (IF) problem • Modulus n = pq • Public exponent e, private exponent d • RSA: e odd • Rabin-Williams: e even; conditions on p, q

  7. Notation M message (string) m message representative (integer) s signature (integer) SP Signature Primitive (ms) VP Verification Primitive (sm)

  8. Encoding Methods • Mappings between message M, integer message representative m • Encode: Mm • Check: M, m consistent? • Decode: mM • Security goals: one-way, collision-resistant, no mathematical structure

  9. IF Signature and Verification Primitives • RSA case: • SP: s = md mod n • VP: m = se mod n • Rabin-Williams case: • SP: s = |td mod n| • where t = m or m/2 such that (t/n) = +1 • VP: m = t, 2t, n-t or 2(n-t) • where t = se mod n, m has redundancy

  10. IF Signature Scheme with Appendix • Signature operation: • m= Encode(M) • s = SP(m) • Verification operation: • m = VP(s) • Check(M, m)

  11. IF Signature Scheme with Message Recovery • Signature operation: • m = Encode(M) • s = SP(m) • Recovery operation: • m = VP(s) • M = Decode(m) • (Size of M is limited)

  12. Draft Specification of PSS • RSASSA-PSS in PKCS #1 v2.1 d2 • “RSAsignature scheme with appendix based on PSS” • Follows general model, with new encoding operation • Aligned with IEEE P1363a D5

  13. PSS Encoding Method • Message representative is roughly same length as modulus • Based on underlying hash function, mask generation function

  14. PSS Encoding Operation(Some Details Omitted) m = PSS-Encode (M) 1. Generate random salt 2. Hash message and salt, with some padding: H = Hash (00 … 00 || Hash (M) || salt) 3. Add padding to salt to form data block: DB = 00 … 01 || salt 4. Mask data block: maskedDB = DB xor MGF(H) 5. Format message representative: m = maskedDB || H || bc16

  15. PSS Checking Operation(Some Details Omitted) PSS-Check (M, m) 1. Parse message representative: maskedDB || H || bc16= m 2. Unmask data block: DB = maskedDB xor MGF(H) 3. Remove padding from data block to recover salt: 00 … 01||salt= DB 4. Rehash message and salt and compare: H =? Hash (00 … 00 || Hash (M) || salt)

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

  17. Block Diagram of Encoding Operation for PKCS #1 v1.5 M Hash 00 01 ff ff … ff 00 HashID H

  18. Observations • Message is hashed with random salt • improves security proof, resistance to fault analysis attacks • Salt value is included in data block • shortens signature overhead • for message recovery, part of message can be included • Data block is masked • randomizes input to primitive • removes multiplicative structure

  19. Observations (cont’d) • Message representative ends with bc16 • per ISO/IEC 9796-2 format, to support RW primitive • but note that hash function identifier, header bits are not taken from that format • security proof would be “looser” • hash function ID turns out to be only partially helpful in variant with message recovery (a long story …)

  20. Two-Level Hashing • In PKCS #1 v2.1 d1 as well as the original PSS, message and salt were concatenated then hashed • Here, message hash is concatenated with salt • Motivation: • typical protocols hash message first, so integration of new method is easier • “single-pass” processing is easier, since salt is not needed until after message is hashed • Security proof is the same, under usual assumptions about hash function • proof holds even if attacker controls hash value

  21. What’s Provable? • Suppose an algorithm A can forge PSS signatures without access to the details of Hash, MGF • Hash, MGF are effectively “random oracles” that can only be queried • Then an algorithm B can invert RSA in about the same time using algorithm A as a subroutine •  If RSA is hard to invert, then PSS is secure against generic attacks

  22. Proof Method • Inverting algorithm B “builds” Hash, MGF that appear random to forgery algorithm A, but embed an instance to be inverted • When A succeeds at forgery, B succeeds at inverting RSA • Random salt is key to “tight” proof; if not random, “looser” proof holds

  23. What about the Random Oracle Model? • Some concerns have been raised about the relevance of proofs in the random oracle model: • some on theoretical grounds • others on practicality of “instantiating” a random oracle with a real hash or mask generation function • But although the proof may “overestimate” the properties of Hash and MGF, it underestimates properties of RSA • e.g., bit security properties are not considered • Thus, in practice, PSS may well provide high security even without the random oracle model

  24. ASN.1 Syntax for RSASSA-PSS • Generic OID: • id-RSASSA-PSS ::= pkcs-1.10 • Parameters: • RSASSA-PSS-params ::= SEQUENCE { hashFunc [0] AlgorithmIdentifier {{oaepDigestAlgorithms}} DEFAULT sha1Identifier, maskGenFunc [1] AlgorithmIdentifier {{pkcs1MGFAlgorithms}} DEFAULT mgf1SHA1Identifier } • (For S/MIME, perhaps a separate OID for the steps after the message is hashed)

  25. Patent Issues • University of California has applied for a patent (U.S. only) on PSS and PSS-R • In a letter to IEEE P1363, UC has offered to waive licensing on PSS for signatures with appendix if adopted as an IEEE standard • agreed for ANSI X9F1, ISO/IEC, NESSIE as well • Reasonable and non-discriminatory licensing for signatures with message recovery

  26. Recommended Deployment • A gradual transition to PSS is recommended in the interest of prudent security • rollover, along with AES, new hash functions, … • PKCS #1 v1.5 signature scheme is still appropriate for new applications • Different than situation with PKCS #1 v1.5 encryption scheme, where only OAEP is recommended for new applications

  27. Related Standards Work • IEEE P1363a will include PSS, PSS-R • also PKCS #1 v1.5 signatures • ANSI X9.31 expected to be revised to include PSS • ISO/IEC 9796-2 working draft includes PSS-R • NESSIE submission prepared by RSA Laboratories • Significant coordination already; meetings of relevant groups over next two months

  28. Questions from Last Year’s Workshop • PSS-R • ANSI X9.31 encoding method • Composite hash functions • New mask generation functions • Rabin-Williams support

  29. PSS-R • Should PKCS #1 v2.1 include the PSS-R encoding method for signatures with message recovery? • ISO/IEC 9796-2 is being updated to include PSS-R • PSS-R to be included in IEEE P1363a • Current answer: No

  30. ANSI X9.31 Encoding Method • Should PKCS #1 v2.1 include the ANSI X9.31 encoding method? • ANSI X9.31 is a banking standard • FIPS 186-2 supports it • Current answer: No

  31. Composite Hash Functions • Should PKCS #1 v2.1 specify “composite” hash functions? • raised by Tom Gindin, IBM • Example: • SHA-1-MD5(M) = SHA-1(M) || MD5(M) • A simple method to increase security in a modular fashion • Could be combined with PKCS #1 v1.5 encoding method, or PSS • Current answer: Maybe

  32. New Mask Generation Functions • Should PKCS #1 v2.1 define new mask generation functions? • Example: • MGF2(Z) = HMAC(Z,0) || HMAC(Z,1) || … • Current method lacks HMAC’s security proof: • MGF1(Z) = Hash(0 || Z) || Hash(1 || Z) || … • Current answer: No

  33. Rabin-Williams Support • Should PKCS #1 v2.1 include the RW primitives for even exponents? • Would be consistent with ANSI X9.31, X9.44 draft, IEEE P1363 • PKCS #1 v1.5, PSS versions require slightly different primitives than currently specified • cf. relevant submissions to IEEE P1363a • Current answer: No

  34. Conclusions • New version of PKCS #1 in development • Standards strategy for RSA signatures emerging • PSS a prudent choice for long-term security, harmonization of standards • For future work? • PKCS #1 usage guidelines • key generation and validation specifications

  35. For More Information • PKCS #1 drafts: www.rsalabs.com/pkcs/ • IEEE P1363a drafts: grouper.ieee.org/groups/1363/ • bkaliski@rsasecurity.com

More Related