I am trying to get my head over this and hope someone can explain what is happening. I have a PGP key pair from which I encrypted a message after specifying the cipher algorithm like AES_128, AES_192 or TWOFISH. Later, I tried to decrypt that encrypted message using a different cipher algorithm and I could still see the message.
How is this possible if I am encrypting a message using cipher AES_128 then how is it getting decrypted using the CAST5 cipher algorithm? I was expecting it to fail or at least get some garbage data however I could see the exact plain text that I encrypted in the first place.
Related
With GPGME, how would I check if I can decrypt a given secret with the current keychain.
I can attempt decryption with gpgme_op_decrypt and catch GPG_ERR_NO_SECKEY errors, but this seems non-optimal, nor do I know if this covers all cases.
Is there can_decrypt function, do_we_own_decrypt_key_for_secret or alike?
Also, can I list the secret recipients without decrypting the secret, that could help with this issue.
I have developed an encryption solution which is based on Hybrid Encryption as:
Sender end:
The message hash will be calculated.
Hash will be signed with private key of sender.
Hash will be encrypted with private key of sender.
A symmetric key will be generated.
Symmetric key will encrypt the message.
Symmetric key will then be encrypted with public key of receiver.
Recevier end:
Decryption of Hash with public key of sender.
Verification of sign with public key of sender.
Decryption of Symmetric key with private key of receiver.
Decryption of message with Symmetric key.
Now I want to save the hash in a file, the digital sign in a file, key encryption in file, actual message encrypted in a file and the key pairs.
In what file type shall I save all of these?
whether it shall be a CSV, TXT file or something else?
I have to keep the keys secure and the digital signature too..
Please guide!
As for the sender: Steps 1, 2 and 3 are commonly combined into a single signature generation operation. You don't do them separately. The same for step 1 and 2 of the receiver for signature verification (where you are missing the hashing step of the message, by the way).
Modern cryptography is based on bytes, so generally you define a single binary container format so that you don't have to expand the ciphertext (compared to the plaintext) needlessly. Such a container can contain multiple values: encrypted key, and encrypted content that consists of the message and signature. Generally there is also a header containing a version string and an ID of the required keys to name just a few.
Of course many container formats have been defined for the hybrid cryptography that you're currently using, with CMS (with a hierarchical PKI) and (Open)PGP (with a web-of-trust based PKI) being the most well known ones.
Otherwise it is up to you. Generally you'd encode the ciphertext / signatures using base 64 if you require text based storage. Do include a version string somewhere in the header and create a document to describe your protocol.
I am trying to understand the following:
Why should a message digest in cryptography be encrypted with the private key from the sender?
The receiver can decrypt it with the public key of the sender, but anyone else can do that too. Even the man in the middle, so I don't really see the point of encrypting the message digest in the sense of Digital Signature.
Try to separate encryption and signing. Even mathematically they are similar operations, there are some important differences. I will try to summarize basics
mesaage and uses his own private key to encrypt the message digest
Actually - person A creates a hash of the content and signs the hash. It means executing a decryption operation with signing padding with its private key, creating a signature
Now person B will make a hash value of the message to compare it to the message digest.
And this is wrong. Whoever (any attacker) could modify/falsify the content and create a valid digest.
Person B
creates a hash value of the content
validates the provided signature - encrypts the provided signature with A's public key which should result to the hash and signing padding
but anyone else can do that too
Signing ensures, that only A could sign the mesage digest, because only with private key you could "decrypt" - create an output, which after "encryption" could lead to some specific value (digest).
It is as well important to use full specification for RSA operations (PSS padding), not text-book RSA (without nonce and padding). Otherwise if some could trick A to decrypt any input, leading to creating a signature or revealing the private key.
Edit:
why isnt it enoug to encrypt with pulic key
Encrypting ensures, that only the addressee could decrypt the message, but it doesn't say who is sending the message. (A can believe that only B reads the message, but B may not be sure it is a message from A)
Signing undeniably identifies the sender. (B can be sure the message is sent by A)
There are some caveats in this approach (signing a directly encrypted message), but details could be better explained in the crypto OS forum.
According to the documentation the gpgme_op_encrypt method of GPGME is able to perform symmetric encryption tasks:
gpgme_op_encrypt (gpgme_ctx_t ctx, gpgme_key_t recp[], gpgme_encrypt_flags_t flags, gpgme_data_t plain, gpgme_data_t cipher)
If recp is NULL, symmetric rather than public key encryption is
performed. Symmetrically encrypted cipher text can be deciphered with
gpgme_op_decrypt. Note that in this case the crypto backend needs to
retrieve a passphrase from the user. Symmetric encryption is currently
only supported for the OpenPGP crypto backend.
But where does the key used for the symmetric encryption come from? Is it somehow possible to fetch this key and transfer it to another device (where I would like to decrypt the text) ?
The session key for symmetric encryption is derived from a passphrase, which will be queried from the user through one of the pinentry methods. Specifically highlighting a part of the text you already quoted:
If recp is NULL, symmetric rather than public key encryption is performed. Symmetrically encrypted cipher text can be deciphered with gpgme_op_decrypt. Note that in this case the crypto backend needs to retrieve a passphrase from the user. Symmetric encryption is currently only supported for the OpenPGP crypto backend.
I'm not aware you can extract the session key through GPGME, but you don't really need to: all you need to know at the other end is the passphrase used, and the session key can be derived again. You could of course also reimplement the string-to-key-function used for OpenPGP.
I have asked a similar question in post Encrypting a file with RSA in Python , but this question has a different connotation.
I am encrypting a file with AES, using RSA to encrypt the AES password.
The only difference is that i really DON'T want to store the AES password. The user must give both the path to his RSA key, and the password.
So what do you think about this scheme?
path_to_RSA_key = ... # Given by the user
pwd = ... # This will be used to encrypt the file. Also given by user.
rsa_enc = RSA.importKey(path_to_RSA_key)
# Encrypt the Password with RSA, keep the last 32 characters
rsa_pwd = rsa_enc.encrypt(pwd)[-32:]
# Aes, with the encrypted password
aes_enc = AES.new(rsa_pwd, AES.MODE_CBC)
# Encrypt the file with AES...
# Store only the encrypted file
# Don't store the password in any way, don't store the path to RSA key
The alternative would be the classic scheme, when you generate a random password, encrypt the file with AES using the random pass, encrypt the random pwd with RSA and store only the encrypted results.
If you really need to know why i need this, it's a project of mine, http://code.google.com/p/scrambled-egg
What do you think about the scheme ? Thank you in advance !
There seems to be some confusion. You mention that you don't want to store the 'password', but you're working with RSA and not a symmetric algorithm. The term 'password' strongly implies a shared secret as used in symmetric encryption, and it appears that you're trying really hard to fit RSA into the mould you've created.
The issue I see is that this functionality may not fit into your planned use very well. Your plan seems focused on symmetric ciphers. Further, using asymmetric keys this way may be a problem. I think asymmetric encryption is used to encrypt nonces for a reason; it may not be robust to attacks that can be waged against a scheme like the one you propose.
Asymmetric keys are often used as follows:
Generate a purely random 32-'character' key and call it "nonce".
Encrypt the message with the "nonce" and call it ciphertext.
Encrypt the "nonce" with your asymmetric key (presumably the public key, but you should specify).
The result consists of the ciphertext and the asymmetrically encrypted "nonce".
Decrypting requires only the paired opposite of the asymmetric key used to encrypt.
If you're hardcore, you could encrypt (using AES + a password or similar) the public or private key that can be used to decrypt the nonce and send it along for a ride too. Sadly that isn't really increasing security over AES+password, and you are increasing the bloat in your message by a lot.