I am encrypting data with public key and decrypting data with private key.
Is there a possibility of having multiple private keys with a single public key?
No you cant that is an essence of Public Private key encryption. Why do u want to have multiple private keys for a single public key? What if u want to sign an encrypted file?
If that would be possible I would be able to send encrypted file to your friends and sign it with my crafted private key?
I suppose in theory it depends on the algorithm.
But with the ones we generally use (RSA, ECC), there is a 1:1 correspondence, so: no.
Not having a 1:1 correspondence seems like a bad thing. After all, you want to know that only a specified person can be the sender/recipient.
If you want group conversations, this is usually done by encrypting the message with a symmetric session key (you'd do that anyway in all likelihood, because public-key-crypto does not scale well for large messages), and then encrypting the session key (separately) for multiple recipients.
Its not feasible to make multiple private keys from one public key. First a key is generated which will be your private key. The public key pair is generated from this private key. Only one public key can be generated from one key. Here is a simple command to generate public key using RSA algorithm
rsa -in <yourkeyname(private key)> -pubout -out <publickeyname>
Related
One public key usually corresponds to one or a specific number of addresses in other cryptocurrencies based on some algorithm.
https://testnet.dragonglass.me/hedera/transactions/0025330611632361982325526043
https://testnet.dragonglass.me/hedera/transactions/0025330611632362160372571164
In hedera, as the above two transactions have shown, using the same public key to send out two accountCreate transactions gives back two different accountId.
Is there an API whose params are a public key and who returns all the account Ids corresponding to the public key?
The mirror nodes support querying based on public key. However, Hedera's accounts are not 1:1 with a public key, you can't assume a public key is linked to a single account, in fact, the same public key can be used across multiple accounts meaning the same private key can sign transactions for all these accounts.
Furthermore, an account can be associated to a list of public keys meaning every key has to sign, or a threshold list which is a list where say 5 of 10 have to sign. All these can be nested too !
Finally, subject to having the private key to sign the transaction, you can update an account's public key. What you can't do is derive the account id from the public key. The account id comes from a sequence of numbers, each new entity (an account is an entity as are topics, tokens, etc...) is given the next id in the sequence.
Consider 3 entities A,B and C. I want A to be able to encrypt a document that can be decrypted only when keys of both B and C are combined. This question talks about a similar problem, but it uses AES.
In my usecase, I don't want the keys to be shared across the entities. There is one solution that was coming to my mind:
A encrypts the document (with RSA) first using public key of B and then public key of C. Then the document is decrypted using private key of C and then private key of B.
Is this approach feasible? Is there a better way?
Note: I tried doing this but got this error when I was doing encryption for the 2nd time: Data must not be longer than 117 bytes.
I am trying to put together a distributed hash table (DHT) with a name system where one will be able claim ownership of any key.
What I have in mind is the following interface
dht.secure_set(public_key, signature, key, value)
where
signature == sign(private_key, public_key, key, value)`
That is the key-value pair is signed by signature.
Then, others will be able to retrieve value given they know the public_key and key:
dht.secure_get(public_key, key)
The peer responsible for key in the DHT will only accept updates to the (public_key, key) pair only if the signature is indeed the signature of the (key, value) pair.
Is this signature scheme secure?
I see at least two issues with that:
A) having the storage peer responsible for verification is not sufficient. it may be a malicious node, so readers will have to verify too
B) If there are many (key, pubkey) tuples with the same key but different pubkeys, i.e. some key being really popular, this can put an undue burden on a small fraction of the nodes in terms of CPU cycles they have to spend (if there are frequent writes), storage and traffic they have to serve.
It may be better to derive a final lookup key from (key, pubkey) through a hash function so that those tuples get scattered throughout the keyspace. This is in fact what the bittorrent DHT specifies for its generic value signed storage
Can we use same pair of public and private keys for more than two communications at the same time?
Or do we need to get a different pair of keys for different communications (at the same time)?
For example:
There are 3 persons: A B C.
Now should A share the same public key with both B and C or should it generate two pairs of public and private keys and give one public key to each?
The same key pair can be used for all communications but to make it secure we need the peers to derive the common key for each specific conversation. Example of such method is TLS protocol where the common key for each conversation is created using the same server peer key pair.
I am using openssl. I need to use a bigger RSA key (2048 ). Is there any relation between the size of the RSA key and the size of the symmetric key (say DES). SSL doesn't appear to put any restriction
Size of symmetric key depends on the symmetric algorithm and it's not directly related to asymmetric key size. Eg. no matter what length of used RSA key is, DES key will remain at 56 bits.
In SSL, that which is encrypted with RSA is the pre-master secret, a random string generated by the client which always has length 48 bytes. Then, the pre-master secret is derived (with the key derivation function that is known as "PRF" in the SSL/TLS standard) into exactly as many bits are required for whatever symmetric encryption algorithms will be used. Thus, no direct relation between the RSA key size, and the symmetric encryption key size.
A 48-byte pre-master can be encrypted with any RSA key of length 472 bits or more, so no problem here.
No, there's no restriction - you can select both the session key and the RSA key separately depending on what level of protection you need. Of course there will be some "recommended" relation between keys lengths, but the choice is up to you. That relation might change if at some point a minor weakness is found in RSA and you decide you need a considerably longer key - that weakness will likely not affect the symmetric algorithm and so the keylength for the latter may be kept unchanged.
The asymmetric key is used to send the symmetric by encrypting it. Thus they are independent operations and independent of each other. As a result an increase in the bit size of one will not impact the size of the other.