If you deployed vulnerable code, you'd see your stack fall over ~10mins later, along with an accompanying notice from the Penetrator Monkey that you've got work to do.
Something similar happens with code coverage. It's pretty easy to write tests that provide 100% code coverage yet still miss basic bugs. 100% code coverage gives you little more guarantee than "this code doesn't crash for naive inputs" unless the tests providing the coverage were well written - code coverage gives you no introspection to how good the tests might actually be.
In short, I agree that this would be a cool + useful tool. But it should come with a disclaimer that it's not a substitute for more thorough testing + verification.
As far as they go, maybe; but I worry that people don't appreciate the limitations. Making sure that someone can't code up an exploit against your system in half an hour is absolutely essential, but it's not the only thing that matters -- a serious cryptographer is also going to be concerned about "two years of coding and ten million dollars of computing power" attacks, which can be safely disregarded in CTFs.
In the sub-domain of web security, django.nV is such a "purposefully vulnerable Django application" that comes as companion to a websec tutorial: https://github.com/nVisium/django.nV
No disclaimer, I have no affiliation with the project, I just enjoy their work.
To have really capable people work on breaking your crypto for free, you have to be an insider. You become an insider by breaking other people's crypto. You can publish a break in an insider's crypto even if you are unknown. After you publish a few such papers, you become an insider and can publish your own crypto other people will spend their time trying to break.
People can learn the state of the art and develop an alternative to the common (NIST) choices which are no worse, but also no better. Some of those are blessed as "national pride ciphers" (GOST, Camellia, SEED, etc.).
Making a secure encryption algorithm requires a lot of presence of mind, and a lot of industry knowledge. If your threat model is incomplete, you lose. If you forgot one tiny thing at one tiny point in the algorithm, you lose.
If you don't have people checking your work, how do you know? If someone is determined to break your encryption, they are capable of spending a lot more time analyzing it than you spent building it. And they only need to find one mistake.
It's definitely better to use the tools that experts have spent lots of time, lots of breadth of knowledge, and lots of depth of knowledge inspecting.
A better question to ask is, how easy is it to break the protocols and the software using the protocols? We have secure ciphers. Those aren't where the problems in computer and network security lie.
Is there a general way to attack naive ciphers?
I fall of at even a proper Vigenère cipher, although I guess I could hack together a terribly inefficient python script to test all options and then print them line by line and start visually scanning for patterns :-/
- https://sourceforge.net/projects/metasploitable/
- https://github.com/ethicalhack3r/DVWA
If you go this direction you will find much more applications prepared for Capture The Flag competitions. Some people are even posting walk-throughs how to hack and fix them. It is very interesting & hard.
Strength training and general athleticism alone too will often allow you to win over someone who practices a martial art that is purely focused on striking, especially one of the more ornamental ones. Hard to win against someone that can just pick you up and slam you on the concrete ala Quinton Jackson.
Which aids in the analogy.
If you restrict yourself to aikido techniques and your attacker has no such reservations, you have to be extremely good.
Good for the analogy.
I think it would be a mistake to give up on self-defense in general because of that. In any case, you have to go into it knowing it's not a guarantee, it just increases your odds.
Good points for the analogy.
That is all there is to it.
Some examples here https://www.youtube.com/watch?v=C_SB0TqvUb8
E.g. even if RSA is (currenly) safe, as well as its primitives and common configuration... rolling your own implementation will probably be subject to timing attacks.
The conspirator is there to teach about Defense in Depth. Systems that rely on just 1 "impenetrable" membrane tend to be brittle. Their failure is catastrophically sudden and complete, like glass breaking. Glass is way harder than steel, but steel structures are much more robust, because steel's ductility allows for partial failures and continued resistance/integrity.
Your security is either sound or broken
What about "Defense in depth?"
Software is not the real world where things bend. If a barrier is sane, it will stand, nobody will break it. But no matter how many non-sane barriers you add, you can not turn them into a sane one. The only thing you will achieve is to increase your system complexity and get more bugs as a result.
All the others are about making the effort required greater than the will to get there in favor of usability.
All the standard libraries stop at "miniscule effort for a state".
And states aren't even "the big boys" anymore.
eh.
RSA is a simple formula. takes a bit of fiddling and skill to get BigIntegers working. but anyone who passed highschool algebra could roll their own. in fact many high schools even set it as homework.
timing attacks you say. erm, not remotely connected.
Rather than putting the rest of us at risk by putting zero value on the security of anything you make and guessing someone [a spook] will do it for you, why dont you recommend everyone takes some time out to at least learn the basics.
Yes, there are several "mines" you need to be wary of.
But they all pale into insignificance compared to linking openssl and thinking you are done.
Fine, I'll trust your overwhelming evidence instead of the many timing attacks described against RSA implementations.
padding -> irrelevent to an RSA public key, everyone has to know the exact modulus and product, even the bad guys (although I recommend keeping public keys relatively secret)
timing -> irrelevent to an RSA public key, there is nothing you can get from how long it takes to decrypt or encrypt even 1024 bits of data (which is more than most impliementations even send), sometimes the exact same data will take 1ms, sometimes 100ms, it depends what else the machine is doing at the time.
I wonder if there shouldn't be a software engineering class where people try to set up a secure web app, with their own homegrown algorithms and protocols, which is then attacked by a tiger team which includes a conspirator on the inside? Perhaps there are such classes now.