5 ms·

A) debatable B) very,very debatable, especially this piece: "understand the space well-enough" C) I tend to agree, but then (especially with hardware-supporte

by mr__y 7y ago

A) debatable B) very,very debatable, especially this piece: "understand the space well-enough" C) I tend to agree, but then (especially with hardware-supported crypto) there is not much to be gained by reducing the number of rounds

tptacek 7y ago
A factor of 2x+ speedup isn't "not much to be gained", but the point again is just to be more rigorous about the security margins we're trying to get. Can you say more about what you believe the "debate" about key size and number of rounds to be? A pretty important point Aumasson seems to be trying to make here is that the reduced-round analytic results against ciphers are arguments in favor of their fundamental strength, not signs that they're teetering on a precipice of insecurity.
- mr__y 7y ago
  2x+ speedup would assume that all you do is just doing encryption/decryption while in most cases crypto would use only a small percentage of cpu time anyways. So if - let's say 1% of cpu time is spent on crypto, then that 2x gain translates to .5% overall speedup. On the other hand I do understand that this % varies a lot depending on what software/system you look at
  - tptacek 7y ago
    I assume we all understand that in this thread, when we talk about performance increases, we mean of the ciphers themselves. "Crypto performance doesn't matter" is a coherent argument, if you want to make it, but if crypto performance does matter, a 2x boost is obviously material. "We could have doubled the speed of this hash if we had been more rigorous about security margins" seems clearly to be a powerful claim. Especially since performance is in reality a pretty huge part of how we choose the cipher designs we standardize.
    - mr__y 7y ago
      >"Crypto performance doesn't matter" the argument I was trying to make is more in the sense "is it worth to take (even a minimal) risk optimizing performance given that this very performance gain is not (that) important overall" That being said, I do understand that there are a lot of areas where performance/energy budget is tight and this actually makes a (huge) difference
  - fanf2 7y ago
    Encryption is about 33% CPU at 100Gbit/s TLS https://2019.eurobsdcon.org/slides/Kernel%20TLS%20and%20TLS%20hardware%20offload%20-%20Drew%20Gallatin.pdf https://2019.eurobsdcon.org/slides/Kernel%20TLS%20and%20TLS%... though at that speed memory bandwidth is more of a constraint
wbl 7y ago
After differential cryptanalysis we are mostly out of ideas.
- tptacek 7y ago
  How true is this (I have no idea)? And to the extent it is, how valid would it be to draw a comparison to the security of software, saying something like "after out-of-bounds writes, we're mostly out of ideas on how to get RCE out of C programs"? There are a lot of extensions to basic differential cryptanalysis.
  - pvg 7y ago
    Seems like a tough comparison to make given the security of a cryptosystem is a lot better defined than that of a program, even in a constrained case like 'RCE in a C program'.
    - tptacek 7y ago
      It might be, I don't know. In practice (that is, in carrying out cryptographic attacks on real systems), nobody ever cryptanalyzes ciphers, so I've hardly studied block cipher cryptanalysis at all; someone much smarter than me gave me a purely linear block cipher once and I didn't spot it (plus side: now I can break purely linear ciphers! make a bunch of them! put them in JWT!), so this stuff is generally over my pay grade, though I have cryptopals exercises for basic linear and differential cryptanalysis tee'd up. But I'm just noticing how many named cryptanalytic techniques, like Boomerang, Impossible Differential, even I guess to an extent Slide, are really extensions of Matsui and Biham and Shamir. And that's true of C/C++ software too: most attacks seen in the wild are derivatives of just a couple basic techniques ("out of bound write" is obviously putting my thumb on the scale, but "buffer overrun", "integer mishandling", and "use after free" cover a pretty good fraction of all attacks on memory safety). Which is all to say: "we've had no good ideas since differential" might not be as meaningful as it sounds? Or maybe it is. Sometimes the best way to get good information into a message board thread is to add bad information, and, in theoretical cryptography, I contribute that ably!

by mr__y 7y ago

tptacek 7y ago

A factor of 2x+ speedup isn't "not much to be gained", but the point again is just to be more rigorous about the security margins we're trying to get. Can you say more about what you believe the "debate" about key size and number of rounds to be? A pretty important point Aumasson seems to be trying to make here is that the reduced-round analytic results against ciphers are arguments in favor of their fundamental strength, not signs that they're teetering on a precipice of insecurity.

mr__y 7y ago
2x+ speedup would assume that all you do is just doing encryption/decryption while in most cases crypto would use only a small percentage of cpu time anyways. So if - let's say 1% of cpu time is spent on crypto, then that 2x gain translates to .5% overall speedup. On the other hand I do understand that this % varies a lot depending on what software/system you look at
- tptacek 7y ago
  I assume we all understand that in this thread, when we talk about performance increases, we mean of the ciphers themselves. "Crypto performance doesn't matter" is a coherent argument, if you want to make it, but if crypto performance does matter, a 2x boost is obviously material. "We could have doubled the speed of this hash if we had been more rigorous about security margins" seems clearly to be a powerful claim. Especially since performance is in reality a pretty huge part of how we choose the cipher designs we standardize.
  - mr__y 7y ago
    >"Crypto performance doesn't matter" the argument I was trying to make is more in the sense "is it worth to take (even a minimal) risk optimizing performance given that this very performance gain is not (that) important overall" That being said, I do understand that there are a lot of areas where performance/energy budget is tight and this actually makes a (huge) difference
- fanf2 7y ago
  Encryption is about 33% CPU at 100Gbit/s TLS https://2019.eurobsdcon.org/slides/Kernel%20TLS%20and%20TLS%20hardware%20offload%20-%20Drew%20Gallatin.pdf https://2019.eurobsdcon.org/slides/Kernel%20TLS%20and%20TLS%... though at that speed memory bandwidth is more of a constraint

wbl 7y ago

After differential cryptanalysis we are mostly out of ideas.

tptacek 7y ago
How true is this (I have no idea)? And to the extent it is, how valid would it be to draw a comparison to the security of software, saying something like "after out-of-bounds writes, we're mostly out of ideas on how to get RCE out of C programs"? There are a lot of extensions to basic differential cryptanalysis.
- pvg 7y ago
  Seems like a tough comparison to make given the security of a cryptosystem is a lot better defined than that of a program, even in a constrained case like 'RCE in a C program'.
  - tptacek 7y ago
    It might be, I don't know. In practice (that is, in carrying out cryptographic attacks on real systems), nobody ever cryptanalyzes ciphers, so I've hardly studied block cipher cryptanalysis at all; someone much smarter than me gave me a purely linear block cipher once and I didn't spot it (plus side: now I can break purely linear ciphers! make a bunch of them! put them in JWT!), so this stuff is generally over my pay grade, though I have cryptopals exercises for basic linear and differential cryptanalysis tee'd up. But I'm just noticing how many named cryptanalytic techniques, like Boomerang, Impossible Differential, even I guess to an extent Slide, are really extensions of Matsui and Biham and Shamir. And that's true of C/C++ software too: most attacks seen in the wild are derivatives of just a couple basic techniques ("out of bound write" is obviously putting my thumb on the scale, but "buffer overrun", "integer mishandling", and "use after free" cover a pretty good fraction of all attacks on memory safety). Which is all to say: "we've had no good ideas since differential" might not be as meaningful as it sounds? Or maybe it is. Sometimes the best way to get good information into a message board thread is to add bad information, and, in theoretical cryptography, I contribute that ably!