There is some algorithm which signs with a private key and verifies with a public key.
Private and public keys are created in pairs.
Assume we have 2 pairs of private and public keys.
Is there a way to combine two private keys to one private key priv_comb, so that the produced signature S, computed with this priv_comb, could be verified with either of those two public keys?
Or does this make sense at all?
Related
One of my client is asking CA Certified Public Key for Encryption/Decryption purpose. And I am not sure how to provide it to them.
Yes, You can reach the Public/Private Key providers to get the key pair (for eg: SSL.com but i am not sure which one is good.)Public key - can be shared with every one but keep the private key as a secret. The information encrypted by your public key can be decrypted only with your private key.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I have a basic question about ECDH (Elliptic Curve Diffie-Hellman).
The whole idea is that both sides exchange their own public keys and arrive at the same private key. However, you can trivially intercept both keys. Inputting the other public key is trivial.
So the main issue is generating your own public key. Does it mean that it is not trivial to re-generate a given public key, i.e. it is not possible to recover the original parameters used to generate a given public key before you can input another public
key and arrive at the same private key?
An ECDH key exchange is not used to create a private key but to calculate a shared secret. This is performed by each party first creating their own EC public/private key pair, then using their own EC private key and the other's EC public key to perform the ECDH computation, which results in both sides calculating the same value.
The first step is for each user to generate an EC public/private key pair. Supose Alice and Bob each generate a key pair. In this example, Alice's EC private key is x and her EC public key is xC, and Bob's EC private key is y and his EC public key is yC. These are then used to perform ECDH key derivation.
Next, Alice uses her EC private key and Bob's EC public key to compute x * yC == xyC. Similarly, Bob uses his EC private key and Alice's EC public key to compute y * xC == xyC. Then xyC is the shared secret created by the ECDH algorithm.
ECDH doesn't rely on the public keys alone; those are just the only components that are required to be send. Instead, it depends on two public / private key pairs, generated by both parties. The trick in Diffie-Hellman key agreement (DH) is that a calculates the shared-secret given the private key and the public key of the other party. This shared secret is identical on both sides if and only if the correct private and public keys are used.
The public and private keys of a pair are linked during key pair generation; the DH public key is calculated from the base point of the curve and the private key. This specific bond between the keys is required to calculate the same shared secret. For this calculation to succeed it is also required that both keys use the same domain parameters; in other words, the public keys need to be on the same curve.
A third party / adversary can of course copy the public key of either party. That will however not help the adversary as it doesn't have access to either of the accompanying private keys. So no other party than the ones involved in the key agreement will be able to calculate the same shared secret; you need one of the private keys to do that.
Taking it further, it is possible for an adversary to create a different key pair. If the public key of that key pair is accepted by the other parties then it is possible to create one or two different shared secrets.
SSL / TLS for instance mainly uses ephemeral (temporary) keys; any public ECDH key is accepted. That means that such a form of DH does not offer authentication of the parties involved. So a man-in-the-middle (MitM) attack is possible unless other authentication measures are used. The TLS for used in browsers uses server certificates / server signing for that.
But this part is giving an answer to a question that you didn't ask (yet).
Sometimes the word "secret key" is incorrectly replaced with "private key", even in books on crypto. This is very confusing, as it is obviously impossible to have a shared private key: "shared" and "private" are two opposites. Diffie-Hellman doesn't calculate a shared private key, it produces a shared secret, which is then used to calculate one or more session keys.
I am pretty sure, that ECDH keys are generated between private key of one party and public key of other party.
lets say two parties are bob and alice, then according to ECDH scheme this holds True.
ECDH(bob_private_key, alice_public_key) == ECDH(bob_public_key, alice_private_key)
because of which nobody other then alice and bob can generate the same key.
check here for the implementation in python,
https://stackoverflow.com/a/52506717/1619003
#Maarten has explained what might have confused you, difference between secret key and private key.
I have read the bip32, but have some confusions.
If I have all the useful information about HD wallet and generate a new public child key with a public parent key, public chain code and index number, how I spend the funds in the new address corresponding the new public child key?
Or in others words, what is the corresponding private key of the new public child key when I sign a new transaction?
I have solved this question after reviewing the bip32 proposal again, and post the answer to help others.
Answesr:
The corresponding private key of a new public child key with HD wallet is the new private child key.
Why:
First, please see the partial picture of bip32 below:
There are two procedures:
Procedure: private parent key -> private child key.
Procedure: public parent key -> public child key.
As you can see the content with red box in the picture, the two calculation result of I are same between two procedures.
For point(k_par)=K_par, the two calculation result of I are same.
Then, the answer of this question is that the corresponding private key of new public child key is the new private child key. This means that:
The k_i in the upper circle is the private key of K_i in the lower circle which is the public key.
As the elliptic curve group is an additive group, it means that:
[(x1+x2) (mod n)]*G = x1*G + x2*G,
where G is the generator of elliptic curve group, n is the order of elliptic curve group, and x1, x2 are private keys.
Then, we focus on this situation, and it is easy to get with the content in the two circle:
[parse_256(I_l) + k_par (mod n)]*G=point(parse_256(I_l)) + K_par,
because two I_l are same and k_par is the corresponding private key of K_par.
For more information, please contact me with the e-mail: xchang17#fudan.edu.cn
Can we have multiple public keys associated with a single private key for RSA public-key encryption?
In practice and with respect to security, no, mathematically, yes. If you have a private key (N, D), there is algebraically an infinite number of solutions to the equation 1 = E*D (mod Phi(N)). However, if you make two such solutions (E, N) and (E', N) that both satisfy the equation public, you will have compromised the secrecy of the private key.
However given one of the usual asymmetric schemes you can easily create such a scheme: To create a private key with n public keys, just generate n public-private keypairs in the normal scheme and define the "private key" to be the collection of the private keys. When signing just sign with all the private keys, when verifying try to verify one of the signatures. Encryption is the usual operation and decrypting should try to decrypt with all the keys (one of them should work).
Such algorithm is well known as "hierarchical deterministic wallets" and well explained here BIP-32
I heard that you can use a private key to encrypt data as a method for digital signing. In other words you can encrypt a message with your private key.
In the text they always seem to say only the public key can encrypt and the private key can decipher the text.
I'm assuming this is a bad choice of words. Is it true that a single instance of a key can do only one or the other, but which key is public or private is not a matter of it's function, but of it's distribution or lack thereof.
For a beginner, the terminology is confusing. RSA can be used for 2 distinct crypto functions: data encryption and digital signatures.
For data encryption, you encrypt data using the recipient's public key; they decrypt it using their private key. Note that due to various limitations of RSA, the "data" that is encrypted and decrypted is usually just a key for a symmetric algorithm.
For digital signatures, you sign the data using your private key; they verify the signature over the data using your public key. Again, various limitations of RSA mean that what is actually operated on by the RSA algorithm is normally a secure hash of the data.
Sometimes the signing operation is called "encrypting with the private key", and the verifying operation is called "decrypting with the public key". I think this just confuses people so I always prefer the terms signing and verifying in this context. Furthermore, "encrypt" and "decrypt" make no sense for other signature algorithms like DSA and ECDSA.
You CAN generate public key from private key.
You CAN'T generate private key from public key (well, you might can, but this is extremely computationally expensive).
That is the difference between the two. They are NOT interchangeable (so, for instance, you SHOULD NOT publish your private key, and keep public key to yourself) because of the way how the algorithms works.
Take for instance RSA. The algorithm base is the problem of integer factorization. You choose two big integers p and q and multiply them to get n = p*q. Then you create public and private key:
Public key: (n, e)
Private key: (p, q, d)
Then:
It is easy to calculate public key from private key:
n = p*q
e = d^(-1) mod φ(n), where φ(n) = (p-1)(q-1)
It is hard to calculate private key from public key - it requires factorization of n to get p and q, which is extremely hard if p and q are big enough.
You release your encryption key to the public, and keep your decryption key private. That way anyone can send you encrypted data that only you can decrypt.
If you did it the other way around, then you would be the only one able to encrypt your data, but anyone could decrpyt it. That makes no sense. If everyone can decrypt your message you might as well send it unencrypted. There is no point encrypted a message and then making the decryption key public.
There are two types encryption one is symmetric another one is asymmetric .In symmetric the key used to encrypt and decrypt is the same . in asymmetric the key used to encrypt is public key and decrypt is private key ..
all works on the principle of a secrecy of the key .In Digital signing commonly used as a part of SSL / TLS protocols uses the asymmetric encryption for the authentication and sharing of the master key which is used further for encrypting the communication line.