undefined | Better HN

0 pointstptacek6y ago0 comments

The point of the larger nonce is to allow safe use of random nonces. You don't do a larger nonce and then record nonces. Among randomized AEADs there seem to be three main strategies for security:

1. Nonces large enough that you can safely use random nonces (XSalsa being the best example).

2. Stateful nonces, such as in systems where the nonce is tied to another protocol, or recorded in non-volatile storage.

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.

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.

I don't have much of a stake in this story. To the extent I do, I guess what I'm here to say is:

* "Performance" and "overhead" aren't good reasons to use a smaller nonce with an AEAD.

* FIPS is bad, and a requirement to be FIPS-compliant will ultimately harm the security of a cryptosystem.

That's it.

You will better answers on Crypto Stack Exchange than on HN, though.

0 comments

3 comments · 1 top-level

api6y ago· 2 in thread

> 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.

tptacekOP6y 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.

api6y 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. :)

1 more reply

j / k navigate · click thread line to collapse