3 ms·

> 3. NMR systems where the nonce isn't necessarily large enough to safely use randomly, but the system doesn't fail catastrophically on the rare occasions they

by api 7y ago

> 3. NMR systems where the nonce isn't necessarily large enough to safely use randomly, but the system doesn't fail catastrophically on the rare occasions they collide. That's what I'm interested in, yes, though making the nonce bigger is also on the table. Ideally I'd like to do both. > If you're trying to do cryptography on systems with no functioning random number generator, my presumption is you have bigger problems than which AEAD you're using. We aren't really trying to do that, but our stuff runs on a ton of devices and we want to maximize its robustness across that device population. If someone puts it on a device with a crappy random source their security will be impacted but we wouldn't mind minimizing that impact if possible. > * FIPS is bad, and a requirement to be FIPS-compliant will ultimately harm the security of a cryptosystem. I agree that FIPS sucks. Bureaucratic requirements arounds security suck in general since they perpetuate a box-checking CYA mentality while hamstringing real security measures. Unfortunately money doesn't suck and bureaucratic organizations control most of the money on this planet. Reality is what it is. > You will better answers on Crypto Stack Exchange than on HN, though. Agreed. I didn't post this here, someone else did. Crypto Stack Exchange is very good in my experience. It seems to have taken over the niche from the old Usenet crypto groups. BTW I also do like WireGuard and if ZeroTier were redesigned today we'd consider the Noise framework it's based upon. None of that stuff existed when the design was originally made. As it stands we have a large user-base so backward compatibility matters and our goals and constraints are a little different from WG but we would like to evolve toward better crypto that is closer to what Noise accomplishes.

tptacek 7y ago
This is all fine. I just wouldn't want to see the meme established that safe nonce sizes are somehow detrimental to performance or create too much overhead, which is what the post I'm responding to said.
- api 7y ago
  If someone takes that as advice they shouldn't be writing crypto, which means they'll probably both ignore your better advice and screw it up in ways far worse than using a small IV. :)
  - tptacek 7y ago
    I don't understand. People shouldn't be writing crypto, that is true, if only to avoid being called "harebrained" on Crypto Stack Exchange by Squeamish Ossifrage. :) It's hard for me to really engage with anything you're saying, because there are so many layers of problematic to this. I'd prefer to focus my concern on the decision to comply with FIPS, rather than trying to contort my take to some weird box in which unreasonable constraints become reasonable because FIPS says they're reasonable. In a serious system, you'd either use AES-GCM-SIV, for its NMR property, or (much more likely) XChapoly, for its wide random nonce. OR, you'd have a "FIPS" mode that, like, just composed CTR with HMAC, rather than sticking yourself with GCM's weird nonce limitation. But you've apparently decided to simultaneously support FIPS and roll your own mode to squeeze out a better cycle count. If there's so much money on the line, just get your design reviewed. Honestly, if you build with cryptography and that cryptography isn't simply Nacl, you should be doing that regardless. Like Nate Lawson used to tell me: you should budget 10x on verification what you do for implementation in a cryptosystem. Are you meeting that standard? I wouldn't know. (Nor, in fairness, would I be qualified to do verification work on a new authenticated encryption mode).
    - api 7y ago
      Your advice is good in most circumstances, and may end up being what we do. In any case the mode I cooked up has after a few minor tweaks essentially converged with AES-(CMAC|PMAC)-SIV but with GMAC in the MAC slot and with an extra AES-ECB (AES as a 128-bit keyed hash) step after GMAC to make it into a proper PRF. If that's the case then it seems that the AES-SIV work and papers apply. I was reading about AES-GCM-SIV and it's unfortunate that they decided to use a new MAC digest function called POLYVAL instead of GHASH/GMAC. If they'd re-used GHASH/GMAC as-is it's possible that AES-GCM-SIV could be described in terms of GMAC and AES-CTR and therefore could pass FIPS. I guess nobody but people trying to sell to certain parties cares about FIPS, which is probably as it should be because FIPS sucks. https://tools.ietf.org/html/rfc8452#page-17 https://tools.ietf.org/html/rfc8452#page-17 Edit: it looks like POLYVAL is GHASH optimized for little-endian machines, so I see the rationale. Still too bad. They missed a bureaucracy-hacking opportunity.

by api 7y ago

tptacek 7y ago

This is all fine. I just wouldn't want to see the meme established that safe nonce sizes are somehow detrimental to performance or create too much overhead, which is what the post I'm responding to said.

api 7y ago
If someone takes that as advice they shouldn't be writing crypto, which means they'll probably both ignore your better advice and screw it up in ways far worse than using a small IV. :)
- tptacek 7y ago
  I don't understand. People shouldn't be writing crypto, that is true, if only to avoid being called "harebrained" on Crypto Stack Exchange by Squeamish Ossifrage. :) It's hard for me to really engage with anything you're saying, because there are so many layers of problematic to this. I'd prefer to focus my concern on the decision to comply with FIPS, rather than trying to contort my take to some weird box in which unreasonable constraints become reasonable because FIPS says they're reasonable. In a serious system, you'd either use AES-GCM-SIV, for its NMR property, or (much more likely) XChapoly, for its wide random nonce. OR, you'd have a "FIPS" mode that, like, just composed CTR with HMAC, rather than sticking yourself with GCM's weird nonce limitation. But you've apparently decided to simultaneously support FIPS and roll your own mode to squeeze out a better cycle count. If there's so much money on the line, just get your design reviewed. Honestly, if you build with cryptography and that cryptography isn't simply Nacl, you should be doing that regardless. Like Nate Lawson used to tell me: you should budget 10x on verification what you do for implementation in a cryptosystem. Are you meeting that standard? I wouldn't know. (Nor, in fairness, would I be qualified to do verification work on a new authenticated encryption mode).
  - api 7y ago
    Your advice is good in most circumstances, and may end up being what we do. In any case the mode I cooked up has after a few minor tweaks essentially converged with AES-(CMAC|PMAC)-SIV but with GMAC in the MAC slot and with an extra AES-ECB (AES as a 128-bit keyed hash) step after GMAC to make it into a proper PRF. If that's the case then it seems that the AES-SIV work and papers apply. I was reading about AES-GCM-SIV and it's unfortunate that they decided to use a new MAC digest function called POLYVAL instead of GHASH/GMAC. If they'd re-used GHASH/GMAC as-is it's possible that AES-GCM-SIV could be described in terms of GMAC and AES-CTR and therefore could pass FIPS. I guess nobody but people trying to sell to certain parties cares about FIPS, which is probably as it should be because FIPS sucks. https://tools.ietf.org/html/rfc8452#page-17 https://tools.ietf.org/html/rfc8452#page-17 Edit: it looks like POLYVAL is GHASH optimized for little-endian machines, so I see the rationale. Still too bad. They missed a bureaucracy-hacking opportunity.