0
$\begingroup$

I am building an Android app that will run purely locally on the user's device, no servers. It has a database that I want to encrypt with the user's password, which requires a 64 byte key. I've considered these 2 ways:

  1. Use bcrypt, but that doesn't give me 64 bytes
  2. Use SHA512 which is much faster to brute-force

The problem with both is that I don't have a reliable place to store a random salt. The "attack scenario" would be someone pulling the database file off the phone and using a rainbow table to decrypt.

Should I:

  1. add a static salt anyway?
  2. use bcrypt and just fill the missing bytes with 0s, because it's more important that generating a rainbow table be hard?
  3. use SHA512?
  4. something else entirely?
Improve this question
$\endgroup$
5
  • $\begingroup$ If you stored a static salt, would that storage also be at risk to the "pull off" attack? $\endgroup$
    – Russ
    Commented Sep 13, 2018 at 16:46
  • $\begingroup$ I don't understand why you can't store salt if you can store database file. Use good stretching hash in all cases - argon2 is the current recommendation. 32 bytes / 256 should be strong enough output for any purpose (to attack directly). $\endgroup$
    – Petar Donchev
    Commented Sep 13, 2018 at 19:10
  • $\begingroup$ @PetarDonchev I can't store the salt in the database because the database is encrypted and i want to use the salt to decrypt it. Will check out argon2! $\endgroup$
    – jfr3000
    Commented Sep 14, 2018 at 5:01
  • $\begingroup$ @Russ, yes, by static I meant just putting it in my code. The attacker could easily retrieve it but would at least have to make a custom rainbow table for this app. Not sure if that makes much sense. $\endgroup$
    – jfr3000
    Commented Sep 14, 2018 at 5:03
  • $\begingroup$ @jft3000 Of course you cannot store salt IN the database, but what prevents you to store in the same storage where you store the database. Anyway, with high enough parameters for stretching it may be fine to use 'static' salt. $\endgroup$
    – Petar Donchev
    Commented Sep 14, 2018 at 7:08

1 Answer 1

Reset to default
1
$\begingroup$

BTW, rainbow tables are more thing of the past. They were time / space tradeoffs and currently rainbow tables of most plausible sizes can be generated in seconds by serious crackers - that is, they are not useful. Salt is still recommended to hide the fact when two people have the same password - but you are not using hashing for password storage, so unless you store the generated key hash somewhere, salt is not helping (you only have the encrypted database, not a hash of the password). One would need a rainbow table for all possible passwords in some set and all possible databases (within some constraints). Storage requirements would be insane. I wouldn't be worrying for rainbow tables if I understand the setup correctly.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.