i have been using PGP. I need to safely store our PGP keyring for our application that will be processing some pgp files. Can I believe that the PGP is Asymmetric cryptography and i should be able to store the information for keyring in a key container?
PGP is a hybrid cryptographic system i.e it uses a mix of public/private asymmetric and standard symmetric encyption/decryption. It generates a unique session ID which it uses to encrypt the data it then encrypts the session ID with your public key. It then adds the asymetric encrypted session ID to the symmetric encrypted data to produce the final ciphertext
For decryption, the private key is used to decrypt the session ID and then standard symmetric decryption to retrieve the plain text.
PGP stores two sets of keyrings - public keyrings and private keyrings.
So if you shipped the private keyring with your app then anyone could use the private key to decrypt the pgp files.
Public/Private key security is not a magic bullet it still relies on the user keeping their private key or keyrings safe
Here's a good link on how PGP works in more depth
You should check and see if there is a OS-level keystore to use for that sort of thing. Rolling your own solution is error-prone. Besides, why re-invent the wheel if you don't have to?
Related
everybody.
Is it possible to perform public key encryption flow for elliptic-curve cryptography?
https://en.wikipedia.org/wiki/Public-key_cryptography
I need to implement the following scenario:
Alice generates a message.
Alice encrypts it with Bob's public key.
Alice sends a message to Bob (via an insecure channel).
Bob gets the message.
Bob can decrypt this message only with his private key.
I can't find a proper method inside the tweetnacl lib (https://github.com/dchest/tweetnacl-js). Could somebody can direct me in the right direction?
Thank you in advance.
You should be looking for an ECIES implementation. Here is a random JavaScript library that seems to support it.
Elliptic Curves do not support a encryption primitive like RSA does. There is EC ElGamal but is not worth it due to the small key sizes and the amount of overhead of ElGamal.
To use curves with encryption you need to use hybrid encryption. ECIES is hybrid encryption: offline ECDH key agreement together with symmetric encryption performed using the derived secret key.
Note that ECIES is not well standardized. You may have to choose your own key derivation function, stream cipher or block cipher and mode of operation. For the key derivation method you could choose HKDF where available. AES in GCM mode seems a sane choice today for the cipher (the 12 byte IV may be set to zero or to a value derived from the "shared secret" as well). Libraries that support ECIES will probably have their own idea on what ECIES should look like, but beware of compatibility issues...
Isn't the encryption method in the documentation that you linked to for tweetnacl-js?
https://github.com/dchest/tweetnacl-js#naclboxmessage-nonce-theirpublickey-mysecretkey
nacl.box(message, nonce, theirPublicKey, mySecretKey)
Encrypts and authenticates message using peer's public key, our secret key, and the given nonce, which must be unique for each distinct message for a key pair.
Returns an encrypted and authenticated message, which is nacl.box.overheadLength longer than the original message.
You would use the recipient's public key as the third argument to the above function. You would use your own private key as the fourth argument. The library takes care of message integrity by creating a signature of the encrypted message, signed by your private key.
I will suggest you go to an easy library that makes the work for you, I specially like the python ecdsa module (https://github.com/warner/python-ecdsa), is easy and not complicated. Also read about how EC works will help you in make your decision.
I'm trying to understand how JWT is implemented in a codebase that I'm reviewing. I read this and this
However, it seems in this codebase, the client has the private AND public key... It has the public key of the server and its own private key (I assume the server has the corresponding private key). Why is this necessary? Shouldn't the client only need the public key and the server only needs the private key? If the client is encrypting a message, can't it use the public key to encrypt it and the server just needs the private key to decrypt it? Conversely, can't it decrypt encrypted messages from the server with its public key? Why would the client need two sets of public and private keys?
From the reading:
To create a digital signature, signing software (such as an email program) creates a one-way hash of the electronic data to be signed. The user's private key is then used to encrypt the hash, returning a value that is unique to the hashed data. The encrypted hash, along with other information such as the hashing algorithm, forms the digital signature. Any change in the data, even to a single bit, results in a different hash value. This attribute enables others to validate the integrity of the data by using the signer's public key to decrypt the hash. If the decrypted hash matches a second computed hash of the same data, it proves that the data hasn't changed since it was signed.
What is the differnce between the hashed data and encrypted data? Why do you need to hash it first? Are hashed data encrypted?
Where doe that secon computed hash come from? If the decryptor is attempting to apply the public key to the encrypted data... how does it know it succeeded? What does it compare it to? Where does that comparison hash come from?
JWT is signed (not encrypted) with the private key of the sender. jWT content can be encrypted optionally using JWE.
A symmetric key is used to sign and verify. With an asymmetric key pair, the message is signed with private key and verified with the public.
A digital signature protects the message against alterations and identify the sender. An asymmetric key allows the receiver to verify the signature using sender's public key without compromise the private key
JWT signing can be used both in client or server side depending on the purpose. For example, in an authentication flow
client side: API requests, where the server validates signature with public key uploaded during registration
server side: issue tokens to final users after presenting credentials
Internally, a digital signature involves several cryptographic operations, digest the message, encrypt the hash and add the algorithm identifier. But you do not have to worry about this because all programming languages support it
I tried to explain JWT&digital signatures in a general way instead of answering your specific questions. I probably have left some. Please comment
This question already has answers here:
Whose key is used to encrypt a HTTPS response?
(3 answers)
Closed 4 years ago.
In the Public Key Cryptography all I know is that the public key in the server is to encrypt the message and the client which has the private key can decrypt that message which is fine.
The part which I don't understand is that as the server has only the public key to encrypt the message how it would decrypt the response from the client. I believe that the public can't be used to decrypt the response from the client.
Also how the client encrypts a message to the server as the private key is only used for decrypting the message and not for encrypting.
Sorry for my ignorance. I have searched the internet and somehow the answers to these are eluding from me.
Any help would be greatly appreciated.
Thanks,
Mohamed
If a server has only a public key it cannot decrypt a message from a client.
One more time, with the important vocab words in bold: If a server has only a public key it cannot decrypt a message from a client.
What the server is probably doing is verifying a message signed by the client.
In the case of SSH public key authentication (RFC 4252, section 7) it is a signature over the just-negotiated session ID and some context data (which requires the client to have the private key). The server can then run the signature verification algorithm (which only requires the public key). If a preregistered key checks out, the client is thus authenticated.
In the case of RSA keys the signing and decrypting operations look mathematically similar, which can cause some to use the terms loosely, but we should be precise.
Encrypt (public key): Transform content in such a way to occlude it from everyone except the intended recipient (the holder of the private key).
Common algorithms: RSA
In encryption the encrypted output REPLACES the original content in transmission.
Public Key Encryption is frequently used to encrypt a newly generated symmetric key which actually encrypts the data. For RSA the encrypted output is limited by the key size, symmetric algorithms have much larger maxima.
Decrypt (private key): Transform content from the Encrypt operation back into its original form.
Since anyone could have your public key, anyone can encrypt data for you.
Nothing is inherent in the Encrypt/Decrypt pair to establish trust... the message could be a poison pill, and you don't know who wrote it.
Sign (private key): Apply a transform over an input (which is usually a digest/hash of the true content) to produce a value no one else can.
Common algorithms: RSA, ECDSA, DSA
The signature is presented WITH the content, it does not replace it.
Verify (public key): Apply a transform over the input and the signature which results in a true or false.
If the digest is computed independently by the content receiver the signature proves that the content was not tampered.
When the signature is deemed correct it proves that it was generated by the key holder, which can be used in a trust decision. (The key could have been compromised, in which case "key holder" and "original key holder" could be different)
For RSA this is "unpack the digest using an algorithm similar to decrypt, then compare the digests", so an RSA implementation could indicate what the correct hash is.
For DSA and ECDSA the digest is used as a BigInteger in a formula that produces the second half of the signature from the first half, so DSA can't tell you what a correct digest value is.
I'm trying to implement licensing system for a software to prevent piracy.
For this I need to read a license file within the application, and I need to make sure this file is written by the owner company.
Asymmetric cryptography has good potential for this aim, but in other way around!
Asymmetric cryptography algorithms, like RSA, give you a Public key and a Private key which are used as follow:
Private keys are used to decrypt.
Public keys are used to encrypt.
But I need them like this:
Private keys to be used to encrypt.
Public keys to be used to decrypt.
A simplistic idea would be to switch the role of public and private keys, but there are posts saying that in RSA public keys can be generated from private ones which make this idea impractical.
So here's my question: Is there any asymmetric cryptography with reversed key roles?
If speaking about RSA public/private key pair can be used in both cases you described. When you use private key to encrypt then public key decrypts and vice-versa.
As you said public key can be derived from private key but not the other way.
If you want to prove the origin of licensing file, use RSA in signature mode. In signature mode a hash is computed from the data you want to protect and then encrypted using private key. The result -the digital signature - is appended to the protected data.
Verification process starts by decrypting the signature which gives you the hash. Then compute hash value from the data. Computed and decrypted value shall be the same.
There are a lot of libraries providing comfortable way of signature creation and verification. You can choose depending on the platform you use for your application development.
http://en.wikipedia.org/wiki/Digital_signature
I'm using VB.Net's RijndaelManaged (RM) to encrypt files, using the RM.GenerateKey and RM.GenerateIV methods to generate the Key and IV and encrypting the file using the CryptoStream class. I'm planning on saving this Key and IV to a file and want to make sure I'm doing it the right way. I am combining the IV+Key, and encrypting that with my RSA Public key and writing it out to a file. Then, to decrypt I use the RSA Private key on this file to get the IV+Key, split them up and set RM.Key and RM.IV to these values and run the decryptor.
Is this the best method to accomplish this, or is there a preferred method for saving the IV & Key?
That's the general idea. The IV does not need to be kept secret, however. Only the "secret key" is secret.
You might consider using a standard like S/MIME (or its underlying Cryptographic Message Syntax) for your file format. I'm not sure if Bouncycastle has ported their S/MIME (or PGP) libraries to .NET, or if .NET has S/MIME support built-in, but there is likely to be a free library available for your platform. A widely used open source library like this has probably been tested and scrutinized more closely than you'll be able to do yourself, and they implement protocols designed by experts in cryptography so your don't have to wonder what pitfalls you've overlooked.
The model you've described is similar to S/MIME's "KeyTransRecipientInfo" method for key exchange. A symmetric key is generated to encrypt the data, then that key is encrypted with the public key of each intended recipient. The encrypted key and the IV (which is not encrypted in this standard) are bundled with information about the algorithms used in a CMS structure. The encrypted data can be included in the same bundle, or be in an separate file.
PGP has mode that is an essentially equivalent.