0

Binance public API supports access to specific operations with RSA key pair. Firstly customer generates an RSA key pair. The customer uses the secret key to hash(SHA256) the query string parameters and puts the hash value in the query string. The public key is sent in the same HTTP call in the headers.

Binance compares the same hash in the server to check query string parameters are not changed by a man in the middle. There is no use for RSA encryption in this communication. Just two different numbers, one as sent as API key, the other used to calculate the hash.

We are about to develop a similar security mechanism. I insist to use generating an RSA key pair but one of my teammates suggests using two different random numbers(one for public and the other for private key).

Is there any security vulnerability for using 2 different random numbers?

Ahmet Arslan
  • 849
  • 1
  • 5
  • 9
  • 1
    For asymmetric cryptography, there must be a 'trapdoor' function, which makes it easy to generate the public key from the private key, but hard to generate the private key from the public key. For example, with RSA crypto, it is easy to generate the public key from the private key, by simply multiplying the two prime numbers that make up the private key. But, doing the opposite is hard, because it requires factoring a very large number. If you simple make the private key one large random number, and the public key a different large random number - there would be no trapdoor function. – mti2935 Jul 22 '22 at 17:43
  • 6
    Please don't roll your own cryptosystem. Use an existing, well-designed library which supports the operations you need. – forest Jul 23 '22 at 00:18
  • While it's *possible* you may create your own wonderful custom system, it's generally a bad idea. In the best case, it will be subject to challenge and debate. In the worst case it will lead to compromise. There is no up side to a custom system. CYA alone justifies using a standard vetted protocol. – user10216038 Jul 24 '22 at 16:42
  • @forest Actually we do not sign or encrypt anything with keys. We will just hash to prove that data is legitimate. Still this scheme is unsafe? – Ahmet Arslan Jul 25 '22 at 12:57
  • Unless you intend this to be a personal *Life Work*, consider a new maintainer in the future. He's going to look at this custom *Bob's Security Algorithm* and think **WTF**. Even if it's well implemented *(which remains a question)*, it's easier and justifiable to simply rip it out in favor of a vetted security algorithm. Don't create future problems just to display your programming chops, no one will be impressed. – user10216038 Jul 25 '22 at 19:11

1 Answers1

1

The "security vulnerability" is that the "public key" cannot be used to verify anything done with the "private key" and vice versa. RSA works, because the public key and private key are mathematically related.

If you simply take two random numbers, then you cannot "sign" the request with it. I mean, sure, you can perform mathematical operations akin to RSA on a random number...it just won't yield anything useful.

And on the other end, you now have the hash of some garbage data, and there is absolutely nothing you can do with that garbage data, or with the "public key" you have been sent. You cannot tell whether that garbage hash contains the query string, or if it's been modified by someone else, etc...

In fact, I would be very curious how your co-worker, who believes using random numbers is enough, envisioned this cryptosystem. Especially in regards to how integrity and authenticity are maintained.

Moral of the story is

Don't roll your own crypto!

schroeder
  • 123,438
  • 55
  • 284
  • 319
Don't roll your own
  • 84
  • 2
  • 2
    Rolling your own is just fine as a means of learning. Don't roll your own and expect it to be secure if you try to secure with it. – schroeder Jul 25 '22 at 12:32
  • True. I was presuming a real-life scenario. Doing something insecure for educational purposes is completely valid (e.g. DVWA, etc.) – Don't roll your own Jul 25 '22 at 12:46