131–140 of 174 posts
Earlier quoted context omitted.
Just curious how far the Excel hacker(s) got... Also, have you made any hires from the contest yet?
All I'm going to say here is that you would not freaking believe how far the Excel guy has gotten. No VBA, either; it's pure spreadsheet cells. Yes, we've hired from the challenges (I don't like thinking of it as a contest; I think of it more as an extremely engaging blog post).
Note: we're still running these challenges: http://www.matasano.com/articles/crypto-challenges/ The current standings are: * level 0 (4362 players), * level 1 (335 players), * level 2 (123 players), * level 3 (40 players), * level 4 (21 players), * level 5 (23 players), * level 6 (32 players) We're still donating $20 to PIH or Watsi for everyone who finishes all 6 sets. The top languages finishers are using are (in o…
Is that the number of people working on that level, or the number of people who've finished that level? My guess was the former, but if so, how many people have finished level 6? And if it's the latter, how many people have started level 0 but not finished? I'm also curious what the stats look like for how long people are taking to complete each level.
a level is a day or two of work, in my experience (unless you get stuck and need to sleep on something, or get entertained and go off exploring something), but i doubt most people are doing them full-time, so timing data is going to reflect mostly how busy they were with other things.
Note: we're still running these challenges: http://www.matasano.com/articles/crypto-challenges/ The current standings are: * level 0 (4362 players), * level 1 (335 players), * level 2 (123 players), * level 3 (40 players), * level 4 (21 players), * level 5 (23 players), * level 6 (32 players) We're still donating $20 to PIH or Watsi for everyone who finishes all 6 sets. The top languages finishers are using are (in o…
Is that the number of people working on that level, or the number of people who've finished that level? My guess was the former, but if so, how many people have finished level 6? And if it's the latter, how many people have started level 0 but not finished? I'm also curious what the stats look like for how long people are taking to complete each level.
For example I got Level 0 set of problems, enjoyed the reading, but decided not to work on these problems, because I'm just not enthusiastic enough about diving deep into cryptography.
I guess most of 4362 "players" on Level 0 are in a similar position.
Few thoughts - why MD5 in the example at all? I thought that SHA-2 was the go to for hash functions nowadays. And a question on the timing attack - how real it is? Because in the response time you have a lot of random variables which with the current fast servers will take more time than the calculation itself. You receive request - how fast it will go trough the loadbalancer is random, then you must read the shared…
For the timing-based one, you I would've made the server wait a small random amount of time during the process. The xor is more clever, though.
Not the way a naive reading of your post suggests, no. If you add a random amount of time, the timing attack still works; it averages out, the same way network jitter does. What you need to do is make every request take the same amount of time; randomness is not helpful here.
His insight that crypto is hard because you don't get feedback when you mess up is good. It made me wonder what other domains are like that -- domains where correctness seems within reach, yet there are subtle aspects that are hard to state. Some that come to mind: * Concurrency. It's easy to introduce race conditions, livelocks, or deadlocks without even knowing. They are often difficult to observe or reproduce, and…
- Relying on undefined or implementation-specified behavior. Problems only show up years down the road. (example issue: expecting signed overflow to wraparound in C) - Avoiding statistical biases when transforming random values. Statistical unit tests are hard. (example issue: shuffling via lots of uniformly random swaps) - Integer overflow ruining algorithms that would be correct, given unbounded integers. (example…
Earlier quoted context omitted.
Funny story - quite a few years back I was a sysadmin for a company that was compiling their own PHP with a couple of patches. When I asked about it, my co-worker said it was to suppress some warnings that were spamming the logs whenever someone created an account. Yes, those warnings were telling us that we weren't using an initialization vector (IV, aka a salt) when hashing the passwords. Facepalm. I suppose that d…
Once you are choosing salts that is almost level 4 knowledge. This is one of the problems with "raw" PHP development, there's no way to say "this is a password field, make it secure" only "hash this with algorithm X". To be fair though , I believe recent releases have addressed this and frameworks like symphony give you a default user class to inherit from that does things sensibly. It also sticks a seed for the salt…
[1] = http://symfony.com/doc/2.0/book/security.html#encoding-the-u...
Earlier quoted context omitted.
Is that the number of people working on that level, or the number of people who've finished that level? My guess was the former, but if so, how many people have finished level 6? And if it's the latter, how many people have started level 0 but not finished? I'm also curious what the stats look like for how long people are taking to complete each level.
there are 6 levels. so presumably level 0 is people who started (ie requested) but did not complete level 1. a level is a day or two of work, in my experience (unless you get stuck and need to sleep on something, or get entertained and go off exploring something), but i doubt most people are doing them full-time, so timing data is going to reflect mostly how busy they were with other things.
So, sure. I'll admit that I'm bad at cryptography. You win! But the problem is, the world needs more, not less, crypto. We need to integrate crypto into more places, not run and hide and declare it too hard every time we come across it. Is it easy to screw up? Sure. So is manually allocating memory. But we use higher level languages to help protect us from ourselves. So too can we use higher-level libraries to help p…
The world needs more broken crypto like a dissident strapped to a chair in a concrete cell in South America needs another car battery alligator clipped to their fingers. How about, if the world really needs more cryptography, the people who bring it to us take the time to become just a little bit literate in how crypto is actually attacked, instead of pretending like they understand it just because they were able to…
Re-reading, I can see how I could have been more clear and to the point, I did meander a bit in my original post.
Earlier quoted context omitted.
One of the problems with cryptography is that "solutions" are not as generally applicable as one might want. There are a lot of assumptions that are made, and violating those assumptions is usually a disaster. For example, when it comes to encryption, it is typically assumed that all messages are the same length. If your application does not make this guarantee, encryption may not provide you with any security. You c…
That makes sense in terms of no standard libraries. But how about design patterns for common scenarios, eg. securing REST apis, User authentication/Login/Signup, Payment information handling etc, all in one place. Does it become less secure if everyone follows standard design patterns?
An example is Hushmail. Your mail is signed, it is encrypted, you're using the tried-and-true PGP...and the DEA can walk into court with a pile of DVDs full of the plaintext of some defendant's email. Hushmail is, at best, only marginally more secure than GMail.
So while we might come up with good practices for using cryptography, it is inevitable that organizational practices will render the cryptography pointless. Solutions need to be tailored to the specific needs of an organization or a system. That is where the real problem lies: we do not have something like SQL for cryptography. We do not have a good way to specify organization needs and design (or even verify the security of) a cryptosystem that meets those needs.