SSH gets protection against side-channel attacks

yjftsjthsd-h wrote: post #5

Unfortunate that there's no commentary on performance impact. It's symmetric encryption on a few kB, so probably fast, but I'd like to have numbers.

If I understand correctly it's effectively a one-time constant cost when setting up an encrypted connection, so it should be negligible unless you have a use case for setting up many extremely short-lived connections.

Re: SSH gets protection against side-channel attacks

#8

Post by hvidgaard » Fri, Jun 21, 2019, 12:14 PM UTC

baq wrote: post #2

> Hopefully we can remove this in a few years time when computer architecture has become less unsafe. I think the author misspelled 'decades' here :)

But why? For security critical software, like this, they should assume as little as possible. In essence you want to make the algorithms immune to side channel attacks when possible.

Re: SSH gets protection against side-channel attacks

#9

Post by mehrdadn » Fri, Jun 21, 2019, 12:15 PM UTC

yjftsjthsd-h wrote: post #5

Unfortunate that there's no commentary on performance impact. It's symmetric encryption on a few kB, so probably fast, but I'd like to have numbers.

Far more important than that what I want to know is whether I should even care, e.g. is there any evidence of Spectre being used in the wild or not.

Re: SSH gets protection against side-channel attacks

#10

Post by Koffiepoeder » Fri, Jun 21, 2019, 12:16 PM UTC

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 private key (in fact one could argue that, the higher the quantity of memory chunks is, the harder it is to correctly decrypt the original private key; although to me this has the security through obscurity smell).

In practice however, this is rarely done. OpenSSL for example has a whole lot of memory-management functions [1], but none of them seem to include RAM encryption (AFAIK it is not present in the source code elsewhere either, but it's a large one, so I am not familiar with all code. Related: in fact some people even argue it's way too large for it's own good [2]).

Even better still, would be to use the CPU Cache for private keys, since this memory is even more difficult to access through any sort of cold boot. An interesting paper with much more information about this subject can be found here [3], to whom it may concern.

[0] https://github.com/veracrypt/VeraCrypt/commit/321715202aed04...

[1] https://www.openssl.org/docs/man1.1.0/man3/OPENSSL_zalloc.ht...

[2] https://queue.acm.org/detail.cfm?id=2602816

[3] https://www.ieee-security.org/TC/SP2015/papers-archived/6949...