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

51–60 of 69 posts

Re: Go Cryptography State of the Union

#51

Post by the_gipsy »

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.

They're like PHP: silent failures that ever push forwards through the system.

Re: Go Cryptography State of the Union

#52

Post by networked »

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?

I evaluated but didn't adopt https://github.com/awnumar/memguard in Go. No matter how well-implemented and reliable it is, I can't pass its secrets to https://github.com/FiloSottile/age.

I assume all process memory may contain residual secrets. As a mitigation in a password manager and an encrypted file editor, I prevent process memory from being swapped to disk with https://pkg.go.dev/syscall#Mlockall.

Re: Go Cryptography State of the Union

#53

Post by gethly »

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…

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.

Re: Go Cryptography State of the Union

#55

Post by [deleted] »

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…

[deleted]

Re: Go Cryptography State of the Union

#56

Post by 0x696C6961 »

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…

How did you write Go for a living and simultaneously not know anything about the language?

Re: Go Cryptography State of the Union

#57

Post by des429 »

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…

Who are u expecting an answer from?

Re: Go Cryptography State of the Union

#59

Post by mjevans »

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…

You can create a new empty array of variable size backed by a 32 Byte array as it's starting size.

The difference is really that [32]Byte is a single pointer (in compiler hands that you never touch) to a slab of 32 bytes of memory; the []Byte (of internal size 32 use 0-32) has the current allocated size, current used size, and a pointer (none of which you directly touch but two of which are trivial to affect with language semantics) values that point to a 32 Byte backing array.

The only time this matter is timing or performance critical code. With respect to cryptography, timing might be critical for performance, but it's absolutely critical for never taking _variable_ time to perform an operation based on data as well as not on key. In that respect this doesn't matter.

Re: Go Cryptography State of the Union

#60

Post by kbolino »

gethly wrote: post #54
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?

clear([]byte) if you want to go to the extreme and clean your own memory.

This only wipes one copy. The GC is free to move the allocation around, and is not required to clear the old copies.
Post reply on HN