Is there a cryptographic mechanism or algorithm to verify if the other party has a valid private
key without being able to decrypt the messages encoded with that private key?
For example with asymmetric encryption private key can decrypt messages encrypted with public key and vice versa public key can decrypt messages encrypted with private key - as I understand this is how usually digital signing works.
This mechanism doesn't work for me as on the server side I don't want to be able to decrypt messages encrypted with the private key... I just want to verify 'in some way' if the client side has a correct private key that can potentially decrypt a 'certain (encrypted) file'.
Just wanted to throw this question here if somebody has come with solution/mechanism for this specific use case? Is that even mathematically possible to achieve?
For example with asymmetric encryption private key can decrypt messages encrypted with public key and vice versa public key can decrypt messages encrypted with private key - as I understand this is how usually digital signing works.
That is not quite correct. A public key's job is to encrypt a message that only a private key can decode.
so in your case, in the simplest implementation,
you create a key pair and give user your public key
user create a key pair and gives you their public keyy
you have a 'for-your-eyes-only' file which you encrypted using the user public key and placed on your server.
the user downloads the file and decodes it using user private key
your main security concerns are;
how you create and store your key pair, same for user
how you exchange the public key, how you/user verify each others public key
there are tons of great blogs on the net, they answer each concern and more in great depth.
Related
I managed to to POST/UPDATE and DEL request from React application (from different microfrontend using Webpack 5), to multiple backend application (microservice) written in Node JS.
Each data is encrypted using a key created with symmetric key. The symmetric key is also encrypted using Public key from client. Then both encrypted data and key sent to server to be decrypted in the server for storing.
What about GET request ? How do I do reverse encryption of data sent from server to be read on the client, especially I have multiple micro front end client. Do I create multiple RSA pair keys for each micro front end, with private keys stored in each client, public key to be sent along with GET request to the server ?
Whenever any application(browser, thick client application) is requesting to generate an AES key, I would like to supply a static key to that application.
Is there any way to do this in Linux or windows?
There is not an universal way of generating AES keys that applications needs to adhere to.
Forcing a static key on an arbitrary application ought to be hard/impossible if the application is secure - and would be a case by case activity.
I would like to ship my app to my client with my own public key. This key will be used when my clients need to export IP data from my app for debugging purposes. This data needs to only be readable by myself. Suppose that clients can not read my code and can not access my app's memory but would be able to identify my public key inside the app and maybe replace it with theirs thus making the exports readable by them. What options do I have to ensure that my public key is actually a pair for my own private key before commencing the export?
If we assume the OP's threat model, specifically that the attacker is not debugging the app and/or somehow messing with the process' memory in run time, the app should validate the public key before performing encryption, wherever the public key might come from.
In the order of diminishing strength:
digital signature from a public certificate authority (it will be paid), rely on system trusted roots
digital signature with another private key that the OP possesses (hard-code the public key in the app)
HMAC of a public key with a hard-coded secret
hash of a public key
In case of RSA keys, the modulus pretty much identifies the public key. The public exponent in most vendor implementations of RSA that I'm familiar with is hard-coded to 65537 anyway.
I am developing a windows desktop app where the clients applications need to download some data file from a public shared folder. in order to protect the data from tempering i would like to generate RSA private and public keys. keep the public key in my own machine at home and include the private key in all clients.
when i want to send a new file for the clients to download (at well) i hash the file and encrypt the hash with the public key and store it as .sig file alongside the data file in a public shared folder.
now if one of the client users is malicious he can steal the private key from his machine.
the question is : provided that the public key is secret and this is the only use of that key pair and i absolutely don't need any encryption on the data file. does stealing the private key from a client compromise my public key? i.e can the malicious user craft a file signature so that the data file appear to be coming from me?
I belive you've designed this backwards.You want to send the public key to the clients and keep the private to yourself. The public key is public; anyone should be able to know it. The private key is private; only the owner should know it.
Rather than hashing the file and encrypting the hash with the public key, you want to sign the file with your private key and let the clients use the public key to verify the signature. The signing operation performs the same idea as your "encrypt the hash" but is the standard construction, and your RSA tools likely include a signing function.
I was wondering if there is a free encryption library that implements group encryption with multiple private keys and a single public key.
I assume you mean for the single public key to be the signer.
OpenPGP can take care of that use case, and the GNU Privacy Guard (with its associated library) is a free implementation of OpenPGP. I've used a Python binding to gpgme, myself.
(As I understand it, this is implemented by encrypting a symmetric key with each of the recipients' public keys, so that any of the recipients' private keys may be used to decrypt the message.)