61–69 of 69 posts
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?
Not sure why you'd think GC'd languages carry more risk.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
I don't love FIPS either, but cryptosystems don't work the same way as buildings and electrical codes. It's very easy to have "secure cryptosystem A" and "secure cryptosystem B", and then have massive security holes in "cryptosystem A + B". This happens all the time, and is one of the main reasons for the classic "don't roll your own crypto" admonition. The FIPS "whole system" mandate is meant to forestall this failu…
IIRC the first wago parts (221) were UL-listed in 2017, the 221 were released in 2014, and the original push-lever splices (the 222) were released in 2004.
Earlier quoted context omitted.
This only wipes one copy. The GC is free to move the allocation around, and is not required to clear the old copies.
Wrong, the []byte is a pointer. There is no copy anywhere. That's why using []byte in encryption makes sense - you can wipe it out whenever you need, whereas string, the only immutable type in Go, would be a problem. Same can be done with array([32]byte).
The process of actually moving allocated memory around by the GC is known as compaction. It's not done aggressively today but Go reserves the right to do so in the future.
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'm pretty sure that C's free() and C++'s delete() will happily leave private data on the heap also. Not sure why you'd think GC'd languages carry more risk.
Earlier quoted context omitted.
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?
This reminds me of a C programmer confidently insisting to me that bool had "always" been a keyword. Nope, only since C23 - but it had been used like a keyword anyway. So it makes sense many practitioners wouldn't know that.
Earlier quoted context omitted.
How did you write Go for a living and simultaneously not know anything about the language?
Because ten years ago Go was a rather different language? Because I don't work only in languages where I would consider myself an expert and so be confident I know every feature ? This reminds me of a C programmer confidently insisting to me that bool had "always" been a keyword. Nope, only since C23 - but it had been used like a keyword anyway. So it makes sense many practitioners wouldn't know that.
It was not.
Earlier quoted context omitted.
Yeah, there's a ton of correctness testing involved. That's mostly at the algorithm, rather than the module level, so it'll fall under CAVP/ACVP rather than CMVP.
That's not for interop, that's for "are you actually doing the crypto you said you'd do". It's designed to prevent broken crypto, not to ensure coordination between parties.