14 ms·
AES-GMAC-CTR (SIV)
- geofft 7y agoFascinating that FIPS not only permitted but basically encouraged them to roll their own crypto instead of using a standard, well-analyzed system. (They're being cautious about their approach but it's still more work to design something that's as safe as a known approach than to just use the known approach.) I suspect that's the exact opposite of the intention behind FIPS....
- GhettoMaestro 7y agoFIPS is about the "correctness" of a particular set of functions (behaviors). You are correct that part of FIPS is encouraging folks to use previous validated crypto modules instead of going from zero. However you are not forced to do so - if you write your own crypto and pay to have it FIPS validated, more power to you - that's great. It is more competition.
- api 7y agoFIPS is a double-edged sword in my experience. On one hand it does set a standard to keep total snake oil crypto out of government. On the other hand it often has the side effect of mandating worse and older crypto and slowing update cycles when there's a bug. When SSL bugs are discovered vulnerable SSL libraries tend to sit around for a lot longer on FIPS-controlled hosts because they have to wait for a FIPS-validated update.
- Nursie 7y agoFIPS also ,at least a decade ago, ruled out things like PFS because actually the federal goverent wanted to be able to audit past traffic.
- jnwatson 7y agoCitation please. There are multiple standards that implement PFS in the FIPS specs.
- Nursie 7y agoFair enough, the ones I was involved with implementing/complying with (FIPS 140-2) ruled out things like DH(E) key exchange. We had to comply with that standard to sell to the federal government at the time. Things may well have changed.
- GhettoMaestro 7y agoECDHE is standard for FIPS these days.
- tptacek 7y agoThis comment doesn't really say anything, does it? The point Geoff made stands.
- GhettoMaestro 7y agoNo? My point was that you are not actively blocked or "discouraged" from making your own crypto implementation and submitting it for FIPS validation. Of course, that will be more expensive and time consuming than simply reusing a previously validated crypto module. So, you could perhaps call that "encouragement".... but the idea of FIPS is to provide some level of assurance to the consumer of said solutions. But there are cases where you desire to control your own crypto.
- alanfranz 7y agoI'm a zerotier user... And I hope that, beyond asking HN and SO, they'll let a professional cryptographer review their design as well!
- api 7y agoYes that would happen. Blogging and fishing for public comments is round one.
- abofh 7y agoRound one should really be talking to an expert in the field with crypto. I'm concerned that Guy On SO may not be as thorough as your product really deserves.
- api 7y agoI'd rather not waste a cryptographer's time with something that contains flaws that Guy On SO can spot. I do know enough about cryptography to generally tell if Guy On SO seems to know what they're talking about or not.
- skrowl 7y agoHave you tried WireGuard? I used ZeroTier in the past (and OpenVPN before that) but found that WireGuard seemed to perform much better (more throughput, less CPU usage)
- tptacek 7y agoWireGuard has also been extensively studied, and more than one academic paper has been written validating it.
- baby 7y agoThere’s also dsvpn which is an extremely simple vpn! The only bad part is that the code has no comments, but it is still auditable in a few hours due to the low amount of lines of code.
- arkadiyt 7y agoAdam Langley also has a good primer post on AES-GCM-SIV: https://www.imperialviolet.org/2017/05/14/aesgcmsiv.html https://www.imperialviolet.org/2017/05/14/aesgcmsiv.html
- wolf550e 7y agoWhy didn't they contact the authors of AES-SIV and AES-GCM-SIV to review their idea?
- abofh 7y agoBecause that would likely cost money, asking on SO costs literally nothing... And surely all appropriate expertise either read SO or their blog, so no problems here! To be fair, I see nothing obviously wrong with their solution, it's their approach that concerns me.
- bsder 7y ago> Because that would likely cost money Yeah, maybe a flight and some expensive beers. Most academic crypto guys are ecstatic at the thought of someone asking them prior to using their stuff wrong.
- tptacek 7y agoHave you asked a lot of academic crypto people about their bill rates?
- bsder 7y agoI've asked a few, and they've been pretty reasonable. Of course, I haven't had something where I've had to ask DJB, so I may be biased.
- CaliforniaKarl 7y agoWhen I work with Faculty (teaching or research, tenured or not), they are very conscious of their image/reputation. It would look pretty bad for a researcher to "sign off" on something, only for flaws to be discovered.
- bsder 7y ago> It would look pretty bad for a researcher to "sign off" on something, only for flaws to be discovered. True, but there is a big difference between "Hey, I'm using your stuff, could you look at this and see if I did something stupid?" and "I want you to sign off on this publicly. Here is the contract."
- aidenn0 7y agoObviously SIV is reviewed by people much more familiar with cryptanalysis than I am, but I am not sure how an IV based upon a hash of the message contents is any less likely to collide than an IV that is randomly generated? Isn't the ideal case for a hash that two different inputs will generate outputs exactly as likely to collide as two random numbers? [edit] I found the RFC[1] and it explains it. In SIV mode, the inputs are a (Key, Nonce) just like AES-GCM, but the keys used internally are generated deterministically from the key and nonce, so that each nonce provided uses a different key for the AES primitive, and then uses a synthetically generated (from plaintext) IV as input to AES. 1: https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-05 https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-05
- api 7y agoSIV-type schemes use the message content to guard against accidental message IV duplication, which can occur for numerous reasons including bad random sources, loss of storage, or just a smaller IV. They use the message content and message IV to generate a synthetic IV that is message-dependent so a duplicated message IV has no effect (other than revealing message duplication if the messages happen to also be the same).
- tptacek 7y agoUsing a large nonce is possible but would add protocol overhead, and we intend ZeroTier to be a very low-overhead high performance protocol No? "Large" in the context of nonces means "larger than the headroom GCM provides". To get to a place where you can safely use random nonces, you're talking about just a couple extra bytes. This is neither here nor there, since the actual problem this system has is a marketing decision to simultaneously comply with FIPS and use a nonce-based AEAD (which means, in practice, using GCM). But "larger nonce" is, I think, the general "right answer" to this problem, and the logic used here is alarming.
- tidepod12 7y agoI had the same thought, but doesn't a larger nonce simply decrease the chance for a duplicate nonce? Even if the chance is decreased to practically-impossible-to-duplicate levels, I could see the thought process being "if we're going to have to roll our own implementation to change the nonce size anyway, we might as well make an implementation that is provably impossible to suffer security issues from a duplicate nonce rather than one that is just immensely unlikely". I'm not sure if that's really the right choice, but I could at least see that being their reasoning, especially if they're going for FIPS certification which maybe (correct me if I'm wrong) would care about something being provably impossible rather than just provably unlikely? (disclaimer: my crypto knowledge is fairly surface level and I'm making this comment in a genuine attempt to learn)
- tptacek 7y agoIt decreases the chance for a duplicate nonce in somewhat the same sense as increasing key sizes decreases the chance of a guessed key. In cryptography, past some threshold, you get to rely on probability.
- 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>
- agl 7y agoI do not represent an NVLAP lab, but I'd question whether this would pass strict muster for FIPS given IG A.5: https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/fips140-2/fips1402ig.pdf https://csrc.nist.gov/csrc/media/projects/cryptographic-modu... (Disclaimer: author of AES-GCM-SIV. Not casting shade here, it's a fair idea! But not sure about the specific FIPS claim.)
- api 7y agoI'm not 100% sure either and am looking into it. FIPS is a rats nest and it may "depend." At this point I was just looking for basic feedback as to whether anyone could see any obvious problems. One person did suggest using a different AES key for each operation, which costs next to nothing and is probably good practice. Edit: plan is to re-key often enough than plain GCM with 64-bit tags would be "fine" from a FIPS point of view. The goal here is to do better than the FIPS requirement by closing a potential attack vector.
- cordite 7y agoWhoa, using the MAC as the IV to AES? That's really neat, I had not considered that before
- resoluteteeth 7y agoIf the creators of Zerotier are here, could you consider doing a kickstarter or something to pay for getting a professional cryptographer to look at it?
- api 7y agoProfessional cryptographers will definitely look at it. Doing design research first.