
Tptacek's Review of "Practical Cryptography With Go" - babawere
https://gist.githubusercontent.com/anonymous/3cc34251e501c2c8ffb7/raw/cf9ff4e7ce13985458b240980e91202ac732b4e6/Practical+Cryptography+in+Go+
======
zatkin
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 Standard
      KDF   - Key derivation function
      CTR   - Counter Mode
      RSA   - Rivest Shamir Adleman (last names of each creator of the RSA algorithm)
      OAEP  - Optimal Asymmetric Encryption Padding
      PSS   - Probabilistic Signature Scheme
      ECDSA - Elliptic Curve Digital Signature Algorithm
      PS3   - Playstation 3?
      DH    - Diffie-Hellman key exchange
      ECDH  - Elliptic curve Diffie-Hellman key exchange
      TLS   - Transport Layer Security

~~~
exDM69
Nice that you composed this list but quite honestly, it isn't very helpful to
know what the letters in the acronyms stand for without knowing what these
things actually are.

Take AES for example, "Advanced Encryption Standard" doesn't really mean
anything. AES is a block cipher, also known as Rijndael. CTR and CBC are block
cipher modes. RSA is a public key cryptosystem, etc. The same applies for most
of these things in the list.

So if someone doesn't know what these things stand for, they're going to have
to go to Wikipedia to check it out anyway, the words behind the acronym are
almost as confusing as the acronyms themselves.

~~~
mhaymo
"Message Authentication Code" is a lot easier to google for than MAC, and more
meaningful in itself too. I found the list helpful.

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

~~~
conformal
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 lot of negative attention
on (this version of) his book.

this pervasive "experts only" attitude is a big part of why "secure" open
source projects have hard times getting and keeping contributors. it is par
for the course for people to be super rude and negative to new participants
instead of trying to encourage them to improve and learn. this lack of
contributors then has a whole array of negative secondary effects, like less
people reading the code for the project.

~~~
tptacek
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 (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.

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

~~~
tptacek
Isom doesn't owe me anything, but the notion that he might arises
straightforwardly from the factionalizing that follows ginned-up outrage,
which is point #2 I was trying to make above.

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

~~~
jvehent
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 needs the two
others, and the rest of the worlds needs all of them. People who write books
are rarely the same people who come up with cryptographic breakthrough.
Instead, they are engineers, and they can use a bit of help to get things
right.

Your review was harsh, because you know more. What, I think, was missing from
it is a bit of "This is a great first step, let me help you make it better so
we can move everybody else forward. Here are my comments."

~~~
Varcht
How can publishing a book purporting to be the way to do security be
considered a first step? A first step would be to get some feed back from
experts prior to publishing. This is the real world where this information is
critical to our future, not something to be taken lightly. On a human level I
have some sympathy for the writer but professionally I think Tptacek's
response is completely acceptable and am glad I read it.

~~~
0xdeadbeefbabe
A short time ago in the information critical real world someone was quietly
exploiting the bug that would become CVE-2014-0160 (heartbleed). Today your
iphone uses really bad software [0]. Today it is easy to be a critic. As for
Tp*'s professionalism, can you figure out if he wants the world to improve or
stay the same?

[0]
[http://www.osnews.com/story/27416/The_second_operating_syste...](http://www.osnews.com/story/27416/The_second_operating_system_hiding_in_every_mobile_phone)

------
GuiA
From tptacek's comment, it sounds like the author of the book may just be an
inexperienced practitioner of cryptography who's only crime is to be too eager
to spread what they've learned.

Someone who picked up the basics from a few Wikipedia articles here, a few
papers there, a couple open source projects here and there... they're smart,
so they're not completely clueless about the field, but they just don't have
the experience to see where they fall short, the industry know-how, and so on.

I feel like instances of this in the tech community are not too rare, and it's
a consequence of the internet: anyone can publish a book and distribute it all
over the world now. It's worth keeping in mind that while harm is being done
through the spread of false information, what's most important is to educate
them, see this as a teachable moment, so they can become productive experts
and modify their message to be fully correct. Of course, it requires them to
be open minded of their shortcomings: but it can be done.

PS: I have no clue who the author of Practical Cryptography With Go is.

~~~
dsymonds
An "inexperienced practitioner of cryptography" should not be writing a book
about cryptography. It's great that such a person is learning, but you
shouldn't be trying to pass on such information at that stage.

(I don't know the author either)

~~~
chipaca
Remember that being wrong about something feels exactly the same as being
right about something, so (extending "being wrong" to "being ignorant") unless
somebody tells them they won't know they still have stuff to learn.

~~~
logicallee
>Remember that being wrong about something feels exactly the same as being
right about something

Not if you extend being wrong to being ignorant, no. When you're right about
something in the sense of not being ignorant, you understand all the
discussions and news easily, you know exactly what everyone is talking about,
including reading academic articles on the subject, etc. When you're wrong
about something your wrongness butts up against the correct model again and a
gain and you're often left confused or unable to understand the actions,
discussions, arguments, and conclusions, of others. (As opposed to seeing
specific places they are wrong.) You can feel this lack of understanding. It
just doesn't feel the same way as properly understanding a subject at all.

I would argue that this review is saying that the author's understanding falls
a little short of par for the course. The author would probably have had a
chance to see this for themselves by getting a little more into the
literature.

~~~
goblin89
Don't forget about Dunning–Kruger effect, though. One doesn't necessarily know
they're ignorant.

------
austinz
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 rigorous testing and analysis from first
principles to try and isolate potential weaknesses. In all cases you want to
ensure the people who worked on the system knew what they were doing and put
the right amount of due diligence into ensuring the system works correctly.

Unfortunately, not even widely used, highly trusted implementations work right
all the time. A out-of-bounds memory bug introduced by an insufficiently
vetted commit opened up a serious flaw in OpenSSL. On a much, much smaller
scale, I once had the misfortune of working with an old version of Microchip's
PIC18 AES library, which had some serious issues that made it nonfunctional
for anything more complex than the toy sample app it shipped with. But with
enough exposure these problems are eventually exposed and fixed. Would a world
where everyone rolled their own bespoke, ad-hoc SSL implementations be more
secure? I doubt it.

In the end, I think there needs to be a cultural shift. People shouldn't be
discouraged from building their own crypto for fun and learning, but they
should be discouraged from deploying it for any application where real
security is required - at least not before undergoing rigorous analysis. One
of the first things Dan Boneh teaches in his Crypto I class is that you should
think very long and hard before implementing your own cryptosystems (i.e.
don't do it), because getting it right is hard, and getting it even the
slightest bit wrong tends to make it useless. And when you consider that
people's livelihoods (their personal information, their money) and even lives
might be jeopardized, taking responsibility as an engineer becomes of
paramount importance. Crypto just doesn't lend itself to a "build an MVP, get
it working, move fast and break things" mindset.

~~~
lkozma
The reason why crypto might be even harder than the other engineering tasks
you mention is that in those the "adversary" is indifferent, not actively
trying to exploit every loophole you might have left. You might build a bridge
that has some small weakness, but no-one will come and stack weights in the
exact pattern that exploits the weakness and makes the bridge collapse.

~~~
dasil003
Beyond that, failure of a bridge or an airplane is not likely to go unnoticed.
Every failure will be investigated, documented and studied. Crypto failure by
contrast can just easily be silent, deadly, and continuously unnoticed for
extended periods of time.

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

~~~
tptacek
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](http://www.hyperelliptic.org/tanja/vortraege/20130531.pdf)

Despite its very weird submission as a story to HN, what you'd been reading
was just a very long HN comment; I wrote it in a single draft and in the style
I would use when writing a comment.

~~~
pbsd
For the sake of historical accuracy, the NIST backdoor argument goes back to
1999 and Michael Scott [1]. I don't really buy it: if the NIST curves can't be
trusted purely by association, then I find it very hard to trust the other
curves as well.

[1]
[https://groups.google.com/forum/#!msg/sci.crypt/mFMukSsORmI/...](https://groups.google.com/forum/#!msg/sci.crypt/mFMukSsORmI/FpbHDQ6hM_MJ)

------
gojomo
Brutal but also in some ways a gift to the author/publisher. Paired with the
1st edition, it cures the major defects.

And, if the criticisms can be addressed, in both specifics and perspective,
for a future edition, they'll have a hardened book... almost sure to earn
another updated expert review ("is it fixed?") at that time.

~~~
vacri
Brutal, but definitely a godsend to the author. Ptacek writes mostly
neutrally, concisely, and clearly, pointing out errors and often putting in
how to fix them. There's a very small amount of "I can't believe..."
statements in there, but they're pretty soft and quite reasonable given his
background. A publisher would love to have this kind of technical review done
on their manuscripts.

------
berdario
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 vulnerable to a cryptographic attack on
> the algorithms used by the driver.

In fact, using /dev/urandom is one of the causes of the creation of weak ssh
key, found in this research:
[https://factorable.net/](https://factorable.net/)

So: Why is /dev/urandom the correct choice over /dev/random ?

~~~
natdempk
Here's the blog post that always gets linked when this comes up:
[http://sockpuppet.org/blog/2014/02/25/safely-generate-
random...](http://sockpuppet.org/blog/2014/02/25/safely-generate-random-
numbers/)

~~~
berdario
Thanks, I never read it before.

Anyhow, its conclusions seem to be mistaken to me:

> It’s also a bug in the Linux kernel. But it’s also easily fixed in userland:
> at boot, seed urandom explicitly. Most Linux distributions have done this
> for a long time.

If you're an application developer (of something that runs very early in the
boot process) but you're not making your own distro, and you can't trust your
distro (I guess that since a lot of factorable keys existed, "Most Linux
distributions have done this" might not actually hold true or count to a good
enough percentage) you don't really have anything else that you can rely on to
seed /dev/urandom explicitly

I'd think that the correct approach is to use urandom on everything but linux
(after all, as long as your application isn't a blocker for the boot of the
system, it doesn't seem terrible to wait for /dev/random)

Also, reading and blocking from /dev/random seems akin to failing early and
explicitly (in the case where blocking on read is actually a problem), while
reading urandom when not initialized seem to be a silent failure.

But I'm not going to write software that has to read from either device
anytime soon, so don't panic if I'm mistaken :)

~~~
maxerickson
Seed it from /dev/random.

------
mikeash
After I finished reading this review, I came to check out the HN comments
knowing that the tone would be the subject of the top comments.

When did this community become more concerned with tone than correctness? The
top of this thread is _filled_ with people saying that the tone is bad, it's
unproductive, it's unnecessary, etc. Yet nobody seems concerned about the
published book filled with bad information that a lot of people are going to
"learn" from. What gives?

~~~
_delirium
> When did this community become more concerned with tone than correctness?

There's been a pretty strong concern about tone on HN from the early days,
mainly (afaict) driven by Paul Graham having an interest in and repeatedly
commenting about it. It's not the _only_ concern, but avoidance of flaming and
mean-spirited comments, _in addition_ to avoidance of vapid or dumb comments,
is one of the openly and repeatedly stated design goals of the community. I.e.
it should be intelligent discussion, conducted in a collegial tone.

(This is a general comment on whether tone is and/or should be important on
HN, not an evaluation of tptacek's review or implication that this
comment/gist in particular would fall afoul of the intended HN standards.)

~~~
mikeash
I have no problem with that. Avoiding flame wars is a noble goal.

The problem I have is that people are freaking out over extremely minor matter
of tone while ignoring important technical problems. Worrying about tone is
fine. Worrying about it to such an extreme degree in preference to other
things is not.

------
jacquesm
I'll take it on faith that Thomas really wrote this (it's his style), but
would the real Thomas 'H' Ptacek please acknowledge that he indeed wrote this
(it is labeled 'anonymous').

~~~
nairteashop
He actually posted this link yesterday as a comment:
[https://news.ycombinator.com/item?id=7581868](https://news.ycombinator.com/item?id=7581868)

~~~
jacquesm
Ah cool! Thanks. It seemed a little strange to have his name used so
prominently in the title here linked to something that did not have his name
attached to it or in any other way easily associated. Call me paranoid ;)

~~~
arethuza
Having a concern about the authenticity of a message seems appropriate in a
discussion about security :-)

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

~~~
mehrdada
> I read Schneier's & Ferguson's Practical Cryptography years ago

I cannot take anyone who advocated MAC-then-Encrypt, in 2010, seriously (in
the book _Cryptography Engineering: Design Principles and Practical
Applications_ by Niels Ferguson, Bruce Schneier, Tadayoshi Kohno).

The school of cryptography they subscribe to seems to be "crypto is black
magic; this is tried and it works and it is pretty much secure because I feel
it is secure; experience is everything; proofs can have bugs too" as opposed
to a more principled, analytical, methodical, provable security.

This is especially problematic in pedagogical contexts, because the learners,
by definition, do not have much experience or calibrated feelings, so they'll
be lost or have to copy the design decisions of the authors without taking
into account the contexts or that they might be flat wrong. That approach
indeed implies the natural advice to someone who wants to learn will be "don't
try it at home".

------
runn1ng
> The book _actively recommends_ public key cryptography, because of concerns
> about key distribution. Again: bad strategy. Cryptographers use public key
> crypto only when absolutely required. Most settings for cryptography don't
> need it! Public key cryptography multiplies the number of things that can go
> wrong with your cryptosystem.

Can I ask why? What is so dangerous with asymmetric crypto compared to
symmetric crypto?

~~~
mehrdada
There's one, admittedly theoretical difference, at least: there is such a
thing as perfectly (information theoretically) secure symmetric encryption
scheme (regardless of the computational power of the adversary), but
asymmetric crypto, by definition, relies on being computationally infeasible,
not information theoretically impossible.

Even though it's theoretical, the side effects of this fact surface from time
to time as engineering issues in asymmetric crypto: all information that the
attacker might need to break asymmetric crypto is more or less in the
ciphertext, intuitively suggesting it's easier for asymmetric crypto to
catastrophically go wrong.

~~~
runn1ng
No, I still don't get it. How is information about the private key in the
ciphertext?

It's great that one-time pad exists, but it's not really relevant in actual
crypto code, right?

The only actual reason I can think of is that symmetric crypto is easier to
write and understand - you just mangle and xor some text back and forth, while
in asymmetric crypto, you need to understand fairly complex algebra. But
again, that's not that important if you use existing primitives, right?

------
laichzeit0
Does Tptacek have a list of books/articles he would recommend to the Crypto
neophyte? I'm talking about books which could be considered de facto standards
like Knuth's TAOCP or Steven's TCP/IP books.

~~~
duongkai
Let check the profile of tptacek. In his profile, there is a his reading list.
Grab some book about cryptography.

Or you can browse his blog, Practical Cryptography or Cryptography Engineering
may be a good start.

------
riffraff
can someone explain this?

    
    
        * This book, I am not making this up, contains the string: "“We can use ASN.1 to make the format easier to parse".
    
    

Last time I had something to do with ASN.1 was years ago but it seemed to work
well, libraries were full featured and cross-language interop was ok. What am
I missing that makes ASN.1 bad ?

Or is the critique to an attempt to write a custom ASN.1 serializer/parser?

~~~
_pmf_
> Last time I had something to do with ASN.1 was years ago but it seemed to
> work well, libraries were full featured and cross-language interop was ok.
> What am I missing that makes ASN.1 bad ?

Didn't you know? If a web developer out of high school cannot read a format at
first glance, it's obviously over-engineered and useless and anyhow everybody
should always use JSON anyways.

~~~
slavak
tptacek is hardly a web developer straight out of high school.

------
ff_
This is the best feedback the author could receive: a violent but objective
review of every weak spot. Well done.

------
VMG
Coursera's "Cryptography I" pays off again -- I know most of the words!

~~~
StavrosK
Still waiting for Crypto II :(

~~~
Nursie
Me too. How long overdue now? 2 years? Crypto 1 was awesome, am impatient to
do more!

~~~
StavrosK
Yeah, they're just pushing it back :( Crypto I was the only course I couldn't
get enough of, I did all the exercises and all the extras and got 100% at the
end, it was fantastic. Dan Boneh explained everything very very well.

------
oinksoft
The last paragraph of this review is in poor taste. The most cursory research
into the author's "CryptoBox" shows that indeed this project is _inspired_ by
NaCL.

~~~
appleflaxen
I found the last paragraph helpful. It's great that NaCL inspired him, but why
use the same name for something different? Libraries and packaging are hard
enough without sound-alikes.

------
feralchimp
This is a great review for two reasons:

a) it provides readers with a laundry list of things to go study independently

b) the book author can, given time and inclination, do the same study and
improve the book

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

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

~~~
nkozyra
I'm sure that's great advice, but I don't respect anyone. :(

~~~
karmajunkie
In that case, you should probably reexamine a few things, starting with why
you don't respect anyone: * are you writing about something "revolutionary"?
If so, reexamine your work, as there are very few new ideas that have never
been written about or studied before. You almost certainly have missed the
previous work on the subject. * Is it because you live somewhere isolated with
few of your peers nearby? Welcome to the internet—i'd be willing to bet you
can probably find the people writing about what you're writing about and ask
them to review it. * Is it because of your ego? I think you can figure out
what to do with this one.

Even if your work is on something fairly esoteric, you can almost certainly
find someone qualified to review it on technical grounds, even if they're not
an acknowledged expert in the precise topic you're writing about.

~~~
nkozyra
Sorry, thought my comment was glaringly tongue-in-cheek. The publisher has
located some extremely esteemed folks to evaluate and frankly it's gotten me
even more self-conscious about what I've written.

I have been unable to locate another _book_ on this subject (its
implementation in Go, anyway), but there are scores of experts in Go, many of
whom are far more qualified than I am. I would respect their opinions on the
book itself.

~~~
karmajunkie
Ah, my apologies then—tone can be hard to grok here sometimes.

Best of luck in the process! Would you care to share the subject area? Now
you've piqued my curiousity...

~~~
nkozyra
General and practical concurrency in Go.

This was challenging primarily because it's so idiomatic and easy to handle in
Go, so a good deal of the book talks about pitfalls, testing and
implementation.

------
raverbashing
Those with glass ceilings shouldn't throw stones

While criticism is good, the condescending way it is presented, as well as
being overly critical are bad. Example:

"Total undue reverence for NIST and FIPS standards; for instance, the book
recommends PBKDF2 over bcrypt and scrypt (amusingly: the book actually
recommends _against_ scrypt, which is too new for it) because it's
standardized."

I know people love scrypt and bcrypt, and have been proven safe _so far_ , but
there are advantages to use standardized methods. An implementation can make
something less safe than the standard.

~~~
tptacek
This is silly. There is no advantage to using PBKDF2 other than to placate
PHBs. PBKDF2 (as commonly implemented, with HMAC-SHA2) is faster than bcrypt
and scrypt and particularly straightforward to implement in GPU crackers.

bcrypt is also approximately the same age as PBKDF2.

And, finally, standardization is a very poor substitute for security analysis.
PKCS1v1.5 is also a standard. If you want to argue against bcrypt, you'll have
to marshal actual arguments.

~~~
raverbashing
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?

~~~
mpyne
> 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't like RSA because of da Feds, why not use the known-good
OpenSSL for securing data in motion instead of something new and untested like
stunnel or spiped?

Known implementations are a very good consideration factor. You _should_ use
TLS (though maybe not OpenSSL's) in general instead of designing your own
secure transport. But being from a known implementation should not be the
_only_ factor you consider otherwise you're just cargo culting. You have to
understand pros/cons of each solution, even if that means you have to learn a
little bit about the problem space.

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

~~~
mpyne
> 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?

------
pronoiac
Reading this makes me think that the Go crypto primitives could use a lot more
plumbing; it would make them more useful, and avoid some pitfalls by making it
easier to do the right thing.

~~~
tptacek
Strong agree. I like Go's crypto library, but wish it had higher-level
interfaces.

------
mac1175
After reading this, could anyone recommend a good intro to crypto book? I see
a lot of good reviews of Bruce Schneier's Applied Cryptography.

~~~
scintill76
Apparently the same reviewer says it's worse[0], unless he's talking about a
different book. This surprises me based on Schneier's popularity, but having
not read the book and not being an expert on crypto, I wouldn't know.

[0]:
[https://news.ycombinator.com/item?id=7597970](https://news.ycombinator.com/item?id=7597970)

------
obilgic
How do we know that this is written by tptacek?

~~~
adamnemecek
He posted it in a comment yesterday, read the rest of this thread.

------
uuid_to_string
The author is a systems engineer at Cloudflare.

------
nichochar
I don't think he liked the book

------
floatboth
"S->C nonce, C->S HASH(pw, nonce), HEAD->DESK smash" :D

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

