.NET授权算法问题:对称与非对称加密结合序列化对象验证失败
Hey there, let's dig into why your VerifyData check keeps failing—this is a super common pitfall with combined symmetric-asymmetric encryption workflows, so we'll break down the most likely issues and actionable fixes:
Common Causes & Debug Steps
1. Mismatched Data Scope for Signing/Verification
This is the #1 culprit here. For verification to pass, the exact same byte stream must be used for both signing and verification. For example:
- If you sign only the raw serializable object before encryption, but try to verify the combined blob of RSA-encrypted key + IV + Rijndael ciphertext, verification will fail instantly.
- Double-check your workflow: You should concatenate the RSA-encrypted symmetric key, IV, and Rijndael ciphertext into a single byte array, sign that entire array, and verify against that same concatenated byte array during loading.
Pro tip: Print or log the Base64 representation of the data being signed and the data being verified—if they don't match, you've found your first problem.
2. Inconsistent Serialization/Encoding
When you serialize the final object to a file and load it back, even tiny differences in serialization can break verification:
- Are you using the exact same serializer (e.g.,
BinaryFormatter,System.Text.Json) with identical settings for both write and read operations? - Did you accidentally introduce extra bytes (like a BOM, or extra whitespace) during serialization or file I/O?
Debug step: After loading the serialized object, extract each component (RSA key blob, IV, ciphertext, signature) and compare their byte arrays to the original values you wrote to the file. If any component differs, your serialization pipeline is the issue.
3. Mismatched Hash/Padding for RSA Signature
RSA signatures rely on matching hash algorithms and padding schemes between signing and verification. For example:
- If you sign with
SignData(data, HashAlgorithmName.SHA256, RSASignaturePadding.Pss)but verify withVerifyData(data, signature, HashAlgorithmName.SHA1, RSASignaturePadding.Pkcs1), verification will fail every time.
Make sure both your signing and verification code use:
- The same hash algorithm (e.g., SHA256, SHA512)
- The same padding mode (PSS vs PKCS#1 v1.5—never mix these)
4. Key Mix-Up
You mentioned using Public-APP for encrypting the symmetric key, and Private-LS for signing. During verification, you must use the corresponding Public-LS public key to validate the signature. If you accidentally use Public-APP instead, verification will fail.
Double-check that your verification code is pulling the correct public key associated with the Private-LS key pair used for signing.
5. Corrupted IV Handling
The IV is critical for Rijndael encryption, and if it's altered during encryption, RSA wrapping, or serialization, it can break both decryption and verification (if the IV is part of the signed data):
- Ensure the IV you generate for encryption is exactly the same IV you wrap with the symmetric key via RSA, and that the decrypted IV during loading matches the original.
- Verify the IV's byte length matches your Rijndael configuration (e.g., 16 bytes for AES-256 in CBC mode)—a truncated or padded IV will cause mismatches.
Quick Debug Hack
To narrow down the issue fast:
- Before signing, save the exact byte array you're signing to a temporary file.
- During loading, extract the byte array you're passing to
VerifyDataand save it to another temporary file. - Compare the two files byte-for-byte.
- If they match: The problem is in your RSA signature/verification logic (keys, hash, padding).
- If they don't match: The problem is in your data serialization, concatenation, or file I/O.
内容的提问来源于stack exchange,提问作者RhapEskies

