221–230 of 255 posts
Earlier quoted context omitted.
I have a personal problem with ASN.1, and with authenticate- then- obliviously- decrypt. I don't know the author of this book at all and reject the implication that the review had a personalized tone. Having said that: had I written the "review" as an actual "review", and not as an oversized HN comment that I had to make a Gist out of to get it onto the site, I would have written it more carefully.
I'm not saying the review was personal, it's pretty clear that you're only talking about the facts. It's just that there are phrases that have a lower "hurt-to-information" numerator with the same denominator.
As long as criticism doesn't cross the "bright lines" of ad hominem or gratuitous ridicule, as a third party reader, I much prefer the targets toughen up, rather than the critics soften their language. And there are way more third-party readers than critics or their targets.
Earlier quoted context omitted.
I never said what my tone was on the bus -- it was blunt and matter of fact. My observation was about the young man's reaction . I take exception to your post, as it suggests I said something I didn't.
My point was more about the way you leapt from tptacek's review of the crypto book to the incident on the bus, which implies that they're comparable situations, when really they're not. Not all cluelessness is equal. > I take exception to your post I demand satisfaction! Pistols at dawn, my good fellow! Pistols at dawn!
Ugh. My point in the previous comment -- for the second time -- is not that I'm not comparing the situations. I'm comparing the reactions. Not all cluelessness is equal, and for the second time I never said that! However, oversensitivity to criticism due to a prioritization of feelings/ego generalizes nicely across both situations.
I demand satisfaction! Pistols at dawn, my good fellow! Pistols at dawn!
I only take challenges from people with basic literacy and reading comprehension. Your comments only demonstrate the former, my good fellow. (Or, if this is the 2nd iteration of a deliberate troll through the subtle placing of words in another's mouth, I'll merely comment that I'd be a bit surprised if someone actually thinks this is clever, and note that this would disqualify a challenger though insufficient intellectual integrity.)
Earlier quoted context omitted.
Out of curiosity, how could it have been better?
There isn't a whole lot. I think removing some of the emotional language would help. I prefer my technical articles to be a "just the facts, ma'am" and make an effort to write that way myself. I think it could also have benefitted from some additional explanation of the right way, beyond just pointing out the wrong way. For example, I would love to have seen a brief explanation of why hash functions aren't MACs, and…
A purely "just the facts" version might need a "how bad on a scale of 1-10" or something to get the same information across, and would be less readable.
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?
> 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…
"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.
Earlier quoted context omitted.
The JCA provides primitives, not whole designs. Primitives are rarely broken; even PHP mcrypt manages to successfully provide low-level crypto primitives. Most of the things that go wrong in cryptography happen at the points where two primitives join to form a more elaborate construction. The JCA isn't much help there. If you have the option to use NaCl, use NaCl. A Java-specific alternative to NaCl is Keyczar.
Speaking of Java crypto, I have a question. Is it possible a garbage collector might be dangerous to crypto code? I've seen it mentioned on HN that maybe we should be worried about implementing crypto code in a language with a non-deterministic GC, but sadly I can't find those comments right now. TextSecure's crypto is implemented in Java, which is of course garbage collected. Some cursory Googling suggests that Java…
The (non-default) CMS and G1 GCs will do as much as they can in background threads before they have to stop the world. For more information see http://www.oracle.com/webfolder/technetwork/tutorials/obe/ja... and http://www.cubrid.org/blog/dev-platform/understanding-java-g.... I only know about this because I kept encountering long, GC-related pauses on my Minecraft server that went away when I switched to the concurrent mark-sweep collector. :)
As someone finishing the final edits of a technical book (on Golang, at that) this is the kind of thing that horrifies me. I want to go through every single chapter and rewrite it to stave off the imaginary critics in my head who will undoubtedly tear it apart.
Friendly advice, find a few people you respect on the subject and ask them to review it. Wards off a lot of the anxiety and will generally make your work a lot better.
Earlier quoted context omitted.
There has been a cultural shift in recent years. None of tptacek's observations are adhominem. But there is now an expectation that one tone down the description of one's own reaction. I suspect this is often a conflict between the expectations of the children of helicopter parents and my generation. (1) Sorry, but I have a right to an emotional reaction to your content and a right to describe it, especially if the r…
Amost all aggressive reactions are partly contrived and controlled, even if they're occasioned by genuine emotion in the actor. You can see this from the fact that you very rarely see someone give a strongly hostile or contemptuous emotional reaction to their boss or someone else whose reaction they fear. Somehow the guys who just have strong feelings, or just have to tell it like it is, manage to tell it in a much m…
This is presuming that such fear is always the input to a conscious decision. That doesn't fit my observations of human nature. Power relationships always have some bearing on the nature of an interaction, so what you're saying is comparable to telling an aquatic species that they're wet.
Also, going by what you say, you should have more respect for those who tell truth to power, or tell their more famous/more highly regarded colleagues the plain truth. Perhaps tptacek should be more humble because he's more famous, but if it comes to the choice of him being frustrated by widespread crypto cluelessness or by a desire to dominate others, I think the former makes far more sense.
Earlier quoted context omitted.
There isn't a whole lot. I think removing some of the emotional language would help. I prefer my technical articles to be a "just the facts, ma'am" and make an effort to write that way myself. I think it could also have benefitted from some additional explanation of the right way, beyond just pointing out the wrong way. For example, I would love to have seen a brief explanation of why hash functions aren't MACs, and…
Personally I like the emotional language, because it lets someone slightly less familiar with the field get a sense of how bad each thing is. A purely "just the facts" version might need a "how bad on a scale of 1-10" or something to get the same information across, and would be less readable.