5 ms·

> the logic used here is alarming. Why? I agree that a larger nonce would be better and that's possible, but even with a larger nonce not having sudden total c

by api 7y ago

> the logic used here is alarming. Why? I agree that a larger nonce would be better and that's possible, but even with a larger nonce not having sudden total compromise of authentication on nonce duplication would be a good thing would it not? Even with larger nonces/IVs nonce reuse can still be an issue. If you store your counter/seed, storage can be corrupted. If you store your counter/seed, your VM can be cloned creating an exact copy of your counter/seed. If you rely on system entropy you can have entropy issues. The latter is fairly common on small and embedded devices including a ton of ARM boards that are on the market. I have actually seen cheapo ARM boards that ship with kernels where /dev/urandom outputs the same bits at boot every time. I imagine it's a combination of disabling every ad-hoc entropy source option in the kernel parameters (because code size!) combined with no non-volatile clock and no hardware entropy source and a very deterministic single in-order core. Sudden death properties are a footgun and I'm a little surprised that constructions with this property have become the standard. Increasing the size of the nonce/IV just makes the footgun's trigger less squirrely. This post (I'm the author) is just research notes posted for feedback, not a final design that is shipping. (I edited the post and added a disclaimer just in case people get confused about that.) My goals are four-fold: (1) to avoid sudden death properties entirely, (2) to be fast (on modern hardware with AES acceleration, which pretty much all targets where performance matters), (3) to be potentially FIPS-certifiable if I plug in FIPS libraries/modules for my primitives, and (4) to avoid adding more packet overhead if possible. My thought is that if (1) is achievable then (4) is also achievable. <rant> I really find the fear-mongering around crypto to be counterproductive. This post is just an idea, and the problem it is attempting to address is a real one. No, I don't like FIPS either, but I do like making money and numerous large clients do require it. So why not research ways to be FIPS compliant and be better than the average FIPS-compliant (stock AES-GCM with sudden death footgun) implementation? Why is that goal alarming? Every time I discuss crypto I get people who just chime in with "don't write crypto, just use standard stuff." (I do agree that it's best to use standard stuff if it meets all your goals, that's not the point.) What does saying that actually accomplish? The people who really shouldn't write crypto will ignore it because they think they know more than they really know (or their boss is telling them to). The people who should write crypto will ignore it because it doesn't apply to them. The only people who will follow those kinds of admonitions are the people who don't know crypto and know they don't know but want to learn, and they'll be discouraged from doing so. I learned about crypto because I realized it was hard, ignored this kind of advice, and read and listened to people who did understand it. When I ask questions about crypto or post ideas for feedback I've learned to only pay attention to replies that contain specific information or point out actual specific issues or flaws in a design. I ignore hand-wavey fear mongering that contains no actual content, and I'd encourage others who are interested in learning about crypto or anything else to do the same. </rant>

tptacek 7y ago
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.
- 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.

by api 7y ago

tptacek 7y ago

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.

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.