Which is more conventional?
For cross-platform; it is ok to store and use JWK in the JSON format?
Do I need to encrypt them before storing it in a database?
Not sure about the format, but I'd strongly recommend against storing private keys as much as you can. These are considered secret.
However, it seems like JWK is about the public keys (as opposed to the private keys) - and these are okay to store. I'd just make sure they can't be replaced by anyone without proper permissions
Should I store private keys in PEM or JWK JSON format?
The main reason for choosing one format or the other mainly depends on the application/library needs.
In general, you want to avoid unnecessary conversion on runtime and serve directly on the required format.
For cross-platform; it is ok to store and use JWK in the JSON format?
Can you elaborate more on this use case?
Do I need to encrypt them before storing it in a database?
Not necessarily. As you tagged this question with [jwe], I understand that the private key is used to decrypt the token you receive.
If this is is stored on a backend server, the risk of key leak is low and if you encrypt it you will undoubtedly need to store the decryption key somewhere that you should also store securely. This has no benefit and you will be required to decrypt it each time you want to use it and thus use CPU time for nothing.
Note that storing private keys in a database is not recommended. It should be stored as a file on the server or set as an env var.
If the private key is stored on a roaming device (smartphone, PC...), it is highly recommended to encrypt it has those devices are considered less secured because of physical attacks. They usually provide convenient ways to encrypt such keys (Android keystore, IOS Keychain, Windows keystore and certificate...).
Related
So, I'm building an application for MTLS authentication and generate X509 certificates using AWS ACM PCA and bundle them together with a private key in PKCS#12 format.
At the moment I generate key pairs programatically in Java which are never stored.
But since I'm not a security expert I thought maybe it's better to use AWS KMS for creating key pairs.
So, it seem like what I need is a CMK which can generate data key pairs which are stored in KMS.
If they're stored in KMS and I can fetch the private key at any time, how is that more secure than not storing it at all?
Or is the purpose of KMS only to store keys securely?
If you have a use for the encrypted private key that kms.generateDataKeyPair will provide, then it would be of use. It would also be a nice way to ensure that your keys are being generated securely (secure randomness, etc).
It’s important to note, KMS will not store the generated key pair. The idea is that you would store the plaintext public key, and the encrypted private key, and call kms.decrypt to turn the encrypted private key into plaintext whenever you need it.
Can anyone explain how to encrypt id using eloquent.Present i am using thirdparty library to encrypt and decrypt id.I want know how to encrypt and decrypt ids using eloquent orm in slim.
Encrypting ids is a terrible idea. It doesn't provide any security and is bad for performance.
Encryption is only meant for sensitive data (e.g. credit card numbers). Ids are just unique identifiers and don't contain any sensitive information (or least shouldn't). If you need an identifier for a private URL, generate a random token and store it in a separate column.
Encrypting an integer with Laravel gives you a string with ~190 characters. You shouldn't use that as a primary/foreign key.
Since Laravel's encrypter uses CBC Mode, encrypting the same value gives you a different result each time. So you can't use Model::find($id) to retrieve an entry from the database. You would have to fetch and decrypt all ids to find the right one.
I assume that this is possible based on the fact that both utilize RSA for encryption. I should be able to read X.509 and store it as a new OpenPGP key.
The collaborator of my software needs OpenPGP.
Another collaborator provides X.509.
I am looking for a way to convert the keys.
Is that possible, how would one do that?
The short version: you can somewhat, but there is rarely good use in doing so.
You can extract the numbers forming the key and theoretically put together a new X.509 and/or OpenPGP key from them, but those would still remain incompatible, different keys in the respective system. Actually, the monkeysphere project brings tools for both directions (openpgp2pem and pem2openpgp, but make sure to read the rest of the post before heading out and converting keys).
Both X.509 and OpenPGP are more than a file format for keys: they add (incompatible) options for key management and certification, metadata, identifiers, ... Also, both systems use slightly different cryptographic modes of operation, and have very different (and thus incompatible) formats for encrypted and signed messages. They even have enormous differences in how certifications are handled (hierarchical structure in case of X.509 vs. an arbitrary graph in case of OpenPGP).
With other words: anything you do with the X.509 "representation" of an OpenPGP key sharing the same RSA primes cannot be used with the OpenPGP variant, and the other way round. Certificates issued in one system don't work in the other (and cannot be converted!).
As both keys "representations" are incompatible anyway and have to be managed separately, I would strongly recommend to create different sets of keys from beginning. After all, this adds another layer of security in case one of the keys is breached, as the other key stayed undamaged. Apart from performing unusual operations is always error-prone and suspicious to follow-up issues.
There might be good use cases, for example the monkeysphere project requires those conversions for authenticating SSH connection through OpenPGP keys. But I would not consider general usage for signing and encrypting messages and files a good use case for the reasons given above.
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.