4 ms·

For your KDF, how did you select the parameters for Argon2id? How often is the KDF invoked / what are your requirements for speed in KDF'ing? Nit, but your "p

by d-z-m 2y ago

For your KDF, how did you select the parameters for Argon2id? How often is the KDF invoked / what are your requirements for speed in KDF'ing? Nit, but your "pepper" is confusingly named IMO, because it is hardcoded and not secret. "label" may make more sense. However, one thing to keep in mind with the use of a static(and public) Argon2 salt is that it allows an attacker to pre-compute keys. If this package were to gain adoption, I think that may become a bigger issue. I would reccommend randomly generating a 128 bit salt, similar to how you're randomly generating the key if one isn't provided.

ncruces 2y ago
I used the parameters suggested in the documentation [1], which follow the RFC. The KDF is invoked every time a connection is opened iff you specify your key with the textkey= parameter. It is ill advised to overuse this, especially if you don't use connection pooling, as it makes opening connections slow. You can bypass the KDF by providing your own 256-bit key using either the hexkey= or key= parameters (key= cannot embed NULLs). I agree pepper confusing (because the pepper is supposedly secret), but this is not a salt either, as a salt is supposed to be public, but unique. Do you have better naming that you can suggest? Anyway, I forgot to do this, but the intention was for the pepper to be changeable as a build parameter. Thanks for reminding me! [1] https://pkg.go.dev/golang.org/x/crypto/argon2#IDKey https://pkg.go.dev/golang.org/x/crypto/argon2#IDKey
- d-z-m 2y ago
  > I used the parameters suggested in the documentation [1], which follow the RFC Where in the RFC is your parameter set mentioned? I don't see it anywhere[0]. The only parameter set I see mentioned with memory requirement as low as 64 MiB have t=3, not t=1. I believe the Go documentation might be outdated. [0]: https://datatracker.ietf.org/doc/rfc9106/ https://datatracker.ietf.org/doc/rfc9106/ > I agree pepper confusing (because the pepper is supposedly secret), but this is not a salt either, as a salt is supposed to be public, but unique. Do you have better naming that you can suggest? If it's tweakable at build, perhaps pepper makes more sense.
  - ncruces 2y ago
    Yep, I just made it tweakable at build, which was always the intent, although I expect the default to be popular. https://github.com/ncruces/go-sqlite3/blob/67d859a5/vfs/adiantum/adiantum.go#L14 https://github.com/ncruces/go-sqlite3/blob/67d859a5/vfs/adia... That's unfortunate about the default parameters, but note that you can also replace the KDF altogether (besides just not using it). You just need to implement this interface, with any HBSH construction and KDF: https://github.com/ncruces/go-sqlite3/blob/67d859a5/vfs/adiantum/api.go#L54 https://github.com/ncruces/go-sqlite3/blob/67d859a5/vfs/adia... If you keep the HBSH and change the KDF, your file format will be “compatible.”
    - d-z-m 2y ago
      > That's unfortunate about the default parameters, but note that you can also replace the KDF altogether (besides just not using it). Right...I would argue if you're going to expose it to users as an option, your parameter set should meet the minimum hardness parameter set in the RFC. Yours is falling off the bottom.
      - ncruces 2y ago
        I don't disagree, and after some consideration and testing, will use the RFC recommendation of 3 iterations, 4 lanes, 64 MiB RAM. However, it's also important to take note of how the KDF is used, and what is used by comparable solutions in equivalent settings. For instance, the official extension, sold by the SQLite authors, uses RC4: “For the "-textkey" option, up to 256 bytes of the passphrase are hashed using RC4 and the hash value becomes the encryption key. Note that in this context the RC4 algorithm is being used as a hash function, not as a cryptographic function, so the fact that RC4 is a cryptographically weak algorithm is irrelevant.” The textkey= parameter is not really appropriate for interactive use, rather it is a convenient way for a user to specify a key in text form, as a URI parameter, without weakening it (by e.g. making NULs impossible, and reserved characters inconvenient to encode). If you're taking a password from a user interactively, you should really be using your own password hashing, then using hexkey=. I'll try to make this clearer in the documentation.

by d-z-m 2y ago

ncruces 2y ago

I used the parameters suggested in the documentation [1], which follow the RFC. The KDF is invoked every time a connection is opened iff you specify your key with the textkey= parameter. It is ill advised to overuse this, especially if you don't use connection pooling, as it makes opening connections slow. You can bypass the KDF by providing your own 256-bit key using either the hexkey= or key= parameters (key= cannot embed NULLs). I agree pepper confusing (because the pepper is supposedly secret), but this is not a salt either, as a salt is supposed to be public, but unique. Do you have better naming that you can suggest? Anyway, I forgot to do this, but the intention was for the pepper to be changeable as a build parameter. Thanks for reminding me! [1] https://pkg.go.dev/golang.org/x/crypto/argon2#IDKey https://pkg.go.dev/golang.org/x/crypto/argon2#IDKey

d-z-m 2y ago
> I used the parameters suggested in the documentation [1], which follow the RFC Where in the RFC is your parameter set mentioned? I don't see it anywhere[0]. The only parameter set I see mentioned with memory requirement as low as 64 MiB have t=3, not t=1. I believe the Go documentation might be outdated. [0]: https://datatracker.ietf.org/doc/rfc9106/ https://datatracker.ietf.org/doc/rfc9106/ > I agree pepper confusing (because the pepper is supposedly secret), but this is not a salt either, as a salt is supposed to be public, but unique. Do you have better naming that you can suggest? If it's tweakable at build, perhaps pepper makes more sense.
- ncruces 2y ago
  Yep, I just made it tweakable at build, which was always the intent, although I expect the default to be popular. https://github.com/ncruces/go-sqlite3/blob/67d859a5/vfs/adiantum/adiantum.go#L14 https://github.com/ncruces/go-sqlite3/blob/67d859a5/vfs/adia... That's unfortunate about the default parameters, but note that you can also replace the KDF altogether (besides just not using it). You just need to implement this interface, with any HBSH construction and KDF: https://github.com/ncruces/go-sqlite3/blob/67d859a5/vfs/adiantum/api.go#L54 https://github.com/ncruces/go-sqlite3/blob/67d859a5/vfs/adia... If you keep the HBSH and change the KDF, your file format will be “compatible.”
  - d-z-m 2y ago
    > That's unfortunate about the default parameters, but note that you can also replace the KDF altogether (besides just not using it). Right...I would argue if you're going to expose it to users as an option, your parameter set should meet the minimum hardness parameter set in the RFC. Yours is falling off the bottom.
    - ncruces 2y ago
      I don't disagree, and after some consideration and testing, will use the RFC recommendation of 3 iterations, 4 lanes, 64 MiB RAM. However, it's also important to take note of how the KDF is used, and what is used by comparable solutions in equivalent settings. For instance, the official extension, sold by the SQLite authors, uses RC4: “For the "-textkey" option, up to 256 bytes of the passphrase are hashed using RC4 and the hash value becomes the encryption key. Note that in this context the RC4 algorithm is being used as a hash function, not as a cryptographic function, so the fact that RC4 is a cryptographically weak algorithm is irrelevant.” The textkey= parameter is not really appropriate for interactive use, rather it is a convenient way for a user to specify a key in text form, as a URI parameter, without weakening it (by e.g. making NULs impossible, and reserved characters inconvenient to encode). If you're taking a password from a user interactively, you should really be using your own password hashing, then using hexkey=. I'll try to make this clearer in the documentation.