>It’s a pretty silly argument to make as rowhammer im sure could also “break” homomorphic encryption.

There's no reason rowhammer should be able to break homomorphic encryption. Homomorphic encryption means at no point is the data on the machine unencrypted, so there is nothing to leak from RAM.

>Homomorphic encryption is really about the utility when it leaves the device, not at the encryption stage.

???

This make no sense. Homomorphic encryption is used for a device to do computations on encrypted data without the device knowing what the encrypted data is.

For example, computing the square of an integer that is homorphically encrypted would not tell the device doing the computation what the original number is or what the square is. Encrypted data comes in, stays encrypted at all times, an algorithm does some operations on the encrypted data, and encrypted data is then sent out.

This paper and attack are not about the encryption stage. The attack is on the operating on homomorphic data.

When talking about encryption techniques, I think we usually assume that the machine performing the encryption isn't compromised. I.e., keeping a machine uncompromised is a separate area of study / endeavor.

What NC State achieved is cool, but it seems a bit like saying "Homomorphic encryption is broken when you can blackmail the sysadmin."

That’s part of the rationale for homomorphic encryption, even if the device performing the operations is completely compromised it never has access to the unencrypted data, so given a theoretical perfect HE system your data would still be safe.

I’m off to read this paper S I don’t understand how they are using a side channel to extract information that the operating device theoretically shouldn’t have. If there’s a measurable power usage difference over the operations that implies that the encrypted bits do leak information about what is encrypted.

In a homomorphic scheme, you have a machine A (trusted), which encrypts some data and sends it to machine B (untrusted) and B then does operations on the data and returns the results to A, which decrypts.

This attack is on machine A, not machine B. The "leak" happens as the data is being encrypted. They're sidechanneling a machine that has the plaintext on it.

Ah, I was super confused (as I said I hadn’t yet read the paper, I was hoping for TLDR at the time)

FTA:

>Our proposed attack targets the Gaussian sampling in the SEAL’s encryption phase

It's literally about stealing the data from the encryptor, which is usually a trusted machine.

Exactly. Power consumption side channel attacks do nothing for devices operating on already encrypted data, because if it did, it would mean homomorphic encryption is fundamentally broken. The side channel attack is on the original encryptor.

As an aside it's worth noting that RSA itself is partially-homomorphic (ciphertext multiplications are preserved in the decrypted plaintext).

The idea of 'homomorphic encryption' was even introduced by another Rivest and Adleman paper, almost immediately after the famous 1977 RSA algorithm ("On Data Banks and Privacy Homomorphisms" by Rivest, Adleman, and Dertouzos 1978).

No, not "pretty much anything". Proper encryption code needs to be written so that the timing and power consumption does not depend on the data, to avoid these kinds of side channel attack. That usually means no conditional branches, so the same processor operations occur regardless of the ciphertext or the key.

Whilst that is true, power side channel attacks are an interesting case.

If they become relevant, then your attacker is really quite close to the device. In most scenarios, once the attacker is that close you are probably fucked anyway. There are exceptions of-course. Using in-memory encryption, ingress detection, etc you might be able to remain safe in these cases. Moreover an attacker might be able to do power-analysis without leaving a trace. Whereas pulling out the RAM-sticks after freezing them leaves more of a mark.

However, few of the scenarios involving good reason to use homomorphic encryption really stand up to an attacker having physical access to the encrypting device. Most of these scenarios are about secure shared computation. Where the threat model revolves around 'what if my computational partner is evil', not 'what if Ethan Hunt breaks in'. Generally, if someone has access to the machine, they will have access to the raw data anyway.