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

11–20 of 69 posts

Re: Go Cryptography State of the Union

#11

Post by OhMeadhbh »

jsheard wrote: post #5
OhMeadhbh wrote: post #3

I'm more of a C person than a Go person, but I am unbelievably happy that someone in that community is using the word "cryptography" to mean cryptography and not Bitcoin.

Wasn't it just the shorthand "crypto" that got co-opted by the Shitcoin Industrial Complex? I think "cryptography" still means what it always meant regardless of who you ask.

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.

Re: Go Cryptography State of the Union

#12

Post by OhMeadhbh »

OhMeadhbh wrote: post #3

I'm more of a C person than a Go person, but I am unbelievably happy that someone in that community is using the word "cryptography" to mean cryptography and not Bitcoin.

Downvoted for mentioning that people confuse cryptography with Bitcoin? Good thing I didn't mention I think we're in an AI bubble. Or that I prefer emacs to vi.

Re: Go Cryptography State of the Union

#13

Post by FiloSottile »

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 have bad failure modes. 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). If you do a copy(seed, foo) it's WAY WORSE, because you risk copying only 5 bytes and leaving the rest to zero and not noticing.

Instead, we decided to move the length check into the library everywhere we take bytes, so at worst you get an error, which presumably you know how to handle.

> why we can't just pass in a seed value to a single unambiguous constructor when generating asymmetric keys

I am not sure what you are referring to here. For e.g. ML-KEM, you pass the seed to NewDecapsulationKey768 and you get an opaque *DecapsulationKey768 to pass around. We've been moving everything we can to that.

> Or how the constructor for a key pair could possibly return an error, when the algorithm is supposed to be deterministic.

Depends. If it takes a []byte, we want to return an error to force handling of incorrect lengths. If the key is not a seed (which is only an option for private keys), it can also be invalid, deterministic or not. (This is why I like seeds. https://words.filippo.io/ml-kem-seeds/)

> removing all dependencies on rand would make it obvious where the entropy must be coming from (the seed parameter)

Another place where experience taught us otherwise. Algorithms that take a well-specified seed should indeed just take that (like NewDecapsulationKey768 does!), but where the spec annoyingly takes "randomness from the sky" (https://words.filippo.io/avoid-the-randomness-from-the-sky/) in an unspecified way, taking a io.Reader gave folks the wrong impression that they could use that for deterministic key generation, which then breaks as soon as we change the internals.

There is only one place to get entropy from in a Go program, anyway: crypto/rand. Anything else is a testing need, and it can be handled with test affordances like the upcoming crypto/mlkem/mlkemtest or testing/cryptotest.SetGlobalRandom.

Re: Go Cryptography State of the Union

#14

Post by FiloSottile »

edoceo wrote: post #2

I'm curious about how GC languages handle crypto. Is it a risk that decrypted stuff or keys and things may be left in memory (heap?) before the next GC cycle?

You might find this proposal and the upcoming runtime/secret package interesting.

https://github.com/golang/go/issues/21865

Re: Go Cryptography State of the Union

#15

Post by FiloSottile »

alphazard wrote: post #9
edoceo wrote: post #2

I'm curious about how GC languages handle crypto. Is it a risk that decrypted stuff or keys and things may be left in memory (heap?) before the next GC cycle?

It can be, another risk it that a secret value is left on the stack, and is never overwritten because the stack doesn't get to that memory address again, so it's never overwritten or zerod. Go really just needs a few `crypto.Secret` values of various sizes, or maybe a generic type that could wrap arrays. Then the runtime can handle all the best practices, like a single place in memory, and aggressive zeroing of any c…

It's not that simple! What about intermediate values during arithmetic computations? What about registers spilling during signal handling?

I honestly thought it could not be done safely, but the runtime/secret proposal discussion proved me wrong.

Re: Go Cryptography State of the Union

#16

Post by kunley »

OhMeadhbh wrote: post #12
OhMeadhbh wrote: post #3

I'm more of a C person than a Go person, but I am unbelievably happy that someone in that community is using the word "cryptography" to mean cryptography and not Bitcoin.

Downvoted for mentioning that people confuse cryptography with Bitcoin? Good thing I didn't mention I think we're in an AI bubble. Or that I prefer emacs to vi.

Let's revert the self-scrutiny trend and actually enjoy a fellow mentioning his downvote. At least I am enjoying, your perception is valid.

Re: Go Cryptography State of the Union

#17

Post by jsheard »

OhMeadhbh wrote: post #11
jsheard wrote: post #5

Earlier quoted context omitted.

Wasn't it just the shorthand "crypto" that got co-opted by the Shitcoin Industrial Complex? I think "cryptography" still means what it always meant regardless of who you ask.

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.

Re: Go Cryptography State of the Union

#18

Post by tialaramex »

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…

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 make the parameter a duration. It seems like this ought to be a similar situation.

Re: Go Cryptography State of the Union

#19

Post by stouset »

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…

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 brain-dead approach to zero values (making it functionally impossible to structurally prevent using zero IVs). But it just serves as yet another reminder that golang’s long history of questionable design choices actively impede the ability to design safe, hard-to-misuse APIs.

Post reply on HN