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.
Related
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.
Hi Crypto experts out there, are there any best practices around distributing an ecnrypted package to multiple end user systems, specially if the end system are offline ones? in context of assymetric crypto.
is it must to create unique pub/pvt key sets [ per end user system] and encrypt the same package many times uniquely with the pub keys, resulting in a specific package per end user system? how will this scale?
will it be a good practice to sign the original private key[ corresponding to pub keys used to encrypt the package] with senders private keys and then enrypt using end user systems pub keys and share it directly with end user? through trusted communication.
or, encrypt the pvt key with end user systems public key, sign with senders private key and re-encrypt[symmetric] this with the hash of certain string uniquely identifying a end user system? This hash should be programtically reproducible using system unique identifiers later during decryption processes. This way, to retreive the original private key to decrypt the package, it will require both a corresponding pub key[end user clients] as well as end user machine [the hash of string to be generated at runtime on end user system.] and senders public key to manage the authenticity?
Thank you for any feedback!
I am not an expert, but as I understand asymmetric encryption, you can generate a key pair in the distribution center.
The private key stays secret in the distribution center.
To each offline client you provide the public key (as a file).
Each client generates a secure password for symmetric encryption, and encrypts it using the public key.
The encrypted symmetric key is sent to the distribution center.
The distribution center should associate the encrypted symmetric password to the client that sent it.
At the time of encrypting the package for the specific client, the distribution center will decrypt the symmetric password using the private key, and use it to encrypt the package.
Then the package can be sent to the client, who will use it's own password to decrypt the package.
I am attempting to develop a file encryption function using user entered passphrase. I am studying the example functions at the WiKi here , but don't understand how 'key' and 'iv' exactly work. By experimenting I found out that I only need the same key value to decrypt the file, but NOT the same iv! Indeed I used a random iv string while decrypting, and it decrypts just fine. I plan to generate the key from the sender's passphrase to share it with the file recipient, but I am not sure what to do with iv value? Does it need to be shared with the recipient and used to decrypt, or I can use a randomly generated value, or should I hardcode the value in the program for encryption and decryption? What is 'iv' is used for in this context?
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.