4 ms·

> Support for 4096-bit RSA keys has been in GnuPG for some time, but Koch contends that real security will require 16Kb keys [...] Could someone corroborate or

> Support for 4096-bit RSA keys has been in GnuPG for some time, but Koch contends that real security will require 16Kb keys [...] Could someone corroborate or cite sources? I thought 2048-bit is still considered secure, and 4096-bit slightly overkill.

ekianjo 9y ago
yes, is there any reliable place to look for the current "best" practices for keys generation? (as in, good enough for the foreseeable future)
- grawlinson 9y ago
  Similar, but slightly unrelated (SSH keys), I find this one of the best resources to look at: https://wiki.mozilla.org/Security/Guidelines/OpenSSH https://wiki.mozilla.org/Security/Guidelines/OpenSSH
- pfg 9y ago
  https://www.keylength.com/ https://www.keylength.com/ presents the recommendations from various best-practice documents for many key types and cryptographic operations.
  - RJIb8RBYxzAMX9u 9y ago
    If I'm using the comparison tool correctly, then it shows that 2048-bit keys would be fine up to 2020 ~ 2030, and 4096-bit keys beyond ~2022. This is in line with my understanding. FWIW, ssh-keygen(1) generates 2048-bit RSA keys by default[0]. Generally if I had to appeal to authority over security matters, I refer to the OpenBSD / OpenSSH guys. [0] https://man.openbsd.org/ssh-keygen#b https://man.openbsd.org/ssh-keygen#b
    - brians 9y ago
      SSH Keys are for login authentication. If tomorrow we crack RSA-2047, you can replace them before we get to 2048 bits. GPG Keys are for secrecy. If the adversary gets a ciphertext, he can hold it until 2030 and decrypt then. Very different model!
      - RJIb8RBYxzAMX9u 9y ago
        Hmm, good point.
      - foo101 9y ago
        I am not convinced they are very different models. My argument: An attacker can save the encrypted SSH traffic going over an insecure channel, then hold the traffic until 2030 and decrypt then. Do you find a flaw in my argument?
        heavenlyhash 9y ago
        Yes. It is, forgive me for being blunt, nearly completely wrong. For starters, there's two different kinds of keys in use: symmetric and asymmetric. The ratio of "bits" to "strength" is completely different for the two categories. Asymmetric keys are typically only used to handle identity, then bootstrap a selection of symmetric keys (which are faster to use, generally); and then the symmetric keys used are typically based on Diffie Hellman key exchange, which is a whole 'nother ball of wax. Which bits you have to hold onto, and what you get when you compromise them, is not a flat field. Compromising the asymmetric keys used for identity at the beginning of communication means you can forge that identity in the future; but it doesn't necessarily mean you get to compromise other communications made with yet other keys which were merely agreed upon under the situational aegis of those asymmetric keys at a previous date.
        cesarb 9y ago
        With encrypted SSH traffic, there are normally three kinds of keys involved. The traffic is encrypted with per-connection symmetric keys, usually 256 bits. These keys are obtained through a Diffie–Hellman key exchange or similar, which uses per-connection randomly-generated keys. Finally, the long-term "SSH key" is used to sign these randomly-generated keys (and other things). If you hold the traffic until 2030 and want to decrypt it, you have to break either the symmetric keys, or the key exchange. Breaking the "SSH key" would allow you only to forge a new signature, but that doesn't help decrypting past traffic. That's the difference between the models: a key used for encryption, once broken, allows you to decrypt. A key used for signing, once broken, allows only forgery. And for SSH, forgery must be done while the forged key is still accepted (known_hosts or authorized_keys).
    - theyregreat 9y ago
      Secure Secure Shell guide is a good security baseline, including generating long enough moduli and using EC. https://stribika.github.io/2015/01/04/secure-secure-shell.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht... In the future, recommendations will need to be increased and less secure methods deprecated.
- xelxebar 9y ago
  I don't know much about the curator, but nacl is apparently on the same domain: http://safecurves.cr.yp.to/ http://safecurves.cr.yp.to/
  - kqr 9y ago
    Daniel J. Bernstein or djb is a very well known crypto expert with no apparent secret agendas.
theyregreat 9y ago
Use 4096 for personal email or anything important. Other uses maybe fine with 2048. Slighly overkill is better than insufficiently expensive ASIC pwned.
colejohnson66 9y ago
Quantum computers?
- okket 9y ago
  Then 4096 keys are also worthless.
  - colejohnson66 9y ago
    Yeah, but are 16k keys? How does quantum factorization scale?
hannob 9y ago
> Could someone corroborate or cite sources? There aren't any. I was also quite surprised, not sure what Werner exactly said, but I doubt he wanted to seriously question RSA-2048. Also the various key length guides people like to cite where someone says "key length x bit is exactly secure until the year 2030" are usually nothing more than things people made up and they're not based on scientific sources. The state of RSA security is actually relatively clear: 2048 bit is secure against all existing classical attacks. It would require massive and unlikely mathematical breakthroughs to change that. If you add in quantum computers then RSA is pretty much broken with all normal key sizes (but ECC is as well). There's a difference between 2048 and 4096, but it probably doesn't matter that much in practice.

ekianjo 9y ago

yes, is there any reliable place to look for the current "best" practices for keys generation? (as in, good enough for the foreseeable future)

grawlinson 9y ago
Similar, but slightly unrelated (SSH keys), I find this one of the best resources to look at: https://wiki.mozilla.org/Security/Guidelines/OpenSSH https://wiki.mozilla.org/Security/Guidelines/OpenSSH
pfg 9y ago
https://www.keylength.com/ https://www.keylength.com/ presents the recommendations from various best-practice documents for many key types and cryptographic operations.
- RJIb8RBYxzAMX9u 9y ago
  If I'm using the comparison tool correctly, then it shows that 2048-bit keys would be fine up to 2020 ~ 2030, and 4096-bit keys beyond ~2022. This is in line with my understanding. FWIW, ssh-keygen(1) generates 2048-bit RSA keys by default[0]. Generally if I had to appeal to authority over security matters, I refer to the OpenBSD / OpenSSH guys. [0] https://man.openbsd.org/ssh-keygen#b https://man.openbsd.org/ssh-keygen#b
  - brians 9y ago
    SSH Keys are for login authentication. If tomorrow we crack RSA-2047, you can replace them before we get to 2048 bits. GPG Keys are for secrecy. If the adversary gets a ciphertext, he can hold it until 2030 and decrypt then. Very different model!
    - RJIb8RBYxzAMX9u 9y ago
      Hmm, good point.
    - foo101 9y ago
      I am not convinced they are very different models. My argument: An attacker can save the encrypted SSH traffic going over an insecure channel, then hold the traffic until 2030 and decrypt then. Do you find a flaw in my argument?
      - heavenlyhash 9y ago
        Yes. It is, forgive me for being blunt, nearly completely wrong. For starters, there's two different kinds of keys in use: symmetric and asymmetric. The ratio of "bits" to "strength" is completely different for the two categories. Asymmetric keys are typically only used to handle identity, then bootstrap a selection of symmetric keys (which are faster to use, generally); and then the symmetric keys used are typically based on Diffie Hellman key exchange, which is a whole 'nother ball of wax. Which bits you have to hold onto, and what you get when you compromise them, is not a flat field. Compromising the asymmetric keys used for identity at the beginning of communication means you can forge that identity in the future; but it doesn't necessarily mean you get to compromise other communications made with yet other keys which were merely agreed upon under the situational aegis of those asymmetric keys at a previous date.
      - cesarb 9y ago
        With encrypted SSH traffic, there are normally three kinds of keys involved. The traffic is encrypted with per-connection symmetric keys, usually 256 bits. These keys are obtained through a Diffie–Hellman key exchange or similar, which uses per-connection randomly-generated keys. Finally, the long-term "SSH key" is used to sign these randomly-generated keys (and other things). If you hold the traffic until 2030 and want to decrypt it, you have to break either the symmetric keys, or the key exchange. Breaking the "SSH key" would allow you only to forge a new signature, but that doesn't help decrypting past traffic. That's the difference between the models: a key used for encryption, once broken, allows you to decrypt. A key used for signing, once broken, allows only forgery. And for SSH, forgery must be done while the forged key is still accepted (known_hosts or authorized_keys).
  - theyregreat 9y ago
    Secure Secure Shell guide is a good security baseline, including generating long enough moduli and using EC. https://stribika.github.io/2015/01/04/secure-secure-shell.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht... In the future, recommendations will need to be increased and less secure methods deprecated.
xelxebar 9y ago
I don't know much about the curator, but nacl is apparently on the same domain: http://safecurves.cr.yp.to/ http://safecurves.cr.yp.to/
- kqr 9y ago
  Daniel J. Bernstein or djb is a very well known crypto expert with no apparent secret agendas.

theyregreat 9y ago

Use 4096 for personal email or anything important. Other uses maybe fine with 2048. Slighly overkill is better than insufficiently expensive ASIC pwned.

colejohnson66 9y ago

Quantum computers?

okket 9y ago
Then 4096 keys are also worthless.
- colejohnson66 9y ago
  Yeah, but are 16k keys? How does quantum factorization scale?

hannob 9y ago

> Could someone corroborate or cite sources? There aren't any. I was also quite surprised, not sure what Werner exactly said, but I doubt he wanted to seriously question RSA-2048. Also the various key length guides people like to cite where someone says "key length x bit is exactly secure until the year 2030" are usually nothing more than things people made up and they're not based on scientific sources. The state of RSA security is actually relatively clear: 2048 bit is secure against all existing classical attacks. It would require massive and unlikely mathematical breakthroughs to change that. If you add in quantum computers then RSA is pretty much broken with all normal key sizes (but ECC is as well). There's a difference between 2048 and 4096, but it probably doesn't matter that much in practice.