Unpopular opinion: it's not actually possible to selectively scrub secrets from memory in complex applications. You can zero all process memory, but I don't believe zeroing just secrets after use works. (Manually, without taint analysis.)
-
Show this thread
-
After using an AES key, you scrub it. Did you also scrub the key schedule computations? What about an RSA key CRT values? We can't keep track of what we need to free() without sanitizers, why do we think we can keep track of every secret byproduct?
11 replies 11 retweets 65 likesShow this thread -
Replying to @FiloSottile
I hear what you're saying, but there's a kind of magical thinking to this. Scrubbing the key barely matters compared to scrubbing the data we were encrypting in the first place. Why do we fetishize the former and barely think about the latter?
1 reply 1 retweet 6 likes -
Replying to @colmmacc @FiloSottile
Using the key involves some kind of memory disclosure plus network tapping. But memory disclosure on its own gets you the data you were after directly in most cases.
Seen that way, it should be clear that data
-ing is for everything.2 replies 0 retweets 1 like -
Replying to @colmmacc @FiloSottile
Network tapping or disk access/theft I should say; for durable data.
1 reply 0 retweets 1 like -
Replying to @colmmacc
Oh, I agree, I'm not saying we need to get better at scrubbing, I'm saying we need to stop doing it, and if it was actually important, find other solutions (like process isolation). (Something's wrong with Tweetdeck, sorry for the tweet-and-delete.)
1 reply 0 retweets 3 likes
Ah, ok! If it does matter: process isolate, mlock(), MMAP_DONTDUMP, and memset() *everything*, ideally scrubbing streams as they are flushed out. Hard and a painful performance hit and so rarely seen :(
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.