3 ms·

I agree the biggest worry isn't a hidden attack on the high parameter modes. The weak modes, though! A 32-bit block(!), 64-bit key, and 22 XOR/add/XOR rounds i

I agree the biggest worry isn't a hidden attack on the high parameter modes. The weak modes, though! A 32-bit block(!), 64-bit key, and 22 XOR/add/XOR rounds is just an excuse to say you have int'l standard crypto despite it being painfully weak. If we see demand for a standard cheaper than hardware AES or software ChaCha20 (or 12 if you live dangerously), we should pick one in an open process like the many we've had.

ryacko 9y ago
I thought the weak modes were to more easily crypto analyze it.
- twotwotwo 9y ago
  My understanding is what tptacek said: they were proposed for real-world use, with IoT and other small/embedded platforms as the justification.
tptacek 9y ago
The small block and key sizes aren't about export controls (obviously, since the standard comes with 128/256); it's for platforms that can't afford serious block and key sizes.
- twotwotwo 9y ago
  Yeah, "int'l standard" in my comment referred to standardization by the International Standards Organization, not the old "international" export-strength keys. I'm saying I think standardizing weak params is a bad idea, even if strong ones are offered too; it gives folks who could afford sane block/key sizes an excuse to cheap out and use something bad and say "it's standard." To the extent industry is calling for cheaper crypto, there are some existing civilian candidates (like the eSTREAM hardware profile though I haven't seen much interest in it), or we could have an open competition, responding to what civilian security folks say they're missing. You could definitely get, e.g. gate area down vs. AES or ChaCha without sacrificing sane block/key sizes.
  - tptacek 9y ago
    If AES is a lightweight cipher now, you should probably inform all the academics working on lightweight cipher designs that what they're doing is pointless.
    - twotwotwo 9y ago
      My phrasing may have been unclear: by "You could definitely get, e.g. gate area down vs. AES or ChaCha without sacrificing sane block/key sizes" I mean you can make ciphers that achieve gate areas lower than AES's or ChaCha's without sacrificing decent block/key sizes. ("Down vs." was not the clearest; maybe it sounded like "down for".) As you note, and as I mentioned above, some standards processes have already picked some ciphers meant to be better for constrained environments than those two. The ones I know about (as a nonspecialist!) still use higher parameters than smallest versions of Simon/Speck. PRESENT, accepted by the same committee, has an 80-bit key and 64-bit block, for example, and eSTREAM has its 80-bit hardware profile. That's the "smaller primitives that still have sane-ish params" I was talking about. The smallest Simon/Speck variants go lower, and seem like skating too close to the edge to recommend and standardize, even if there's somewhere they're the right/only fit. After posting the comment you replied to, I found a PDF from IAD that suggested that the 32/64 block/key size was never going to be submitted to the ISO committee because they have a minimum key size of 80 bits, and 48/96 was canned out of technical concern about the 48-bit block. (Posted it as a self-reply (a...great-uncle? of this comment), because it was too late to edit.) What they wrote actually makes dropping the weaker versions sound a lot less contentious than the Reuters story does, though of course it's one party's version of the story. And the continued pushback from some countries to the 128/256 versions clearly has other causes. If you mostly just want to dunk on me, I'm sure I've said something wrong here, but not wanting to standardize very low parameters at least isn't the same as just not being aware of lightweight crypto.
twotwotwo 9y ago
Since I can't edit, noting here that the minimum key size required here was 80 bits, so apparently the 32-bit-block version was never really considered. Yay! (Search for 'ISO' in https://iadgov.github.io/simon-speck/papers/Algorithms-to-Support-the-Evolution-of-Information-Assurance-Needs.pdf https://iadgov.github.io/simon-speck/papers/Algorithms-to-Su...) The Reuters story made it sound a bit like this was a topic of debate, when the IAD doc makes it sound like more of an assumption from the start. The grump in me still sees a pretty narrow niche for this sort of algo (like, maybe most considering it should just be using AES?), but whatever.

ryacko 9y ago

I thought the weak modes were to more easily crypto analyze it.

twotwotwo 9y ago
My understanding is what tptacek said: they were proposed for real-world use, with IoT and other small/embedded platforms as the justification.

tptacek 9y ago

The small block and key sizes aren't about export controls (obviously, since the standard comes with 128/256); it's for platforms that can't afford serious block and key sizes.

twotwotwo 9y ago
Yeah, "int'l standard" in my comment referred to standardization by the International Standards Organization, not the old "international" export-strength keys. I'm saying I think standardizing weak params is a bad idea, even if strong ones are offered too; it gives folks who could afford sane block/key sizes an excuse to cheap out and use something bad and say "it's standard." To the extent industry is calling for cheaper crypto, there are some existing civilian candidates (like the eSTREAM hardware profile though I haven't seen much interest in it), or we could have an open competition, responding to what civilian security folks say they're missing. You could definitely get, e.g. gate area down vs. AES or ChaCha without sacrificing sane block/key sizes.
- tptacek 9y ago
  If AES is a lightweight cipher now, you should probably inform all the academics working on lightweight cipher designs that what they're doing is pointless.
  - twotwotwo 9y ago
    My phrasing may have been unclear: by "You could definitely get, e.g. gate area down vs. AES or ChaCha without sacrificing sane block/key sizes" I mean you can make ciphers that achieve gate areas lower than AES's or ChaCha's without sacrificing decent block/key sizes. ("Down vs." was not the clearest; maybe it sounded like "down for".) As you note, and as I mentioned above, some standards processes have already picked some ciphers meant to be better for constrained environments than those two. The ones I know about (as a nonspecialist!) still use higher parameters than smallest versions of Simon/Speck. PRESENT, accepted by the same committee, has an 80-bit key and 64-bit block, for example, and eSTREAM has its 80-bit hardware profile. That's the "smaller primitives that still have sane-ish params" I was talking about. The smallest Simon/Speck variants go lower, and seem like skating too close to the edge to recommend and standardize, even if there's somewhere they're the right/only fit. After posting the comment you replied to, I found a PDF from IAD that suggested that the 32/64 block/key size was never going to be submitted to the ISO committee because they have a minimum key size of 80 bits, and 48/96 was canned out of technical concern about the 48-bit block. (Posted it as a self-reply (a...great-uncle? of this comment), because it was too late to edit.) What they wrote actually makes dropping the weaker versions sound a lot less contentious than the Reuters story does, though of course it's one party's version of the story. And the continued pushback from some countries to the 128/256 versions clearly has other causes. If you mostly just want to dunk on me, I'm sure I've said something wrong here, but not wanting to standardize very low parameters at least isn't the same as just not being aware of lightweight crypto.

twotwotwo 9y ago

Since I can't edit, noting here that the minimum key size required here was 80 bits, so apparently the 32-bit-block version was never really considered. Yay! (Search for 'ISO' in https://iadgov.github.io/simon-speck/papers/Algorithms-to-Support-the-Evolution-of-Information-Assurance-Needs.pdf https://iadgov.github.io/simon-speck/papers/Algorithms-to-Su...) The Reuters story made it sound a bit like this was a topic of debate, when the IAD doc makes it sound like more of an assumption from the start. The grump in me still sees a pretty narrow niche for this sort of algo (like, maybe most considering it should just be using AES?), but whatever.