how to generate long keys?
Is there a way to generate long key? Like 16384 bit? GUI allows for 2048-4096 bits.
Comments are currently closed for this discussion. You can start a new one.
|?||Show this help|
|ESC||Blurs the current field|
|r||Focus the comment reply box|
|^ + ↩||Submit the comment|
You can use
Command ⌘ instead of
Control ^ on Mac
Support Staff 1 Posted by Steve on 29 Mar, 2015 05:35 PM
we follow the gnupg defaults. I've never even heard of 16k bit keys in the field so far. If you want to discuss key length and feel unsecure about 4k keys, the gnupg users mailing list is the place to discuss your concerns: http://lists.gnupg.org/mailman/listinfo/gnupg-users
All the best,
2 Posted by Ben on 03 Apr, 2015 05:26 AM
GPG 2.0.x should be able to create 8192-bit keys on the command line with the expert settings enabled by default, but no higher without modification. GPG 2.1.x has optional settings at compile time to raise the maximum key size. GPG 1.4.x needs to modify the source code (in 2 files) to raise both the maximum key size and the secure memory allocation. You should only do that if you really know what you're doing (which is why I'm not naming the files on this forum ... and, yes, I've done it).
Oh, by the way Steve, 16K keys have been around since the mid-1990s, beginning with the PGP 2.6ckt versions (a fork of the PGPi releases by a group of cypherpunks calling themselves the Cyber-Knights Templar). Back then it took them hours, sometimes days, to generate each key on 386 and 486 systems.
3 Posted by Ben on 03 Apr, 2015 11:51 AM
Erm, allow me to correct myself here: GPG 2.1.2 still needs bits of the source be modified prior to compiling it, but only for the maximum key size, the secure memory is still just a configure option.
That said, it's probably not worth the effort for email. It may be worth it to a small number of people for file encryption (which is why I bother going to the effort). Plus it will be largely a moot issue when we all shift over to ECC keys for encryption once that part is implemented in GPG 2.1.x. Especially since key generation only runs on a single core of modern systems and will still take ages (on the plus side, that means you can still do other things while that happens).
Anyway, though it can be done with 2.1 (and presumably 2.0 too, but I skipped that), it's a lot easier with 1.4.x (assuming you know which bits of the source to change). Mainly because 2.0 and 2.1 bring gpg-agent into the key generation process, which may impose its own limits on creating the largest key sizes (i.e. anything over 8K). Whereas 1.4.x will (or can) ignore that entire segment of code and just throw itself at the task until it's done. Not that it really matters that much, if anyone here is facing opposition the likes of which justify generating 16384-bit keys then they'll get you some other way (either technically through some other attack vector or emotionally through pressuring your friends and/or family).
4 Posted by _owl on 05 Apr, 2015 03:54 PM
Thanks a lot Ben, your posts are really helpful. I think I'd try to recompile 1.4.x with those modifications, so I'd appreciate if you drop me a line on what specific files I shell modify and what modifications I shell make ([email blocked]). I assume it's possible to do under OSX, right? May be there's some step by step how to for that? I remember I saw one for Win32 platform.
My idea is to make really long key and use it for signing, probably not for encryption. Use HRNG, make the key on trusted air gaped platform, store it on Token. Collect really many signatures and make it verifiable through WOT. Keep it for decades. And use it to sign other (may be shorter) keys designated for encryption, which can be changed really often, may be once a week or so, to facilitate forward secrecy. What you think?
5 Posted by Ben on 05 Apr, 2015 04:29 PM
It wn't work because there are no card readers or tokens which support
key sizes above 4096-bit. In fact, for a long time there weren't any
which could handle keys larger than 3072-bit, which is also the upper
limit for DSA2 keys (and incidentally the minimum strength for
asymmetric encryption of "Five Eyes" information classified as SECRET).
Steve closed this discussion on 14 Aug, 2015 12:55 PM.