Hacker News Reader

Comment by tatersolid | Hacker News Reader

I would love to see this used in a FIPS-compliant variant of age[1] for archival file encryption use cases. We had banking industry auditors veto age for this use case due to the use of ChaCha instead of AES (they were fine with the X25519 public key part of age which I think was somewhat recently approved by NIST).

I’ve no experience with golang but it seems like it should drop right in based on the age spec. I might give it a shot if time ever permits. I guess I should call it “cage” as in “compliant actually good encryption”

1: https://github.com/FiloSottile/age

View on HN

> “compliant actually good encryption”

an oxymoron, perhaps

also an unfortunate acronym

> they were fine with the X25519 public key part of age which I think was somewhat recently approved by NIST

As far as I can tell, Ed25519 is approved (FIPS 186-5), but X25519 is still not (yet).

FWIW Go doesn't have an implementation of XAES in the stdlib yet, there's only the reference implementation in C2SP.

Thank goodness. I am kind of sick of the constant churn in the crypto package.

I get that you want to keep up to date with security, but the entire crypto tree is basically a playground for Filippo Valsorda at this point. Meanwhile stuff that I actually need like CMAC is "won't fix"

What's another language with a stdlib that includes CMAC?

Zig[1].

[1] https://ziglang.org/documentation/0.11.0/std/#A;std:crypto.a...

Erlang / Elixir

Link? Does Elixir even have cryptography in the stdlib?

https://www.erlang.org/doc/apps/crypto/crypto

Elixir can call Erlang/OTP modules directly, so they also have access to that same module. Erlang/OTP is a hard dependency for Elixir afaik.

Gotcha, thanks!

What churn does the crypto package get? It's part of the standard library and so bound by the compatibility promise, which basically freezes existing things in place.

see for yourself

https://github.com/golang/go/commits/master/src/crypto

so pretty stable, and you're mad that other people won't do free work for you to implement a mostly unused spec.

There's a lot of this kind of entitlement around.

Trash other peoples' work as "playground" activity, and demand they work on something else for free.

Churn implies upheaval, breaking things that used to (and ought to) work. I don't see examples of that from the first few commits I examined.

bge, bureaucratic good encryption.

Reply on news.ycombinator.com