Hacker News Reader

Comment by njtransit | Hacker News Reader

This looks like a very simple wrapper around golang.org/x/crypto/nacl/secretbox

What’s the point of this?

To remove/obscure structure from a token so that the structure is not relied upon & can be changed in backwards incompatible ways without disrupting API consumers.

If you think it's internal details are too simple to justify a dependency, you can vendor or reimplement it, but that's orthogonal to whether it's pointless. The README is pretty detailed & explicit about what the point is.

But nothing about the API is specific to pagination. This library essentially is just two other API calls: marshal and seal. It can do this operation on any marshal-able type. By using this library, you lose control over marshaling, which seems like a high cost to pay for this very simple and basic functionality.

Would the library be better if it were more restrictive or more complicated?

No, the library would be better if it provided some utility. As it stands, it provides negative utility.

You're conflating how it works internally with whether it's useful. You've critiqued is internal details but you haven't engaged with the premise of why you might want to use it.

A coin is just a metal disk. A dollar bill is just a piece of paper. Neither of them do anything. After adopting them, you lose control of how your cash is represented. And yet we find them useful.

A simple implementation is a virtue, not an albatross.

No, I'm sorry, you are not correct. I am not conflating internal implementation with whether or not it is useful. Rather, I am evaluating the opportunity cost, i.e. comparing this library to the "next best thing."

For this library, the next best thing would be to make two simple API calls instead of one simple API call. As a cost, this is very low. However, the "next best thing" also has a number of desirable properties compared to this library: better support for custom serialization and a lower attack surface for supply-chain attacks. When you look at the costs vs. the benefits of this library, the utility is negative.

Using your example of currency: a paper bill is not just a piece of paper. It's a piece of paper coupled with the vast machinations of a nation state that can enforce its currency via its monopoly on violence. You can't get all the benefits of a $100 bill just by having a green piece of paper.

It was presumptive of me to tell you what you were thinking, and I apologize.

Huh. Anyone know why the nonce isn't baked into the box upon sealing?

It's the same in the original: https://nacl.cr.yp.to/secretbox.html

The operation doesn't dictate how the nonce is to be conveyed to the recipient.

Yes, but since you never want to reuse the nonce (at least not with the same key; and no one stores nonces for later use), they are 1:1 to the message, suggesting it would have been less error-prone to encode it in the box.

I had the impression NaCL was about being highly opinionated, so this choice surprised me.

Relatedly, what's the advantage of that secretbox package over calling https://pkg.go.dev/crypto/cipher#NewGCM ?

NaCl predates GCM by some 15 months. But that's an old concern, both are pretty old by now.

NaCl tends to be faster on hardware without AES acceleration.

Go's AES/GCM implementation is not constant time unless the hardware has AES acceleration.

Reply on news.ycombinator.com