41–50 of 166 posts
Earlier quoted context omitted.
Where did I say it shouldn't be patched? I just said this is information I think a user would care to know along with the patch.
You said you shouldn't care if it was not found in the wild, this is just wrong
Earlier quoted context omitted.
Ah yes, I too love the panicked rush of trying to force application vendors to patch once we we discover something is being exploited in the wild. Remember defense is depth is a valid strategy.
What I was trying to say was I think library users care to know how urgent it is. If this is being used in the wild then application vendors might need to provide out-of-band patches somehow, and end users should rush to get those patches. If OTOH this is known to be extremely hard to pull off and not known to be used, then it'd be nice for users to know that just the same. Nowhere was I trying to suggest they should…
Earlier quoted context omitted.
I’m really not convinced that this is a realistic concern. And anyway, what you’re posing certainly isn’t a performance concern, but a “does the software work” concern.
"I’m really not convinced". Ok great thanks, neither is anyone else, which is why we'd like numbers.
Why are you concerned about this in the first place? Obviously there's always a general concern about any changes, but what makes this specific change a big deal to you?
Earlier quoted context omitted.
You said you shouldn't care if it was not found in the wild, this is just wrong
You don't even know my requirements or how I use my computers. How do are you so confident it's "just wrong"?
Take my money!
You can donate to OpenSSH[0], whose "funding is generally done via the same donation framework" as the rest of OpenBSD, to which you can donate either directly[1] or via the OpenBSD Foundation[2]. If you're serious about donating obviously please check that these links are legitimate and I'm not a scammer. (I'm not affiliated with OpenBSD in any way.)
[0] https://www.openssh.com/donations.html
Earlier quoted context omitted.
"I’m really not convinced". Ok great thanks, neither is anyone else, which is why we'd like numbers.
Why do you think that this specific change would make ssh not "work at all" as opposed to the hundreds of other changes that happen? Do you even pay close attention to those changes? I for sure don't. Why are you concerned about this in the first place? Obviously there's always a general concern about any changes, but what makes this specific change a big deal to you?
Earlier quoted context omitted.
"I’m really not convinced". Ok great thanks, neither is anyone else, which is why we'd like numbers.
Why do you think that this specific change would make ssh not "work at all" as opposed to the hundreds of other changes that happen? Do you even pay close attention to those changes? I for sure don't. Why are you concerned about this in the first place? Obviously there's always a general concern about any changes, but what makes this specific change a big deal to you?
RAM encryption for sensitive data is overlooked in so many applications, even "highly secure" applications like veracrypt [0] only recently started adding it. In my opinion server-applications of all sorts should encrypt their private keys by default; this makes cold-boot attacks and other memory-escape attacks so much harder, since now two totally unrelated memory chunks have to be combined in order to retrieve the…
Yup, we added this feature to Varnish Cache a few years ago, random key encryption. It generates a random key at startup and encrypts all memory with it. Since this kind of memory is only resident for the lifetime of the process, it works. We stored the random key in the Linux kernel using the crypto API [0] just because its not safe storing any kind of keys in a memory space used for caching (Cloudbleed [1]). We the…
Anyone with the actual link to the specific commit?
Sure: https://github.com/openbsd/src/commit/707316f931b35ef67f1390...
Wouldn't it be possible to block-wise xor the random data onto the key?
Maybe use a windowing mechanism, where the window is moved forward depending on the random data (e.g. for a 16 bit key, xor random bits 0 to 15, then move forward 4 to 16 bits, depending on the current window; iterate until the maximum number of window movements necessary to go over the whole random data is reached [leak less bits via timing]; if the end of the data is reached, again start at the beginning, but with some offset to avoid result_bit_0 = secret_bit_0 xor random_bit_0 xor random_bit_0).
Earlier quoted context omitted.
What I was trying to say was I think library users care to know how urgent it is. If this is being used in the wild then application vendors might need to provide out-of-band patches somehow, and end users should rush to get those patches. If OTOH this is known to be extremely hard to pull off and not known to be used, then it'd be nice for users to know that just the same. Nowhere was I trying to suggest they should…
That's not how security works. If it can potentially lead to a software like openssh leaking secrets, it is of the highest urgency, period. It doesn't matter if it is thought to be hard to exploit and it doesn't matter if it was already found "in the wild".