RSA-PSS â Provably secure RSA Signatures and their ...

More documents

Recommendations

Info

However, we already saw that the Bleichenbacher attack was only possiblewith a very small exponent like e = 3. So it seems small exponents are not aproblem per se, but a risky choice regarding implementation problems.Usually today‘s RSA implementations use an exponent of e = 65537 - atradeoff between very big exponents that make verification very slow and verysmall exponents that seem risky. e = 65537 avoids all known attacks againstsmall exponents. The NIST recommendations do not allow exponents smallerthan 65537 (page 6 in [NIST, 2010]).6.4 Separating Keys for different SchemesWe saw in chapter 2.4 that when using plain RSA, it causes severe problemswhen using the same key for signature generation and encryption. While withany kind of padded / hashed RSA this is not a direct issue, it is still consideredbad practice to use the same key for different purposes. This is not limitedto RSA, it is always a useful safety measurement to use key material only forone purpose due to unconsidered protocol / algorithm interactions. Schneier,Wagner and Kelsey have investigated this [Schneier et al., 1997] and have cometo the conclusion that it is advisable to fixate the purpose of key material directlywith the key generation.For our case, this would mean that in an ideal case, an RSA key (e.g., in anX.509 certificate) would be limited to either RSASSA-PSS or RSAES-OAEP.Neither should one key be used for both PSS and OAEP, nor should the samekey be used for old (PKCS #1 1.5) and new (PSS) padding.6.5 SummaryWhen implementing RSA with PSS, we also need to make a couple of otherdesign decisions. For best security properties, it is advisable to use a securehash function without collision problems (currently one of the SHA-2 familyones, in the future probably SHA-3), a decent key size (2048 bit or more) andan exponent not to small (65537 or above).It also looks like a good idea to limit the key usage exclusively to PSS andnot to use the same keys for different padding schemes.7 Protocols – Standards and ImplementationsIn this chapter, we will have a look at some common cryptographic high levelprotocols and their support of RSASSA-PSS.26
Default / no parametersWith parameter blockDiffering hashesPSS-keysEngineOpenSSL latest/1.0.0d a ✗ ✗ ✗ ✗OpenSSL CVS/1.1 ✓ ✓ ✓ ✗nss latest/3.12.9 b ✗ ✗ ✗ ✗nss CVS+patches ✓ ✓ ✓ ✗GnuTLS latest/2.12.2 ✗ ✗ ✗ ✗Windows Vista/7 SChannel.dll c ✓ ✓ ✗ ✗MacOS 10.6.7 d ✓ ✗ ✗ ✗IAIK java library ✓ ✓ ✓ ✓BouncyCastle java library ✓ ✓ ✓ ✗a used by Operab used by Firefox, Thunderbird, Chromium/Chrome on Linuxc used by Internet Explorer, Chromium/Chrome on Windows, Safari on Windowsd used by Safari on MacOSFigure 6: PSS support in X.509 implementations7.1 X.509X.509 is a standard to provide certificates which can be used to ship public keysfor further cryptographic operations. Sometimes X.509 certificates are calledSSL certificates, but this is not accurate – SSL / TLS is their most commonusage, but X.509 certificates are more generic and can be used in a large varietyof protocols.In RFC 4055 [IETF Network Working Group, 2005a], the use of the PKCS#1 v2.1 primitives within X.509 certificates and certificate revocation lists isspecified, RFC 5756 [IETF Network Working Group, 2010] contains some minorupdates. X.509 certificates are used in a wide variety of applications, theirmost common use is in combination with SSL / TLS.RFC 4055 allows two things: Generating signatures with RSASSA-PSS onother X.509 certificates and creating keys designated for RSASSA-PSS andRSAES-OAEP. Signatures can also be generated with “normal”/old RSA keyswithout a designated use case. However, designated RSASSA-PSS keys arebarely supported anywhere at all.Implementations of RFC 4055 have been lacking until recently. Most applicationsare based on four SSL / X.509-engines. The Microsoft Windows andApple MacOS X operating systems bring their own cryptographic engine thatis used by their own browsers (Internet Explorer, Safari) and partly by others27
Page 3 and 4: 7.6 No Support yet: OpenPGP, DNSSEC
Page 5 and 6: look at requirements by law and pos
Page 7 and 8: side: Every decryption operation pr
Page 9 and 10: MMGFMGF(M)Figure 2: Full Domain Has
Page 11 and 12: key size have equal security. Howev
Page 13 and 14: MHashPadding1mHashsaltPadding2saltH
Page 15 and 16: In the PKCS standard, the old and n
Page 17 and 18: --- crypto / rsa / rsa_sign .c 26 A
Page 19 and 20: impact of fault-based attacks on ra
Page 21 and 22: This only works because the first t
Page 23 and 24: MsaltRMXRMHashPadding1mHashsaltPadd
Page 25: PKCS #1 v2.1 specifies the use of P
Page 29 and 30: MacOS X supports only PSS signature
Page 31 and 32: DNSSEC is a security extension to t
Page 33 and 34: static SECStatusemsa_pss_verify ( c
Page 35 and 36: such a struct to pass it down throu
Page 37 and 38: 8.10 DifficultiesI found out that t
Page 39 and 40: During the implementation of RSASSA
Page 41 and 42: Certificate :Data :Version : 3 (0 x
Page 43 and 44: 11 Really provable SecurityThe conc
Page 45 and 46: PSPACE problemsNP ProblemsBQPFigure
Page 47 and 48: and physics where today very little
Page 49 and 50: are more likely to consider the use
Page 51 and 52: [Brier et al., 2006] Brier, E., Che
Page 53 and 54: [IETF Network Working Group, 2005a]
Page 55 and 56: [Technical Committee CEN/TC 224, 20
Page 57 and 58: OAEP Optimal asymmetric Encryption

RSA-PSS â Provably secure RSA Signatures and their ...

Create successful ePaper yourself

Delete template?

Save as template?

RSA-PSS â Provably secure RSA Signatures and their ...