Bouncy Castle PGP Decryption Issue
Asked Answered
Z

2

20

I've had a application using Bouncy Castle for PGP decryption which has run without any issues for the past 8 months or so, and the past 2 days all of a sudden an issue has come up where the GetDataStream method is throwing an exception:

Exception Message: "error setting asymmetric cipher".

Inner Exception Message : "Not an RSA key".

private static PgpObjectFactory getClearDataStream(PgpPrivateKey privateKey, PgpPublicKeyEncryptedData publicKeyED)
{
    // Exception throws here.
    Stream clearStream = publicKeyED.GetDataStream(privateKey);

    PgpObjectFactory clearFactory = new PgpObjectFactory(clearStream);
    return clearFactory;
}

The key hasn't expired, it has no expiration date:

enter image description here

I haven't made any changes to the application, I haven't touched the keys, so I can't quite understand why an issue has come up out of the blue. Any ideas? I can also manually decrypt the files using Kleopatra using the same keys that I load in the application.

Update 1 - I downloaded the free trial for OpenPGP Library for .NET, which looks to use BouncyCastle also, and I have no issues decrypting the files using the same key. For some reason, my implementation of decryption using BouncyCastle that has worked for several months stopped working for some reason that I have not been able to identify yet.

Update 2 - I pulled files from last week that worked, and I've also downloaded the source code of BouncyCastle in order that I can step through and debug to see where the exception is throwing and how the variables differ between a file that works and a file that doesn't work. The exception is being thrown at the beginning of the GetDataStream method of the PgpPublicKeyEncryptedData class:

byte[] plain = fetchSymmetricKeyData(privKey);

When I step into this method, for files that I can decrypt without any problem, I've noticed that the keyData.Algorithm variable is set to "ElGamalEncrypt", whereas for files that the exception throws, the file keyData.Algortithm is set to "RsaGeneral". Why would these differ? Did the company sending me the files change their encryption method? And is this encryption method not properly supported by BouncyCastle?

private byte[] fetchSymmetricKeyData(PgpPrivateKey privKey)
{
    IBufferedCipher c1 = GetKeyCipher(keyData.Algorithm);

    try
    {
        c1.Init(false, privKey.Key);
    }
    catch (InvalidKeyException e)
    {
        throw new PgpException("error setting asymmetric cipher", e);
    }

Also, not sure if this is related, the certificate type of our key is DSA.

enter image description here

Update 3 - I've been unable to figure out how to resolve the issue as of yet given the current keys. I generated new keys (type DSA) yesterday, and with the new keys the issue has been resolved.

Update 4 - This issue has just come up again, with the new key that worked in my last update. Once again, the keyData.Algorithm within the PgpPublicKeyEncryptedData class is being see to "RsaGeneral" instead of "ElGamalEncrypt" now. Why would the Algorithm property change? Is the person encrypting the file changing something?

Zelazny answered 19/6, 2012 at 18:17 Comment(5)
Maybe the certificate holding the RSA keys expired? Can you check this?Mercie
I've checked that previously, and just added a screenshot, our key doesn't have an expiration date. Additionally, I can manually decrypt the files using a utility such as Kleopatra using the same keys. So the keys are good.Zelazny
If you have fixed your problem you should put the solution in an answer and accept itHewart
I had really hoped this might be about an API for moon bounces.Mareah
Most of the time when you run into issues that happen once in a while it is not the encryption/decryption process itself. It normally has to do with incorrect input/output. In the case of encryption, the most common issue is that bytes are seen as characters and transmitted as such. The problem is that not all bytes encode to characters, resulting in data loss. The fun thing about cryptography is that the result should look like random characters, hence it is common that these kind of issues pop up now and then. Test with large, randomly generated data sets to avoid such issues.Receiptor
J
1

This could be important (Source: http://www.opensourcejavaphp.net/csharp/itextsharp/PgpPublicKeyEncryptedData.cs.html) :

It explains the value of your keyData.Algorithm being different, but the why I am still unsure of. It is most likely the input file that is the case. It could be different (client using a different key?)

private static IBufferedCipher GetKeyCipher(
            PublicKeyAlgorithmTag algorithm)
        {
            try
            {
                switch (algorithm)
                {
                    case PublicKeyAlgorithmTag.RsaEncrypt:
                    case PublicKeyAlgorithmTag.RsaGeneral:
                        return CipherUtilities.GetCipher("RSA//PKCS1Padding");
                    case PublicKeyAlgorithmTag.ElGamalEncrypt:
                    case PublicKeyAlgorithmTag.ElGamalGeneral:
                        return CipherUtilities.GetCipher("ElGamal/ECB/PKCS1Padding");
                    default:
                        throw new PgpException("unknown asymmetric algorithm: " + algorithm);
                }
            }
            catch (PgpException e)
            {
                throw e;
            }
            catch (Exception e)
            {
                throw new PgpException("Exception creating cipher", e);
            }
        }
Jentoft answered 21/6, 2012 at 9:47 Comment(0)
R
0

Looks like another party is encrypting to other/different keys. Probably your keyring contains RSA key as well, but BouncyCastle uses only the first (???). Using gpg, you can check the contents of your encrypted file by issuing gpg --list-packets YourEncryptedFile.pgp

After that apply the same command to 'good' file, and to your keyrings, and compare key identifiers to which file is encrypted. Since you are using DSA keys, file should be encrypted to ElGamal subkey.

Revanchism answered 19/6, 2012 at 18:17 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.