I have a private key, which is:
0x66228b427f07b168c7cb1380aa5554403b9e24bf935a9364c89711a306a23ddb
NOTE: The Original Key was the Public Key when the question was posted:
0x6a2043113D5640F9F50dC593D0DcD8CC1c970EB1
I generated it randomly for this question, so don't worry that it's public on the Internet.
I want to use it as the encryption scheme for a JWT token, using the ES256 algorithm.
To get it into my library, I have to have it in one these formats.
secretOrPrivateKey is a string, buffer, or object containing either the secret for HMAC algorithms or the PEM encoded private key for RSA and ECDSA. In case of a private key with passphrase an object { key, passphrase } can be used (based on crypto documentation), in this case be sure you pass the algorithm option.
Is there any easy way to move the hex value to one of these formats? Or, will this not work because I'm not understanding the difference between an Ethereum Private key and a ES256?
Etherium keys are actually ES256K and not ES256 so in this case it might not be possible.
If you need to turn the key in PEM in NodeJS there is a library called key-encoder for this specific purpose. Which can be accomplished with the following code.
var KeyEncoder = require('key-encoder');
console.log(KeyEncoder.default);
let keyEncoder = new KeyEncoder.default('secp256k1')
var pemPrivateKey = keyEncoder.encodePrivate('0x66228b427f07b168c7cb1380aa5554403b9e24bf935a9364c89711a306a23ddb', 'raw', 'pem')
console.log(pemPrivateKey);
Related
As far as I've learned, I have to keep the private key secure and publish the public key, so that anyone can encrypt any data using public key and I can decrypt it using my own private key (which nobody has).
The question is, what if I publish the private key and keep the public key? Again the algorithm seems to work: anybody locks the data with the private key (which is published), but no one has the public key (which is kept secure by me).
What makes a public key, a public key? What secure and important data is stored on private key which I should show no one?
For a complete encrypt + decrypt (or sign + verify) process you always need BOTH keys. One for encryption/signing and the other one for decryption/verifying. Which of the keys you use for which operation is (in principle) irrelevant, as long as you use the respective other one for the inverse operation.
So let's assume you used a tool like openssl to generate a key-pair A and B.
When it comes to publishing one of those keys, we have to take into account two aspects
Math: From a pure mathematics point of view (and leaving out the security for a moment), it's irrelevant which of the keys you make public and which you keep private. All processes will work either way.
decrypt(encrypt(data, A), B) == data == decrypt(encrypt(data, B), A)
verify(sign(data, A), B) == OK == verify(sign(data, B), A)
Security: When we take security into account, proving your identity via digital signature is only possible, if you use a key, nobody else can possibly know. For certain crypto systems, it's possible to derive key A from key B, ie there exists a function such that
A = f(B)
but not vice versa, ie there is no function such that
B = f(A)
Thus, the moment you know B, you also know A, but if you only know A, there is no possibility you can derive B.
Thus B is called the private key and must kept private, A is the public key, which can be published. If you do it the other way around, the processes will still work from a mathematical point of view (although most systems will reject your keys), but they are not secure anymore ...
Depending on the system use, the public key may be 'well known'. For example, with RSA, the public key is just your modulus plus the public exponent 65537, while the private key is the modulus plus the private exponent (which is the real secret). So someone who knows the private key also knows the public key pretty much by default. The same is true of most elliptic curve based systems.
In theory one could make an RSA-style system where the public exponent is also hard to determine (say a randomly generated value of enough bits to be non-guessable), in which case it would be more symmetric, but that is not the way the system is usually set up. In any case someone who knows the secret parameters underlying the keys (the factors of the modulus in RSA) can easily determine the public key from the private key or the private key from the public key.
In systems like Diffie-Hellman, the public key is actually derived from the private key by a well-known algorithm (there are no secret paramters other than the private key itself), so in such cases the keys are not symmetrical at all, and anyone who knows the private key can trivially determine the public 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 am new to java card applet development.i want to create application which send me to public key for the future authentication.for the movement i used RSA algorithm for the create public key and private key.
keys = new KeyPair(KeyPair.ALG_RSA_CRT, KeyBuilder.LENGTH_RSA_2048);
keys.genKeyPair();
rsa_publicKey = (RSAPublicKey) keys.getPublic();
now i want to send the public key to my host application.i found some way using modulus and exponent send the public key to host application.but i don't know how to implement that one.can some one please help me to implement the send public key to host application..
Thanks
SSV
If you already have the RSAPublicKey instance it is easy. There you have to methods for getting the modulus and the exponent. Both get-methods copy the requested value into a byte array you can return in an result APDU.
Note that for a common JavaCard without extended length APDUs a 2048 bit RSA key is to large to return it in one response APDU. Depending on the available bytes in the response APDU you may even have to split modulus and exponent into 2 or more parts for returning them to the host.
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.
OK-- thanks to Mike, I was able to get Wincrypt to generate a Diffie-Hellman keypair. I figured out out to export the public key, and how to import the other party's public key. According to the docs, upon import of the other party's public key, the shared secret has been computed. Great.
I now need to get ahold of that shared secret, but I don't think its possible. Simply calling CryptExportKey with a type of PLAINTEXTKEYBLOB fails unless I call CryptSetKeyParam to change the algorithm id from CALG_AGREEDKEY_ANY to something... else. But I don't want something else, I want the shared secret. The API, however, seems designed to discourage this.
Any ideas out there? I should note that the problem here is that I'm only writing one side of an implementation of WiFi Protected Setup. So the protocol is defined for me, and the other party is not giving me HCRYPTKEYs.
This looks like what you need...
from: http://msdn.microsoft.com/en-us/library/aa381969(VS.85).aspx
To import a Diffie-Hellman public key and calculate the secret session key
Call the CryptAcquireContext function to get a handle to the Microsoft Diffie-Hellman Cryptographic Provider.
Create a Diffie-Hellman key by calling the CryptGenKey function to create a new key, or by calling the CryptGetUserKey function to retrieve an existing key.
To import the Diffie-Hellman public key into the CSP, call the CryptImportKey function, passing a pointer to the public key BLOB in the pbData parameter, the length of the BLOB in the dwDataLen parameter, and the handle to the Diffie-Hellman key in the hPubKey parameter. This causes the calculation, (Y^X) mod P, to be performed, thus creating the shared, secret key and completing the key exchange. This function call returns a handle to the new, secret, session key in the hKey parameter.
At this point, the imported Diffie-Hellman is of type CALG_AGREEDKEY_ANY. Before the key can be used, it must be converted into a session key type. This is accomplished by calling the CryptSetKeyParam function with dwParam set to KP_ALGID and with pbData set to a pointer to a ALG_ID value that represents a session key, such as CALG_RC4. The key must be converted before using the shared key in the CryptEncrypt or CryptDecrypt function. Calls made to either of these functions prior to converting the key type will fail.
The secret session key is now ready to be used for encryption or decryption.
When the key is no longer needed, destroy the key handle by calling the CryptDestroyKey function.