tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 8017

 
 
 

PKCS #1: RSA Cryptography Specifications Version 2.2

Part 3 of 4, p. 39 to 53
Prev Section       Next Section

 


prevText      Top      ToC       Page 39 
9.  Encoding Methods for Signatures with Appendix

   Encoding methods consist of operations that map between octet string
   messages and octet-string-encoded messages, which are converted to
   and from integer message representatives in the schemes.  The integer
   message representatives are processed via the primitives.  The
   encoding methods thus provide the connection between the schemes,
   which process messages, and the primitives.

   An encoding method for signatures with appendix, for the purposes of
   this document, consists of an encoding operation and optionally a
   verification operation.  An encoding operation maps a message M to an
   encoded message EM of a specified length.  A verification operation
   determines whether a message M and an encoded message EM are
   consistent, i.e., whether the encoded message EM is a valid encoding
   of the message M.

   The encoding operation may introduce some randomness, so that
   different applications of the encoding operation to the same message
   will produce different encoded messages, which has benefits for
   provable security.  For such an encoding method, both an encoding and
   a verification operation are needed unless the verifier can reproduce
   the randomness (e.g., by obtaining the salt value from the signer).
   For a deterministic encoding method, only an encoding operation is
   needed.

   Two encoding methods for signatures with appendix are employed in the
   signature schemes and are specified here: EMSA-PSS and
   EMSA-PKCS1-v1_5.

Top      Up      ToC       Page 40 
9.1.  EMSA-PSS

   This encoding method is parameterized by the choice of hash function,
   mask generation function, and salt length.  These options should be
   fixed for a given RSA key, except that the salt length can be
   variable (see [JONSSON] for discussion).  Suggested hash and mask
   generation functions are given in Appendix B.  The encoding method is
   based on Bellare and Rogaway's Probabilistic Signature Scheme (PSS)
   [RSARABIN][PSS].  It is randomized and has an encoding operation and
   a verification operation.

   Figure 2 illustrates the encoding operation.

      __________________________________________________________________

                                     +-----------+
                                     |     M     |
                                     +-----------+
                                           |
                                           V
                                         Hash
                                           |
                                           V
                             +--------+----------+----------+
                        M' = |Padding1|  mHash   |   salt   |
                             +--------+----------+----------+
                                            |
                  +--------+----------+     V
            DB =  |Padding2|   salt   |   Hash
                  +--------+----------+     |
                            |               |
                            V               |
                           xor <--- MGF <---|
                            |               |
                            |               |
                            V               V
                  +-------------------+----------+--+
            EM =  |    maskedDB       |     H    |bc|
                  +-------------------+----------+--+
      __________________________________________________________________

   Figure 2: EMSA-PSS Encoding Operation

   Note that the verification operation follows reverse steps to recover
   salt and then forward steps to recompute and compare H.

Top      Up      ToC       Page 41 
   Notes:

   1.  The encoding method defined here differs from the one in Bellare
       and Rogaway's submission to IEEE 1363a [PSS] in three respects:

       *  It applies a hash function rather than a mask generation
          function to the message.  Even though the mask generation
          function is based on a hash function, it seems more natural to
          apply a hash function directly.

       *  The value that is hashed together with the salt value is the
          string (0x)00 00 00 00 00 00 00 00 || mHash rather than the
          message M itself.  Here, mHash is the hash of M.  Note that
          the hash function is the same in both steps.  See Note 3 below
          for further discussion.  (Also, the name "salt" is used
          instead of "seed", as it is more reflective of the value's
          role.)

       *  The encoded message in EMSA-PSS has nine fixed bits; the first
          bit is 0 and the last eight bits form a "trailer field", the
          octet 0xbc.  In the original scheme, only the first bit is
          fixed.  The rationale for the trailer field is for
          compatibility with the Integer Factorization Signature
          Primitive using Rabin-Williams (IFSP-RW) in IEEE 1363
          [IEEE1363] and the corresponding primitive in ISO/IEC
          9796-2:2010 [ISO9796].

   2.  Assuming that the mask generation function is based on a hash
       function, it is RECOMMENDED that the hash function be the same as
       the one that is applied to the message; see Section 8.1 for
       further discussion.

   3.  Without compromising the security proof for RSASSA-PSS, one may
       perform Steps 1 and 2 of EMSA-PSS-ENCODE and EMSA-PSS-VERIFY (the
       application of the hash function to the message) outside the
       module that computes the rest of the signature operation, so that
       mHash rather than the message M itself is input to the module.
       In other words, the security proof for RSASSA-PSS still holds
       even if an opponent can control the value of mHash.  This is
       convenient if the module has limited I/O bandwidth, e.g., a smart
       card.  Note that previous versions of PSS [RSARABIN][PSS] did not
       have this property.  Of course, it may be desirable for other
       security reasons to have the module process the full message.
       For instance, the module may need to "see" what it is signing if
       it does not trust the component that computes the hash value.

Top      Up      ToC       Page 42 
   4.  Typical salt lengths in octets are hLen (the length of the output
       of the hash function Hash) and 0.  In both cases, the security of
       RSASSA-PSS can be closely related to the hardness of inverting
       RSAVP1.  Bellare and Rogaway [RSARABIN] give a tight lower bound
       for the security of the original RSA-PSS scheme, which
       corresponds roughly to the former case, while Coron [FDH] gives a
       lower bound for the related Full Domain Hashing scheme, which
       corresponds roughly to the latter case.  In [PSSPROOF], Coron
       provides a general treatment with various salt lengths ranging
       from 0 to hLen; see [IEEE1363A] for discussion.  See also
       [JONSSON], which adapts the security proofs in [RSARABIN]
       [PSSPROOF] to address the differences between the original and
       the present version of RSA-PSS as listed in Note 1 above.

   5.  As noted in IEEE 1363a [IEEE1363A], the use of randomization in
       signature schemes -- such as the salt value in EMSA-PSS -- may
       provide a "covert channel" for transmitting information other
       than the message being signed.  For more on covert channels, see
       [SIMMONS].

9.1.1.  Encoding Operation

   EMSA-PSS-ENCODE (M, emBits)

   Options:

      Hash     hash function (hLen denotes the length in octets of
               the hash function output)
      MGF      mask generation function
      sLen     intended length in octets of the salt

   Input:

      M        message to be encoded, an octet string
      emBits   maximal bit length of the integer OS2IP (EM) (see Section
               4.2), at least 8hLen + 8sLen + 9

   Output:

      EM       encoded message, an octet string of length emLen = \ceil
               (emBits/8)

   Errors:  "Encoding error"; "message too long"

Top      Up      ToC       Page 43 
   Steps:

      1.   If the length of M is greater than the input limitation for
           the hash function (2^61 - 1 octets for SHA-1), output
           "message too long" and stop.

      2.   Let mHash = Hash(M), an octet string of length hLen.

      3.   If emLen < hLen + sLen + 2, output "encoding error" and stop.

      4.   Generate a random octet string salt of length sLen; if sLen =
           0, then salt is the empty string.

      5.   Let

              M' = (0x)00 00 00 00 00 00 00 00 || mHash || salt;

           M' is an octet string of length 8 + hLen + sLen with eight
           initial zero octets.

      6.   Let H = Hash(M'), an octet string of length hLen.

      7.   Generate an octet string PS consisting of emLen - sLen - hLen
           - 2 zero octets.  The length of PS may be 0.

      8.   Let DB = PS || 0x01 || salt; DB is an octet string of length
           emLen - hLen - 1.

      9.   Let dbMask = MGF(H, emLen - hLen - 1).

      10.  Let maskedDB = DB \xor dbMask.

      11.  Set the leftmost 8emLen - emBits bits of the leftmost octet
           in maskedDB to zero.

      12.  Let EM = maskedDB || H || 0xbc.

      13.  Output EM.

Top      Up      ToC       Page 44 
9.1.2.  Verification Operation

   EMSA-PSS-VERIFY (M, EM, emBits)

   Options:

      Hash     hash function (hLen denotes the length in octets of
               the hash function output)
      MGF      mask generation function
      sLen     intended length in octets of the salt

   Input:

      M        message to be verified, an octet string
      EM       encoded message, an octet string of length emLen = \ceil
               (emBits/8)
      emBits   maximal bit length of the integer OS2IP (EM) (see Section
               4.2), at least 8hLen + 8sLen + 9

   Output:  "consistent" or "inconsistent"

   Steps:

      1.   If the length of M is greater than the input limitation for
           the hash function (2^61 - 1 octets for SHA-1), output
           "inconsistent" and stop.

      2.   Let mHash = Hash(M), an octet string of length hLen.

      3.   If emLen < hLen + sLen + 2, output "inconsistent" and stop.

      4.   If the rightmost octet of EM does not have hexadecimal value
           0xbc, output "inconsistent" and stop.

      5.   Let maskedDB be the leftmost emLen - hLen - 1 octets of EM,
           and let H be the next hLen octets.

      6.   If the leftmost 8emLen - emBits bits of the leftmost octet in
           maskedDB are not all equal to zero, output "inconsistent" and
           stop.

      7.   Let dbMask = MGF(H, emLen - hLen - 1).

      8.   Let DB = maskedDB \xor dbMask.

      9.   Set the leftmost 8emLen - emBits bits of the leftmost octet
           in DB to zero.

Top      Up      ToC       Page 45 
      10.  If the emLen - hLen - sLen - 2 leftmost octets of DB are not
           zero or if the octet at position emLen - hLen - sLen - 1 (the
           leftmost position is "position 1") does not have hexadecimal
           value 0x01, output "inconsistent" and stop.

      11.  Let salt be the last sLen octets of DB.

      12.  Let

              M' = (0x)00 00 00 00 00 00 00 00 || mHash || salt ;

           M' is an octet string of length 8 + hLen + sLen with eight
           initial zero octets.

      13.  Let H' = Hash(M'), an octet string of length hLen.

      14.  If H = H', output "consistent".  Otherwise, output
           "inconsistent".

9.2.  EMSA-PKCS1-v1_5

   This encoding method is deterministic and only has an encoding
   operation.

   EMSA-PKCS1-v1_5-ENCODE (M, emLen)

   Option:

      Hash     hash function (hLen denotes the length in octets of
               the hash function output)

   Input:

      M        message to be encoded
      emLen    intended length in octets of the encoded message, at
               least tLen + 11, where tLen is the octet length of the
               Distinguished Encoding Rules (DER) encoding T of
               a certain value computed during the encoding operation

   Output:

      EM       encoded message, an octet string of length emLen

   Errors:  "message too long"; "intended encoded message length too
      short"

Top      Up      ToC       Page 46 
   Steps:

      1.  Apply the hash function to the message M to produce a hash
          value H:

             H = Hash(M).

          If the hash function outputs "message too long", output
          "message too long" and stop.

      2.  Encode the algorithm ID for the hash function and the hash
          value into an ASN.1 value of type DigestInfo (see
          Appendix A.2.4) with the DER, where the type DigestInfo has
          the syntax

               DigestInfo ::= SEQUENCE {
                   digestAlgorithm AlgorithmIdentifier,
                   digest OCTET STRING
               }

          The first field identifies the hash function and the second
          contains the hash value.  Let T be the DER encoding of the
          DigestInfo value (see the notes below), and let tLen be the
          length in octets of T.

      3.  If emLen < tLen + 11, output "intended encoded message length
          too short" and stop.

      4.  Generate an octet string PS consisting of emLen - tLen - 3
          octets with hexadecimal value 0xff.  The length of PS will be
          at least 8 octets.

      5.  Concatenate PS, the DER encoding T, and other padding to form
          the encoded message EM as

             EM = 0x00 || 0x01 || PS || 0x00 || T.

      6.  Output EM.

Top      Up      ToC       Page 47 
   Notes:

   1.  For the nine hash functions mentioned in Appendix B.1, the DER
       encoding T of the DigestInfo value is equal to the following:

         MD2:     (0x)30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 02 05 00 04
                      10 || H.
         MD5:     (0x)30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04
                      10 || H.
         SHA-1:   (0x)30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 || H.
         SHA-224:  (0x)30 2d 30 0d 06 09 60 86 48 01 65 03 04 02 04
                      05 00 04 1c || H.
         SHA-256: (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00
                      04 20 || H.
         SHA-384: (0x)30 41 30 0d 06 09 60 86 48 01 65 03 04 02 02 05 00
                      04 30 || H.
         SHA-512: (0x)30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00
                      04 40 || H.
         SHA-512/224:  (0x)30 2d 30 0d 06 09 60 86 48 01 65 03 04 02 05
                           05 00 04 1c || H.
         SHA-512/256:  (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 06
                           05 00 04 20 || H.

   2.  In version 1.5 of this document, T was defined as the BER
       encoding, rather than the DER encoding, of the DigestInfo value.
       In particular, it is possible -- at least in theory -- that the
       verification operation defined in this document (as well as in
       version 2.0) rejects a signature that is valid with respect to
       the specification given in PKCS #1 v1.5.  This occurs if other
       rules than DER are applied to DigestInfo (e.g., an indefinite
       length encoding of the underlying SEQUENCE type).  While this is
       unlikely to be a concern in practice, a cautious implementor may
       choose to employ a verification operation based on a BER decoding
       operation as specified in PKCS #1 v1.5.  In this manner,
       compatibility with any valid implementation based on PKCS #1 v1.5
       is obtained.  Such a verification operation should indicate
       whether the underlying BER encoding is a DER encoding and hence
       whether the signature is valid with respect to the specification
       given in this document.

10.  Security Considerations

   Security considerations are discussed throughout this memo.

Top      Up      ToC       Page 48 
11.  References

11.1.  Normative References

   [GARNER]   Garner, H., "The Residue Number System", IRE Transactions
              on Electronic Computers, Volume EC-8, Issue 2, pp.
              140-147, DOI 10.1109/TEC.1959.5219515, June 1959.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RSA]      Rivest, R., Shamir, A., and L. Adleman, "A Method for
              Obtaining Digital Signatures and Public-Key
              Cryptosystems", Communications of the ACM, Volume 21,
              Issue 2, pp. 120-126, DOI 10.1145/359340.359342, February
              1978.

11.2.  Informative References

   [ANSIX944] ANSI, "Key Establishment Using Integer Factorization
              Cryptography", ANSI X9.44-2007, August 2007.

   [BKS]      Bleichenbacher, D., Kaliski, B., and J. Staddon, "Recent
              Results on PKCS #1: RSA Encryption Standard", RSA
              Laboratories, Bulletin No. 7, June 1998.

   [BLEICHENBACHER]
              Bleichenbacher, D., "Chosen Ciphertext Attacks Against
              Protocols Based on the RSA Encryption Standard PKCS #1",
              Lecture Notes in Computer Science, Volume 1462, pp. 1-12,
              1998.

   [CHOSEN]   Desmedt, Y. and A. Odlyzko, "A Chosen Text Attack on the
              RSA Cryptosystem and Some Discrete Logarithm Schemes",
              Lecture Notes in Computer Science, Volume 218, pp.
              516-522, 1985.

   [COCHRAN]  Cochran, M., "Notes on the Wang et al. 2^63 SHA-1
              Differential Path", Cryptology ePrint Archive: Report
              2007/474, August 2008, <http://eprint.iacr.org/2007/474>.

   [FASTDEC]  Quisquater, J. and C. Couvreur, "Fast Decipherment
              Algorithm for RSA Public-Key Cryptosystem", Electronic
              Letters, Volume 18, Issue 21, pp. 905-907,
              DOI 10.1049/el:19820617, October 1982.

Top      Up      ToC       Page 49 
   [FDH]      Coron, J., "On the Exact Security of Full Domain Hash",
              Lecture Notes in Computer Science, Volume 1880, pp.
              229-235, 2000.

   [FOPS]     Fujisaki, E., Okamoto, T., Pointcheval, D., and J. Stern,
              "RSA-OAEP is Secure under the RSA Assumption", Lecture
              Notes in Computer Science, Volume 2139, pp. 260-274,
              August 2001.

   [FORGERY]  Coppersmith, D., Halevi, S., and C. Jutla, "ISO 9796-1 and
              the new forgery strategy", rump session of Crypto, August
              1999.

   [HAASTAD]  Haastad, J., "Solving Simultaneous Modular Equations of
              Low Degree", SIAM Journal on Computing, Volume 17,
              Issue 2, pp. 336-341, DOI 10.1137/0217019, April 1988.

   [HANDBOOK] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook
              of Applied Cryptography", CRC Press, ISBN: 0849385237,
              1996.

   [HASHID]   Kaliski, B., "On Hash Function Firewalls in Signature
              Schemes", Lecture Notes in Computer Science, Volume 2271,
              pp. 1-16, DOI 10.1007/3-540-45760-7_1, February 2002.

   [IEEE1363] IEEE, "Standard Specifications for Public Key
              Cryptography", IEEE Std 1363-2000,
              DOI 10.1109/IEEESTD.2000.92292, August 2000,
              <http://ieeexplore.ieee.org/document/891000/>.

   [IEEE1363A]
              IEEE, "Standard Specifications for Public Key Cryptography
              - Amendment 1: Additional Techniques", IEEE Std 1363a-
              2004, DOI 10.1109/IEEESTD.2004.94612, September 2004,
              <http://ieeexplore.ieee.org/document/1335427/>.

   [ISO18033] International Organization for Standardization,
              "Information technology -- Security techniques --
              Encryption algorithms - Part 2: Asymmetric ciphers", ISO/
              IEC 18033-2:2006, May 2006.

   [ISO9594]  International Organization for Standardization,
              "Information technology - Open Systems Interconnection -
              The Directory: Public-key and attribute certificate
              frameworks", ISO/IEC 9594-8:2008, December 2008.

Top      Up      ToC       Page 50 
   [ISO9796]  International Organization for Standardization,
              "Information technology - Security techniques - Digital
              signature schemes giving message recovery - Part 2:
              Integer factorization based mechanisms",
              ISO/IEC 9796-2:2010, December 2010.

   [JONSSON]  Jonsson, J., "Security Proofs for the RSA-PSS Signature
              Scheme and Its Variants", Cryptology ePrint
              Archive: Report 2001/053, March 2002,
              <http://eprint.iacr.org/2001/053>.

   [LOWEXP]   Coppersmith, D., Franklin, M., Patarin, J., and M. Reiter,
              "Low-Exponent RSA with Related Messages", Lecture Notes in
              Computer Science, Volume 1070, pp. 1-9, 1996.

   [MANGER]   Manger, J., "A Chosen Ciphertext Attack on RSA Optimal
              Asymmetric Encryption Padding (OAEP) as Standardized in
              PKCS #1 v2.0", Lecture Notes in Computer Science, Volume
              2139, pp. 230-238, DOI 10.1007/3-540-44647-8_14, 2001.

   [MD4]      Dobbertin, H., "Cryptanalysis of MD4", Lecture Notes in
              Computer Science, Volume 1039, pp. 53-69,
              DOI 10.1007/3-540-60865-6_43, 1996.

   [MD4FIRST] Dobbertin, H., "The First Two Rounds of MD4 are Not One-
              Way", Lecture Notes in Computer Science, Volume 1372, pp.
              284-292, DOI 10.1007/3-540-69710-1_19, March 1998.

   [MD4LAST]  den Boer, B. and A. Bosselaers, "An Attack on the Last Two
              Rounds of MD4", Lecture Notes in Computer Science, Volume
              576, pp. 194-203, DOI 10.1007/3-540-46766-1_14, 1992.

   [NEWATTACK]
              Coron, J., Joye, M., Naccache, D., and P. Paillier, "New
              Attacks on PKCS #1 v1.5 Encryption", Lecture Notes in
              Computer Science, Volume 1807, pp. 369-381,
              DOI 10.1007/3-540-45539-6_25, May 2000.

   [OAEP]     Bellare, M. and P. Rogaway, "Optimal Asymmetric Encryption
              - How to Encrypt with RSA", Lecture Notes in Computer
              Science, Volume 950, pp. 92-111, November 1995.

   [PA98]     Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway,
              "Relations Among Notions of Security for Public-Key
              Encryption Schemes", Lecture Notes in Computer
              Science, Volume 1462, pp. 26-45, DOI 10.1007/BFb0055718,
              1998.

Top      Up      ToC       Page 51 
   [PADDING]  Coron, J., Naccache, D., and J. Stern, "On the Security of
              RSA Padding", Lecture Notes in Computer Science, Volume
              1666, pp. 1-18, DOI 10.1007/3-540-48405-1_1, December
              1999.

   [PKCS1_22] RSA Laboratories, "PKCS #1: RSA Cryptography Standard
              Version 2.2", October 2012.

   [PREFIX]   Stevens, M., Lenstra, A., and B. de Weger, "Chosen-prefix
              collisions for MD5 and applications", International
              Journal of Applied Cryptography, Volume 2, No. 4, pp.
              322-359, July 2012.

   [PSS]      Bellare, M. and P. Rogaway, "PSS: Provably Secure Encoding
              Method for Digital Signatures", Submission to IEEE P1363a,
              August 1998, <http://grouper.ieee.org/groups/1363/
              P1363a/contributions/pss-submission.pdf>.

   [PSSPROOF] Coron, J., "Optimal Security Proofs for PSS and Other
              Signature Schemes", Lecture Notes in Computer
              Science, Volume 2332, pp. 272-287,
              DOI 10.1007/3-540-46035-7_18, 2002.

   [RFC1319]  Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319,
              DOI 10.17487/RFC1319, April 1992,
              <http://www.rfc-editor.org/info/rfc1319>.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              DOI 10.17487/RFC1321, April 1992,
              <http://www.rfc-editor.org/info/rfc1321>.

   [RFC2313]  Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
              RFC 2313, DOI 10.17487/RFC2313, March 1998,
              <http://www.rfc-editor.org/info/rfc2313>.

   [RFC2315]  Kaliski, B., "PKCS #7: Cryptographic Message Syntax
              Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
              <http://www.rfc-editor.org/info/rfc2315>.

   [RFC2437]  Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
              Specifications Version 2.0", RFC 2437,
              DOI 10.17487/RFC2437, October 1998,
              <http://www.rfc-editor.org/info/rfc2437>.

   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
              2003, <http://www.rfc-editor.org/info/rfc3447>.

Top      Up      ToC       Page 52 
   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <http://www.rfc-editor.org/info/rfc5652>.

   [RFC5958]  Turner, S., "Asymmetric Key Packages", RFC 5958,
              DOI 10.17487/RFC5958, August 2010,
              <http://www.rfc-editor.org/info/rfc5958>.

   [RFC6149]  Turner, S. and L. Chen, "MD2 to Historic Status",
              RFC 6149, DOI 10.17487/RFC6149, March 2011,
              <http://www.rfc-editor.org/info/rfc6149>.

   [RFC7292]  Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
              and M. Scott, "PKCS #12: Personal Information Exchange
              Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,
              <http://www.rfc-editor.org/info/rfc7292>.

   [RSARABIN] Bellare, M. and P. Rogaway, "The Exact Security of Digital
              Signatures - How to Sign with RSA and Rabin", Lecture
              Notes in Computer Science, Volume 1070, pp. 399-416,
              DOI 10.1007/3-540-68339-9_34, 1996.

   [RSATLS]   Jonsson, J. and B. Kaliski, "On the Security of RSA
              Encryption in TLS", Lecture Notes in Computer
              Science, Volume 2442, pp. 127-142,
              DOI 10.1007/3-540-45708-9_9, 2002.

   [SHA1CRYPT]
              Wang, X., Yao, A., and F. Yao, "Cryptanalysis on SHA-1",
              Lecture Notes in Computer Science, Volume 2442, pp.
              127-142, February 2005,
              <http://csrc.nist.gov/groups/ST/hash/documents/
              Wang_SHA1-New-Result.pdf>.

   [SHOUP]    Shoup, V., "OAEP Reconsidered (Extended Abstract)",
              Lecture Notes in Computer Science, Volume 2139, pp.
              239-259, DOI 10.1007/3-540-44647-8_15, 2001.

   [SHS]      National Institute of Standards and Technology, "Secure
              Hash Standard (SHS)", FIPS PUB 180-4, August 2015,
              <http://dx.doi.org/10.6028/NIST.FIPS.180-4>.

Top      Up      ToC       Page 53 
   [SILVERMAN]
              Silverman, R., "A Cost-Based Security Analysis of
              Symmetric and Asymmetric Key Lengths", RSA
              Laboratories, Bulletin No. 13, 2000.

   [SIMMONS]  Simmons, G., "Subliminal Communication is Easy Using the
              DSA", Lecture Notes in Computer Science, Volume 765, pp.
              218-232, DOI 10.1007/3-540-48285-7_18, 1994.


Next Section