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

Go Cryptography State of the Union

words.filippo.io

Post reply on HN
Print view View original

31–40 of 69 posts

Re: Go Cryptography State of the Union

#31

Post by throwaway894345 »

tialaramex wrote: post #18
FiloSottile wrote: post #13

Earlier quoted context omitted.

> I don't know why the standard library crypto packages insist on passing around `[]byte` for things like a seed value These are actually very deliberate choices, based on maybe unintuitive experience. We use []byte instead of e.g. [32]byte because generally you start with a []byte that's coming from somewhere : the network, a file format, a KDF. Then you have two options to get a [32]byte: cast or copy. They both ha…

It's been many years since I wrote any Go for a living, but does Go seriously lack a way to say "foo is probably 32 bytes, give me the 32 byte array, and if I'm wrong about how big foo is, let me handle that" ? If the caller was expected to provide a duration and your language has a duration type, you presumably wouldn't take a string, parse that and if it isn't a duration return some not-a-duration error, you'd just…

> It's been many years since I wrote any Go for a living, but does Go seriously lack a way to say "foo is probably 32 bytes, give me the 32 byte array, and if I'm wrong about how big foo is, let me handle that" ?

Not in the static type signature, but you can do that as a runtime check either by casting and handling the potential panic (as described above) or by checking the size and returning an error if it's not as expected, which is what the library does.

Re: Go Cryptography State of the Union

#32

Post by throwaway894345 »

piekvorst wrote: post #26
stouset wrote: post #19

Earlier quoted context omitted.

Those aren’t arguments for having []byte instead of [32]byte like you think they are. They’re arguments for having an unambiguous IV type that can be constructed from a []byte or [32]byte, or responsibly generated on your behalf. The error-handling logic can be expressed once in the conversion process, and the rest of your crypto APIs can assume the happy path. Of course, this isn’t really reasonable given golang’s b…

What’s wrong with zero values? They free the developer from guessing hidden allocations. IMO this benefit outweighs cast riddles by orders of magnitude.

I'm not nearly as angsty as the parent on this subject, but they don't really free the developer from guessing about hidden allocations--Go's allocations are still very much hidden even if developers can reasonably guess about the behavior of the escape analyzer. I think it would have been better if Go _required_ explicit assignment of all variables. That said, despite not being a big fan of this particular decision, Go is still by far the most productive language I've used--it strikes an excellent balance between type safety and productivity even if I think some things could be improved.

Re: Go Cryptography State of the Union

#35

Post by [deleted] »

tialaramex wrote: post #18
FiloSottile wrote: post #13

Earlier quoted context omitted.

> I don't know why the standard library crypto packages insist on passing around `[]byte` for things like a seed value These are actually very deliberate choices, based on maybe unintuitive experience. We use []byte instead of e.g. [32]byte because generally you start with a []byte that's coming from somewhere : the network, a file format, a KDF. Then you have two options to get a [32]byte: cast or copy. They both ha…

It's been many years since I wrote any Go for a living, but does Go seriously lack a way to say "foo is probably 32 bytes, give me the 32 byte array, and if I'm wrong about how big foo is, let me handle that" ? If the caller was expected to provide a duration and your language has a duration type, you presumably wouldn't take a string, parse that and if it isn't a duration return some not-a-duration error, you'd just…

[deleted]

Re: Go Cryptography State of the Union

#36

Post by amluto »

FiloSottile wrote: post #13
alphazard wrote: post #6

I don't know why the standard library crypto packages insist on passing around `[]byte` for things like a seed value, or why we can't just pass in a seed value to a single unambiguous constructor when generating asymmetric keys. Or how the constructor for a key pair could possibly return an error, when the algorithm is supposed to be deterministic. It all just seems a bit sloppy. Asking for a seed value like `[32]byt…

> I don't know why the standard library crypto packages insist on passing around `[]byte` for things like a seed value These are actually very deliberate choices, based on maybe unintuitive experience. We use []byte instead of e.g. [32]byte because generally you start with a []byte that's coming from somewhere : the network, a file format, a KDF. Then you have two options to get a [32]byte: cast or copy. They both ha…

boggle

I’m not a golang programmer, but I find this quite bizarre. Sure, C++ arrays are awful and even std::array may not be able to legally alias a vector. But Rust (no surprise) gets this right — there is a properly fallible conversion from slice reference to array reference.

But I guess Go doesn’t. This seems silly to me.

Re: Go Cryptography State of the Union

#38

Post by fl0ki »

SAI_Peregrinus wrote: post #30
pregnenolone wrote: post #27

I agree with the author’s sentiment about FIPS 140. I find NIST to be incredibly slow. I understand there must be some stability, but they are too slow. For example, I think it's horrible that they are still recommending PBKDF2 in 2025.

A big part of the problem I have with it is that it's a "ceiling" on security. Things like electrical code or building code are a "floor" on quality, you have to be at least as good as the code requirements , but can freely be better. FIPS-140 bounds you both ways. If you could more easily do better it'd be much less of a problem that NIST are slow.

In fairness, it's one thing for an implementation like a building to be as over-enginereed as possible in its own right, but it's another when a standard has to ensure that multiple implementations can interoperate. I'm not saying FIPS-140 has only that kind of limitation (far from it), just that this isn't the best analogy.

Re: Go Cryptography State of the Union

#39

Post by OhMeadhbh »

FiloSottile wrote: post #28
OhMeadhbh wrote: post #22

Earlier quoted context omitted.

Respectfully disagree. My experience is that they've read a couple chapters from Applied Cryptography and think "IACR" is a router manufacturer. But we all see different parts of the industry. Happy to hear you're encountering more capable people in that industry.

There are definitely better cryptographers than me working at Zcash, for example.

I was at Microsoft for meetings once and one of the guys asked if I was a cryptographer. I replied that it depends on who else is in the room. If it's just me and my boss, I'd probably qualify as being a cryptographer. But if I'm in the room with Niels Ferguson or Adi Shamir, I should be considered a software engineer who is somewhat decent at reading math papers. At about the same time, Niels Ferguson walked in the room and I quickly commented "you should not consider me a cryptographer for the rest of this meeting."
Post reply on HN