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

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
ciphertext = public_key.encrypt(
message,
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!

• Thanks. Still It is secure since MGF is not a standard way to find SHA-1 collisions. however, find a way to migrate Migrate to use SHA-256; find ways to use it. Dec 13 '21 at 20:35
• I get that SHA-256 is a recommended choice. However, I'd like to understand why and what the risk is with SHA-1. Is MGF a Moment Generating Function? Dec 13 '21 at 20:47