Hacker Newsnew | comments | show | ask | jobs | submit | _phred's comments login

The best publicly known attacks on RSA reduce the attack time by a few orders of magnitude at best. A functional quantum CPU could reduce that by a few more orders. Your 4096-bit RSA key is still 2^3072 times harder to break, so even with reductions we're still talking about "heat death of the universe" amounts of time to brute force.

RSA has issues but as of yet hasn't yielded entirely to cryptanalysis.

As the article says, it's easier to attack the system and try to get the plaintext, or coerce you into giving up your key through legal means.

Edit: adding a link to Wikipedia's article on post-quantum crypto, it's a good place to start understanding how to answer these type of questions:

http://en.wikipedia.org/wiki/Post-quantum_cryptography

-----


"Your 4096-bit RSA key is still 2^3072 times harder to break,"

No, because the difficulty of breaking RSA keys doesn't scale in the same way as symmetric encryption. Integer factorisation is much easier than a brute force search of the keyspace. A 1024-bit RSA key is believed to be roughly equivalent to an 80-bit symmetric key. A 3072 bit key is about as hard to brute force as an 128-bit symmetric key.

(Source: http://www.keylength.com/en/4/ )

-----


Ah shoot, you're right. I'm an armchair crypto geek at best.

In any case, you can choose a public key exponent large enough to still make it a hard problem to crack in a reasonable amount of time. Barring some huge vulnerability in RSA that hasn't been discovered in 30 years of public scrutiny, of course.

-----


Are you sure about that? As far as I understand it, generic quantum computation would cut that '3072' in half, and using quantum computers specifically for factoring reduces problems to a low polynomial time.

-----


Correct. Shor's algorithm renders any use of RSA... pointless.

And while there are limits to the applicability of Grover's algorithm, you're correct that it effectively cuts the number of bits in any cryptosystem it applies to in half. Which, to my nonexpert eyes, looks to be most of them.

-----


Hmm, yes, I think I conflated the asymmetric vs symmetric cases.

Shor's algorithm is very tasty, but when the real world demonstrations at top research facilities are saying, "yes, we factored 21 into 7x3, but WITH ENTANGLEMENT"[1] it makes me think that scaling to RSA-size prime factors is still a good way off.

Listen, the US government is powerful, but building a full scale quantum crypto decoder ring in complete secrecy _decades_ ahead of everyone else? I just don't think so. Maybe I'm a sheep for not wanting to believe the government so powerful and corrupt, but the whole thing sounds like a tin foil fantasy.

I don't doubt they would if they could, though. And they've done as much as they can with present day tech: supercomputers, mass data collection, penetration of target systems, exploiting SSL's many weaknesses, tapping undersea lines, and legally strong-arming perceived threats into giving up their encryption keys. I just don't think we need to get science fiction involved.

[1] http://www.nature.com/nphoton/journal/vaop/ncurrent/full/nph...

See http://en.m.wikipedia.org/wiki/Shor's_algorithm

-----


Hey, I wasn't claiming practical quantum computers existed. Just that, at whatever point running Shor's algorithm becomes practical, RSA will be pointless.

-----


But what if they have some vulnerability in the crypto itself? thus skipping the need to brute force.

-----


Yes: call/SMS forwarding. It depends on how good your first factor (e.g. password policies) are, and how your reset process works. Getting someone's phone number and setting up call forwarding doesn't require much social engineering savvy to pull off.

http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-hona...

-----


Call forwarding doesn't forward SMS. I don't think you can do SMS forwarding (at least for any carrier I'm aware of). You'd need to social engineer the carrier to port your target's number to a different phone -- in which case the target is going to be exposed to a ton of trouble...

-----


Looks like it's built around KVM (Kernel Virtualization Modules), i.e. "containers", rather than full-blown virtual machine emulation like Xen or VirtualBox/Vagrant.

It appears to be a configuration management / deployment tool for KVM containers. New to me too, gonna dive in and check it out.

-----


KVM is full machine emulation (i.e. hardware is emulated, and you can run different kernels inside the guests than you do on the host).

Docker uses LXC which is like BSD Jails, most of the advantages of VMs but you don't have to emulate a whole system, there's only one kernel atop which multiple containers/jails can run different software and have thorough isolation. Very fast and light-weight, but you can't run different OS kernels.

-----


nitpicking: KVM stands for "Kernel Virtual Machine". It's an implementation of virtual machines, just like VirtualBox or VMWare. Containers are completely separate from KVM.

-----


That's a great way to describe it. It's a "lightweight" VM that is created per process.

-----


Wow, that comment thread... does not lend itself to confidence in their project's security.

It also illustrates a really key point about crypto: because it looks simple (oh, just run the bytes through that function/hash/send them over SSL), people assume that it is simple they know enough to hack together a decently secure system.

At the very least, a healthy respect of crypto theory is called for. In my experience most developers do not have this healthy respect and see crypto as a magic black box that makes data unreadable.

I find attacks on cryptosystems illustrative for the "oh CRAP" moment. Oh CRAP salted hashes are a terrible idea. Oh CRAP you can pad a hash to make a remote system accept "signed" data. The more I learn and the older I get, the more cautious I am.

-----


Hackers built Facebook. They hire hackers. If there's a group that's hardest to pigeonhole in terms of beliefs it's hackers.

The idea that a company composed if hackers could have not a single whistleblower, no single person that objects so strongly that they must speak up regardless of their personal situation is betting against human nature. Nay, hacker nature.

Freedom ain't looking good nowadays, but this is not the vast conspiracy it may seem.

-----


I have a theory that the accelerometer-linked 3D "layer" effects might make the flat interface more usable in person. As in, the subtle perspective shift would make it obvious that a button is a button, etc. Can you comment on that? Are those effects extended to all of the UI elements?

-----


It seems like a pretty gimmicky effect right now, although if you hold it in a certain way it does have a cool 3D effect. The scrolling animation stutters quite a bit currently. I anticipate they'll have that fixed by release.

-----


Interesting, thanks!

-----


I personally hope the accelerometer-linked 3D will not also help to make flat the battery which already does not last long.

-----


They aren't, and even the little layer effect on the home screen is nothing but a gimmick. I don't wave around with my phone while I use it and would never have noticed the iOS6 volume slider effect if blogs hadn't pointed it out.

-----


I have the beta, and as of right now they aren't - the effects are only for the wallpaper.

-----


A lot of API authentication is half-assed, like the examples in the article. "OAuth is hard, roll your own" is a common approach. Even with, e.g., OAuth 2, who's to say that the scheme is completely safe and that your implementation is correct?

As far as API vs. user account, it depends on the loot. An API might let me do more damage faster, or subtly lurk and alter/steal data over time. It might also be harder to detect from the UI, no "last logged in" giveaway.

Also, some API vendors recommend disabling SSL cert validation client side. Even for credit card gateways, unbelievably. Since it's a script talking to a script, no one is going to see the cert problems from a MITM until it's too late.

-----


Right. If the attack vector is "break SSL" I'm going to try some other attacks first. There's an underlying assumption in the question: my app (and everything else hosted on the box) is safe from XSS, CSRF, injections, and other information leakages. Is it really? How do I know for sure?

And who's to say that your forum server (for example) is just as secure? That could be a foothold into your environment too. And let's not forget social manipulation of your staff and users. Maybe I'll just steal the machine in question, or your laptop.

After I try all those avenues, I'm either finding another target or ramping up for a protracted attack on your SSL connections.

If your site attracts this dedicated of an attack, you'd better get that high paid security consultant. ;)

-----


The problem with these attacks on SSL is that they're not protracted; They're trivial. Python's httplib doesn't check SSL certificates at all by default, for example, so you just hijack the TCP connection, negotiate SSL, and then you're done.

With libcurl, I think you have to set CURLOPT_SSL_VERIFYHOST to 2. If you set it to TRUE (i.e. 1), it skips part of the certificate check, rendering the whole thing trivially insecure.

Most (all?) crypto libraries have terrible APIs, or have APIs that are far too low-level to be safely used by most developers. SSL shouldn't be the easiest thing to attack, but in the current state of affairs, it often is.

-----


O, cruel fortune! I rue my talent.

-----


So as a sort-of-amusing counterpoint to this article, I know at least one ASV who insists that the only way to mitigate BEAST is to disable all ciphers but RC4. Still scratching my head on that one.

That tool you posted is great, hugely helpful for anyone who has to deal with this stuff.

-----


This is a pretty good illustration of why professional appsec people don't like PCI.

-----

More

Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: