I am confused about the execution order of ECDSA and ECDH, which one runs first ?
Since ECDH can not avoid MITM attach, therefore ECDSA is used to verify the entity. So ECDSA should run before ECDH ?
Or it doens't matter at all?
Since ECDH can not avoid MITM attack
First, here is one of the many ways you could solve this difficulty using RSA instead of DSA (or ECDSA): the client, before sending its ECDH (or DH) public key on the wire, could encrypt this ECDH (or DH) public key with the public RSA key of the server. And this way, the server is the only peer that knows the client ECDH key. Therefore, both sides are protected against man in the middle attacks. Of course, using RSA to encrypt another key may need OAEP.
Or it doens't matter at all?
In your case, using ECDSA instead of RSA, you can not encrypt anything. So you need to have mutual authentication in the protocol you will design: your server and your client must have previously exchanged their public ECDSA keys or must have some kind of PKI with some kind of root certificate to authenticate the remote public ECDSA key. Finally, the client and the server just need to follow those steps, in this order:
sign their ECDH public key with their ECDSA private key,
send this information to the other host,
receive this information from the other host,
check the signature,
if the check failed, stop talking,
if the signature is correctly checked, perform the end of the DH algorithm.
Related
I've generated a key-pair using keytool -genkeypair command. I presume this create a pair of private key and public key.
I've also generated a CSR out of this key-pair using the keytool -certreg command. I got it signed by our CA (or whatever they call it) and I got another certificate in return along with it is its thumbprint.
My question is, what am I going to use that certificate for or what is its purpose? I'm still able to generate a JWT just using the private key.
A key is a set of mathematical parameters describing how to initialize certain algorithms for cryptographic operations, e.g. for signing/verification or for encryption/decryption.
A key pair merely is a pair of such keys where each key can verify what the other one has signed or where each key can decrypt what the other one has encrypted.
One key in such a pair is declared the public key and the other one the private key. (This choice is not completely arbitrary, there can be different extra requirements to a private key than to a public one.)
There is nothing in these keys declaring that they are bound to a specific person, to a specific issuer, to a specific purpose, to a specific accountability, etc.
This is where X.509 certificates come into the picture: A X.509 certificate is a structure that bundles the public key of a key pair with extra information like the name of the holder of the key pair, the name of an issuer of the certificate, validity time spans, and much more.
This structure furthermore contains a signature of all those other data in the structure. This signature is generated using the private key of the issuer of the certificate.
The information in the certificate in particular allows you to determine the issuer of it. If you trust organization of the issuer to only issue certificates to persons whose identity they checked, and if you successfully validated that the certificate signature is valid and created by the issuer, you can trust the identity of the holder of the key pair of a given certificate.
Thus,
My question is, what am I going to use that certificate for or what is its purpose? I'm still able to generate a JWT just using the private key.
you provide your certificate publicly to allow people to be sure of your identity when they use the contained public key to validate your signatures or encrypt information they send to you. Without a mechanism like the certificates you'd have to give people your public key in person for them to be sure of that.
Spring's default OAuth JWT flow (using client_credentials grant) is as follows:
Launch the Auth Server (AS)
Launch the Resource Server (RS)
At startup the RS requests the tokenKey by calling GET /oauth/token_key using Basic Auth
The AS returns a PUBLIC KEY using RS256 (SHA256withRSA)
Some time later, the Client requests an accessToken by calling GET /oauth/token using the client_credentials grant
The AS returns a JWT accessToken containing a JWS signature
The Client sends the JWT as a Bearer token to the RS
The RS uses the tokenKey that it received from the AS at startup to verify that the JWT accessToken came from the AS. This is where I get confused...
Is this secure? Why would a public cert be used rather than a shared secret key? Couldn't a hacker easily obtain the public key and sign their own valid JWT accessToken? How does the usage of the public key cert and the JWT signature work together to verify that the sender was actually the Auth Server and not an attacker?
Any insight would help.
Some research into the nature of public key cryptography and digital signatures gleans this:
Digital signatures implement asymmetric cryptography. A digital signature gives the receiver reason to believe the message was sent by the claimed sender. Similar to a handwritten signature they are difficult to forge. The signer, in this case, the AS, uses a secret PrivateKey to create the signature. Some non-repudiation schemes offer a time stamp for the digital signature, so that even when the PrivateKey is exposed, the signature is valid.
A digital signature scheme typically consists of 3 algorithms
1) A key generation algorithm that selects a PrivateKey uniformly at random from a set of possible private keys. The algorithm outputs the private key and a corresponding public key.
2) A signing algorithm that creates a signature using the message and the private key
3) A signature verifying algorithm that, given the message, PublicKey and signature, either accepts or rejects the message's claim to authenticity.
In this case (RS256), the signature was created using SHA256withRSA which is not used as an encryption algorithm, rather it is used to verify the origin or the authenticity of the data. The signature was generated using a private key. The public key is passed to the Resource server to be used to verify the signature. In this scenario, even if an attacker has the PublicKey, they cannot create a spoof message with the signature or alter the contents.
i want to know performance wise which is better to provide message authenticity, ECDSA signatures or hash based signatures, although i have read the comparisons of ECDSA with RSA, but not found with hash based signatures. Can ECDSA signatures replaced with Hash based signatures improves the message authenticity or not.
ECDSA is a hash based signature, in that the data gets hashed, then ECDSA is performed on the hash (not the whole data)
When it comes to data verification there are three main approaches:
Straight hash (e.g. SHA-2-256)
The fastest option to verify
If you are only protecting against line corruption this is a valid choice.
Otherwise, requires that the hash/digest value be sent over a secure (from tamper) channel, because the tampered can easily transmit the digest along with the tampered document
Provides no proof of origin
HMAC (e.g. HMACSHA256)
Requires that both the sender and receiver share the secret key
Either the sender or receiver having the key stolen puts both sides at risk
Secret key needs to come from key agreement algorithms (ECDH) or be transmitted in secret (encrypted)
Proves the document came from someone with the shared secret.
Digital Signature (e.g. ECDSA, RSA signature)
The sender is the only entity with the private key, receiver needs public key (non-secret)
Public key can be embedded in an X.509 certificate to provide a notarized association of public key to the signer
Or the public key can be transmitted raw over a secure (from tamper) channel.
Provides strong assurances about the document origin, since they shouldn't share their private key.
All three options use a hash algorithm to reduce the original data, the rest of the algorithms are what do you do with that data. There's not really a standard definition of "secure", you have to say "secure against (something)". ECDSA provides more assurances than HMAC as long as the private key isn't shared. But if HMAC provides enough assurance it is probably faster on average (specialty hardware aside).
Scenario
A SOAP web service provides an interface for retrieving documents and data. Security is paramount.
WS-Security is used and both the client and server encrypt and sign the entire SOAP envelope.
Questions
Should the private key used for signing be compiled into the application and stored on the device or should it provided by the server using a key exchange protocol (perhaps after authentication of the user)?
Should the private key for decryption be stored on the device or provided by the server?
Is it realistic to have a unique key for each file that is to be decrypted by the server (if uploading from client) or decrypted by the client (if downloading from server)?
Just a couple suggestions:
-You should consider symmetric keys embedded into anything outside your server as public due to reverse engineering (i.e. don't bother even encrypting if the key is out in the wild).
-You should use a per-session symmetric key generated by a secure RNG on the client, and transmitted to the server encrypted with the global asymmetric public key. Private keys have a shelf-life.
-You can use the session key for all files/streams transferred in that session, but you should use a unique nonce to salt the symmetric-key encryption for each file. Depending on the encryption mode, using the same key/nonce with more than one stream can leave you vulnerable to XOR'ing the two streams and recovering a mashed-together but unencrypted result.
The entire concept of a private key is defeated if it has to be transmitted from one device to another. Each end of the communication channel must generate their own private keys. Note, that this doesn't mean compiling private keys into an executable, because then everyone with the executable shares a private key, which is obviously not what you want. Each individual device has to use a cryptographically secure source of random numbers to generate it's own public/private key pair. Then public keys can be exchanged in the clear, you can use them to exchange session keys (which can be unique for each and every file), private keys can sign, and everybody is happy.
But remember: Never, ever hard code private keys, and never, ever share them with anybody.
I'm working on a Single Sign On solution to allow my company to integrate with other vendors.
As I'm doing my research, one thing is constantly confusing me.
My understanding of Public/Private key is that data is always encrypted with the vendor's public key and they decrypt using their private key. So far so good.
However, to validate that the message is really coming from me, I will compute the hash of the message and encrypt the hash with my private key (this process is also known as signing). To verify that the message is coming from me, the vendor will use my public key to decrypt the Hash and compare it with the unencrypted hash. If they match, the vendor can be confident that it came from me.
So how come my private key is used to encrypt the message..and how can public key decrypt the message? I thought Asymmetric keys doesn't allow that..! i.e Public Key always encrypts and private key always decrypts. Any explanations will be greatly appreciated..!
Encryption and signature are two different systems. In some ways, they work in opposite directions.
With public-key encryption, anybody can encrypt data with the public key. Only the owner of the private key can decrypt encrypted messages to recover the data.
With signatures, only the owner of the private key can sign messages. Anybody can use the public key to verify the signature of a message.
My understanding of Public/Private key is that data is always encrypted with the vendor's public key and they decrypt using their private key.
That's correct. But it only covers public-key encryption, not other uses of public-key cryptography such as signatures.
However, to validate that the message is really coming from me, I will compute the hash of the message and encrypt the hash with my private key (this process is also known as signing).
Actually, this process should only be known as signing. Calling it “encrypting with my private key” is very misleading: that's not the way it actually works. There is one popular type of keys (RSA) which can be used for both signature and encryption, but even with RSA, the signature and decryption mechanisms are different.
To verify that the message is coming from me, the vendor will use my public key to decrypt the Hash and compare it with the unencrypted hash. If they match, the vendor can be confident that it came from me.
That's not quite correct. Many signature algorithms are not deterministic. Verifying a signature is not done by reversing the signature process, but by making some slightly different calculations involving the signature, the message and the key.
So how come my private key is used to encrypt the message..and how can public key decrypt the message? I thought Asymmetric keys doesn't allow that..! i.e Public Key always encrypts and private key always decrypts. Any explanations will be greatly appreciated..!
The private key is used to sign the message, not to encrypt it. The public key is used to verify the signed message, not to decrypt it.
i found this link very helpful :
http://www.nusphere.com/products/library/ssl.htm
Wayback Machine archive from 2007 of the above nusphere link.
HTH
Ohad
EDIT
after 2.5 years, I see that the link is broken. So this one is good as well.
And in case it will be broken again in 2.5 years from today, here is the summary:
The Public Key is what its name suggests - Public. It is made
available to everyone via a publicly accessible repository or
directory. On the other hand, the Private Key must remain confidential
to its respective owner.
Because the key pair is mathematically related, whatever is encrypted
with a Public Key may only be decrypted by its corresponding Private
Key and vice versa.
Public Key Cryptography can therefore achieve Confidentiality. However
another important aspect of Public Key Cryptography is its ability to
create a Digital Signature.
The difference between symmetric and asymmetric encryption is only the existence of private and public keys.
Nevertheless in the common algorithms you can use the private key to encrypt messages which can be decrypted with the public key and you can also decrypt messages which are encrypted with the public key. So it is possible in both directions.