3 ms·

Ah, good. We are using AES-GCM for our IoT devices, with counters maintained very carefully in EEPROM, with mechanisms to detect/repair failing counters (eg po

Ah, good. We are using AES-GCM for our IoT devices, with counters maintained very carefully in EEPROM, with mechanisms to detect/repair failing counters (eg powered off at just the wrong moment). It would be nice to be able to be a little less careful, and also we're likely moving to an MCU without onboard byte-writeable EEPROM (ie page-write Flash with 1/10th the endurance), and this approach may make that less painful.

tptacek 9y ago
Another problem with GCM is that GHASH is hard to compute safely without hardware support. Modern Intel CPUs have a CLMUL instruction that makes it straightforward and fast to compute without needing table lookups, but IOT devices might not have PCLMULQDQ or an equivalent available.
- DamonHD 9y ago
  We have an implementation that seems to be acceptably fast and small on (8-bit) AVR: https://github.com/opentrv/OTAESGCM https://github.com/opentrv/OTAESGCM (It also compiles and runs on our x64 machines, Linux and macOS.)
  - tptacek 9y ago
    That's unoptimized GCM, but you might not be pushing enough traffic for it to matter; also note that you're using a vanilla software s-box driven AES, which is itself a cache timing risk. My point is just: there are reasons beyond nonce misuse safety to avoid GCM, especially on IOT devices.
    - DamonHD 9y ago
      Please point me to a few more. AES-GCM seemed the best available choice for us, after much discussion, and some scrutiny from third parties. I hear you on timing issues: we may work on those, though when it comes to AVR there is no cache! B^>
      - tptacek 9y ago
        In pure software, the conventional choice for an AEAD is some variant of Salsa20 and Poly1305 (usually abbreviated as "Chapoly"). They're designed to be fast in software without table lookups. The cache thing is a good point!
  - wolf550e 9y ago
    Have you looked at BearSSL? It has constant time AES[1]-GCM[2] optimized for ARM Cortex M0 (32bit microprocessors that go into USB cables: http://www.cypress.com/products/ez-pd-ccg2-type-c-port-controller http://www.cypress.com/products/ez-pd-ccg2-type-c-port-contr...) 1 - https://bearssl.org/speed.html#symmetric-encryption https://bearssl.org/speed.html#symmetric-encryption 2 - https://bearssl.org/speed.html#mac https://bearssl.org/speed.html#mac

tptacek 9y ago

Another problem with GCM is that GHASH is hard to compute safely without hardware support. Modern Intel CPUs have a CLMUL instruction that makes it straightforward and fast to compute without needing table lookups, but IOT devices might not have PCLMULQDQ or an equivalent available.

DamonHD 9y ago
We have an implementation that seems to be acceptably fast and small on (8-bit) AVR: https://github.com/opentrv/OTAESGCM https://github.com/opentrv/OTAESGCM (It also compiles and runs on our x64 machines, Linux and macOS.)
- tptacek 9y ago
  That's unoptimized GCM, but you might not be pushing enough traffic for it to matter; also note that you're using a vanilla software s-box driven AES, which is itself a cache timing risk. My point is just: there are reasons beyond nonce misuse safety to avoid GCM, especially on IOT devices.
  - DamonHD 9y ago
    Please point me to a few more. AES-GCM seemed the best available choice for us, after much discussion, and some scrutiny from third parties. I hear you on timing issues: we may work on those, though when it comes to AVR there is no cache! B^>
    - tptacek 9y ago
      In pure software, the conventional choice for an AEAD is some variant of Salsa20 and Poly1305 (usually abbreviated as "Chapoly"). They're designed to be fast in software without table lookups. The cache thing is a good point!
- wolf550e 9y ago
  Have you looked at BearSSL? It has constant time AES[1]-GCM[2] optimized for ARM Cortex M0 (32bit microprocessors that go into USB cables: http://www.cypress.com/products/ez-pd-ccg2-type-c-port-controller http://www.cypress.com/products/ez-pd-ccg2-type-c-port-contr...) 1 - https://bearssl.org/speed.html#symmetric-encryption https://bearssl.org/speed.html#symmetric-encryption 2 - https://bearssl.org/speed.html#mac https://bearssl.org/speed.html#mac