Questions about encryption implementation

Aperta
#515 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Documentazione
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
java
Ambito
security

Direzione di ricerca

No files or tests are named in the issue. Start by locating S3Proxy's encryption implementation and tracing how it uses PBKDF2 and AES; then assess the questions raised about key derivation and higher-level libraries. Done would require a clear, maintainers-approved answer or a defined follow-up change, but the issue does not specify one.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
2.4k
Fork
289
Merge medio
12h 52m
PR unite (30g)
22

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di gaul/s3proxy

Tutte le issue di gaul/s3proxy

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.