Live data from Hacker News

Tptacek's Review of "Practical Cryptography With Go"

gist.githubusercontent.com

91–100 of 255 posts

Re: Tptacek's Review of "Practical Cryptography With Go"

#91
post #89

Earlier quoted context omitted.

How will regulation take care of bad crypto? Even experts get it wrong with some regularity (of course not as often as noobs, but still).

The problem with regulation is that one must first establish who is capable of regulating correctly. There's no such thing as abstract regulation that simply exists. The entities that would most likely do the regulating already exist, but I'm unconvinced any of them would actually improve the situation. For instance, see http://blog.cr.yp.to/20140411-nist.html . What real group of people could really regulate cryptog…

I failed to express myself well. I'm not suggesting that all crypto is immediately regulated, that is completely infeasible. I'm just point out that regulation in general, over all domains, isn't inherently bad.

There is actually some regulation in this space. FIPS compliance, PCI DSS etc.. It's just not as wide reaching as something like the FAA for aeroplanes.

Re: Tptacek's Review of "Practical Cryptography With Go"

#92

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...

Re: Tptacek's Review of "Practical Cryptography With Go"

#93

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…

Open source security projects have a hard time getting and keeping contributors because the expertise for this particular kind of work is difficult to develop.

Publishing a book like this sends a strong public signal of deep expertise.

I have not found tptacek to be overly rude or negative when offering advice to journeyman cryptologists. But a journeyperson should not necessarily be publicizing their how-to guides yet.

Re: Tptacek's Review of "Practical Cryptography With Go"

#94

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…

I firmly believe that you shouldn't author a book in something if you lack the appropriate expertise. If you do so, you risk disseminating misinformation at scale, causing enormous harm.

Sometimes expertise is actually required.

Re: Tptacek's Review of "Practical Cryptography With Go"

#95
I wonder who the intended audience of this review is. The book is clearly geared toward beginners. It would seem a review of such a book should be geared toward those who might read it to learn about cryptography. This review is obviously geared toward some other audience, however. Otherwise a criticism like The book writes its own Diffie-Hellman implementation and recommends it to readers would be backed up and explained, instead of being expected to stand on its own.

Is the audience for this review intended to be cryptography experts, who would not read such a book except to praise or trash it? If that's the case, it seems rather mean spirited. More "wow check this loser out" than "I don't recommend this book to beginners or anyone and here's why."

Re: Tptacek's Review of "Practical Cryptography With Go"

#96
post #66

Earlier quoted context omitted.

I think the tone is what makes it tougher than it needs to be, not the factual content. Props to the author for just looking at the content and not at the way in which it was delivered. Props to Thomas for taking the time to review the book.

You're being downvoted, but I agree that a greater amount of tact would have been warranted. Phrases like "I am not making this up", "argh!" and "huh?" add nothing to the review, but only serve to make it more personal, and I say this as a guy who also has very little tact.

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 reaction is grounded in objective technical reality. I suspect that younger people have this idea that online descriptions of emotional reactions are fictional and purposely crafted for effect -- mostly having to do with emotional aggression. It's true that sometimes "passion" over a subject is used as a pretext for such aggression. That doesn't mean that it's always true, however. In some cases, it's honesty.

That said, "arrrgh" reactions in a technical discipline often indicate a frustrating failure of outreach, education, or communication. I learned things from reading tptacek's review. Maybe he could supervise the ghost-writing of his own undoubtedly excellent book?

(1) - I was riding the bus and this young man had his sneakers tied to the back of his backpack, the soles of which he was pressing into my chest. I tried discretely hinting to him by pressing back, but he was oblivious, so I brought this to his attention.

I was amazed that his first priority wasn't to apologize or help me out, rather it was that I recognize that he didn't mean any harm. Be correct first, then worry about your own ego second.

Re: Tptacek's Review of "Practical Cryptography With Go"

#97

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…

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 chance to see why.

Re: Tptacek's Review of "Practical Cryptography With Go"

#98
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 "backdoored" elliptic curve of prime order over a prime field (in particular, the closest thing resembling such a backdoor, namely Teske's key escrow technique based on isogenies from GHS-weak curves, cannot work over a prime field). Scientifically speaking, I don't see more reasons to believe the assertion that "NIST parameters are backdoored because they aren't rigid" than the (equally unfounded) speculation that "Curve25519 may be weak because it has small parameters/a special base field/composite order/etc.".

Moreover, to say that the NSA has backdoored the NIST curve parameters is to assume that they have known, for quite a long time now, a serious weakness affecting a significant fraction of all elliptic curves of prime order over a given base field that has so far escaped the scrutiny of all mathematicians and cryptographers not working for a TLA. Being leaps and bounds ahead of the academic community in an advanced, pure mathematical subject doesn't quite align with what we know about NSA capabilities.

Don't take this the wrong way: there are good reasons to favor Curve25519 and other implementation-friendly elliptic curves (namely, they are faster, and they are fewer ways of shooting yourself in the foot if you implement them), but "NIST curves are backdoored" is not a very serious one.

Re: Tptacek's Review of "Practical Cryptography With Go"

#99
post #43
post #12

I see the implementation of cryptosystems as an engineering endeavor little different than designing, for example, a commercial airplane, a bridge, or a radiation therapy machine. In all cases you have a system whose failure can result in anything from monetary loss to death (for an example of the latter, faulty cryptographic software used by dissidents in repressive countries). In all cases you use a combination of…

> I see the implementation of cryptosystems as an engineering endeavor little different than designing, for example, > a commercial airplane, a bridge, or a radiation therapy machine. Couldn't agree more. The problem is that for any bridge that gets used, every structural engineer signing off is going to have been educated and experienced to the extent that they are Chartered (or equivalent), the plans for the bridge…

> I see the implementation of cryptosystems as an engineering endeavor little different than designing, for example, a commercial airplane, a bridge, or a radiation therapy machine.

I disagree with you completely and absolutely. Your bridge in Boston isn't going to collapse the moment a researcher sitting in his bathtub in Tel Aviv has a eureka moment.

But if that eureka moment results in a preimage collision in a secure hashing algorithm, that hashing algorithm is broken for everyone all over the world forever. (Practically, as soon as the collision is public knowledge). Cryptographers have to actively seek out this information.

That's why MD5 is deprecated, even though the weakness is weaker than the one I've just stated. (It's just a chosen prefix collision that can be done today - a preimage [chosen hash] attack still takes nearly the full search space.)

Security is applied mathematics, the way engineering is applied physics. But the laws of physics don't change on an annual basis, or the way in which they change is too low-level to apply to engineering, whereas the laws of applied mathematics do.

Systems administrators have to keep up to date on an even more active basis, in some cases needing to patch any system within 48 hours of a public disclosure.

So I simply disagree that as an engineering endeavor implementation of cryptosystems is in any way similar to any other form of engineering.

In fact, for the particular example I used in the above case (a hash), the very existence of the operation is an open problem. ("The existence of such one-way functions is still an open conjecture", Wikipedia.)

What other branch of engineering relies on laws that may well be false?

Re: Tptacek's Review of "Practical Cryptography With Go"

#100

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…

The "experts only" attitude is because, well, as we've seen with HeartBleed, this is VerySeriousStuff.

If the author instead put together a book on how a layperson could perform open-heart surgery, you're damn right that actual surgeons would jump all over it.

There is some strange pervasive attitude/arrogance in tech that all it takes to be good at something is to be smart and give it a try. Why learn the theory/fundamentals when you can just start coding?

For building a web app, sure. But security is not one of those things. You actually need to learn the fundamentals and theory, and even then, need lots of experience.

Post reply on HN