SSH gets protection against side-channel attacks

Post by sedatk » Sat, Jun 22, 2019, 12:59 PM UTC

eridius wrote: post #135

ajaurio wrote: post #114

Could password managers like 1Password (AgileBits Inc.) employ similar techniques? They seem to make very little effort in this regards. E.g. on 1Password, https://discussions.agilebits.com/discussion/101551/article-... .

This kind of mitigation really only makes sense on shared machines (such as servers). On a desktop OS, if an attacker is in a position to read memory from other processes, it's pretty much game over already. Browsers implement Spectre/Meltdown mitigation on desktop OSes because without that, JS could read secrets from other JS contexts executing in the same process. One of the mitigations is in fact to just segregate…

Post by rurban » Sat, Jun 22, 2019, 2:08 PM UTC

cesarb wrote: post #74

simias wrote: post #67

Earlier quoted context omitted.

I've tried implementing a couple of (toy) password managers over the years and dealing with private keys is genuinely complicated. Even something as trivial as making sure that the memory gets zeroed correctly when you discard the key is trickier than it seems. Compilers these days are very good at detecting "dummy" memsets to memory that's never read afterwards and optimize them away. You have to use some dirty tric…

> Compilers these days are very good at detecting "dummy" memsets to memory that's never read afterwards and optimize them away. You have to use some dirty tricks to get the compiler to do what you want (copious amounts of volatile helps). Or you can use explicit_bzero(), which is designed for that use case.

Post by rurban » Sat, Jun 22, 2019, 2:14 PM UTC

saurik wrote: post #90

java-man wrote: post #82

Earlier quoted context omitted.

by explicitly clearing it when an operation is finished. example: https://github.com/andy-goryachev/PasswordSafe/blob/master/s... byte[] key = generateKey(); try { // sensitive operation } finally { Crypto.zero(key); } once the operation finishes, the memory is cleared (and possibly subject to gc) the problem is that some java classes, for instance BigInteger, are not designed for cryptographic operations - it's unde…

In that code, after generateKey, during the sensitive operation, the system might need to do a garbage collection, at which point this array might have been copied to a different location in memory before your call to zero. You have to also "pin" (afaik this is the usual terminology for this) that array to a fixed location (which would then have to be a feature of that runtime and garbage collector) after allocating…

Post by pstrateman » Sat, Jun 22, 2019, 5:24 PM UTC

java-man wrote: post #93

pstrateman wrote: post #89

Earlier quoted context omitted.

That operation is almost certainly optimized out.

Would you elaborate please?

Post by [deleted] » Sun, Jun 23, 2019, 12:12 AM UTC

sedatk wrote: post #151

eridius wrote: post #135

Earlier quoted context omitted.

This kind of mitigation really only makes sense on shared machines (such as servers). On a desktop OS, if an attacker is in a position to read memory from other processes, it's pretty much game over already. Browsers implement Spectre/Meltdown mitigation on desktop OSes because without that, JS could read secrets from other JS contexts executing in the same process. One of the mitigations is in fact to just segregate…

> On a desktop OS, if an attacker is in a position to read memory from other processes, it's pretty much game over already. Not really. Password managers have access information to your other accounts in the cloud. Your desktop may not have your most valuable data.