0

Is it possible to leak private key data if attacker control signing request ?

Everyone know $N$ and $E$ because they are public.

My server is designed to decrypt incoming request which is encrypted with public key.

Make sign and for decrypted data which have SHA-2 return back RSA sign for that data.

Is it possible that an attacker can learn my private key?

I am testing this in my local workshop for education purposes.

I am using PKCS#1 public key encrypted message for incoming request; data is decrypted by my private key and its have SHA-2 so I just sign & return back signed data to client.

Example in Python:

Message & key pair generation:

message = struct.pack('>IIII', 0, 0, 0, 1)
(pub, priv) = rsa.newkeys(512) //only for example, I know no one uses 512 bit

Incoming request:

encrypted = pkcs1.encrypt(message, pub)

Server operations:

decrypted = pkcs1.decrypt(encrypted, priv)
signature = pkcs1.sign(decrypted, priv, 'SHA-256')

and return back answer.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
rockymaster
  • 1
  • 2
  • 2
    Are side-channel attack (timing, power analysis..) left aside? Can it be assumed the private key $(N,D)$ is only used to compute the function $X\mapsto X^D\bmod N$? If yes to both: there's no known way the (or a working) private key can leak. But perhaps you are also interested in the server being abused to decipher or sign, there might be attacks allowing that. Independently: please clarify. Use "signature" when it's meant a piece of data, and "sign" for the action of making a signature. What's hashed with SHA2? Exactly how is the result used? Do encryption and signing use padding? – fgrieu Sep 22 '21 at 16:41
  • i have updated my question and added sample too. – rockymaster Sep 23 '21 at 11:21
  • There remains a lot of room for improvement of form: "make sign and for decrypted data which have SHA2 return back rsa sign for that data" -> sign the decrypted data with padding using SHA2 and return the corresponding signature; code formatting, perhaps Mathjax. And it's missing the essential: are side-channel attack (timing, power analysis..) on the Python crypto libraries considered as valid attacks? These can "leak private key data". – fgrieu Sep 23 '21 at 11:34

1 Answers1

1

It appears from the example that encryption and signature use some padding modes in PKCS#1; likely RSAES-PKCS1-v1_5 for encryption and RSASSA-PKCS1-v1_5 with SHA-256 for signature.

Is it possible to leak private key data?

As far as we know, no, the fact that it's deciphered a message and signed it with the same key can not leak private key data. That's independently of the exact padding schemes used for encryption and signature: we just know no way that any use of an RSA private key $(n,d)$ limited to computing $x\mapsto x^d\bmod n$ in a black box free of side channels can leak private key data.

Among similar things that could happen:

  • The implementation could leak the private key by a side channel; such as a down-to-earth trojan program running on the platform, or Differential Power Analysis. There are many other side-channels to fear.
  • The implementation of RSAES-PKCS1-v1_5 decryption might be among the many that are vulnerable to some variant of Bleichenbacher attack. That could allow turning the server into an oracle that allows (with enough queries) computation of the function $x\mapsto x^d\bmod n$ for arbitrary $x$, giving a (very slow) equivalent to knowing the private key to an attacker that can communicate with the server.

It's not academically correct to use the same public/private key pair for encryption and signature, but with the four encryption and signature modes in PKCS#1 it does not enable any known attack. The weakest apparent links in the security chain are

  • The very functionality of the server: it allows to obtain the signature of anything that fits the size limitation for encryption (117 bytes).
  • The 512-bit modulus, which can be factored (that was already possible in the 20th century).
  • The use of RSAES-PKCS1-v1_5 decryption on unauthenticated ciphertext from the open.
fgrieu
  • 140,762
  • 12
  • 307
  • 587