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

21–30 of 69 posts

Re: Go Cryptography State of the Union

#21

Post by FiloSottile »

stouset wrote: post #19
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…

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…

I'm not sure what you are referring to, but we were talking about keys, not IVs.

Also, "an unambiguous key type that can be constructed from a []byte or responsibly generated on your behalf" is exactly what crypto/mlkem exposes.

Re: Go Cryptography State of the Union

#22

Post by OhMeadhbh »

jsheard wrote: post #17
OhMeadhbh wrote: post #11

Earlier quoted context omitted.

That's mostly the case, but I've seen job postings for "cryptography experts" that are, as best I can tell, looking for block chain hucksters. But I'm unlikely to work for Microsoft, so I just ignore them.

Well yeah, someone hired to work with the low-level nuts and bolts of blockchains would ideally need to know their way around actual bona-fide cryptography.

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.

Re: Go Cryptography State of the Union

#23

Post by jsheard »

OhMeadhbh wrote: post #22
jsheard wrote: post #17

Earlier quoted context omitted.

Well yeah, someone hired to work with the low-level nuts and bolts of blockchains would ideally need to know their way around actual bona-fide cryptography.

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.

Oh no I'm not speaking from experience, just saying that in principle you would want actual cryptography experts in that position, so there's no contradiction in terms. How that tends to play out in practice is another question.

Re: Go Cryptography State of the Union

#24

Post by alphazard »

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…

> If you do a ([32]byte)(foo) cast, you risk a panic if the file/packet/whatever is not the size you expected (e.g. because it's actually attacker controlled)

Can you give an example of a situation where that is actually a concern? It doesn't really seem like a realistic threat model to me. Knowledge of the key is pretty much how these algorithms define attackers vs. defenders. If the attacker has the key that's gg.

There are lots of things in Go that can panic. Even in syntax, the conversion is very similar to an interface conversion, and those haven't been a problem for me in practice, partly because of good lint rules to force checking the "okay" boolean.

Re: Go Cryptography State of the Union

#25

Post by FiloSottile »

alphazard wrote: post #24
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…

> If you do a ([32]byte)(foo) cast, you risk a panic if the file/packet/whatever is not the size you expected (e.g. because it's actually attacker controlled) Can you give an example of a situation where that is actually a concern? It doesn't really seem like a realistic threat model to me. Knowledge of the key is pretty much how these algorithms define attackers vs. defenders. If the attacker has the key that's gg.…

A cloud service that lets users upload their certificates and private keys, to be served by the service's CDN. Here the attacker is attacking the system's availability, not the key.

(But also, it's easy to see how this is a problem for public keys and ciphertexts, and it would be weird to have an inconsistent API for private keys.)

Re: Go Cryptography State of the Union

#26

Post by piekvorst »

stouset wrote: post #19
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…

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.

Re: Go Cryptography State of the Union

#28

Post by FiloSottile »

OhMeadhbh wrote: post #22
jsheard wrote: post #17

Earlier quoted context omitted.

Well yeah, someone hired to work with the low-level nuts and bolts of blockchains would ideally need to know their way around actual bona-fide cryptography.

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.

Re: Go Cryptography State of the Union

#29

Post by tialaramex »

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.

Zero values prioritize implementation convenience (we always have a zero value so we don't need to handle any cases where we don't have a value, just says those are zero) over application convenience (maybe my type should not have a default and the situation where it has no value is an error)

Take either of Rust's library types named Ordering - core::cmp::Ordering (is five less than eight or greater?) or core::sync::atomic::Ordering (even if it's on another core this decrement definitely happens before that check) neither of these implements Default because even though internally they both use the zero bit pattern to mean something, that's a specific value, not a default.

Re: Go Cryptography State of the Union

#30

Post by SAI_Peregrinus »

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.
Post reply on HN