SyntaxError: invalid token
opened this issue · comments
Hi,
Happened upon your code looking for gpg best practices; intrigued by the 8192bit RSA.
Sadly discovered a glitch; is it a Python 2 piece of code? I don't l know enough about Python to tell.
I'm running on a stock ArchLinux system on this machine.
~ ❯❯❯ python ./Downloads/gpg-keygen.py master ✱ ◼
File "./Downloads/gpg-keygen.py", line 53
os.makedirs(path, mode = 0700)
^
SyntaxError: invalid token
~ ❯❯❯ python --version ⏎ master ✱ ◼
Python 3.4.3
Let me know if there's anything I can do to help.
hi!
that script only runs on pything 2.7. i already have a local version that is updated to run using python3.
as a sidenote: i've been updating my knowledge because of the new gnupg 2.1 release, and some of these "best practices" in my notes need to be amended. especially if you are looking for a strong key, then apparently using RSA beyond 2048, or maybe 4096, is pretty much pointless (newer gnupg versions also reject the gen key request for 8k keys). they recommend using the new ECC algorithm, but it's very new (which means others will have a headache if their programs don't support it).
i think the best of both worlds would be to generate an ECC master signing key (which is mostly only needed by you, except when you sign other people's keys), and use some more conservative subkeys that interoperate better with old/other tools.
i'll soon update the readme along these lines, and hopefully the script, too.
Thank you for your reply!
The rejection of 8k+ (RSA) keys is apparently down to something else, I thought: "--enable-large-rsa With –gen-key and –batch, enable the creation of larger RSA secret keys than is generally recommended (up to 8192 bits). These large keys are more expensive to use, and their signatures and certifications are also larger." ( https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html )
ArchLinux doesn't have the appropriate options turned on in the compile, so this CL options fails. (I'm usually a Exherbo desktop man).
That doesn't mean that you are not correct!
I think that ECC keys are the future too but there is as yet no RFC and people are running shy of the NIST bias ones:
"For many people the NIST and also the Brainpool curves have an doubtful origin and thus the plan for GnuPG is to use Bernstein’s Curve 25519 as default. GnuPG 2.1.0 already comes with support for signing keys using the Ed25519 variant of this curve. This has not yet been standardized by the IETF (i.e. there is no RFC) but we won’t wait any longer and go ahead using the proposed format for this signing algorithm. The format for an encryption key has not yet been finalized and will be added to GnuPG in one of the next point releases." ( https://www.gnupg.org/faq/whats-new-in-2.1.html#ecc )
re 8k keys: i have this in my local version of the readme, waiting for commit:
- The security of RSA keys does not scale well beyond 2048 bits, use ECC instead as recommended.
if you follow the link, they say:
RSA-2048 gives roughly 112 bits of security and RSA-3072 gives roughly 128. There is no formal recommendation on where RSA-4096 lies, but the general consensus is that it would come in somewhere around 140 bits — 28 bits of improvement over RSA-2048. This is an improvement so marginal that it’s really not worth mentioning.
AFAIU, the complexity of cracking RSA keys saturates after a large enough key, and even 4k keys are already giving only marginal extra protection while they bring compatibility issues and unnecessarily makes the keyblocks large (think of keyservers, etc).
Each additional bit gives correspondingly less in the way of additional security, and we quickly reach a point of diminishing returns. That point of diminishing returns happens around RSA-2048. Once you move past RSA-2048, you’re really not gaining very much.
Interesting, thank you! Closing.