I'm surprised by how many people in my workshops still complain about wildly varying results with today's models. In my experience that's almost always a context problem, not a model problem. The post argues for keeping that context as plain Markdown in the repo, so it also serves as documentation for humans. This is Spec-Driven Development, but with the tools you already have. I'm wary of existing SDD frameworks: they often feel a bit too heavy for my taste. Since things are evolving at breakneck speed, I also would like to avoid any kind of abstraction lock-in.

Feel free to try it out yourself. A simple demo with the full run: https://github.com/emboss/text-first-demo (start from the bare-repo branch, compare with the implementation branch, which shows one sample run). I'd be especially interested in where this breaks down for you in brownfield codebases.

Comments URL: https://news.ycombinator.com/item?id=50274856

Points: 3

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=6258108

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=6196081

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=5235178

Points: 1

# Comments: 0

http://crypto.junod.info/2012/12/13/hash-dos-and-btrfs/

Comments URL: https://news.ycombinator.com/item?id=4921784

Points: 6

# Comments: 4

Comments URL: https://news.ycombinator.com/item?id=4862326

Points: 10

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=4652852

Points: 3

# Comments: 0

C: https://github.com/floodyberry/siphash

Go: https://github.com/dchest/siphash

C: https://github.com/emboss/siphash-c

Ruby: https://github.com/emboss/siphash-ruby

Java: https://github.com/emboss/siphash-java

Comments URL: https://news.ycombinator.com/item?id=4146531

Points: 6

# Comments: 1

> unlike in Java, you can also call a class method on an instance

It's possible in Java, too. It's just considered bad practice.

Still, a very nice read!

They go the other way round and set a "security parameter" that should hold for a particular instance (all the parameters fixed) of their algorithm. That "security parameter" determines how hard it should be for an arbitrary adversary to break the scheme by brute force, and in addition the scheme is only thought to be secure if there is no polynomial time algorithm that can break it in time significantly less than the brute force algorithm would take.

Given such a security parameter, the art is then typically to design the fastest primitive that upholds this same security margin. For example, if two (unbroken) algorithms would take O(2^80) for a brute force Birthday Attack, then you'd conceive the faster of the two as the "better" algorithm. ("Fast" of course can be subjective, e.g. fast in HW or fast in SW etc.)

For one thing, that's simply just because making an algorithm slower is always possible (PBKDF2), but in practice there are a lot of applications (probably more) where a hash should be as fast as possible rather than as slow as possible, as in digital signatures for example.

It's not just that it's endorsed by RSA, no it's actually the NIST recommendation for password hashing and I find it rather unfair that people on this thread turn that against it!

It's the same argument why we generally recommend AES over let's say Twofish or Serpent. We all agreed here that in crypto it's a good thing to be mainstream. And being recommended by NIST makes you Justin Bieber, or not? Standard algorithms may be poor, true, but being a standard has one important advantage: most of the public scrutiny goes into the standard. Much more money and fame there. So it's much more likely that the public will get to know about a flaw in the standard faster than it will get to know about flaws in non-standard algorithms. And that's why I follow standards - even if it's a crappy algorithm, I will know immediately when it's broken and I can react by replacing it right away. The time between an algorithm gets broken and the fact becoming public knowledge is potentially higher the less common an algorithm is. And the time in between being broken and being public knowledge is the most dangerous in my opinion.

I'd like to point out that bcrypt is not equal to Blowfish. It piggybacks on Blowfish's key setup. But note that it just piggybacks, on top of that it further extends the original key setup. Blowfish's key setup was probably never invented to do what bcrypt does now, and the last 30min of googling have not brought up any papers about bcrypt cryptanalysis. Compare that to HMAC. Compare that to using PBKDF2 with HMAC SHA-3 when it's out. I'm not saying that Blowfish or any of its parts are bad, but if not PBKDF2 itself, but then most certainly its building blocks have received a lot more analysis than bcrypt or scrypt. With SHA-3 on the horizon the research community knows a lot more about hash algorithms and there is a lot of research going into these topics. That's why I personally feel safer with a construction that maybe in itself has not received more research than the other two alternatives, but where its building blocks almost certainly have, unless somebody proves me wrong. And when that happens, I'll stand happily corrected and will use the next standard.