To do this, you need a good understanding of cryptographic techniques and protocols in general and how to implement these securely.

On to your question: You don’t implement RSA keys, you implement secure encryption/decryption functions in the context of a standard protocol. They might use RSA keys underneath, but decouple that. Almost all systems will have a cryptographic support library to help you. On top of that, you will need to take care of key management, and likely user registration for the cryptographic functions and key distribution.

All needs to be flexible, so you can change or upgrade cryptographic technology without functional change to the protocol.

This is all very much dependent on the technological environment you are working in and building for.

Get this right, and it will work. Get details wrong and it might still work, but be totally insecure. This is very hard to get right in all details, don’t underestimate this and involve cryptographic experts if you are working on something as important as an e-voting system.

Start by studying OWASP’s guide to cryptography: https://www.owasp.org/index.php/Guide_to_Cryptography

From there on, consider their suggestions for further reading.

To answer your second question: SHA is a collection of hash algorithm families. Do not use SHA-1 anymore. It does not need to work with RSA. You typically compute a hash for a data message, encrypt the hash and send/store the encrypted value (often with the message), so that the reader can later recompute the hash and decrypt the one originally computed. If they are the same, you may conclude that the data message is unaltered. This requires that relying parties trust the encryption to be secure.

i agree with Lex Borger

I follow the answer

Dear Timos Mukoko,

to answer this question illustratively, I would like to refer to some figures in the following literature sources:

[1] Anatol Badach: TLS – Transport Layer Security

https://www.researchgate.net/publication/292995131_TLS_-_Transport_Layer_Security

See here in particular the figures: 4132 (TLS Importance), 4134 (TLS Handshake) und 4140 (Structure of Shiper Suites)

[2] Dr. Erwin Hoffmann: Was ist neu bei TLS 1.3? TSLv1.3 – 21nd Century Internet Transmission Security

https://fraosug.de/assets/98/9709/TLS_1_3.pdf

See especially the pages: 3, 4, 8, 11 und 16

By using asymmetric cryptographic algorithm RSA and SHA (Secure Hash Algorithm), connection-oriented communication can be secured over TCP connections - especially communication in distributed web applications with HTTP.

In order to be able to secure communication over TCP connections, for example in distributed web applications and the use of HTTP, TLS was developed. Among other things, the security protocol TLS regulates the way in which RSA and SHA are used.

As shown in Fig. 4134 in [1], according to TLS, the two communicating partners - the TLS client and the TLS server - agree on the principles by which they secure the communication. These principles are specified in the form of a cipher suite. Each cipher suite has the structure shown in Fig. 4140.

Each cipher suite consists of the following three parts:

• Key Exchange and Authentication: Specifying the method by which the key exchange and the authentication - when establishing a TLS connection - run between client and server.
• Encryption: Specifying the cryptographic method used to encrypt the data of an application protocol transported via the TLS connection.
• Hash: Specify the hash function to verify the integrity of the transported data of an application at the destination.

When using RSA, for Key Exchange (only „key material“ exchange!) and Authentication, and SHA (for Data Integrity Checking), the cipher suites can take the form:

TLS_RSA_WITH_3DES_EDE_CBC_SHA

The "good" cipher suites are registered with the IANA. Their listing can be found at the web address

http://www.iana.org/assignments/tls-parameters/tls-parameters

Best regards and much success

Anatol Badach