
AES-GMAC-CTR (SIV) - LukeLambert
https://www.zerotier.com/aes-gmac-ctr-siv/
======
tptacek
_Using 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
I 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
It 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.

------
agl
I 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-
modu...](https://csrc.nist.gov/csrc/media/projects/cryptographic-module-
validation-program/documents/fips140-2/fips1402ig.pdf)

(Disclaimer: author of AES-GCM-SIV. Not casting shade here, it's a fair idea!
But not sure about the specific FIPS claim.)

~~~
api
I'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.

------
geofft
Fascinating 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
FIPS 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
FIPS 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
FIPS 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
Citation please. There are multiple standards that implement PFS in the FIPS
specs.

~~~
Nursie
Fair 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
ECDHE is standard for FIPS these days.

------
arkadiyt
Adam 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)

------
aidenn0
Obviously 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
SIV-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).

------
resoluteteeth
If 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
Professional cryptographers will definitely look at it. Doing design research
first.

------
alanfranz
I'm a zerotier user... And I hope that, beyond asking HN and SO, they'll let a
professional cryptographer review their design as well!

~~~
skrowl
Have 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
WireGuard has also been extensively studied, and more than one academic paper
has been written validating it.

~~~
baby
There’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.

~~~
tptacek
Oh, is that how that works? :)

------
cordite
Whoa, using the MAC as the IV to AES? That's really neat, I had not considered
that before

------
wolf550e
Why didn't they contact the authors of AES-SIV and AES-GCM-SIV to review their
idea?

~~~
abofh
Because 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
> 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.

~~~
CaliforniaKarl
When 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
> 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."

