[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151120064159.GA30873@gremlin.ru>
Date: Fri, 20 Nov 2015 09:41:59 +0300
From: gremlin@...mlin.ru
To: owl-dev@...ts.openwall.com
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".
s/is/was/
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.
Yet...
> 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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
