On Thu, 2015-05-21 at 13:59 +0100, Matthew Vernon wrote: 
> bits  count
> 1023  36
> 1535  32
I'd remove at least these completely.

> 2047  28
This I'd keep probably only with a warning (according to ECRYPT II it's
only safe in the range to aat best 2020-2030

> 3071  26
Still below "Long term protection", according to ECRYPT II

> 4095  31
> 6143  20
> 8191   6
More of these!


> A colleague reports that generating new 2047-bit moduli takes a few
> minutes, and that time taking scales non-linearly with length (~90
> minutes for 4095, ~40 hours for 8191). So I'm not sure if we should
> make some newer larger moduli and start shipping them, and/or start
> generating some at install time; the latter feels too invasive to me. 
It shouldn't be a problem if the groups are pre-competed (and thus known
to the attacker).


> iii) it's less clear what to do about the weaker KexAlgorithms -
> diffie-hellman-group1-sha1 uses Oakley Group 2 (1024 bits) and
> diffie-hellman-group14-sha1 uses Oakley Group 14 (2048 bits); RFC4253
> says that implementations MUST support these, and I don't know what
> clients might break if we were to stop doing so.
They should be kept in the client/server, but disabled per default (not
via patching the hardcoded defaults, but via a custom ssh[d]_config
file).

Or even better, they should be disabled upstream per default and
enabling them should be only possible when e.g. specifying some
"--allow-unsafe-algos" parameter as option to ssh[d].


> I'd be interested to hear the opinions of the other openssh
> maintainers, and perhaps we should ask upstream for their views (I've
> not seen anything on the upstream dev list as yet).
I've did that some months ago and as mentioned before I've even opened
bug reports about the related issues,... but there seems to be little
willingness to work on this issue.

Apparently focus is more on CSH (having a _C_ompatbile SH) than SSH
(having a _S_ecure SH)... but that seems to match Debian's security
philosophy quite well =)


Cheers,
Chris.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to