7 ms·

> otherwise, we just forward the encryption request to the slower, generic C-based xts(ecb(aes-generic)) implementation This seems like at least something of a

by nullc 7y ago

> otherwise, we just forward the encryption request to the slower, generic C-based xts(ecb(aes-generic)) implementation This seems like at least something of a bad idea, because that implementation (if my search-fu is correct) is: https://github.com/torvalds/linux/blob/master/crypto/aes_generic.c https://github.com/torvalds/linux/blob/master/crypto/aes_gen... Which is obviously not constant time, and will leak information through cache/timing sidechannels. AES lends itself to a table based implementation which is simple, fairly fast, and-- unfortunately-- not secure if sidechannels matter. Fortunately, AES-NI eliminated most of the motivation for using such implementations on a vast collection of popular desktop hardware which has had AES-NI for quite a few years now. For the sake of also being constructive, here is a constant time implementation in naive C for both AES encryption and decryption (the latter being somewhat hard to find, because stream modes only use the former): https://github.com/bitcoin-core/ctaes https://github.com/bitcoin-core/ctaes (sadly, being single-block-at-a-time and constant time without hardware acceleration has a significant performance cost! ... better could be done for XTS mode, as the above algorithm could run SIMD using SSE2-- it isn't implemented in that implementation because the intended use was CBC mode which can't be parallelized like that) Can't the kernel aes-ni just be setup to save the fpu registers itself on the stack, if necessary?

nemo1618 7y ago
I wish the world could move on from AES. We have ciphers that are nearly as fast without requiring specialized hardware, just generic SIMD. Imagine how fast a ChaCha ASIC could run! There are other options for non-AES FDE too: most infamously Speck (suspected to be compromised by the NSA), but also Adiantum, which is now in Linux 5.0.
- nullc 7y ago
  AES in an ASIC is pretty efficient, I'd expect the difference to flatten if both had good hardware implementations. Not that I wouldn't be happy to see faster chacha20 on systems.
- dependenttypes 7y ago
  > Imagine how fast a ChaCha ASIC could run Not as fast. Chacha20 uses 32-bit additions which are fast in software but expensive and slow in hardware. In addition protecting Chacha20 from power analysis attacks is more difficult compared to AES. > just generic SIMD Constant-time AES with SSE2 is actually faster than the naive variable-time AES. See https://www.bearssl.org/constanttime.html#aes https://www.bearssl.org/constanttime.html#aes In addition Chacha20 is not nearly as fast as AES when using the AVX-512 Vector AES instructions. > but also Adiantum Which uses AES (once per sector).
  - karim 7y ago
    Genuinely curious, would you mind explaining why some operation can be fast in software but slow in hardware?
    - kop316 7y ago
      I think the parent comment is saying it is fast in software on a modern CPU, but making tha into an ASIC would either be a) slow or b) expensive due to the 32-bit additions. IIRC (I can't find it right now), when NIST had the contest for AES, AES hhad to run on low power hardware in the late 90s/early 2000s. This required things like everything to be fast on an 8-bit microcontroller.
    - dependenttypes 7y ago
      To implement 32-bit + in hardware you need 31 full adders and one half adder, each of which uses multiple gates and depends on the result of the previous adder. Meanwhile + and bitwise and tend to take the same amount of cycles to be processed, and each cycle takes the same amount of time, see https://gmplib.org/~tege/x86-timing.pdf https://gmplib.org/~tege/x86-timing.pdf Chacha20 in hardware would not be any slower than chacha20 in software, but it would be slower than other algorithms which do not use 32-bit +.
      - JoshTriplett 7y ago
        > To implement 32-bit + in hardware you need 31 full adders and one half adder, each of which uses multiple gates and depends on the result of the previous adder. This is not how CPUs typically implement addition, or other ALU operations. Carry-lookahead adders have existed since the 1950s: https://en.wikipedia.org/wiki/Carry-lookahead_adder https://en.wikipedia.org/wiki/Carry-lookahead_adder
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 ago
  You could measure the timing over the internet.
  - starfallg 7y ago
    Users 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 ago
      This 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 ago
        I always imagined key size to relate to computation cost and not storage — what algorithm are you referring to?
gruez 7y ago
>Which is obviously not constant time, and will leak information through cache/timing sidechannels. What's the threat model here? I can't think of a plausible scenario where side channel attacks can be used to gain unauthorized access to FDE contents.
nshepperd 7y ago
> Which is obviously not constant time, and will leak information through cache/timing sidechannels. This confuses me. Why is it in the kernel if it's not constant time? Isn't that a security risk? (Is there any context where it would be safe to invoke this?)
- cbsmith 7y ago
  Sure. There's lots of cases where you are controlling for timing attacks elsewhere, or where a timing attack isn't a concern. This can particularly be true for a case where you are writing data to block storage with the idea that a potential attacker won't be accessing it until much later... at which point all timing information would be gone.
  - nullc 7y ago
    Unfortunately cache sidechannels defeat a lot of measures that would otherwise destroy timing data. I agree that there can be some cases where it doesn't matter but it's extremely expensive to be sure that it doesn't matter-- making it usually cheaper, when you consider the total costs, to deploy code that doesn't have the sidechannels.
    - cbsmith 7y ago
      It's pretty cheap if the use case is, "the computer will be turned off before I worry about an attacker".

by nullc 7y ago

nemo1618 7y ago

I wish the world could move on from AES. We have ciphers that are nearly as fast without requiring specialized hardware, just generic SIMD. Imagine how fast a ChaCha ASIC could run! There are other options for non-AES FDE too: most infamously Speck (suspected to be compromised by the NSA), but also Adiantum, which is now in Linux 5.0.

nullc 7y ago
AES in an ASIC is pretty efficient, I'd expect the difference to flatten if both had good hardware implementations. Not that I wouldn't be happy to see faster chacha20 on systems.
dependenttypes 7y ago
> Imagine how fast a ChaCha ASIC could run Not as fast. Chacha20 uses 32-bit additions which are fast in software but expensive and slow in hardware. In addition protecting Chacha20 from power analysis attacks is more difficult compared to AES. > just generic SIMD Constant-time AES with SSE2 is actually faster than the naive variable-time AES. See https://www.bearssl.org/constanttime.html#aes https://www.bearssl.org/constanttime.html#aes In addition Chacha20 is not nearly as fast as AES when using the AVX-512 Vector AES instructions. > but also Adiantum Which uses AES (once per sector).
- karim 7y ago
  Genuinely curious, would you mind explaining why some operation can be fast in software but slow in hardware?
  - kop316 7y ago
    I think the parent comment is saying it is fast in software on a modern CPU, but making tha into an ASIC would either be a) slow or b) expensive due to the 32-bit additions. IIRC (I can't find it right now), when NIST had the contest for AES, AES hhad to run on low power hardware in the late 90s/early 2000s. This required things like everything to be fast on an 8-bit microcontroller.
  - dependenttypes 7y ago
    To implement 32-bit + in hardware you need 31 full adders and one half adder, each of which uses multiple gates and depends on the result of the previous adder. Meanwhile + and bitwise and tend to take the same amount of cycles to be processed, and each cycle takes the same amount of time, see https://gmplib.org/~tege/x86-timing.pdf https://gmplib.org/~tege/x86-timing.pdf Chacha20 in hardware would not be any slower than chacha20 in software, but it would be slower than other algorithms which do not use 32-bit +.
    - JoshTriplett 7y ago
      > To implement 32-bit + in hardware you need 31 full adders and one half adder, each of which uses multiple gates and depends on the result of the previous adder. This is not how CPUs typically implement addition, or other ALU operations. Carry-lookahead adders have existed since the 1950s: https://en.wikipedia.org/wiki/Carry-lookahead_adder https://en.wikipedia.org/wiki/Carry-lookahead_adder

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 ago
You could measure the timing over the internet.
- starfallg 7y ago
  Users 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 ago
    This 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 ago
      I always imagined key size to relate to computation cost and not storage — what algorithm are you referring to?

gruez 7y ago

>Which is obviously not constant time, and will leak information through cache/timing sidechannels. What's the threat model here? I can't think of a plausible scenario where side channel attacks can be used to gain unauthorized access to FDE contents.

nshepperd 7y ago

> Which is obviously not constant time, and will leak information through cache/timing sidechannels. This confuses me. Why is it in the kernel if it's not constant time? Isn't that a security risk? (Is there any context where it would be safe to invoke this?)

cbsmith 7y ago
Sure. There's lots of cases where you are controlling for timing attacks elsewhere, or where a timing attack isn't a concern. This can particularly be true for a case where you are writing data to block storage with the idea that a potential attacker won't be accessing it until much later... at which point all timing information would be gone.
- nullc 7y ago
  Unfortunately cache sidechannels defeat a lot of measures that would otherwise destroy timing data. I agree that there can be some cases where it doesn't matter but it's extremely expensive to be sure that it doesn't matter-- making it usually cheaper, when you consider the total costs, to deploy code that doesn't have the sidechannels.
  - cbsmith 7y ago
    It's pretty cheap if the use case is, "the computer will be turned off before I worry about an attacker".