Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Nov 2015 09:41:59 +0300
Subject: Re: OpenSSH

On 2015-11-17 23:42:14 +0100, Pavel Kankovsky wrote:

 > Have you modified /etc/ssh/moduli (the list of groups for
 > diffie-hellman-group-exchange-*)? The developers seem to
 > have already eliminated all DH groups with a modulus shorter
 > than 2048 bits but a higher lower limit might be needed to
 > prevent the key exchange from being the weakest link.

Not yet, but will do that before releasing .src.rpm to public.

 > If NIST curves have been somehow manipulated then at least
 > one of the two following conditions would have to be true:
 > 1. There is a feasible preimage attack against SHA-1 that
 > makes it possible to turn "cooked" parameters back into an
 > X9.62 seed. (Note we are talking about preimages rather than
 > collisions here!)

Unlikely, but not impossible at all.

 > 2. The hypothetical "spectral weakness" is real, there exists
 > a sufficiently large subset of weak elliptical curves, and it
 > is feasible to find a weak curve by trial and error.

Very likely and, theoretically, possible.
However I can't neither prove nor refute that.

 > That said, SSH should probably support more curves, perhaps
 > even curves with arbitrary parameters (like TLS; see RFC 4492).

Both: more curves and longer keys.

 > But then again, there is also the recent Pythian announcement
 > by NSA that we need to get ready for the coming of quantum
 > computers and the resulting crypto-apocalypse...

We? Or our grandsons?

 >> It it notoriously difficult to compare the relative strength
 >> of symmetric and asymmetric crypto.  

They don't need to be compared, as they serve for different purposes.

 >> However, it's relatively simple to notice that every additional
 >> bit in a key would require at least two transistors (physical
 >> areas on the chip) just to store it and much more to process.
 > This is a correct observation... but also completely pointless
 > because the same thing holds for both an attacker and a legitimate
 > user and the whole point of cryptography is to make attacks much
 > more expensive than legitimate operations.

Where legitimate user performs computations once in a single thread,
attacker has to perform them many times in parallel.

 >>>> I think of disabling ED25519 [...] intentionally weakened by
 >>>> reducing the key size beyond good sence
 >>> As far as I know Ed25519 is able to provide approximately 128
 >>> BoS. [...]
 >> IIRC, the DSA used 1024-bit keys. Switching to the use of elliptic
 >> curves could be a good reason to keep the key size the same, but
 >> not to reduce it.
 > I am afraid you compare apples to oranges.

That's normal if you are interested in carbohydrates, vitamins etc.

 > First, let me note there are two size parameters in DSA
 > Let n denote log_2 of the order of the subgroup and l denote
 > log_2 p.
 > The complexity of some attacks depends on n (approx. 2^(n/2))
 > while the complexity of other attacks depends on l
 > Attacks of the first kind are more efficient in some cases,
 > attacks of the second kind in other cases and there are also
 > balanced cases where neither kind gets much advantage

Yes, obviously.

 > traditional DSA with n = 160 and l = 1024 is an example
 > of such balanced design providing cca 80 "bits of security".


Now it's considered weak and even is disabled in SSH by default.

 > There are some more efficient attacks against special and
 > presumably rare weak curves.

I doubt they are rare... most likely, only a small subset of all
curves is really strong.

 > Also, there is a recent attack by Bernstein & Lange that might
 > offer better *amortized* complexity but it does not seem to be
 > useful in any practical situation.


 > The order of Ed25519 is cca 2^252 and this corresponds to 126
 > "bits of security" (until a major breakthrough makes attacks
 > against ECC more efficient).
 > To sum it up: Ed25519 is likely to be much stronger than
 > traditional DSA despite having much shorter public keys. (OTOH,
 > its private keys are longer: it's 160 bits for DSA and 256 bits
 > for Ed25519.)

Obviously, yes. But the question was whether to enable ED25519
for server or to keep it only in client, leaving server RSA-only.

Alexey V. Vissarionov aka Gremlin from Kremlin
GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ