Hot answers tagged

10

Summary: they aren't different signature schemes. Both specify the use of RSA-PSS. The difference is in how to parse the certificate to find the public key. RSA-PSS (also spelled RSASSA-PSS and other variants) is a family of short-message signature schemes defined in PKCS#1 (RFC 8017). A short-message signature scheme can only sign a message with a small ...


10

PSS is harder to implement because it uses randomness -- randomness is hard on many embedded systems like smart cards. The most proclaimed advantage of PSS is that it has a "security proof" with, apparently, a rather tight reduction (see this page for some references). Security proofs are not an easy subject; the proof for OAEP (the encryption padding which ...


9

If you reuse the same key material for different algorithms, you rely not on the security of any one algorithm individually, but on the security of the composition of the two algorithms simultaneously. For a particularly egregious example, if you use the same RSA public key for RSASSA-PKCS1-v1_5 and for HMAC-SHA256, the results might be entertaining. It ...


9

Which of these should I be using? PKCS1 v1.5 seems a bit simpler to implement. Generally you should not be implementing this yourself, there are plenty of libraries that implement these schemes out of the box. Both the PKCS#1 v1.5 padding for signature generation and PSS padding have pro's and con's which I list below. Which one you decide to use it up to ...


7

Any probabilistic signature scheme can be made deterministic without any loss of security. The generic transformation is as follows: Let $(pk,sk)$ be the key-pair of the original signature scheme Choose a random key $k$ for a pseudorandom function $F$ (you can use HMAC or CMAC), where the output of $F$ is enough randomness used to sign. This key is part of ...


6

A fixed hash function can be computed by anyone. A signature depends also on a public key, and can be computed only by someone who knows a secret related to the public key. Anyone can verify a signature on a message under the public key, but only knowledge of the secret enables creating signatures. Signatures practically always involve the use of a hash ...


6

I2OSP and OS2IP mean Integer to Octet Stream Primitive and Octet Stream to Integer Primitive. There is an often used play on words here: "two" (2) has almost the same pronunciation as "to". The word "octet" simply means 8-bit "byte" and that "stream" can be replaced with "array". So these are conversion functions between integers to byte arrays. The I2OSP ...


6

OpenSSL is not being dumb and there is a reason the keys have different OIDs, but it's unrelated to the key data — it's the key metadata. The metadata describes the key. Specifically, the ASN.1 type above is PrivateKeyInfo and the difference is in the AlgorithmIdentifier. From an organizational perspective where you have to keep track of two RSA ...


5

This is a) no attack on the security model, but an attack in the security model of EUF-CMA, and b) a generic attack on any signature scheme that signs the hash of a message instead of the message itself (as done in RSA-FDH). The idea is that if you can find a collision for the used hash function $H$, i.e., two messages $m_1, m_2$ such that $H(m_1) = H(...


5

For the private key it may or may not matter to code using the key, but for the public key especially in a CSR or cert the algorithm identifier is visible and can matter. OpenSSL generates a CSR containg a public key which is automatically extracted from the private key, including the AlgId, which is normally copied to a cert where the AlgId in the public ...


5

The answer is either "no" or "it depends". Generally speaking, RSA-PSS is more robust, in the sense that you don't have to take as many extra precautions in order to use it securely. RSA-PKCS#1-v1.5 is OTOH more widely supported by pre-exisiting software, but you sometimes have to patch the way it is used in order to prevent exploits. For instance, if you ...


4

To prove that, for a generic hash function, forging PSS signatures is not much easier than computing arbitrary $e^\mathit{th}$ roots modulo a large composite of unknown factorization, we need to grant the attacker, who is trying to compute $e^\mathit{th}$ roots, oracle access to a forger for a signature scheme that uses the entire set of residue classes $\...


4

Some authors draw a distinction between: RSA-PSS, analyzed by Bellare and Rogaway in 1996[1] and proposed for IEEE P1363 in 1998[2], which is roughly defined in terms of $H(r \mathbin\| m)$, and RSASSA-PSS, standardized in IEEE P1363-2000 and RSA PKCS #1 v2.1, which is roughly defined in terms of $H(r \mathbin\| H(m))$. This distinction is significant: RSA-...


4

There is only one standard cryptographic mechanism that uses both the RSA trapdoor function family and the PSS padding scheme, and that's RSASSA-PSS defined by PKCS#1 v2.1 and above (RFC 8017 being the current version of this standard). So “RSASSA-PSS” is the formal name of a cryptographic mechanism, and “RSA-PSS” is an unambiguous abbreviation of “RSASSA-...


4

Even if we make RSASSA-PSS deterministic by fixing its seed, it remains with a security proof in the Random Oracle Model per Full Domain Hashing (Jean-Sébastien Coron, On the Exact Security of Full Domain Hashing, in proceedings of Crypto 2000). We can't say the same for RSASSA-PKCS1-v1_5, because a lot of the message representative is fixed. In practice, a ...


3

There are two different identifiers in a certificate, the algorithm of the public key for the certificate and the algorithm of the signature from the issuer. The two don't have to even be the same algorithm family (e.g. RSA CA certs can sign ECDSA certs, and vice versa). In the following certificate parse structure the algorithm identifiers starting at ...


3

Yes, this is expected, if the RSASSA-PSS signing code/test uses salt the width of the hash, which is customary. In that case, a $h$-bit hash (with $h$ multiple of 8) requires an RSA public modulus at least $2h+9$ bits. That's semi-clearly stated in PKCS#1 v2.2, section 9.1.1, condition on enBits, with actual test in step 3. That's because the message ...


3

Provided you follow PKCS#1 v1.5 verification exactly, and don't attempt shortcuts like checking only the hash part of the message hash representative, it should be fine. There's no security reduction to the RSA problem proven, like there is for RSA-FDH or RSASSA-PSS, and certainly no reduction to factorization, like there is for Rabin–Williams, but no ...


3

Why PSS does not use a last call to a hash function (for instance SHA-256) so as to reduce the size of the resulting element before performing the exponentiation? There's a radical reason why: it would no longer be possible to verify the signature, because hashing is irreversible, and prevents PSS verification to work. The present section of this answer ...


3

Use the value of public exponent $e$ that came with the public key, here $e=3$ according to the question. Otherwise, signatures won't check. Common RSA public exponents include $65537$ and $3$, and more generally the Fermat primes $2^{(2^k)}+1$ with $0\le k\le4$; and $37$ (used by Putty). $e=3$ leads to the fastest RSA public key operation, because we can ...


2

I'm not going to add any analysis, but just some RFC quotes and timelines about RSA signing ('signature scheme with appendix'), PKCS #1 v1.5 and PSS ('probabilistic signature scheme') February 2003 Users encouraged to move away from RSASSA PKCS #1 v1.5 in RFC 3447 PKCS #1: RSA v2.1, §8: Signature schemes with appendix, p. 36 Two signature schemes ...


2

As mentioned already, very good question. What follows is my attempt at tracking down the answer. I first googled for rsa_pss_rsae_sha256 wireshark and the first result was https://fossies.org/linux/wireshark/epan/dissectors/packet-ssl-utils.c. On line 1285, this links to https://tools.ietf.org/html/draft-ietf-tls-tls13-23#section-4.2.3 which in turn ...


2

The paper : PSS: Provably Secure Encoding Method for Digital Signatures by Bellare and Rogaway in August 1998 Shortly, RSA-PSS was designed to be provably reducible to the hardness of the RSA problem, a property which the previous PKCS#1.5 scheme did not possess.


2

What you are thinking would work (mostly). Every public key algorithm includes a public/private key generation algorithm; this algorithm takes a source of random bits, and produces a public/private key pair. This algorithm is deterministic, and so using those same random bits a second time will produce the same public/private key pair. So, if you take ...


2

To give an example with less maths, suppose that I come to you and ask you to sign the message "Josiah's favourite number is 747895723190543. Weird I know." You think that is a bit odd, but harmless so you do so. Unbeknown to you, the hash of that message is also the hash of "Please pay Josiah the sum of 87476 United States dollars." Because the hash ...


2

We don't know any forgery algorithm which can do a better job if there are more signed messages available, or smaller signed messages available. The best way we know to forge messages is to factor $n$. The best algorithm we know to factor $n = pq$ when $2^{1023} < p < q < 2^{1024}$ are (near) uniform random primes, the general number field sieve, ...


2

Let's first get rid over two parameters that only have one option: the Mask Generation Function (MGF) and the trailer field. These can only be configured to MGF1 and 1 respectively in RFC 3447 which specifies RSA-PSS. You won't find a generic standard that chooses one hash over the other for MGF1 because any hash will be considered secure, including the ...


1

Q: I am using CAPI Engine in OpenSSL and I did some test. When I use TLS 1.0 or 1.1, during handshake and RSA signing, PKCS padding is chosen. When I use TLS 1.2, RSA signing uses PSS padding. Funny, a quick lookup of TLS 1.2 contains the following: Note that there are certificates that use algorithms and/or algorithm combinations that cannot be ...


1

It depends on what publickey is. An X.509/PKIX cert contains a SubjectPublicKeyInfo structure which contains an AlgorithmIdentifier that specifies what type the key is and in some cases to some extent how it is used, plus the actual publickey value (wrapped in an OCTET STRING type). See also the links to 3279 and 4055 (which is updated by 5756). These TLS1....


1

In Result = F (4 - Format of the EM is incorrect - hash moved to left ), the first F says that a correct signature verification implementation must Fail to verify the test vector (for known-good vectors, there is Result = P for Pass). What's in parenthesis following F documents the intention in making the test vector, but that's purely informative. My guess ...


Only top voted, non community-wiki answers of a minimum length are eligible