Default to 2048-bit RSA now #3455
Conversation
1024-bit RSA has been disallowed by our underlying libraries for a while now. We should choose a better default. Currently 2048-bit works with DEFAULT and FIPS, but FUTURE is defaulting to 3072. It isn't immediately clear when FUTURE will become default, but we can always update again later when that occurs. Signed-off-by: Alexander Scheel <ascheel@redhat.com>
cipherboy
force-pushed
the
better-rsa-key-sizes
branch
from
64f1976
to
edbc59c
Compare
| @@ -17,7 +17,7 @@ Token profiles are defined using properties in the TPS configuration file. | |||
| The following property sets the size of the key the token should generate: | |||
|
|
|||
| ``` | |||
| op.enroll.<tokenType>.keyGen.<keyType>.keySize=1024 | |||
| op.enroll.<tokenType>.keyGen.<keyType>.keySize=2048 | |||
| ``` | |||
|
|
|||
| The maximum value is 1024. | |||
There was a problem hiding this comment.
I'm not familiar with this, but if the maximum value is referring to the keySize parameter, would they be contradictory now?
There was a problem hiding this comment.
Maybe it depends on the key type? DSA has a strict 1024-bit maximum, ECDSA obviously differs based on curve type/size and isn't user controllable, and for RSA, most implementations top out around 8192-bit ish.
There was a problem hiding this comment.
The valid algorithms are:
- 2 - RSA
- 5 - ECC
For ECC, the valid key sizes are 256 and 384.
There was a problem hiding this comment.
Or maybe this line should just be removed, and let the actual maximum be determined by the crypto library.
|
@jmagne , my memory may be a bit hazy on this, but wasn't there a time when some smart cards had issues with 2048 and that's why we set the default to be 1024 in TPS? |
1024-bit RSA has been disallowed by our underlying libraries for a while
now. We should choose a better default. Currently 2048-bit works with
DEFAULTandFIPS, butFUTUREis defaulting to 3072. It isn't immediatelyclear when
FUTUREwill become default, but we can always update againlater when that occurs.
Signed-off-by: Alexander Scheel <ascheel@redhat.com>