Skip to main content
Polish
Source Link
fgrieu
  • 145.5k
  • 12
  • 319
  • 611

Three reasons:

  • Technical: often the integrity and origin of a piece of data becomes immaterial after the data is acted upon; and for long-term use (e.g. document signing), if the security of the signature becomes questionable, there is often the option to stop considering the key valid, and make a new signature with a larger key size, restoring security. When for encryption (one of the common goal of key establishment), we can't make the ciphertext disappear from the adversary's archive. Therefore, at any given time, we arguably need less security margin (smaller RSA modulus) for signature than for key establishment targeting long-term confidentiality.
  • Scope: my reading of NIST's FIPS 186 standard is that it specifies modulus sizes mostly for interoperability purposes, with security level not in the maincore scope; when NIST SP 800-56B is a recommendation with security level in scope. At least, only the later includes comparison with symmetric cryptography key sizes.
  • Historical: FIPS 186-4 (July 2013) is a standard with a long history, with RSA included in FIPS 186-1 (December 1998) which as RSA is concerned essentially approved a subset of ANS X9.31, with minimal key size set to 1024-bit for both; that size then made a lot of sense. When NIST SP 800-56Br1 is more recent (September 2014), revising earlier NIST SP 800-56B (August 2009) which still allowed 1024-bit RSA.

Three reasons:

  • Technical: often the integrity and origin of a piece of data becomes immaterial after the data is acted upon; and for long-term use (e.g. document signing), if the security of the signature becomes questionable, there is often the option to stop considering the key valid, and make a new signature with a larger key size, restoring security. When for encryption (one of the common goal of key establishment), we can't make the ciphertext disappear from the adversary's archive. Therefore, at any given time, we arguably need less security margin (smaller RSA modulus) for signature than for key establishment targeting long-term confidentiality.
  • Scope: my reading of NIST's FIPS 186 standard is that it specifies modulus sizes mostly for interoperability purposes, with security level not the main scope; when NIST SP 800-56B is a recommendation with security level in scope. At least, only the later includes comparison with symmetric cryptography key sizes.
  • Historical: FIPS 186-4 (July 2013) is a standard with a long history, with RSA included in FIPS 186-1 (December 1998) which as RSA is concerned essentially approved a subset of ANS X9.31, with minimal key size set to 1024-bit for both; that size then made a lot of sense. When NIST SP 800-56Br1 is more recent (September 2014), revising earlier NIST SP 800-56B (August 2009) which still allowed 1024-bit RSA.

Three reasons:

  • Technical: often the integrity and origin of a piece of data becomes immaterial after the data is acted upon; and for long-term use (e.g. document signing), if the security of the signature becomes questionable, there is often the option to stop considering the key valid, and make a new signature with a larger key size, restoring security. When for encryption (one of the common goal of key establishment), we can't make the ciphertext disappear from the adversary's archive. Therefore, at any given time, we arguably need less security margin (smaller RSA modulus) for signature than for key establishment targeting long-term confidentiality.
  • Scope: my reading of NIST's FIPS 186 standard is that it specifies modulus sizes mostly for interoperability purposes, with security level not in the core scope; when NIST SP 800-56B is a recommendation with security level in scope. At least, only the later includes comparison with symmetric cryptography key sizes.
  • Historical: FIPS 186-4 (July 2013) is a standard with a long history, with RSA included in FIPS 186-1 (December 1998) which as RSA is concerned essentially approved a subset of ANS X9.31, with minimal key size set to 1024-bit for both; that size then made a lot of sense. When NIST SP 800-56Br1 is more recent (September 2014), revising earlier NIST SP 800-56B (August 2009) which still allowed 1024-bit RSA.
Polish
Source Link
fgrieu
  • 145.5k
  • 12
  • 319
  • 611

Three reasons:

  • Technical: often the integrity and origin of a piece of data becomes immaterial after the data is acted upon; and for long-term use (e.g. document signing), if the security of the signature of a document becomes questionable, there is often the option to stop considering the key valid, and make a new signature with a larger key size, restoring security; whensecurity. When for encryption (one of the common goal of key establishment), we can't make the ciphertext disappear from the adversary's archive. Therefore, at any given time, we arguably need less security margin (smaller RSA modulus) for signature than for key establishment targeting long-term confidentialyconfidentiality.
  • Scope: my reading of NIST's FIPS 186 standard is that it specifies modulus sizes mostly for interoperability purposes, with security level not the main scope; when NIST SP 800-56B is a recommendation with security level in scope. At least, only the later includes comparison with symmetric cryptography key sizes.
  • Historical: FIPS 186-4 (July 2013) is a standard with a long history, with RSA included in FIPS 186-1 (December 1998) which as RSA is concerned essentially approved a subset of ANS X9.31, with minimal key size set to 1024-bit for both, whichboth; that size then made a lot of sense. When NIST SP 800-56Br1 is more recent (September 2014), revising earlier NIST SP 800-56B (August 2009) which still allowed 1024-bit RSA.

Three reasons:

  • Technical: if the security of the signature of a document becomes questionable, there is often the option to stop considering the key valid, and make a new signature with a larger key size, restoring security; when for encryption (one of the common goal of key establishment), we can't make the ciphertext disappear from the adversary's archive. Therefore, at any given time, we arguably need less security margin for signature than for key establishment targeting long-term confidentialy.
  • Scope: my reading of NIST's FIPS 186 standard is that it specifies modulus sizes mostly for interoperability purposes, with security level not the main scope; when NIST SP 800-56B is a recommendation with security level in scope. At least, only the later includes comparison with symmetric cryptography key sizes.
  • Historical: FIPS 186-4 (July 2013) is a standard with a long history, with RSA included in FIPS 186-1 (December 1998) which essentially approved ANS X9.31, with minimal key size set to 1024-bit for both, which then made a lot of sense. When NIST SP 800-56Br1 is more recent (September 2014), revising earlier NIST SP 800-56B (August 2009) which still allowed 1024-bit RSA.

Three reasons:

  • Technical: often the integrity and origin of a piece of data becomes immaterial after the data is acted upon; and for long-term use (e.g. document signing), if the security of the signature becomes questionable, there is often the option to stop considering the key valid, and make a new signature with a larger key size, restoring security. When for encryption (one of the common goal of key establishment), we can't make the ciphertext disappear from the adversary's archive. Therefore, at any given time, we arguably need less security margin (smaller RSA modulus) for signature than for key establishment targeting long-term confidentiality.
  • Scope: my reading of NIST's FIPS 186 standard is that it specifies modulus sizes mostly for interoperability purposes, with security level not the main scope; when NIST SP 800-56B is a recommendation with security level in scope. At least, only the later includes comparison with symmetric cryptography key sizes.
  • Historical: FIPS 186-4 (July 2013) is a standard with a long history, with RSA included in FIPS 186-1 (December 1998) which as RSA is concerned essentially approved a subset of ANS X9.31, with minimal key size set to 1024-bit for both; that size then made a lot of sense. When NIST SP 800-56Br1 is more recent (September 2014), revising earlier NIST SP 800-56B (August 2009) which still allowed 1024-bit RSA.
Polish
Source Link
fgrieu
  • 145.5k
  • 12
  • 319
  • 611

Three reasons:

  • Scope: my reading of NIST's FIPS 186 standard is that it specifies key sizes for interoperability, with security level out of scope; when NIST SP 800-56B is a recommendation with security level in scope, to some degree.
  • Technical: if the security of the signature of a document becomes questionable, there is often the option to stop considering the key valid, and make a new signature with a larger key size, restoring security; when for encryption (one of the common goal of key establishment), we can't make the ciphertext disappear from the adversary's archive. Therefore, at any given time, we arguably need less security margin for signature than for key establishment targeting long-term confidentialy.
  • Scope: my reading of NIST's FIPS 186 standard is that it specifies modulus sizes mostly for interoperability purposes, with security level not the main scope; when NIST SP 800-56B is a recommendation with security level in scope. At least, only the later includes comparison with symmetric cryptography key sizes.
  • Historical: FIPS 186-4 (July 2013) is a standard with a long history, with RSA included in FIPS 186-1 (December 1998) which essentially approved ANS X9.31, with minimal key size set to 1024-bit for both, which then made a lot of sense. When NIST SP 800-56Br1 is more recent (September 2014), revising earlier NIST SP 800-56B (August 2009) which still allowed 1024-bit RSA.

Three reasons:

  • Scope: my reading of NIST's FIPS 186 standard is that it specifies key sizes for interoperability, with security level out of scope; when NIST SP 800-56B is a recommendation with security level in scope, to some degree.
  • Technical: if the security of the signature of a document becomes questionable, there is often the option to stop considering the key valid, and make a new signature with a larger key size, restoring security; when for encryption (one of the common goal of key establishment), we can't make the ciphertext disappear from the adversary's archive.
  • Historical: FIPS 186-4 (July 2013) is a standard with a long history, with RSA included in FIPS 186-1 (December 1998) which essentially approved ANS X9.31, with minimal key size set to 1024-bit for both, which then made a lot of sense. When NIST SP 800-56Br1 is more recent (September 2014), revising earlier NIST SP 800-56B (August 2009) which still allowed 1024-bit RSA.

Three reasons:

  • Technical: if the security of the signature of a document becomes questionable, there is often the option to stop considering the key valid, and make a new signature with a larger key size, restoring security; when for encryption (one of the common goal of key establishment), we can't make the ciphertext disappear from the adversary's archive. Therefore, at any given time, we arguably need less security margin for signature than for key establishment targeting long-term confidentialy.
  • Scope: my reading of NIST's FIPS 186 standard is that it specifies modulus sizes mostly for interoperability purposes, with security level not the main scope; when NIST SP 800-56B is a recommendation with security level in scope. At least, only the later includes comparison with symmetric cryptography key sizes.
  • Historical: FIPS 186-4 (July 2013) is a standard with a long history, with RSA included in FIPS 186-1 (December 1998) which essentially approved ANS X9.31, with minimal key size set to 1024-bit for both, which then made a lot of sense. When NIST SP 800-56Br1 is more recent (September 2014), revising earlier NIST SP 800-56B (August 2009) which still allowed 1024-bit RSA.
Polish
Source Link
fgrieu
  • 145.5k
  • 12
  • 319
  • 611
Loading
Source Link
fgrieu
  • 145.5k
  • 12
  • 319
  • 611
Loading