In Asymmetric cryptography, is the number of Private Keys limited?

Question

My question is a bit of a leading question, because I assume that the number of Private Keys is a finite number.

However, it is possible that the number is such a large number that it would theoretically never be reached.

All of this leads me to the real question I am attempting to find the answer to:

Main Question

Why not generate a private key / public key pair for one use and then delete both of them after the use?

Why Would I Want To Do That?

Let's say I want to send something private to Alice but we've never spoken before.

1. Alice would open the app I've developed using her phone and press a button.
2. This would contact my server. The server would generate 1 private key and 1 public key.
3. It would send the public key to her app.
4. She would then see a form where she can type in the data that I am expecting from her. Then she presses a button to send the data.
5. The application would use the public key she received from me and encrypt the data.
6. the application would then also create a new private key on her phone to sign the encrypted data.
7. the application would then generate a public key from her private key
8. finally, the application would post all of that data back to my server and it would post her public key (so I can authenticate she is the one who sent the data).
9. after it was successfully posted it would delete her private key, the public key I sent her and the public key she just sent me.
10. Finally, my side of the application would authenticate the data I've received, decrypt the data and delete my private key, the public key I sent and her public key.

The Point I would have her secure data that she wanted to send me. The private keys used for all of this would never be able to be used again.

This would help alleviate the problem where your private key is exposed since it is only used for a one-time exchange.

Why doesnt this type of ad hoc encryption occur?

Would this offer any additional layer of security since it is time-based? Used once for this live exchange.

Would this run out of Private Keys? Unlikely, since it just generates another value which is used for a specific time period.

Would Private Key collision occur more often? Imagine if millions of people used an app that did this every day? Would it cause people's data to be accidentally decrypted by someone else's private key? Unlikely.

Would This Be A Way to Allow Ad Hoc Sharing of Private Data?

Finally, I'm curious if this would be a way to allow more of an ad hoc sharing of private data in a secure manner?

For example Alice calls Bob and needs his credit card information.

Wouldn't this be closer to the idea of a one-time pad anyways? And offer more security?

Answer 1

The fundamental problem you seem to overlook here is that Alice and Bob need some secure channel to guarantee no one can tamper with the keys that are being exchanged. As explained in Cthulhu's comment, in the particular scenario you describe, a man in the middle could break the confidentiality of the messages exchanged by generating his own pair of keys and sending his own public key to Alice. One way to address this issue is to use a long-term pair of keys, which happens to be the practice you want to get rid of.

To address the otherwise catastrophic implications of leaking a long-term private key, modern cryptosystems actually generate per-session key pairs that are never stored in any permanent memory. This property of a key agreement protocol is called perfect forward secrecy. In any case, you will still need to rely on a long-term key pair to start the whole process.