Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Did you not read the next sentence? "Implementations MAY accept longer keys.". It should say "of at least 2048 bits", I'll update the docs.


I did, but it doesn't make sense in the context of the first one (it doesn't matter that peers may accept longer keys if everyone must use 2048 bit keys). But with your correction it makes sense.

I'm still interested in the reasoning behind accepting 2048 bit RSA keys instead of setting a 3072 bit minimum, which corresponds to AES128 in security[1][2].

[1] http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_p... (Page 64, Table 2)

[2] http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/k...


Quite many seems to be using 2048 bits RSA-keys for SSL- certicaties:

openssl s_client -connect www.google.com:443 Server public key is 2048 bit openssl s_client -connect www.twitter.com:443 Server public key is 2048 bit openssl s_client -connect www.hsbc.com:443 Server public key is 2048 bit openssl s_client -connect www.citibank.com:443 Server public key is 2048 bit

I don't know the limitations in all the legacy bank systems around the world, but I know my personal OpenPGP smart-card is limited to 3072 bits, but that card is quite modern. Maybe the limits for legacy systems is even worse.

The System Design supports multiple keys per bank, so if a stronger key length is required, keys can easily be upgraded in the future.

But, I agree the strongest key length possible should be used if possible, which is 4096 bits according to the OpenPGP specs.

We will update the specs accordingly.

If any bank for some reason cannot support 4096 bits, then I think it's fair to require at least 2048 bits, as that key length is used by a lot of high profile websites, including banks, already today. (see above list)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: