it uses AES-CBC
Probabilmente dovresti utilizzare la modalità EAX anziché CBC. Impedirà la manomissione dei dati crittografati (con quasi nessuno sforzo), e ti proteggerà da alcuni casi limite che influenzano la modalità CBC. Vedi questa risposta per una discussione su diverse modalità.
Le uniche modifiche che devi fare per fare questo sono usare EAX invece di CBC, e devi usare una chiave doppia più grande (una chiave a 256 bit se usi AES-128 o una 512- bit key se si utilizza AES-256). Puoi fare in modo che PBKDF2 generi una chiave di qualsiasi dimensione, ma assicurati che l'output sia la dimensione di output nativa della funzione hash, quindi se vuoi una chiave a 512 bit, usa PBKDF2-HMAC-SHA512.
I dont want to use a static IV (due to security reasons) how do i go about it? do i have to append the IV to the file and then when decrypting extract it?
Puoi memorizzare la IV come vuoi. Sembra comune anteponerlo ai dati (il prepending è leggermente più semplice, perché puoi leggere il file dall'inizio senza saltare in giro). Il formato OpenPGP è bello perché puoi usare altre applicazioni per leggere e scrivere i file (e il formato ha avuto un molta attenzione, quindi probabilmente gestisce casi che non hai ancora pensato). Ho scritto programmi che generano un file JSON, con i dati crittografati con codifica Base64 e IV come attributi. Potresti usare XML. È possibile distribuire i dati e i metadati come file separati. Dipende davvero da te.
When the encryption is finished the unencrypted file is deleted. Should i have any concerns that an attacker could recover the unencrypted file (this is an android app so the underlying storage technology is flash, and i am using the standard API to delete the file) should i implement a secure delete function or how to deal with this?
Quando elimini un file, di solito il file system lo contrassegna come eliminato in modo che altri file possano essere scritti in alto. Per risolvere il problema, è necessario scrivere sopra il file, ma non sono sicuro che ci sia un modo per garantirlo su un filesystem di journaling, specialmente se usa il flash (perché i controller flash di solito spostano i blocchi per il livellamento dell'usura). Potresti probabilmente fare questo eliminando il file, quindi scrivendo un file gigante che occupa tutto lo spazio libero sul dispositivo, quindi cancellando quel file.
Il modo migliore per garantire che i dati privati non siano lasciati decodificati sul disco è di non scriverli mai sul disco in modo non criptato, ma sembra che non sia un'opzione per il tuo programma.
The files are encrypted using a 256-Bit key derived by PBKDF2. PBKDF2 needs a salt for which i use a hash of the users password is this a bad idea?
Un unico sale proteggerà il tuo sistema da un gran numero di vulnerabilità, quindi dovresti sicuramente usarlo.
does the salt has to be random?
Non deve necessariamente essere casuale, ma deve essere unico. La casualità è solitamente il modo più semplice per ottenere valori unici.
if so how do i deal with it do i have to append the salt to the file to perform decryption?
Memorizza il sale nello stesso modo in cui memorizzi il IV.
Probabilmente vuoi anche memorizzare il numero di iterazioni PBKDF2, in modo da poter aumentare il valore predefinito in futuro, e comunque essere in grado di decifrare i file più vecchi. Assicurati che il numero di iterazioni sia sufficientemente alto. Per confronto, iOS utilizza PBKDF2 con 10.000 iterazioni durante l'archiviazione delle password. A meno che il tuo programma non sia in esecuzione su un tostapane, non hai scuse per impostare il valore più basso di quello.