gaul
Questions about encryption implementation
First off let me say thanks for creating and sharing this project!
I'm definitely not a cypto expert but as far as I can tell PBKDF2 is used to derive the AES secret key (which is used for encryption) from a user supplied password (i.e. a Password Based Key Derivation Function - PBKDF). Various articles have popped-up (such as PSA: upgrade your LUKS key derivation function) in which it is asserted that an AES encrypted LUKS drive which used PBKDF2 as it's PBKDF was sucessfully brute forced and thereby decrypted. Long story short; PBKDF2 wasn't designed with todays GPU's in mind. You need something like argon2id instead.
I'm wondering how much of this is also a problem for the S3Proxy crypto implementation? PBKDF2 in LUKS seems to be used in a similar way in S3Proxy?
I'm also curious (not judging) as to why the encryption was not implemented by using a higher level (well audited and understood) library such as Google Tink? Which is described as:
Tink is a crypto library written by a group of cryptographers and security engineers at Google. It was born out of our extensive experience working with Google's product teams, fixing weaknesses in implementations, and providing simple APIs that can be used safely without needing a crypto background.
Are there performance reasons? Or implementation constraints which prevent the use of such higher level libraries? Tink has for example also other benefits such allowing upgrade path for encryption, ciphers, etc. It can also work with KMS implementations (AWS KMS, GCP KMS) out of the box or use a small standalone key management utility.
@FlorinPeter I realize that you probably have a busy schedule like most of us devs. But it would really be appreciated if you could help me understand (and by extension anyone relying on encryption in s3proxy) things such as if the implementation is impacted by the PBKDF2 weakening and the (technical) reasons not to use something such as Tink.