No, we use assembly for access to specialized (e.g. AES-NI) or vector instructions, and we do so reluctantly. We much prefer writing cross-platform constant time Go. https://go.dev/wiki/AssemblyPolicy
Hah, touché my friend. It's just that every time I think about touching that page it scope creeps into making it autogenerated from the kernel sources via CI etc. etc. :)
Go is as susceptible to timing side channels as C, if not less. (The difference being that while there is one major Go compiler, which usually does not go overboard with optimizations, when writing C you have to do increasingly complex tricks to defend against the compiler realizing what you are trying to do and replacing it with a more efficient variable-time branch.) This implementation was written to avoid any secret dependent code path.
Power side channels, which require physical access, are indeed outside the threat model of Go.
Cryptography has a peculiar approach to the threat of quantum computers, because it is not acceptable for some of the data and connections encrypted today to become decryptable even thirty, fifty years in the future. That means that the question is not "are QC coming soon" but "might QC plausibly come into existence in the next half century". Since the answer, despite not having a precise consensus, is not "no", here we are.
This is also why you are seeing a lot more progress on PQ key exchanges, as opposed to signatures: signature verification today is not affected by QC fifty years from now, while encryption is.
There is also the problem of embedded devices. Some of these will still be operational in 20 years, at which point a "cryptographically relevant quantum computer" might exist. So we want to ensure today that these devices can support post-quantum algorithms, and depending on the device, this support might need side-channel and fault protection.
In some cases we can add support with a device firmware update, but things like secure boot flows and hardware accelerators can't always be updated in the field. And we need to make sure that the devices are fast enough, have big enough key storage, RAM and packet sizes, etc to support the new algorithms.
It's also important to have an established history of use and vetting so by the time PQ is needed, systems with a long history of security are available
I have a wishlist for v2 changes, and I am considering slowly and carefully making such a release this year, but the difference in security between scrypt and Argon2 doesn't really justify making a change there.
Yeah, replacing the hash would take a fork. Note that this implementation spends only about 20% of CPU time in SHA-3, so the gain wouldn't be massive. That proportion would probably grow after optimizing the field implementation, but almost certainly not enough to make it worth using a non-standardized, less-tested mode.
No, something being under github.com/google means the person who started it was paid by Google, not paid by Google to code this. Google contracts (like most tech contracts in the US) have ridiculously broad IP assignment clauses, so unless you go through a lengthy process to request Google disown something, they own anything you code, and they insist you open source your things under github.com/google.
You decide your own definitions, but that's very different from "Gmail by Google" or even "Go by Google" in my book. Note how the main author has "Ex-Google" in their bio, too.
No, please don't send me emails in a format that will not reflow readably on my phone, especially if I didn't use the same format when emailing you. (The Fastmail instructions explicitly say to disable "When replying, use the same format as the original message".)
That sounds like a bug in your phone. Perhaps you should report it to the vendor? Even my ancient Emacs mail reader can reflow plain text emails when I ask it to do so. It sometimes needs to be told on a paragraph-by-paragraph basis, because otherwise it might also reflow ASCII art diagrams and such, but in practice I find it a minor problem.
> It sometimes needs to be told on a paragraph-by-paragraph basis, because otherwise it might also reflow ASCII art diagrams and such
Yes exactly, there is no "one right way" to do it because you never know if a newline is a "hard enter" or just a "reflow to the next line". Every default will break something.
This is why you need some (minimal) markup, no matter what you do text-only email is broken for some use cases.
It's a tradeoff. I'm willing to accept some clumsyness in return for conceptual and technical simplicity. Others may feel different. In practice, most people who write plain text emails manage to format them pleasingly themselves (and 72 column plain text is perfectly readable on my phone, although I prefer not reading email there).
"Attack surface" in this case, boils down to bugs and fuck ups. "Massive" is subjective but justified in my opinion too. A message delivered via http or https is the same - one is encrypted on wire and one is not. There is a minimal cost of encryption these days. We are long past the point where a CPU gets bogged down with it.
I still contend that "everything should be encrypted" is cargo culting:
An unencrypted webby stream does not expose a browser to anything nastier than an encrypted webby stream. The eventual payload is the same, regardless of the transport. The difference is that the browser has to use vastly more code paths to do the same job of receive -> display. It has to decrypt the stream. That additional complexity introduces vastly more possibilities for bugs.
So, I think you should pick your medium with care. I do think that https is a safe transport for all messages and do routinely use it myself. I have done a risk assessment on it - I don't simply use it because everyone else says its a good idea 8)
I deliberately used the pejorative term "cargo cult" in this discussion.
> An unencrypted webby stream does not expose a browser to anything nastier than an encrypted webby stream. The eventual payload is the same, regardless of the transport.
No, my point is that an unencrypted payload is controlled by anyone on your network path (your ISP, anyone on the same open WiFi, ...), so it can be nastier than an encrypted payload. Remember that TLS provides not just encryption, but also authentication.
We are now in the realms of risk management etc. An unencrypted TCP stream still has sequence numbers - famously abusable in the past. You can still use them to be reasonably sure that your stream is untampered with, with care.
I'm talking about integrity - ie what I sent is what you received or what I requested you to send is what I received.
TLS does only provide encryption, it does not authenticate anything. You can use TLS as a wrapper for auth - to make the exchange private or you could pre-arrange a swap of public keys (certificates) via a method that is mutually agreed. That mutually agreed bit is the authentication part but it has nothing to do with TLS per se.
You click on a website link that starts with https://, most people allow their browser to use its trust store to decide whether to proceed. Increasingly, browsers are becoming opinionated about this, which is bloody annoying for IT bods.
Should you trust MS/Google/Apple/KDE/Mozilla int al to tell you who is trustworthy? No and they don't really (tell you who is trustworthy! All they do is tell you which certification authorities follow the rules. There are not too many rules and they certainly do not ensure anything as such. What you are nearly guaranteed is that if you use things like "Perfect Forward Secrecy" (which cannot be perfect, by definition) and a few other tricks ... your conversation is probably private.
Authentication is a whole new ball game as they say several thousand miles to my left and down a bit!
That's the whole point of a TKey as a security device: the secret available to an application depends on both the device it's running on and the application, and can't be extracted, so you can do things like "sign a blob only if it follows these rules" and enforce it in hardware. If the device wasn't locked, you could just... change the rules.
You're more than welcome to change the rules. Please read my other comments in this thread, and you'll hopefully find answers to your concerns. The TKey Unlocked gives you all the control you're asking for.
The actual implementations are in that tree, too: https://cs.opensource.google/go/go/+/master:src/crypto/