On Thu 2019-04-11 15:56:50 +0200, schlifka@xxxxxxxxxxx wrote:
> Sometime ago min rsa key length was increased to 1024 bit and i have a
> little understanding problem with this.
> I hope somebody with some crypto-experience can enlighten me. To make
> that clear, that is not about allowing lower keys in general.
> Personally i would tend to use even longer keys(2048bit+).
> However Due nature of RSA-algorithm in case of 1024bit this might result
> in a key length of 1023 or 1024 bit.
if some RSA key generation algorithm is generating a 1023-bit key when
it is asked for a 1024-bit key, that implementation sounds buggy.
The generally-accepted understanding of a 1024-bit RSA key is one where
bit 1023 is set to 1 (and all higher bits are set to 0). (i'm assuming
that the LSB is "bit 0", so "bit 1023" is the 1024th bit)
a 1023-bit RSA key is one where bit 1022 is 1 and bit 1023 (and all
higher bits) are set to 0.
> By default with a RSA Min Key length of 1024 this means all 1023bit
> length keys are rejected, while there is no real advantage regarding the
> complexity of the key when enforcing 1024bit length only.
I think this is a "slippery slope" line of reasoning, which can be
extended against making any sort of cutoff -- clearly a bad outcome,
because we'd like to draw the line someplace. For example, 17-bit RSA
keys are clearly inappropriate for use on the public Internet.
1024-bit RSA keys are obsolescent at best today -- arguably we should
have a higher limit than 1024 itself (i wouldn't object to a 2048-bit
RSA cutoff by default, it's 2019!). And a "would-be 1024-bit" RSA keys
generated by a buggy implementation is probably below the threshhold of
what we want to tolerate.
does that make sense?
--dkg
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
