231–240 of 255 posts
This is a good illustration of how, 1) crypto is hard 2) real-world cryptosystem design & implementation is hard and 3) teaching the aforementioned is hard. I read Schneier's & Ferguson's Practical Cryptography years ago, the only thing I remember about it is the "don't try this at home" message.
Earlier quoted context omitted.
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…
I understand where you're coming from, but the author is the one who put this out in public. Publishing a book like this sends a strong message of "I am an expert, take what is written here as fact". Maybe the tone could have been a little softer, but this should not have been done privately. The criticism of the work needs to be just as public as the work itself, so that people who might have been misled have a chan…
And we, of the Internet age, should be shocked to learn this is no longer true! Eric Drexler once proposed that hypertext would save the world by allowing such peer review. Just what are we collectively missing when it comes to crypto?
Earlier quoted context omitted.
Isn't this the problem, then? People here seem to think you are , and by reading you I get the impression that they're right. I don't believe that you won't write a book because you're not qualified : you just don't want to write one. And that's a good enough reason. I think the community in general is very harsh towards anything related to cryptography. It's as if you shouldn't bother writing code unless you have ma…
I don't know how to say this other than directly: you're wrong. I shouldn't write a book on how to design cryptosystems, because I'm not qualified to do it, and I'll get things wrong. I can barely write an HN comment on crypto without being corrected by 'pbsd and 'cperciva. I am an odd duck, even for my odd little field: I'm a software security person who has spent a couple years getting decent at breaking crypto, an…
Interesting. When I worked at Entrust, our cryptology team consisted of both cryptographers and cryptanalysts. The former were math PhDs who spent their entire graduate careers designing cryptosystems, so by the time they came to us, they knew what they were about. The latter - well, there was only one when we got started - was a B.Eng. who got interested in crypto at BNR, taught himself the basics, and became one of the top cryptanalysts in the world.
You and he probably have much in common - including not being qualified to design cryptosystems! Like you, he would have said to leave that to the experts.
Then he would have quite happily spent weeks and months figuring out what those experts missed, thereby advancing the field.
It puzzles me to this day that so few in the security field appreciate the difference between the two types of cryptologists.
Earlier quoted context omitted.
While reading your review, one of the main criticisms seems to be that the it's not made sufficiently clear that the code as written is insecure. 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?
I feel comfortable with the idea of writing a book showing people how to break badly-implemented crypto designs, so much so that Sean, Alex, and I are in fact writing that book; it'll be a "pay-what-you-want" directly to a preferred charity. If anyone can point us to someone who will take our money to expertly typeset a giant text file, that would be helpful. I do not feel remotely comfortable with the idea of writin…
Earlier quoted context omitted.
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…
It's good to stick up for people. It's less good to be thin-skinned on someone else's behalf. 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…
Earlier quoted context omitted.
I feel comfortable with the idea of writing a book showing people how to break badly-implemented crypto designs, so much so that Sean, Alex, and I are in fact writing that book; it'll be a "pay-what-you-want" directly to a preferred charity. If anyone can point us to someone who will take our money to expertly typeset a giant text file, that would be helpful. I do not feel remotely comfortable with the idea of writin…
Is your book also based on golang crypto lib ?
Earlier quoted context omitted.
> Which one is safer, using PBKDF2 from a known implementation or the "bcrypt library" What kind of dilemma choice is that? It should rather be: "Which one is safer, using PBKDF2 from a known implementation or bcrypt from a known implementation?" But even that question is erroneous. After all, why shouldn't we just use PBKDF2 from RSA's known BSAFE implementation? What could possibly go wrong with that? Or if you don…
Yes, "Bob's bcrypt lib" is safer (apart from some serious mistake or compromise, which are not rare) than hashing your passwords with a rock-solid sha1 library. "But being from a known implementation should not be the only factor you consider otherwise you're just cargo culting" Of course In the same way some people blindly answer "use bcrypt" to any mention of password hashing.
It's almost like there was a reason I explicitly decried cargo culting (yes, that counts too) and blind answers instead of understanding.
Could you try to read and understand the comments that are left instead of responding to points that were never made?
Earlier quoted context omitted.
It's good to stick up for people. It's less good to be thin-skinned on someone else's behalf. 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…
Isom should thank tptacek for providing thousands of dollars in free consulting/editing work. He'll probably be a better engineer because of this feedback and the next edition of his book should be a lot better.
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.
It's not specific to cryptography. There is a hierarchy in all fields: 1. Top researchers come up with algorithms and techniques - The research corpus reviews them 2. Top programmers implements these techniques - The programmers communities review them 3. Top engineers write books to explain these techniques - which everybody else relies on in their tools 1 knows more than 2 which knows more than 3. But each group ne…
Can someone explain me this? > In considering RSA, the book recommends /dev/random, despite having previously advised readers to avoid /dev/random in favor of /dev/urandom. The book was right the first time. From "man 4 urandom": > A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vuln…
Here's the blog post that always gets linked when this comes up: http://sockpuppet.org/blog/2014/02/25/safely-generate-random...