Hacker News Reader

Comment by stcredzero | Hacker News Reader

When I was taking Aikido, there was a day when the sensei was going through all of our techniques and showed how the uke (initiator of the attack, receiver of the technique) could turn things around on the tori. (receiver of the attack, initiator of the technique) It seemed like there were a half dozen ways each that a technique could go seriously wrong, and that many of them didn't require much skill, only determination and the opportunity provided by a mistake. That day made me question the validity of the entire notion of self defense.

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.

View on HN

I've always thought it would be neat to have something like the Netflix "Chaos Monkey", but rather than sitting around on your machines taking them down at random, it sits on your network (or as part of the offering of the PaaS you've deployed to) trying to break into your stack using Metasploit et al, and then will immediately shut down/isolate every piece of software it manages to gain access to.

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.

I worry that this would give a false sense of security. Definitely it's better to have something that will highlight problems than to have the problems go unnoticed, but there's no way that something like a Penetrator Monkey could be comprehensive, and less experienced people might fall into the trap of believing that the monkey is as competent as an actual attacker.

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.

There should be. In industry, we call those things CTFs, and there are both attacker and defender CTFs. My experience has been that they are extremely effective learning tools.

extremely effective learning tools

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.

Not exactly what you describe but related: people build intentionally-vulnerable applications for the sake of teaching security by example.

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.

This is slightly tangential since you specified a conspirator on the inside, but how easy is it to break a homegrown encryption algorithm if you don't have the source code? I assume there are tools (what are they?) that will break a simple caesar cipher if you have more than a sentence or so of plain text to work with. But if you strung together 2-3 broken algorithms and your attacker doesn't know which ones, is it still trivial to decrypt?

Also interested.

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 :-/

Vigenère ciphers based on xor: xor the ciphertext with itself at varying offsets. Stop when you detect likely plaintext in the result.

People who can break it won't spend the time breaking your homegrown crypto, so you won't get proof it's broken. But it's still broken. If lots of money or lives of political dissidents are at stake, it will be broken.

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.).

Ciphers aren't the place where security most often fails. The failures have to do with implementation. More commonly, they have to do with implementation of protocols and systems using the protocols.

I agree, but I replied to someone who talked about ciphers.

Of course. I was also (mainly) posting for the benefit of 3rd parties.

We're specifically talking about the scenario where you have a "tiger team" (strcredzero's phrasing) trying to break it. I interpreted GP as asking just how hard a time the tiger team would have if they don't have source code.

how easy is it to break a homegrown encryption algorithm if you don't have the source code?

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.

I've seen a few fun articles about people breaking home grown encryption. The question is mostly about how motivated someone might be to find a problem.

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.

Those articles (and their sources) sound interesting. Think you can share any of them?

There are penetration testing classes, but doubt that they are bundled together with classical CS, thought never know what some uni or courses may add. And there are project like those for practicing, few pointers:

- https://sourceforge.net/projects/metasploitable/

- https://github.com/ethicalhack3r/DVWA

- https://www.vulnhub.com/

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.

Aikido in particular seems to be very subtle, both in my experience and the opinion of an aikido black belt I've asked about it. If you restrict yourself to aikido techniques and your attacker has no such reservations, you have to be extremely good. 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.

Aikido in particular seems to be very subtle

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.

Yeah, I studied Aikido briefly in college and found it quite powerful when a petite 65yr old Japanese lady could inflict the most excruciating drop-to-your-knees pain I've ever felt with barely a touch. But it takes a decade or more of diligent practice to achieve that kind of skill, and I found Judo, BJJ, and Krav Maga quicker to become effective with.

Freestyle Olympic wrestling also has many useful techniques for winning a real street fight, and as an activity it builds the type of strength that is very effective in a fight. Worth taking a look at wrestler and BJJ practitioner Daniel Cormier's recent win of the UFC light heavyweight championship over Anthony Johnson, an extremely talented striker, to see why this is the case. Johnson essentially had a small window of time to knock Cormier out, and he nearly did, but once Cormier manage to get a hold of him the fight was brutal after that.

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.

The act of reversing a technique is called "kaeshiwaza". Kaeshiwaza is possible only if there there is an opening (weakness) in the waza.

That is all there is to it.

Some examples here https://www.youtube.com/watch?v=C_SB0TqvUb8

What would be the purpose of such a class? If the point is to show that rolling your own security is bad, it seems like having an inside man would just help leave people convinced that they could have succeeded if only it weren't for that other guy.

Something tells me a conspirator wouldn't be required anyways. Your security is either sound or broken, i.e. probably broken unless you use proven implementations of proven cryptosystems with proven configurations.

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.

Something tells me a conspirator wouldn't be required anyways.

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?"

Defense in depth mostly does not work (against willful targeted attacks).

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.

only one encryption scheme works against "willful targeted attacks" - the one time pad (and even that has potential for going wrong)

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.

since im not in the market for downvoting. ill just say.

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.

If you implement RSA from the textbook, as a simple formula, you'll leave yourself vulnerable to padding based attacks that can recover the private key. It turns out that though the formulas are straightforward and the math can be explained after a decent undergraduate education, the implementation is still very subtle.

padding attacks are only really related to encrypting data not sharing the product of two very large primes. You clearly havent got the faintest idea what you are talking about.

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.

> timing attacks you say. erm, not remotely connected.

Fine, I'll trust your overwhelming evidence instead of the many timing attacks described against RSA implementations.

All those attacks are "theoretical". As opposed to actually having been usefull in the wild - FUD (heartbleed otoh.....).

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.

Reply on news.ycombinator.com