So Currently, I am trying to understand public/private keys with servers and clients work.
Overall, I am trying to set up a server (Socket Stream) storing all messages which will show up encrypted on the server side.
When a user connects through entering the port and its username, through the client application, any message intended for this user will show while the messages which arent will stay encrypted. These messages will all be sent to the client side from the server which is storing it currently.
So lets say Alice wants to messages Pami secretly, Pami's public key will be used to encrypt the message while alice's private key will be used for the signature.
For this, will encryption be done on the server side and decryption on the client side or does both occur on the same side?
Related
So the question is: How does a tcp server with encryption knows which key belong to which client so to encrypt with the correct key for the specific client?
Example:
Client1 share key with server and Client2 share key with server. Then the server want to send data to Client2, how does he know which key to select?
Does the server associate ip address with key? If yes, what happens if my ip change mid session?
This question refers after the exchange of the private key, this is synchronous encryption.
I'm building an enterprise-level API to automatically send and receive private data between two corporate servers. The data will be sent in daily batches to send large amounts of private data to a receiving server in another data center. I'm coding both the API on the receiving server and the automated task on the sending server to automatically connect to the API server and send the daily data.
Data will be transmitted via an HTTPS endpoint. An API key (using a random 30 character string) is required to authenticate the API between the sending server and receiving server.
I'm being asked to go above and beyond to ensure the security of the data while in transit between the two servers. A few things I'm currently considering:
Is coding an additional private/public key pair exchange between the servers for authentication needed if we already use HTTPS + API key? I don't think a private/public key pair really provides additional authentication security -- as long as the API key is stored securely (and other precautions such as changing the API key on a monthly basis) coding a private/public key pair exchange doesn't seem to offer any additional security?
Is it worth it to encrypt the data in the code on the sending server, to be decrypted by the receiving server? We're using an HTTPS connection which already encrypts the data, and honestly a second level of encryption seems like overkill and useless (not to mention whether our programming team can even provide better encryption security than SSL which is already best practice).
Protection against other types of attacks. For example to protect against a man-in-the-middle replay attack we require a unique session key be sent along with the data. The session key is only accepted once by the receiving server and so a replay attack will be rejected. However this is only to ensure data integrity on the receiving server by making sure the same request can't be sent twice.
I'm looking for other suggestions that would be considered enterprise-level best practice to protect the API authentication process, security of the data while in transit, or protection against other types of attacks for this scenario. Any suggestions welcome.
Thanks!
I am in the process of creating a flutter application that will include direct messaging. You can message 1 person or a group of people. I want this to all be encrypted for privacy.
The method I was thinking about is to do a hybrid RSA, AES system. On signup, a RSA key pair would be generated and the public key would be sent to the database for storage. Then when the user wants to message someone, they would request the other persons public key and create a AES-256 key for encrypting any messages. Then when the user wants to send the message it will be encrypted with AES and the AES key will be encrypted with RSA, so that the receiver can decrypt the message.
The problem I am facing is that I want the user to be able to sync the messages across devices. I had the idea of generating the public and private keys from a mnemonic phrase and then using that for recovery.
However this doesn’t solve the AES recovery issue. I am unsure if storing the AES key in the database for each chatroom is secure, even if it is encrypted with RSA. An encrypted AES key for each person involved in the chat would have to be stored.
If anyone has any recommendations or tips please let me know.
I'm developing the set of applications, that provide the possibility to read encrypted data between several users using email messages.
It's rather hard... If to compare email messaging with the live chatting (IMs) through single server (for live chatting, I need just chanell with TLS). because I need to decrypt the the message, which is just saved on remote server.
Also, as I suppose the secure server mustn't keep private keys, because the user wants to be sure, that event supplier side (backend) can't decrypt content. Private keys must store on some stuff like smart-cards (which only user has).
For emails, I've found two options:
S/MIME
OpenPGP
So... the main problem (for me) is how to distribute private data, which will allow to decrypt email message for the user, which received the encrypted email message.
So, question is about correct distribution of private keys, right now I can't imagine how to deliver it in secure way.
Private keys are, well, private. You don't want to be transferring them. Never.
Instead, re-think the problem in terms of distributing the public keys in the other direction. Then you don't need to worry about eavesdropping (but you will want to be concerned with authenticity).
The proper approach is to use asymmetric cryptography to secure the data. In this scenario your users send each other their public key, and they can do this in any way. Private keys remain on user's side. The sender encrypts the data with the public key of the recipient, the recipient uses the private key to decrypt the data.
If you absolutely must use symmetric algorithms and keys for encrypting the data, then you still can use asymmetric cryptography to deliver symmetric keys in encrypted form (this is what S/MIME and OpenPGP would do for you, actually).
Note: when I am talking about encryption with a public key, I mean a hybrid scheme, when the data is encrypted with a symmetric session key, which is then encrypted with a public key. The data are almost never encrypted with asymmetric cryptography directly, without employing a symmetric algorithm.
I am developing a client server application in which data is transferred between two clients through the server.
The data should be encrypted and I thought of using AES.
My thought was to use PBKDF2 in order to derive the AES key from the client's password.
In this case the client will encode the data, the server will decode it, reencode it using the 2nd client's password and send it to the 2nd client.
Do you think this is the best way to implement this?
Is there a way for the first client to encode and the 2nd client to decode without server interference?
How can I encrypt the AES key and transfer it from one client to the other?
What do you think of the following solution?
Client and server create a private AES key using Diffie-Hellman (this key is specific to each client).
Transmitting client creates a session AES key and encodes it using the private AES key.
Server decrypts the session key and re-encrypt it for every client in the session (using each client's private key).
Transmitting client encrypts the data using the session AES key and sends it to the server.
Server sends the data to all recipient clients without any required processing.
You could also use Diffie–Hellman key exchange. What programming language do you use?
You could use an asymmetric encryption algorithm to send the AES key securely and then use this key for symmetric AES encryption/decryption. The communication could go like this:
A client wants to talk to a server with encrypted messages.
The client generates a pair of public/private keys and sends the public key to the server.
The server uses the public key to encrypt some secret key and sends it back to the client.
The client uses his private key to decrypt the secret (both now know the secret key to encrypt/decrypt their communication).
The client uses AES with the secret key to encrypt the message he wants to send to the server.
The server uses the secret key to decrypt the message.
You must create your own protocol for communating part of your program first or use available secure protocols such as HTTPS.the only thing that i can tell you is that heavy computing operations such as encryption/decryption must be passed by clients first and then server process reliable requests.