> In a real attack you may, depending on the circumstances, only have access to that (at first, at least).
You misunderstand the whole deal.
When imagining different potential attacks on your house you can't go laying down rules that the burglars have to follow. What if there are special circumstances (that you weren't aware of) that allows the burglars to bypass your restrictions under certain conditions? You plan for the worst case scenario, always!
Take password hashing+salting for instance. You could say that it's actually safe to store plaintext passwords because outsiders don't have credentials to access the database.
You could even run a contest where to say that you will give a million dollars to anybody who can get access and steal the passwords, and then insist that since nobody has claimed that million dollars yet, plaintext passwords are clearly safe.
But we all see how foolish that would be. You plan for the worst case scenario and hash+salt your passwords. You don't plan for the "average case scenario" where "normally attackers don't have access to the database".
"When imagining different potential attacks on your house you can't go laying down rules that the burglars have to follow"
Of course. But everything is limited and for each scenario there's a specific chance that will happen. Some RSA key sizes are breakable if you can put a lot of computing power behind.
For example, a house may not be built to withstand tanks, so there's your limitation.
On the other hand, there's a huge likelihood someone will walk past your house and see the door ajar, or try to open it.
So, again, everybody is right to secure against KPA, CPA, etc, BUT don't forget that there may be something easier, and yes, if it resists the deeper attacks it's probably safe against capture of cyphertext.
"But we all see how foolish that would be. You plan for the worst case scenario and hash+salt your passwords"
Sure. But in practice the plaintext + strong DB security may be safer "overall" than a hash + salt on a MySQL with the credentials forgotten in some config.php somewhere.
(It's not an excuse to not hash the passwords, though)
> Of course. But everything is limited and for each scenario there's a specific chance that will happen. Some RSA key sizes are breakable if you can put a lot of computing power behind.
I can agree with you that bruteforce attacks should not be within the scope of such a bug bounty prize or competition (unless somebody has exposed a flaw that allows for very easy brute forcing).
But that's not what's happening here. What's happening here is that the people running the show are handing out a few pieces of encrypted information and saying that since nobody can crack their stuff using that handed out information, their system is secure. It's easy to be confident in a controlled sterilized environment.
The blogger is pointing out that an attacker could very well have access to a lot more information and functionality than what they are handing out. They are only demonstrating that their system is safe in a "good case scenario" when everything goes as planned. They have not demonstrated that their system is secure if everything doesn't go as planned, if suddenly the attacker found a way to spoof the email messages and send his own prodding cypher, or something to that flavor, which isn't part of the neat little package they have arranged as part of competition.
Saying that "that's most likely not the case, the hackers wouldn't have anymore information or access" just is not a rebuttal to that. It's not a rebuttal to anything, it's just a brain fart.
>> Well, if the algorithm is so broken then it should be trivial to break it even with their limitations.
This is the critical sentence from the article - "If you want to show that a system is secure, give the adversary as much power as possible, and if they still can’t break it, the security is good."
This is at the root of modern crypto systems, and without it a system is considered broken.
It may be that within the rules of the contest, breaking one message is non-trivial. That doesn't mean that I couldn't (for instance) collect and analyse multiple individual's traffic over time, or find a way to alter data in-flight, both of which are specifically ruled out of the contest.
Yeah, it's like saying "oh but the attack possibilities are so limited" to then proceed to mention how all the components can't bear the load of the bridge.
Well, if that piece of steel can so obviously not hold those 10000 tons of concrete given the corrosion over the next 30 years, it should be trivial to break it even with their limitations.
It has been shown that SHA1 is broken - it's just that experts in the field tend to be able to know such things before the bridge has collapsed, but that does not mean that they can demonstrate it to anyone who doesn't want to study the theories behind their assessment without building the bridge and waiting 30 years.
And yet, the fact that a bridge design contains a pillar that any expert expects to collapse after 30 years might tell you something about the designer's competence and thus about the viability of the whole design.
This is not so much about showing how to break their system, but about showing how their design methodology is likely to produce an unreliable system - because that (a) is much easier to do than actually breaking a system and (b) precisely because of that is how cryptographers usually work and (c) it is actually known to be possible to build systems that are more likely to be and to stay secure, so there is no point in compromising reliability for implementability.
Well, if the algorithm is so broken then it should be trivial to break it even with their limitations.
Isn't that what they say? "Oh SHA-1 is broken", great, show it.
Of course, the capability to do that may be worth more than getting the $200k from the contest