Risks of Using SHA1 Instead of SHA256 for RSA with OAEP Padding

Question

I'm presently implementing a simple RSA-based encryption as follows in PHP (using openssl_public_encrypt):

// $sRawText is the text string to encrypt.
// $sPublicKey is the public key stored on the server.
openssl_public_encrypt($sRawText, $sResult, $sPublicKey, OPENSSL_PKCS1_OAEP_PADDING);
// $sResult is the encrypted result which is then stored.

I made sure to use the OAEP padding option, however the padding is done with SHA1 instead of SHA256. PHP does not have a built-in padding option that supports SHA256. By example, Python's cryptography library uses SHA256 instead like this:

from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import padding
ciphertext = public_key.encrypt(
    message,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None
    )
)

The only options for me to get SHA256 on PHP are to use a third party library like PHPSecLib or EasyRSA. I've run into roadblocks after a few hours trying to install and use either of them on my shared hosting environment. (It would be ideal if I could put one .php file that had the RSA all in one place.)

The data is encrypted into a database on an online server, and that has to happen in PHP so I can insert new entries when users sign up (using the public key). I'd like to make sure that if the encrypted database data and public key got into nefarious hands with access to a reasonable level of computing power, the data would stay private (as secure as a brute force attack). Data in the wrong hands can be abused to phish users or create fraudulent false claims.

Client-side storage does not work as the data is already in the database presently and I need certain fields such as contact information, in order to contact the user. Plus, I feel that most clients will lose the data, which is irrecoverable and needs to potentially still be available in several years. However, I don't wish to fully trust the server environment, so I'd like to minimize the attack surface to only the specific moments when the data is being used. It is far easier for me to keep that private key and pass phrase offline and safe, than to try to secure a dynamic database which is constantly changing and needs to be stored redundantly.

I plan to do all manipulation of the encrypted data offline and only ever use encrypted database fields for verification (ie data matches something the user input) or to count entries. Some fields in the database aren't sensitive, so they aren't encrypted, and others like passwords are hashed.

What I want to know is, if I proceed with the SHA1 padding implementation, what kind of attacks would this open me up to against an adversary with the encrypted database data and public key. How would they go about these attacks? Does SHA256 padding help to better protect the data, and how?

Thanks so much!

Answer 1

You can use SHA-1 or MD5 for OAEP. It won't expose you to any attack.

OAEP uses the hash functions for two things: to hash the label, and as part of the mask generation function, which, in practice, is always MGF1 of some hash function.

For the label, the hash function is just used to turn the label into a ciphertext domain separator: when decrypting, a ciphertext with the wrong label hash is detected as invalid. As long as you don't build the label from parts that can be supplied by an adversary, you don't risk collisions. And if you do build the label in a complex way and you rely on it for security, you should probably have a signature anyway.

For MGF1, the hash function is used as a random oracle. Its properties as a hash are not relevant. The former popular hash functions that have become deprecated are deprecated because there are concrete attacks against their properties as hash functions (specifically, collision resistance). However, as random oracles, they're still considered as good as ever. (They have one known flaw, which is length extension, and also applies to SHA2 which has no known flaw as a hash function. But length extension doesn't apply to MGF1 in OAEP anyway, since it's used on a fixed-size input for a given RSA key.)

Using SHA-1 in a cryptographic construction may make auditors frown, and it can make your system non-compliant to certain security standards. In terms of security, it's a bit of a distraction, but not a vulnerability.