_phred
Joined 18 years ago
Joined 18 years ago
https://agileforall.com/history-of-tdd-as-told-in-quotes/
Djikstra proposed the idea in the 1970s. Rails did not in any way pioneer TDD. They were very vocal about it but “[stood] on the shoulders of giants.”
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...
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.
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://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-hona...
It appears to be a configuration management / deployment tool for KVM containers. New to me too, gonna dive in and check it out.
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.
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.
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.
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. ;)