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]byte` could at least communicate to me that the level of security is at most 256 bits. And removing all dependencies on rand would make it obvious where the entropy must be coming from (the seed parameter). Cloudflare's CIRCL[0] library does a bit better, but shares some of the same problems.

[0] https://github.com/cloudflare/circl

▲ FiloSottile 8 hours ago | parent | next [-]

> 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.

▲ tialaramex 8 hours ago | parent | next [-]

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.

	▲	0x696C6961 an hour ago \| parent \| next [-]
		How did you write Go for a living and simultaneously not know anything about the language?
	▲	des429 36 minutes ago \| parent \| prev \| next [-]
		Who are u expecting an answer from?
	▲	7 hours ago \| parent \| prev \| next [-]
		[deleted]
	▲	throwaway894345 7 hours ago \| parent \| prev [-]
		> 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.

▲ alphazard 8 hours ago | parent | prev | next [-]

> 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.

	▲	FiloSottile 8 hours ago \| parent [-]
		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.)

▲ stouset 8 hours ago | parent | prev | next [-]

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.

▲

FiloSottile 8 hours ago | parent | next [-]

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.

▲

kalterdev 8 hours ago | parent | prev | next [-]

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

	▲	tialaramex 7 hours ago \| parent \| next [-]
		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.
	▲	the_gipsy 4 hours ago \| parent \| prev \| next [-]
		They're like PHP: silent failures that ever push forwards through the system.
	▲	throwaway894345 7 hours ago \| parent \| prev [-]
		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.

▲

2 hours ago | parent | prev [-]

[deleted]

▲ amluto 6 hours ago | parent | prev [-]

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.

▲ kbolino 5 hours ago | parent | next [-]

Right now, type casts (called conversions in the spec) always produce a single value. The idiomatic way to have checked casts would IMO be a two-value form, as this would be consistent with type assertions, channel receives, and map indexing, off the top of my head. End result would be something like:

  var x []byte
  y, ok := [32]byte(x)
  // ...

However, it feels like a relatively significant change to the language just for a niche use. Even the ability to cast from []T to [N]T or *[N]T is actually fairly new (Go 1.20 and 1.17, respectively). I don't think it's that hard to check the length before casting, though a checked cast would be convenient since you wouldn't have to repeat the length between the check and the cast.

▲ XorNot 5 hours ago | parent [-]

But it would be a subvariant of a much more common pattern in code - destructuring which is quite noisy now but could just be:

  a, b, rest := strings.Split(somestr, "/")

Which would be conventional for the whole thing, and the check would be for an empty type after rest.

I usually wind up using something like the samber/lo library to reduce the noise here. You wind up doing this all the time.

	▲	kbolino 5 hours ago \| parent [-]
		I must disagree. Destructuring is nifty, but it is almost completely unrelated. The second value in any of the builtin two-value assignment forms is invariant on the type or size of RHS; it's always a boolean, and its meaning relates to the "kind" of RHS, not the exact type: `msg, ok := <-ch // ok means "channel ch is not closed" val, ok := m[key] // ok means "map m contains key" dyn, ok := i.(T) // ok means "interface i's dynamic type is T or implements T"` This new operation would be similar: `arr, ok := [N]T(s) // ok means "slice s has len(s) == N"` For all of these cases, ok being true indicates that the other value is safe to use.

▲ 6 hours ago | parent | prev [-]

[deleted]

▲ gethly 4 hours ago | parent | prev [-]

Try creating new AES cypher, you will see that you have to provide 16, 24 or 36 bytes in order to get AES-128, AES-192, or AES-256. There is no single [32]byte, for example, as the length cannot be inherently fixed due to this.