Comment by akerl_ | Hacker News Reader

Comment by akerl_ | Hacker News Reader

Parent Full thread

I'm a bit concerned at some of the leaps of logic made in this article.

We're told to discount 1024 bit exchanges because of "unknown attacks". If they're unknown, why are we determining that 2048 bits is safe? How do we know the attacks aren't specifically against some other aspect?

The guide talks about creating a newer stronger host key, but doesn't provide any information about preventing initial MITM there: ensuring you get the right host key on first connection is a major issue, and somebody trying to "make NSA analysts sad" ought to be explaining methods for ensuring that happens securely via host key CAs or similar tools.

Likewise, the suggestion for "Preventing key theft" is "ven with forward secrecy the secret keys must be kept secret. The NSA has a database of stolen keys - you do not want your key there.". No insight is provided on how to actually accomplish that.

This is certainly a way to turn off weaker ciphers and exchanges, but passing it off as a way to "make NSA analysts sad" is hyperbolic and runs the risk of people believing the hype.

We don't know exactly the design of a rig that would solve a 1024-bit discrete log or factoring problem, but we have a decent idea of what it would probably cost, and most VC firms could fund it.

Costs don't scale linearly. No math projection puts 2048 bit keys in reach. The thing that breaks 2048 bit RSA may well put RSA completely out of action, a reason to prefer alternatives to RSA over 4096-bit keys.

Granted, but if that's the concern, that's what the article ought to be explaining:

We are aware of the infrastructure to break 1024-bit discrete logs, and it's feasible; current projections put 2048 bit key safely out of reach for the time being, so we'll disable 1024 and leave 2048 enabled.

My concern there is with the talk of 'unknown attacks' and then providing suggestions based on that statement.

> but we have a decent idea of what it would probably cost, and most VC firms could fund it.

I'd wonder if a "CaaS" startup (Cracking as a service) would be feasible. Using amazon spot instances, it would require only as much funding as to serve the first ten users - and requiring each user to send the money to an escrow, e.g. a notary (in Germany, it's possible to deposit an amount at a notary, which gives the customer the assurance that without the private key, the company gets their money and the company has the assurance that the customer doesn't walk away with the keys and leaves the company with a 5-figure AWS bill).

One interesting topic of semi-paranoia that hasn't been discussed is timing attacks. I'm not even implying its a realistic concern, but a timing attack could be imagined that works better with longer keys.

So 1024 is run too fast to gather intel based on timing, but an imaginary 8192 bit key would run slowly enough to leak one random bit of key per session via timing analysis, as a physics-style thought experiment.

Not trying to claim out that longer keys are weaker in reality, but am trying to make the point that being impervious to timing analysis attacks might be kinda important. Or another way to phrase it is there's more ways to break a key than pure math or torture.

Longer keys could also make some compromises less obvious; finding identical keys -> bad entropy, weak keys (Debian/OpenSSL, lots of devices). I don't know if anyone found backdoored key generators that aren't based on weak entropy.

Considering it's on github.io, you can make a pull request with recommended changes here:

https://github.com/stribika/stribika.github.io

:P

Non-PFS crypto-systems shouldn't be considered "safe" anyway. The NSA can steal the keys quite easily from most individuals/companies from what I gather from the documents.

Are any non-forward-secure methods under discussion here? The author makes pretty clear that both the options used by SSH for key exchange are forward-secure.

Reply on news.ycombinator.com