4 ms·
Curious why CF needs to worry about side-channel attacks when all software run on those machines belong to / written by them. They do have a “workers” product w
by harikb 7y ago
Curious why CF needs to worry about side-channel attacks when all software run on those machines belong to / written by them. They do have a “workers” product with 3rd party code but they can easily keep storage servers out of that pool. Typically storage encryption is all about what happens when a machine is physically stolen, hard disk discarded on failure or other such actions beyond network security. Please correct me if I am wrong.
- dependenttypes 7y agoYou could measure the timing over the internet.
- starfallg 7y agoUsers aren't interacting directly with the storage layer so any timing attack via the network is going to be once or twice removed. Can attackers really gleam useful and mount a successful attack in this type of setup?
- oconnor663 7y agoThis is almost certainly true in practice, but it's a big risk, compared to the risk tolerance that we usually engineer into crypto. For comparison, suppose someone was suggesting: "Why not use 80-bit keys instead of 128-bit keys? No one in the real world can brute force 80 bits, and we'll save on storage." Yes, that's true, but it's taking a relatively large risk for relatively little benefit. Hardware will get faster over time, and an extremely high value target might justify an extremely expensive attack, etc etc. We prefer 128-bit keys because then we don't even have to consider those questions. I think timing attacks are similar: Yes they're very difficult in practice, but they raise questions that we'd rather not have to think about. (And which, realistically, no one will ever revisit in the future, as hardware evolves and new APIs are exposed.)
- necovek 7y agoI always imagined key size to relate to computation cost and not storage — what algorithm are you referring to?
- joshuaissac 7y agoThe point is that you need more bits to store a longer key, but the storage space saved is very little in this case compared to how much easier it is to crack.
- necovek 7y agoSure, but a difference of 0.1% of storage to go from 80-bit key to 1024-bit key for 1 Megabit of data (that's 118 bytes out of 128KiB), or 0,00001% for 1Gbit (128MiB) seems not worth raising as a concern. (I've chosen example numbers just to make calculation trivial) So I can't ever imagine storage size being the driver for choosing the key size, though from the other threads, it seems that there are algorithms that do have a storage overhead that might be related to key sizes.
- eximius 7y agoYES. It requires statistical techniques to remove the noise, making the attack harder, but not necessarily infeasible.
- mbreese 7y agoIs that really the case though when the differences in computation would be measured in microseconds, but the network noise would be in the order of milliseconds?
- nullc 7y agoYes, https://cr.yp.to/antiforgery/cachetiming-20050414.pdf https://cr.yp.to/antiforgery/cachetiming-20050414.pdf
- mbreese 7y agoI don’t know about that... in the paper the client and server are on the same network. It would be very interesting to repeat this study using faster processors (which will make this signal smaller) and over the public internet (making the noise bigger).
- eximius 7y agoThis is why constant time functions are used in cryptographic implementations, even over the network. These are called timing attacks and they're less common now because professional cryptographers know how to deal with it. But this is very much a perfect example of it.
- nullc 7y agoMaybe not relevant for CF-- more likely relevant for wider use of the approach!
- fanf2 7y agoI believe you are wrong because of https://workers.cloudflare.com/ https://workers.cloudflare.com/
- homero 7y agoLast time i saw they use many contractors and third parties to deploy mini data centers in other data centers. They ship them servers to install. Cloudflare doesn't have many private data centers.