Closed davidperrenoud closed 3 years ago
Removing the support for specifying nonces in the public libsodium APIs is a breaking change.
Any breaking changes to libsodium would land in libosdium 2.0.0, not 1.0.z or 1.y.
I think the actual question here is around the intent of the change. Specifically: does making step 3 optional have the intent of letting PASETO implementations use libsodium bindings which do not surface nonces in their APIs, where step 2 is performed by libsodium (i.e. APIs like jedisct1/swift-sodium's which auto-generate the nonce, and don't allow it to be specified)?
If the answer is yes, then use of these APIs still isn't possible due to the the inclusion of the nonce that will be used for encryption in the preAuth value (i.e. this requires a deterministic encryption API, which is not available in swift-sodium). So I'm thinking that the more likely answer is no?
So far, libsodium 2.0.0 has not materialized. I don't think we should worry too much about what @jedisct1 does with 2.0.0 until it has landed and everyone is using it.
After discussing with @aidantwoods in a separate issue (https://github.com/aidantwoods/swift-paseto/issues/5), it looks like PAE assumes that deterministic encryption is available in XChaCha20-Poly1305 encryption.
Even if specifying nonces has been made optional in
paseto-rfc-01
, it is still assumed that the same random bytes will be used in PAE and in the subsequent encryption/decryption:This is problematic because @jedisct1 plans to remove specifying nonces from the public libsodium APIs (https://github.com/jedisct1/swift-sodium/pull/173#issuecomment-441638492).