29 ms·
Tptacek's Review of "Practical Cryptography With Go"
- zurn 13y agoThis 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.
- Nursie 13y agoI recommend Dan Boneh's coursera course, Crypto I, to get a good (basic) grounding in how some of this stuff works. He shows just how easy it is to break bad crypto systems in unexpected ways, and he does it by leading you through 5he attacks and getting you to implement some. Was rather impressed...
- mehrdada 13y ago> 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".
- icambron 13y ago"Don't try this at home" is good practical advice for building real systems that have real users. It's terrible pedagogy, though. You have to learn somehow, and trying it at home is actually how you do that.
- stcredzero 13y agoWell, the message should be, do try this at home, as an exercise, but don't put it into production!
- VMG 13y agoCoursera's "Cryptography I" pays off again -- I know most of the words!
- StavrosK 13y agoStill waiting for Crypto II :(
- Nursie 13y agoMe too. How long overdue now? 2 years? Crypto 1 was awesome, am impatient to do more!
- StavrosK 13y agoYeah, 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.
- smackfu 13y agoIt says it is scheduled for July 21. Don't know how accurate that is.
- jacquesm 13y agoI'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 13y agoHe actually posted this link yesterday as a comment: https://news.ycombinator.com/item?id=7581868 https://news.ycombinator.com/item?id=7581868
- jacquesm 13y agoAh 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 13y agoHaving a concern about the authenticity of a message seems appropriate in a discussion about security :-)
- dbaupp 13y agoFrom the original discussion: https://news.ycombinator.com/item?id=7581868 https://news.ycombinator.com/item?id=7581868
- dylz 13y ago'anonymous' just means that the user was not logged into github when posting the gist.
- zatkin 13y agoFor 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
- e_proxus 13y agoI usually make it a habit to spell out abbreviation the first time I use them and include the abbreviation in parentheses, like Transport Layer Security (TLS). Later, after the first introduction I can safely assume people know it, like TLS. Even for technical documents, if you expect your target audience to be familiar with the domain, nobody remembers every abbreviation every time. It also helps new readers to quickly familiarize themselves with the material (and might even help a few understand more than they would have done without expanded abbreviations).
- tomp 13y agoThis hardly makes any sense: - for the readers who already know the abbreviation, it's a waste of space and time - for readers who don't, the words won't tell them much either - Transport Layer Security tells you about nothing about what TLS really is - besides, for those who are really interested, they can always look it up on Wikipedia (that way, they will actually understand it).
- mhaymo 13y ago> Transport Layer Security tells you about nothing about what TLS really is Doesn't it? Even a complete tech-illiterate can glean some meaning from the word "security".
- austinz 13y agoI 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 13y agoThe 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.
- laichzeit0 13y agoDoes 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 13y agoLet 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.
- deleted 13y ago[deleted]
- olalonde 13y agoHe replied to this question here: https://news.ycombinator.com/item?id=7581885 https://news.ycombinator.com/item?id=7581885 (http://sockpuppet.org/blog/2013/07/22/applied-practical-cryptography/ http://sockpuppet.org/blog/2013/07/22/applied-practical-cryp...)
- obilgic 13y agoHow do we know that this is written by tptacek?
- adamnemecek 13y agoHe posted it in a comment yesterday, read the rest of this thread.
- GuiA 13y agoFrom 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.
- zura 13y agoAt least I got an impression that Tptacek's most points are easily accountable so lets wait for Practical Cryptography With Go, 2nd Ed. :)
- dsymonds 13y agoAn "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 13y agoRemember 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 13y ago>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.
- gojomo 13y agoBrutal 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 13y agoBrutal, 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.
- oinksoft 13y agoThe 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 13y agoI 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.
- deleted 13y ago[deleted]
- riffraff 13y agocan 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_ 13y ago> 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 13y agotptacek is hardly a web developer straight out of high school.
- _delirium 13y agoASN.1 parsers have been the source of a decent number of exploits, producing a bad reputation. Although doing a little looking through CVEs that mention ASN.1, it looks like the vast majority come from one specific ASN.1 parser, the one in OpenSSL, so it might just be that OpenSSL's code is a mess.
- ff_ 13y agoThis is the best feedback the author could receive: a violent but objective review of every weak spot. Well done.
- runn1ng 13y ago> 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 13y agoThere'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 13y agoNo, 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?
- a8000 13y agoOne symmetric cryptography method are one-time pads. Essentially you generate a truly random key (for example by observing some decay process) that has the same length as the maximum length of a message you might want to send and distribute the key to the receiver in advance. You encrypt the message by modular vector addition and decrypt it by subtracting the key. If you use the key only once and it is random, there can't be any attack on this method.
- jgrahamc 13y agoI 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.
- nailer 13y agoIt's a tough thing for anyone to read: it's browserWidth wide and monospaced. Here's a readable version: https://gist.github.com/mikemaccana/10847077 https://gist.github.com/mikemaccana/10847077
- andor 13y agoit's browserWidth wide I like that, because my browser window is resizable.
- Sae5waip 13y agoI don't. So is mine, but resizing it for each individual website is unnecessary work. And some websites have a legitimate need for a wider format, so you can't even say "all websites should be like this".
- jacquesm 13y agoI 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.
- deleted 13y ago[deleted]
- nichochar 13y agoI don't think he liked the book
- mac1175 13y agoAfter 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 13y agoApparently 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
- floatboth 13y ago"S->C nonce, C->S HASH(pw, nonce), HEAD->DESK smash" :D
- raverbashing 13y agoThose 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 13y agoThis 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 13y agoI'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?
- tptacek 13y agoThe bcrypt library.
- raverbashing 13y agohttps://github.com/dcodeIO/bcrypt.js/blob/master/src/bcrypt.js https://github.com/dcodeIO/bcrypt.js/blob/master/src/bcrypt....
- nkozyra 13y agoAs 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 13y agoFriendly 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 13y agoI'm sure that's great advice, but I don't respect anyone. :(
- karmajunkie 13y agoIn 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 13y agoSorry, 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.
- berdario 13y agoCan 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 13y agoHere's the blog post that always gets linked when this comes up: http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ http://sockpuppet.org/blog/2014/02/25/safely-generate-random...
- berdario 13y agoThanks, 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 :)
- solipsism 13y agoI 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."
- mti 13y agotptacek 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 13y agoI 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 13y ago
- mikeash 13y agoAfter 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?
- m0a0t0 13y agoPerhaps the reason people are not commenting on the correctness as much is that it is, broadly, correct. It's quite difficult to add to a discussion when it's already right - there's no debate to be had.
- mikeash 13y agoIn which case, in a sane technical community, I would expect this thread to contain few comments.
- mindslight 13y agoThe tech "community" (if you can even call it that anymore) has jumped a fucking pyramid of sharks. Being right used to be the ultimate trump over social dynamics, which is what made tech a breath of fresh air to so many. Now that the field has become socially popular, it's been mired in the same vapid talking heads as everywhere else. And the people who actually know things are much quieter, as they generally have better things to do than compete for airtime.
- _delirium 13y ago> 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.)
- tptacek 13y agoIf 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 13y agoIt'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."
- MattRogish 13y agoWhen you see someone repeatedly walking up the down escalator you don't give them an attaboy when they reach the top. You tell them to use the right escalator.
- Varcht 13y agoHow 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 13y agoA 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_system_hiding_in_every_mobile_phone http://www.osnews.com/story/27416/The_second_operating_syste...
- pronoiac 13y agoReading 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 13y agoStrong agree. I like Go's crypto library, but wish it had higher-level interfaces.
- feralchimp 13y agoThis 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
- uuid_to_string 13y agoThe author is a systems engineer at Cloudflare.