That is http://www.thevintagenews.com/2017/09/10/the-hoba-meteorite-...

https://en.wikipedia.org/wiki/QBasic#History

Where a side channel attack studying the decryption speed/power use can reveal information, the encoding of said encrypted data can not as far as I ever heard about. (It will still be encrypted after base64 decoding has taken place).

Please correct me if I'm wrong.

EDIT: I see you updated your original message with different wording, please ignore this rant.

My contribution is here: https://github.com/paragonie/constant_time_encoding

https://galois.com/blog/2013/09/high-assurance-base64/

Also, anyone wanting constant time implementation might just run a verified implementation through something like FaCT or Jasmin:

https://cseweb.ucsd.edu/~dstefan/pubs/cauligi:2017:fact.pdf

https://acmccs.github.io/papers/p1807-almeidaA.pdf

I don't.

Where a side channel attack studying the decryption speed/power use can reveal information, the encoding of said encrypted data can not as far as I ever heard about. (It will still be encrypted after base64 decoding has taken place).

Encoding/decoding a value to/from base64 depends on the value, and many implementations use a lookup table or branches. While the table is small, so it fits in CPU cache thus making timing differences harder to detect, it's important for code dealing with secret values to avoid any timing differences by using simple branchless instructions that we know are constant-time on CPUs.

Most SSH hosts store their secret keys encoded in base64 (/etc/ssh/).

Then, there's JWK which supports unwrapped secret keys.

Basically, you can't guarantee that the whole world is only encoding encrypted keys. That's why it's a good software engineering practice to prevent possible attacks by using constant-time encoder/decoder. As you can see from the link in posted, BoringSSL implements one.

Finally, the context of this thread is encoding and decoding of secret data, so I'm not sure why you had to post your opinion stating that it never happens. 1) It happens in real world. 2) I mentioned a solution for the case when it happens.

Care to extend upon why you don't feel go is a good fit for other programming?

    package main

    import (
        "fmt"
        "net/http"
        "path/filepath"
    )

    var (
        host = "0.0.0.0"
        path = "/var/www/public"
        port = 8080
    )

    func main() {
        path, err := filepath.Abs(path)
        if err != nil {
            panic(err)
        }
        listenAt := fmt.Sprintf("%s:%v", host, port)
        fmt.Println("static-serve-dir serving", path, "over http at", listenAt)
        err = http.ListenAndServe(listenAt, http.FileServer(http.Dir(path)))
        if err != nil {
            panic(err)
        }
    }

This time it could be an AVX512 instruction (intel only) that leaks kernel address in a way or another.

I was talking from an ISA perspective. For eg, clflush may be implemented differently between Intel and AMD, it has the same effect on system RAM hence a shared exploit.

No, rowhammer does not need clflush. All rowhammer needs is to be able to write to the same physical memory locations repeatedly. Normally the cache would get in the way, so the attacker needs to bypass it. Flushing the cache (clflush) is one way, but there are others; AFAIK, it has been demonstrated rowhammer from within a Javascript VM, which has no access to clflush.

I just made a bet that I could guess something out of ISA only. Going macro to describe what may be the issue. I'm just doing a guess work here.

I was not implying Intel has the same implementation as AMD, nor I was making a case for "this is like rowhammer"