I am sniffing a client side application traffic and I found some encrypted data. I am not able to decrypt it. Information which I have is

Public Key:


Private Key:


Encrypted string:


I am able to retrieve all the keys, But I am not able to view encrypted content. Help me to decrypt with procedures.

  • The strings are all encoded in base64. Now, how does one interpret them it's another business. Can you name the application or not? Can you RE it?
    – miniBill
    May 22, 2013 at 21:05
  • RSA public key, private key, and data will be in base64 right?(Correct me if am wrong.) May 22, 2013 at 21:10
  • That's right, those strings are all [most probably] base64. You can tell from the charset and the trailing =s
    – miniBill
    May 22, 2013 at 21:11
  • How to do it so? May 22, 2013 at 21:13
  • You would have to understand how the private and public keys are represented. Is the application a windows or linux binary? What does it link to? Can you reverse engineer it?
    – miniBill
    May 22, 2013 at 21:15

2 Answers 2


Start with saving the three parts respectively to pub.b64, priv.b64 and blob.b64:

$ base64 -d < pub.b64 | openssl asn1parse -inform DER -i

    0:d=0  hl=3 l= 158 cons: SEQUENCE
    3:d=1  hl=2 l=  13 cons:  SEQUENCE
    5:d=2  hl=2 l=   9 prim:   OBJECT            :rsaEncryption
   16:d=2  hl=2 l=   0 prim:   NULL
   18:d=1  hl=3 l= 140 prim:  BIT STRING

Clearly not an X.509v3 certificate. No matter, we don't need that to decrypt. openssl dumpasn1 isn't up to the heavy lifting here, try Peter Gutmann's dumpasn1 to peek inside the bit string:

$ base64 -d < pub.b64 > pub.der
$ dumpasn1 -al pub.der

   0  158: SEQUENCE {
   3   13:   SEQUENCE {
   5    9:     OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
         :       (PKCS #1)
  16    0:     NULL
         :     }
  18  140:   BIT STRING, encapsulates {
  22  136:     SEQUENCE {
  25  128:       INTEGER
         :         77 C8 9B 9A 58 AC 43 14 B8 95 1E BE 61 03 E9 B5
         :         05 C7 CA 7D 1B FE 6F 17 E8 9A F9 09 EB 9F C3 9E
         :         32 92 09 FC A4 B6 9E A0 CB C5 7C 7F 7B 33 4A 94
         :         50 2B 58 AD 56 7A BE 1D 8B 04 09 D9 C7 62 0A A3
         :         68 AE E6 C0 82 73 97 31 5F BF 16 C8 80 4D 08 CC
         :         4F 61 36 94 8F 71 51 6A AA 36 AF 8F 7E 0C 82 3C
         :         82 D1 96 23 47 4F F8 F6 A8 EB C0 38 79 9F DD AD
         :         5D 3F C9 5C A6 FC 37 C7 71 41 04 AA 6A B7 3A 89
 156    3:       INTEGER 65537
         :       }
         :     }
         :   }

That's more like it, we have what appears to be a 1024-bit modulus, and a likely public exponent of 65537.

The key is a base64 encoded normal RSA key in DER (binary) format:

$ base64 -d priv.b64 | openssl rsa -inform DER > out.key
writing RSA key
$ cat out.key

If you decode that key:

$ openssl asn1parse  < out.key
    0:d=0  hl=4 l= 600 cons: SEQUENCE          
    4:d=1  hl=2 l=   1 prim: INTEGER           :00
    7:d=1  hl=3 l= 128 prim: INTEGER           
  138:d=1  hl=2 l=   3 prim: INTEGER           :010001

and compare with the dumpasn1 decoding of the public key, you can see that they share a 1024 bit modulus and exponent, so it looks like the public and private key match. Good.

So, decode your encrypted data:

$ base64 -d blob.b64 > blob

and decrypt it:

$ openssl rsautl -decrypt -inkey out.key < blob > decrypted
$ hexdump decrypted
0000000 0355 1739 575b 5434 ccc5 bec7 e70a 0d44
0000010 a4a9 11d4 166c 3423 4e36 e657 2fea ef53

That's 32 bytes (256 bits), quite likely a key used in a symmetric cipher to encrypt more data, since you can only encrypt relatively small amounts of data with RSA

Good luck with the next part ;-)

  • 2
    Fantastic answer!
    – Adi
    May 23, 2013 at 11:02
  • Thanks spuratic. As far as i understood that key.b64 contains public key, crt.b64 contains private key and blob.b64 contains ciphertext. Correct me if i am wrong. May 23, 2013 at 11:36
  • crt.b64 is the public key, since it turns out it's not an actual cert, I'll rename it to be more obvious. In general the "public key" is wrapped up in a cert, hence the name I used. May 23, 2013 at 12:06
  • For a key whose algorithm-specific data is ASN.1 (RSA DSA DH but not EC) you can use openssl asn1parse [-inform d/p] -strparse N where N is the location of the BITSTRING wrapper, in this example 18. Also now you often don't need a separate base64-d; for asn1parse (only) -inform pem doesn't check the dash-BEGIN/END lines and accepts any base64, but below 1.1.0 the line length must not exceed 76 (which this example does); 1.1.0 as of 2016 allows about 1000. Sep 21, 2017 at 4:21
  • You are a master! Jan 31, 2019 at 15:19

After decoding the strings from base64 to binary, you should try the following, depending on the algorithm used.

This encodes from base64 to binary. You probably would have to do it with the keys, too (or just decode them manually)

$ openssl enc -in ciphertext -out binarytext -d -a

And to perform the decryption:

$ openssl rsautl -decrypt -in binarytext -out plaintext -inkey private.pem

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.