Hacker News new | past | comments | ask | show | jobs | submit login

I wonder what the effort to break a 2048-bit prime would be. I suspect it's heading into "dyson sphere powered ideal computer" territory, but I'd be curious to know what it would actually be.



The thing that breaks 2048 bit conventional multiplicative group Diffie Hellman is likely to break conventional multiplicative group Diffie Hellman altogether.


Any reason not to just settle on ECDH for new applications?


It's Complicated. All else equal, yes, you should use ECDH over a good curve, implemented carefully in a curve library you yourself did not write, which library has been carefully reviewed for flaws.

But if you don't have access to that code on every platform you might need to deploy on, it might be better to do DH-2048 than to use crappy curve code.

Basically, your best choice right now is Curve25519. If you can't get a trustworthy Curve25519, though, it might be tricky to pick between DH-2048 and {other curve software}.


I understand the reasoning for this recommendation but as this paper shows there is also a danger in going along with what's popular, even if it's the best currently recommended practices. If you as a reasonably well-versed engineer can come up with a custom implementation it would be more likely that you'll be protected from mass surveillance. Even if your implementation has some weaknesses you won't be caught up in a dragnet. Assuming the eye of Sauron does not look right at you, meaning a government-level adversary targets you directly.


The opposite is true: if you implement ECDH yourself, you aren't unlikely to end up with software that thousands of different people will be able to break with their laptops. It's tricky to get right.


(1) You're saying use standardized fully-vetted methods.

(2) Parent is asking for something just slightly different enough that it escapes dragnets and automated attacks.

There is no question that (1) is much better than (2).

But in special circumstances, one could do both (1) and (2) in cascade operation (i.e., do one first, then the other). If the code for (1) and (2) run as separate processes with independently chosen keys, seeds, parameters, etc., then it doesn't matter how awful (2) is. It might help, it might not help, but it won't make the security worse than using (1) alone.

The obvious downsides are slowness, code complexity, non-standard API/interface, code maintenance headaches, and false sense of extra security (but not worse security).


You have to be careful which algorithm you run first though. If you use your crappy implementation first, it might compromise the security of the second round of encryption.

ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauMas93a.pdf


This was a great reverse engineering trick. A lot of "hackers" would make their tools super-secure by packing the binary and then protecting it with VMProtect. Because, that's way better than just using VMProtect by itself, right?

Except that you could run the VMProtected binary until just after the unpacking routine ended giving you the original binary in memory. Didn't have to understand VMProtect at all.

Thanks hackers!

The same thing isn't necessarily true with crypto, but the lesson is that thinking you're adding security by layering without knowing what you're doing might backfire.


Any handspun crypto will likely have trivial flaws. But they might escape the NSA's notice, in the same way that a hand-rolled CAPTCHA can sometimes prevent more spam than a better-designed but widely-deployed one?


Pretty much: Odds are that, if you roll your own, you’ll make mistakes which make your code trivial to break for a motivated attacker that is willing to put the effort into targeting you personally.

It’s also quite possible that the NSA/GCHQ/5-Eyes will notice that your communications are 'interesting, because different' and mark them to be stored in perpetuity in case they ever do decide that you’re of interest so that they can go back and break it all then.

So, how lucky are you feeling?


I don't think many people (let alone businesses) would rather introduce a risk of being exploited by a hacker than a huge government agency that could care less about their existence. And if you are in a position where the NSA does care to look at you closely, bad crypto is going to make their job easy.


Why is there not more hedging of bets by implementing both? That way if one is broken or improperly implemented, there's a bit of safety. Apart from being ugly is there a reason this doesn't work?


You're increasing your attack surface area. Do you use both, do you let the server choose, do you let the client choose? What if the client requests the lower-security crypto? What if what the client asked you is different to what you think you were asked from the client (MITM)?


I think the question meant literally both, always.


Yeah, setup one channel and then another inside that. Seems like hash functions could be used this way, too. For instance, are there any practical attacks in sight that'd work simultaneously on both MD5 and SHA1? 3DES does this with DES so it probably works in general?


This gets complicated fast, especially with hashes[1]. Like most of crypto, you shouldn't do it unless you have a team of experts who publicly vetted the algorithm and implementation.

[1]: http://security.stackexchange.com/questions/83881/is-using-t...


According to the paper in OP: "Precomputation for a 2048-bit non-trapdoored group is around 10^9 times harder than for a 1024-bit group, so 2048-bit Diffie-Hellman will remain secure barring a major algorithmic improvement".




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: