Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tptacek's Review of "Practical Cryptography With Go"

gist.githubusercontent.com

Post reply on HN
Print view View original

241–250 of 255 posts

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

#241

Post by _delirium »

mikeash wrote: post #109

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 o…

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

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

#242

Post by bdamm »

sillysaurus3 wrote: post #185
tptacek wrote: post #149

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…

In my opinion having sensitive keys in Java, or pretty much any software stack, is not the correct way to go.

We should turn to hardware solutions for access to raw keys. Let the software stacks do what they do well, which is accelerate users and engineers.

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

#243

Post by tptacek »

pronoiac wrote: post #156

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.

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

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

#244

Post by bdamm »

tptacek wrote: post #153
MetaCosm wrote: post #144

Earlier quoted context omitted.

Most of your review seemed to be utilitarian and useful for a second edition. That is awesome, the way you structured it means the author could use a ton of it, and it gives readers specific things to be aware of. Sincere thanks for that. That said, you first point seemed silly. Simplified, partial and building block examples are used in almost all fields to facilitate teaching (including among medical students and s…

The author doesn't demand that his readers implement AES or SHA2 directly. So, what I would do is start with a simple, secure design based on an AEAD like AES-GCM, which is also in the Golang standard library. I would accompany that design with very strong warnings that substituting AES-GCM for anything else is likely to destroy the security of the design. Then, when I wanted to teach about generically composed MACs,…

I would buy that book in a heartbeat, no matter what language it was written for.

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

#245

Post by bmm6o »

sillysaurus3 wrote: post #185
tptacek wrote: post #149

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…

I don't buy the argument about GC being a hindrance. If you have sensitive data (e.g. a key) that you don't want sitting around in your process memory, you should wipe it as soon as you are done with it (e.g. zero out the byte array). Just because there is a GC doesn't mean that it's the only way to clean up a resource. String is immutable in both Java and C#, so if you are holding a password in an instance of one it can be difficult to overwrite the backing memory, but this is a separate argument from GC causing problems. This is the problem that SecureString is meant to solve http://msdn.microsoft.com/en-us/library/system.security.secu....

Regarding GC performance, maybe there's an avenue for attack there. You could potentially infer the amount of garbage being generated by an implementation, which seems like it could be variable in a PK implementation. I can't really think of a way to generate variable amounts of garbage without doing variable amounts of computation, so I think you're already leaking timing information. [Actually I can, but not in a way that seems natural].

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

#246

Post by heavenlyhash »

sillysaurus3 wrote: post #185
tptacek wrote: post #149

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…

I suspect that constant factor memory usage should go hand in hand with the criticality of constant factor cpu usage.

If a constant time cpu algorithm was not also constant factor memory, then the timing of cache misses (or gc, alike) would certainly be subject to side channel attacks.

If constant factor memory usage is attained, I cannot easily think of a way that a garbage collector could cause an interference that leaks information. (Though by all means, one ought think harder than I have.)

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

#247

Post by mikeash »

_delirium wrote: post #241
mikeash wrote: post #109

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 o…

> 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 state…

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.

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

#249

Post by tzs »

tptacek wrote: post #214
tzs wrote: post #212

Earlier quoted context omitted.

Wow...e=1? That makes me feel better about my biggest crypto goof, which I had assumed was the stupidest mistake anyone had ever made with RSA, but e=1 is worse. Briefly, I was doing a single RSA encryption on the client and corresponding RSA decryption on the server as part of a login procedure, and using e=3 (which, at the time, was considered acceptable by most experts). Due to licensing issues the client code had…

Yes, that actually happened: https://github.com/saltstack/salt/commit/5dd304276ba5745ec21... There's an interesting real-world RSA bug related to yours: in the absence of proper padding, it's possible that e=3 RSA of a small plaintext might not wrap the modulus. A similar cube root operation produces a signature that naive implementations (the ones that check the digest embedded in a signature block, but not the padd…

I have signed up for the first set of challenges, although I doubt I'll do well on them. I'm not very good at that kind of challenge--with crypto I tend to do better on the theory side [1] than on the practical side when it comes to dealing with breaking things.

[1] by "theory" I mean vigorous and convincing hand waving and white board diagramming...

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

#250

Post by Jugurtha »

stcredzero wrote: post #96
stavros wrote: post #66

Earlier quoted context omitted.

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 r…

I agree. Sometimes, the frustration also builds up if someone is witnessing a trend of nonsense, and he reads yet another thing following that trend, which triggers the writing of a rant.

That said, it's funny that most these rants aren't ad hominem, unlike some of the "formatted" vitriol which attacks you without really seeming to do so.

Someone should watch EEVBLOG on Youtube, Dave Jones does reviews and teardowns of electronics.

There was a rant over PICKit3 where he voiced his frustrations with the new device (that wasn't better than the old one, and took out nice features, replaced things that worked perfectly with things that were sort of dumb) which triggered Microchip to answer with a funny video their own.

Your tale about the boy ... Arrrghh ! I don't want to go off topic, but man, I think nothing gets diluted more than values each year.. Well, except shares of a startup once VC's get in.

Post reply on HN