PKCS #1 v2.

1:
RSA Cryptography Standard
Burt Kaliski, RSA Laboratories PKCS Workshop, 30 September 1999

Summary
PKCS #1 v1.5 published in November 1993

Wide deployment, in parallel with increased understanding of security of RSA-based techniques

PKCS #1 v2.0 released in July 1998 with OAEP (Optimal Asymmetric Encryption Padding) for enhanced security of encryption schemes
OAEP developed by M. Bellare and P. Rogaway, 1994

PKCS #1 v2.1 draft incorporates the companion technique for digital signatures, PSS (Probabilistic Signature Scheme)
PSS developed by same authors, 1996

Goals of Presentation
Part I: Review the current draft

Part II: Propose a strategy for RSA signature standards

Part III: Discuss several other topics related to the draft

Part I: The Current Draft

Status
PKCS #1 v2.1 adds PSS signature scheme, includes some editorial improvements Draft 1 released 21 September for 30-day review

Outline
What is PSS?

General Model for Signature Schemes

Draft Specification of PSS ASN.1 Syntax Example Applications PSS Advantages and Alternatives Patent Issues Recommended Deployment A Brief Security Update

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

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

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

Notation
M message (string)

m
s SP VP

message representative (integer)

signature (integer) Signature Primitive (m s) Verification Primitive (s m)

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

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

IF Signature Scheme with Appendix

Signature operation:
m = Encode(M) s = SP(m)

Verification operation:
m = VP(s) Check(M, m)

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)

Draft Specification of PSS

RSASSA-PSS in PKCS #1 v2.1 d1
RSA signature scheme with appendix based on PSS

Following general model, with salt value

input to encoding operation optional output from signature operation and input to verification operation for single-pass processing two cases for verification operation, with and without salt value

Based on RSA primitives, also supports RW

as noted in Bellare-Rogaway submission to IEEE P1363a

PSS Signature Operation

Input: message M

Output: signature s, salt (opt.)

1. Generate salt 2. Apply encoding operation to message, salt to produce message representative:
m = Encode(M, salt)

3. Apply signature primitive to produce signature:

s = SP(m)

PSS Verification Operation w/Salt

Input: message M, signature s, salt

Output: valid / invalid

1. Apply encoding operation to produce message representative:
m = Encode(M, salt)

2. Apply verification primitive to recover original message representative:

m = VP(s)

3. Compare:
m =? m

PSS Verification Operation w/o Salt

Input: message M, signature s

Output: valid / invalid

1. Apply verification primitive to recover original message representative:
m = VP(s)

2. Apply checking operation to determine whether message representative is valid:

Check(M, m)

PSS Encoding Method

Following general model, with encoding and checking operations Salt is additional input to encoding operation
same length as hash function output

Message representative is one byte shorter than modulus Based on underlying hash function, mask generation function

PSS Encoding Operation

Input: message M, salt

Output: message representative m

1. Hash message and salt:
H = Hash (salt || M)

2. Add padding to salt to form data block:

DB = salt || 00 00

3. Expand hash and mask data block:

maskedDB = DB xor MGF(H)

4. Format message representative:

m = H || maskedDB

Block Diagram of PSS Encoding Operation

M salt PS

Hash

DB

MGF

xor

maskedDB

EM

Observations
Message is hashed with random salt
improves security proof reduces reliance on hash function security

Hash value is expanded to full length

randomizes input to primitive removes multiplicative structure enables proof

Salt value is xored into expanded hash

shortens signature overhead part of message may also be xored

PSS Checking Operation

Input: message M, message representative m

Output: consistent / inconsistent

1. Parse message representative:
H || maskedDB = m

2. Expand hash value and unmask data block:

DB = maskedDB xor MGF(H)

3. Check and remove padding to recover salt:

salt || 00 00 =? DB

4. Rehash message and salt and compare:

H =? Hash (salt || M)

PSS Advantages
Provable security under random oracle model
other methods have ad hoc security, not a proof

Reduced reliance on hash function security

birthday attack collisions not useful due to random salt

Natural extension to message recovery

Whats 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

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, but even if not random, proof still holds

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

Alternatives to PSS
Current methods
but not provably secure (what if?)

Full Domain Hashing (Bellare-Rogaway 1993)

but security proof not as tight not as flexible

Future research

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, salt OCTET STRING OPTIONAL }

Note: syntax needs some updating

Some Special Syntax

In some applications, e.g., PKCS #7 and S/MIME CMS, the hash function underlying a signature scheme is identified separately Generic OID for use in combination with PSS:
id-salted-hash ::= pkcs-1.11

Parameters:
Salted-Hash-Params ::= SEQUENCE { hashFunc [0] AlgorithmIdentifier, salt OCTET STRING OPTIONAL }

Example Application: X.509 Certificates

Signature algorithm identified in two places:
body of certificate adjacent to signature

To save space, both identifiers should specify idRSASSA-PSS without salt Salt can be recovered from signature during verification

Example Application: S/MIME Signed Messages

Relevant algorithms are identified in three places:
underlying hash function before message and in SignerInfo after message signature algorithm in SignerInfo

To facilitate single-pass processing, identifier before message should specify id-salted-hash with underlying hash function, salt Hash function identifier in SignerInfo should specify id-salted-hash without salt Signature algorithm identifier should specify idRSASSA-PSS without salt

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 Reasonable and non-discriminatory licensing for signatures with message recovery

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

A Brief Security Update

At Crypto 99, J.-S. Coron, D. Naccache and J. Stern give a thorough analysis of security of RSAbased signature schemes against attacks based on factoring message representatives
stronger versions of Desmedt-Odylzko attack (1985)

PKCS #1 v1.5 fared very well

attacks are impractical, more expensive than finding hash function collisions (280 operations) design considerations by R. Rivest (1991) provide resistance

D. Coppersmith, S. Halevi and C. Jutla extended the attack to break ISO/IEC 9796-1 (Crypto 99 rump session)

Part II: RSA Standards Strategy

Introduction
Various methods today for digital signatures in the integer factorization / RSA family Standards, practice, theory differ How to harmonize?

Major Signature Schemes in the IF Family

Signature schemes with appendix:
ANSI X9.31 PKCS #1 v1.5 (also in v2.0, v2.1 draft) Bellare-Rogaway FDH and PSS

Signature schemes with message recovery:

ISO/IEC 9796-1 Bellare-Rogaway PSS-R

This discussion focuses on the first set

ANSI X9.31
Encode(M) =

6b bb bb ba || Hash(M) || 3x cc
where x = 3 for SHA-1, 1 for RIPEMD-160

Ad hoc design

Widely standardized
IEEE P1363, ISO/IEC 14888-3 US NIST FIPS 186-1

ANSI X9.31 requires strong primes

PKCS #1 v1.5
Encode(M) =

00 01 ff ff || HashAlgID || Hash(M)
Ad hoc design Widely deployed
SSL certificates S/MIME

To be included in IEEE P1363a

Bellare-Rogaway FDH
(Full Domain Hashing, ACM CCCS 93)

Encode(M) =

00 || Full-Length-Hash(m)
Provably secure design To be included in IEEE P1363a

PSS vs. FDH: Technical Comparison

PSS is probabilistic, FDH is deterministic

Both provably secure

same paradigm as Optimal Asymmetric Encryption Padding (OAEP)

PSS has tighter security proof, is less dependent on security of hash function PSS-R variant supports message recovery, partial message recovery PSS is patent pending (but generously licensed)

ANSI X9.31 vs. PKCS #1 v1.5: Technical Comparison

Both are deterministic

Both include a hash function identifier

Both are ad hoc designs
both resist Coron-Naccache-Stern / CoppersmithHalevi-Jutla attacks on ISO/IEC 9796-1,-2

Both support RSA and RW primitives

see IEEE P1363a contribution on PKCS #1 signatures for discussion

No patents have been reported to IEEE P1363 or ANSI X9.31 for these encoding methods

Standards vs. Theory vs. Practice

ANSI X9.31 is widely standardized

PSS is widely considered secure

PKCS #1 v1.5 is widely deployed How to harmonize?

Challenges
Infrastructure changes take time
particularly on the user side

ANSI X9.31 is more than just another encoding method, also specifies strong primes
a controversial topic

Many communities involved

formal standards bodies, IETF, browser vendors, certificate authorities

Prudent Security
What if a weakness were found in ANSI X9.31 or PKCS #1 v1.5 signatures?
no proof of security, though designs are well motivated, supported by analysis would be surprising but so were vulnerabilities in ISO/IEC 9796-1,-2

PSS embodies best practices, prudent to improve over time

Proposed Strategy
Short term (1-2 years): Support both PKCS #1 v1.5 and ANSI X9.31 signatures for interoperability
e.g., in IETF profiles, FIPS validation NIST is in the process of adding PKCS #1 v1.5 to FIPS 186-2 for an 18-month transition period

Long term (2-5 years): Move toward PSS signatures

not necessarily, but perhaps optionally with strong primes upgrade in due course e.g., with AES algorithm, new hash functions

Standards Work
IEEE P1363a will include PSS
also FDH, PKCS #1 v1.5 signatures

PKCS #1 v2.1 d1 includes it To be proposed to ANSI X9F1

Other relevant standards bodies include ISO/IEC, US NIST, IETF

Part III: Some Discussion Topics

Outline
PSS-R

ANSI X9.31 encoding method

Composite hash functions New mask generation functions Rabin-Williams support

PSS-R
Should PKCS #1 v2.1 include the PSS-R encoding method? ISO/IEC 9796-1, -2 may be updated with new and potentially different signature scheme with message recovery PSS-R to be included in IEEE P1363a

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-1 includes it

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

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 HMACs security proof:

MGF1(Z) = Hash(0 || Z) || Hash(1 || Z) ||

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

Conclusions
A new draft of PKCS #1 nearing completion

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