Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
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 '13 at 21:05
RSA public key, private key, and data will be in base64 right?(Correct me if am wrong.) – javad_shareef May 22 '13 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 '13 at 21:11
How to do it so? – javad_shareef May 22 '13 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 '13 at 21:15
up vote 14 down vote accepted

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 they key and cert 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 ;-)

share|improve this answer
Fantastic answer! – Adi May 23 '13 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. – javad_shareef May 23 '13 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. – mr.spuratic May 23 '13 at 12:06
It worked well mr.spuratic. Thanks.. :) – javad_shareef May 23 '13 at 12:59

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
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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