Encrypting just using a passphrase, asymmetric encryption and combining both

Hi,

as I understand assymetric encryption it works with two keys, which are used to ensure that only the one user who has a specific key is able to decrypt the file/message.

There are different checkboxes inside the gui.

  1. It is possible to encrypt with the personal public key. So decryption is possible with the private key I own. Got it.

  2. It is possible to add someone else. So it means to me the encrypted object can be “shared” with someone else. Is that true?

  3. It is possible to just encrypt by passphrase. It is possible to decrypt just by entering a formerly defined passphrase. I - guess - it’s done by symmetric encryption as there are no “two keys”.

4 )It’s possible to combine all of these options.

I am a bit confused about how option 2, 3 and 4 work and I’d like to understand the technical backround. l would like to use option 3 as a fallback solution as not all people are familiar to gpg. How save is it? Do I have different options for symmetric encryption?

Thanks in advance
Philipp

Hi,

You have it mostly right. But I think some background would help you.

OpenPGP and S/MIME both use a mixed encryption scheme. All data is encrypted with a symmetric algorithm. The secret to decrypt that data is called the “Session Key”. Imagine the “Session key” as a 128bit random number. (For AES-128) That is 2^128 so there are a lot of possible session keys :wink: (So this is considered secure.)

That session key is the secret someone needs to know to decrypt the data.

Usually the session key is then encrypted using an assymetric (public / private) key encryption scheme.

So lets look at your cases.

  1. The session key is encrypted with your public key and added to the encrypted data (we call this a “packet”). You can decrypt that session key with your private key and so can decrypt the data.

2.) Just like with your own an additional “packet” is added where the session key is encrypted with someone elses public key. There can be as many additional packets as you like. There is one for each recipient. All containing the same “session key” as the secret information.

3.) In that case the session key is indeed encrypted symetrically with another “128bit” long number which is derived in a specified manner from the string you enter as the passphrase. It is just another “packet”.

4.) Yes the symettrically encrypted packet can be added just like any other packet. I think it might be possible (although we don’t support that) in theory to encrypt the same data with multiple passphrases. As any passphrase is just a packet containing, you guessed it, the session key ;-).

As for “different options” there is the possibility to configure the algorithms used under the hood. But our defaults are state of the art and you should not worry about the algorithms. The “Math” is not the problem in crypto, it is more operational security etc. (oversimplified: https://xkcd.com/538/ :wink: )

Using a passphrase means that it will be easier to decrypt your session key then using public / private (asymmetric) encryption. An attacker would only need to guess or capture your passphrase and it is much easier to break most passphrases then it is to break RSA encryption.

But for more details, wikipedia has some good articles etc :wink: Just to summarize: Passphrase is less secure then public / private key encryption.

Hope this helped.

Andre

Hi Andre,

thank you so much for your explanation! I understand the session key and packet concept now. As I don’t seem to have to worry about what’s going on “under the hood” (though I even tried to read and understand the documentation ;)), I’d like to ask one last question. As long as I use a passphrase which is hard enough to guess like “KjeuF8:LJ)cvVM]>” or anything similar, it would be hard to impossible to decrypt?

Kind regards
Philipp

Hi,

I’ve searched for “password entropy checker” and http://rumkin.com/tools/password/passchk.php came out with 85.2bits. That means that it is a very strong passphrase. I would consider it secure. Maybe not for stuff that will be relevant / needs to be protected 10 years from now. But even then it will probably be very expensive to break.

Best Regards,
Andre