# Symmetric versus asymmetric self encryption

I can encrypt my files with a symmetric encryption algorithm like AES, or with an asymmetric encryption algorithm like RSA or ECC (I encrypt my files with my own public key). No communication is involved in this scenario. The latter, which one may call asymmetric self encryption, might seem an unusual choice in situations where a key exchange is not required. However, it still does have some advantages: you don't need to type your passphrase for encryption (you need your public key); it works well with keys stored in a hardware token; also, an attacker apparently needs both to have the public key and brute-force the passphrase to decrypt the data. In GnuPG, these two encryptions are achieved via options gpg -c and gpg -e -r USERNAME.

Considering attacks on the asymmetric encryption, does hiding the public key increase the entropy required for a brute force attack? What information does the public key leak to the attacker?

The standard algorithms for symmetric and asymmetric encryption are AES-256, 4098-bit RSA. The answer to the above question helps compare the security level of these algorithms (in terms of the number of bits that needs to be checked).

• I know I don't need to hide the public key (which is on servers). The question 1 was, can you decrypt my data with (i) encrypted data plus public key, any faster than with (ii) encrypted data only. The answer is Yes or No. Mar 15 '20 at 16:03
• I also know the hybrid encryption is used (data encrypted with ASE with a random key that is encrypted and exchanged with RSA). The question remains. You may assume the data is empty, ifs the ASE part bothers you (exchange of an encrypted random key with RSA). I am looking for cryptoanalysis. Mar 15 '20 at 16:06
• Perhaps a duplicate, or partial duplicate: crypto.stackexchange.com/a/47993 Mar 15 '20 at 17:27
• @user77251 Point number 2 introduces a separate series of questions. Mar 15 '20 at 17:33
• OK, I removed the second question (on the comparison of the RSA with elliptic curve cryptography such as Curve25519). Mar 15 '20 at 20:48

called asymmetric self encryption

No, not really, you just made up that term.

might seem an unusual choice in situations where a key exchange is not required

No it doesn't, although commonly a hybrid cryptography is used, especially for EC based cryptography.

an attacker apparently needs both to have the public key and brute-force the passphrase to decrypt the data.

Of course not, the attacker requires the encrypted private key and a password to unwrap that key using password based encryption (PBE).

Considering attacks on the asymmetric encryption, does hiding the public key increase the entropy required for a brute force attack? What information does the public key provide to the attacker?

Possibly, but the scheme should of course be secure even if the public key is known to the attacker. Generally the public key is not considered a secret, and that means schemes, but also the implementations of the public key operations are not protected against leaking the public key.

The standard algorithms for symmetric and asymmetric encryption are AES-256, 4098-bit RSA. The answer to the above question helps compare the security level of these algorithms.

No, it really doesn't. In some situations asymmetric cryptography may be more secure, even though the key strength of the symmetric encryption is larger than the key strength of asymmetric encryption. However, it is impossible to quantify that advantage, so you cannot talk about a "level".

• I made some terminology edits. (1) Strictly speaking, even without an encrypted private key, an attacker could still use the same algorithm to produce all pairs of public and (unencrypted) private keys and try private keys. Sure, that probably takes too much time. (2) You can define the security level as the number of bits needed to crack them by brute force. It seems that you are saying the public key does not leak any information about the secret key. In other words, I could use my public key on servers for "self encryption" and don't need to generate new (sub) keys. Mar 16 '20 at 7:18
• I've clean up my comments. Maybe you can do more. Mar 17 '20 at 21:31

an attacker apparently needs both to have the public key and brute-force the passphrase to decrypt the data.

Uh, no. The only way the passphrase helps the attacker is if s/he gets the file (often named secring) containing the private key, which in this file is encrypted using the passphrase. It is very useful to keep that file secret, especially if the passphrase is weak or/and the s2k parameters of PGP/GPG are set poorly (a common error).

What information does the public key provide to the attacker?

It gives a way to find (a functional equivalent of the) private key without both the private key file and (a guess of) the passphrase; but (if things work as intended and parameters are chosen large, e.g. 4096-bit RSA), that's only with so enormous computational power that it is believed not feasible by harnessing the power of all computer gear ever made.

Does hiding the public key increase the entropy required for a brute force attack?

Note: Entropy is what fair coin throws give. More does not help to an attacker. Work is meant.

The file with the public key (often named pubring) is of relatively little interest to an attacker. Yes, there are some attacks (most notably, with RSA, factorization of the public modulus in the public key) that recover (a functional equivalent of) the private key from the public key. But when using appropriate parameters (see above), they are typically a negligible threat compared to passphrase enumeration as possible with the passphrase-encrypted private key file. These attacks using the public key are typically (and rightly) discounted, as are attacks that recover the plaintext without needing the public or private key by finding the ephemeral symmetric key.

For asymmetric encryption to self using PGP for automated backup of an autonomous system like a server, simply generate the public/private key pair on an independent machine, and bring only the public key to the system that needs backup. Bring the private key only if/when the disaster recovery procedure requires restoration of the data on the original system (my preferred disaster recovery strategy is to restart from a clean system, hence the private key is not needed on systems as used day-to-day).

• Thanks! In terms of n = pq, where p and q are prime numbers, if I have a public and secret key, how can I find numerical values for n, p and q? That helps clarify it.
– eli
Apr 17 '20 at 15:06
• @eli: if you have an exported openpgp RSA public key as a file testpub.asc, and gpg, then the command gpg --list-packets --verbose testpub.asc will show what's in there. pkey[0] is $n$, pkey[1] is $e$ (they are shown in hex). That works similarly with a private key saved without passphrase.
– fgrieu
Apr 17 '20 at 15:18
• Cool! So the pubic key reveals n and e. That actually helps an adversary quit a lot (otherwise they have to search over n and e, which is a non-negligible cost).
– eli
Apr 17 '20 at 15:56