141–150 of 255 posts
Earlier quoted context omitted.
If I had written a book on implementing cryptography I've been throwing $20 bills at my monitor so that your book will start downloading, but it doesn't seem to be working. But really, you should write one.
No, I'm not even close to qualified to write that book.
Earlier quoted context omitted.
This book doesn't come within an astronomical unit of being the worst book on cryptography I've read; _Applied Cryptography_ is far worse. Which is why I didn't write anything like "goddamn this is literally the stupidest book that has ever been written".
Sorry, I have a habit of not clarifying enough. I'm not saying you said that, I'm just pointing out that one can say the same thing more innocuously if one is a bit more dry/factual.
For those of you who don't know what the acronyms stand for, I've compiled a list, in order by their appearance: AES - Advanced Encryption Standard CBC - Cipher Block Chaining PKCS - Public Key Cryptography Standards SHA - Secure Hashing Algorithm MAC - Message Authentication Code PBKDF - Password-Based Key Derivation Function NIST - National Institute of Standards and Technology FIPS - Federal Information Processing…
Welcome to HN. I see that you are new here so I would like to give you a little friendly advice. If you have to make a long list like this on HN use the pre/code formatting (two spaces at begining of line). Long lists like this take up a ton of space. I have a sneaking suspicion this is the a deliberate design choice so that people link to reference resources and use the comments for discussion. Compare: AES - Advanc…
If I had written a book on implementing cryptography in Golang, I assure you that someone else would have reviewed it harshly too. It's simply a difficult subject to get right.
That said, you first point seemed silly. Simplified, partial and building block examples are used in almost all fields to facilitate teaching (including among medical students and surgeons). They are useful because they keep people moving along the process, teaching them terms, skills and concepts they will need to get to the next step in the process.
What is your alternative method for teaching someone unfamiliar with these concepts in a way that won't just put them out to sea without a paddle?
Earlier quoted context omitted.
I'm not arguing against bcrypt/scrypt per se. I'm arguing that there may be advantages in using standardized methods (for interoperability) and especially implementations. Which one is safer, using PBKDF2 from a known implementation or the "bcrypt library" for Ruby/Node that someone just posted to github? Oh what do you mean that's not how you read secure random numbers?
The bcrypt library.
I happen to know the author of this. This was a really tough thing for him to read, but he's taking it as constructive criticism. I would add to the people commentating here on HN: tptacek's review is tough; you do not need to lay into the author of this book any more.
DISCLAIMER: i know and have worked with kyle (the author). while the factual content of tptacek's review may be spot on, his overall tone is very negative and smacks of "only experts allowed" logic. while he could have easily helped improve kyle's book and shared these comments privately, he instead chose to lambast kyle publicly, which doesn't really help anybody: tptacek looks like a total jerk and kyle now has a l…
Here, your attitude causes two problems.
First, you know and apparently like Kyle Isom, and so I presume you're also ready to tell me that he's an adult and a professional. Professionals do one of three things with criticism: ignore it, rebut it, or learn from it. My assumption has been that Kyle is choosing options (1) and (3) from that list. But here you are, inventing option (4): "get indignant about it". I wonder if you've thought about the extent to which people will attribute that response not to you, but to Isom.
Second, whatever you might think about the tone of my feedback, it's clear that Isom needs additional technical review for his book. Whipping up a totally unproductive us-versus-them narrative about "jerks" versus "open source" does the opposite: it generates drama. Even if you think my review was itself dramatic, piling more drama on doesn't make Isom's work more attractive to experts.
I'm not sure how big of a deal either of these issues are, but they're a bad habit for message board denizens. The exact same thing happened to Willem when he wrote his critique of the Akamai allocator, and Hacker News had a totally unproductive drama storm for a couple hours before Akamai (a) thanked Willem and (b) acknowledged that he was absolutely correct. Read the Akamai comments on the HN thread, and apply them here, substituting "Kyle Isom" for "Akamai", and I think you'll see that they apply.
Finally, I'll admit to being personally irritated by the claim that I operate from "experts only" logic with regards to cryptography. There are at last count something like twelve thousand people who have reached out to us for our free crypto challenges, and thousands of those people have gone on to solve multiple sets of challenges (something like 60 people have finished the first 6). Every damn one of those people is an email exchange that me, Sean, or Marcin had to have directly, on our own time, with no compensation --- the opposite of compensation, in fact, because we donate to charity when people finish them.
There are a lot of people on the Internet to whom you could direct the "experts only elitism" criticism regarding crypto. I am not one of them.
What's more annoying about that bogus critique is how it muddles a real issue. I'd like many more people to understand crypto and, particularly, what goes wrong when it's implemented naively. But I'd like far fewer people to plow ahead and implement their own broken stuff. The track record on amateur cryptography is bad, and what developers don't like to acknowledge is that the badness that work generates is an externality to them. People have in the real world been hurt, physically, because of broken amateur crypto. It is hard for me to take the hurt feelings of developers all that seriously by comparison.
If I had written a book on implementing cryptography in Golang, I assure you that someone else would have reviewed it harshly too. It's simply a difficult subject to get right.
In keeping with the philosophy of being hands on; would the book be improved if after introducing the code in the first section, have the reader implement an exploit for the same code?
Earlier quoted context omitted.
You know what else is hard? Writing a book on cryptography. It's all very well and good to point out problems, but there are probably more productive ways to teach people than simply point out what not to do.
When you are writing about a difficult subject, you should invite reviews from experts to vet your work.
Earlier quoted context omitted.
No, I'm not even close to qualified to write that book.
You trumpet NaCl's crypto_box and mentioned other language runtimes are deficient in one way or another, but what do you think about security of crypto in the Java standard library?
If you have the option to use NaCl, use NaCl. A Java-specific alternative to NaCl is Keyczar.
tptacek makes a number of good points but I find it hard to agree with this one: > there is concern that the NIST curves are backdoored and should be disfavored and replaced with Curve25519 and curves of similar construction. Of course, "there is concern" is pretty vague, but it should be made clear that such concerns are in the realm of pure speculation at this point. There is simply no known way of constructing a "…
I actually agree with most of this. The issue with the NIST P- curves is that there's no good reason to trust them. And, for what it's worth, being ahead of academia on pure math isn't science fiction; NSA employs a lot of mathematicians. But the notion of a backdoor in the NIST curves is totally speculative. Here's what I was trying to capture: http://www.hyperelliptic.org/tanja/vortraege/20130531.pdf Despite its ve…
[1] https://groups.google.com/forum/#!msg/sci.crypt/mFMukSsORmI/...