Make all 192 bits of nonces random

[DemiMarie]

This is the libsodium recommendation.

[tasket]

I'm fine with adding this. However, counters are recommended by libsodium for all constructions. It might merit some discussion as to why all-random is preferred over Wyng's existing multi-factor counter scheme, which uses a number of techniques to protect the counter and nonce uniqueness.

The intent I'm reading into the libsodium docs is, 'Now with 192-bit nonces, random also becomes a safe option'. Yet that is not a guarantee of uniqueness.

[DemiMarie]

I'm fine with adding this. However, counters are recommended by libsodium for all constructions.

The last time I checked the libsodium docs, my understanding was that recommendation was to use a random nonce for the first message, and to increment it for subsequent messages.

It might merit some discussion as to why all-random is preferred over Wyng's existing multi-factor counter scheme, which uses a number of techniques to protect the counter and nonce uniqueness.

The problem with the existing scheme is that it isn’t guaranteed to actually work. Time in Qubes OS is controlled by sys-net, which is not trusted. Filesystems can (and in practice sometimes are) rolled back to previous snapshots. Only a hardware monotonic counter is suitable for this, and Wyng cannot assume it has access to one.

The intent I'm reading into the libsodium docs is, 'Now with 192-bit nonces, random also becomes a safe option'. Yet that is not a guarantee of uniqueness.

An even safer option would be to go back to plain ChaCha20, but to hash 256 bits of random data, the other counters, and the actual secret to make a secret and unique session key.

[tasket]

The last time I checked the libsodium docs, my understanding was that recommendation was to use a random nonce for the first message, and to increment it for subsequent messages.

I don't recall "random nonce" defined as a random-initialized counter. I've only seen it used this way, which is a straightforward rnd with no increment.

---

On rollbacks:

Wyng detects differences between local cached metadata and remote, so a remote rollback would affect the internal timestamp and counter on the remote, but not the local copy.

            if cache_aset.updated_at > aset.updated_at:
                raise ValueError(f"Cached metadata is newer: "
                                 f"{cache_aset.updated_at} vs. {aset.updated_at}")

Wiping the local cache or rolling back both remote and local in tandem are required to make a clock-based attack feasible—assuming the 80 random bits are not enough of an obstacle, and the clock can be perfectly synced with the time corresponding to the rolled-back counter.

Only a hardware monotonic counter is suitable for this, and Wyng cannot assume it has access to one.

Noting first that Wyng will refuse to run for an encrypted archive having an internal timestamp >= now, I was also going to suggest using a monotonic timer to shore up this process. If Xen makes it impossible to tell if dom0 has a suitable monotonic timer available, I'd consider that an issue. Python offers monotonic timers (on specific OSes only) which appears credible if they claim it can track time with and without system sleep/suspend, for example.

[tasket]

Only a hardware monotonic counter is suitable for this,

This is not true, BTW. The hardware part can be dropped, as that would be required for synchronizing two trusted parties with a protocol; Wyng is not doing that. Barring the revelation of some astonishingly obvious bug on their part, I'll trust that anything Linux or Xen provides under the guise of "monotonic" can satisfy at least its one core requirement: don't go backwards. That's all we need from it.

[DemiMarie]

The last time I checked the libsodium docs, my understanding was that recommendation was to use a random nonce for the first message, and to increment it for subsequent messages.

I don't recall "random nonce" defined as a random-initialized counter. I've only seen it used this way, which is a straightforward rnd with no increment.

I can see how that would be confusing. A random-initialized counter should work, though.

[tasket]

I can see how that would be confusing.

@DemiMarie @marmarek Oh, OK. I just provided you the definition from NIST, that's all.

[tasket]

The two basic problems here are:

1. Justifying a change as matching libsodium documentation, when the specifics of the change are undocumented. That's a red flag.

2. Framing the existing counter code as an undocumented use, when in fact it is documented. Wyng uses a counter; concat-ing it with other elements doesn't make it any less of a counter.

[DemiMarie]

The two basic problems here are:

1. Justifying a change as matching libsodium documentation, when the specifics of the change are undocumented. That's a red flag.

This was my mistake. I was going off of what I remembered being the libsodium documentation, but I believe it was actually an old version of the documentation and possibly for crypto_secretbox_*. Sorry about that.

2. Framing the existing counter code as an undocumented use, when in fact it is documented. Wyng uses a counter; concat-ing it with other elements doesn't make it any less of a counter.

That was not my intent, sorry.

[DemiMarie]

Closing in favor of #157, which takes advantage of Wyng being content-addressed.