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?
  • If you stored a static salt, would that storage also be at risk to the "pull off" attack? – Russ Sep 13 at 16:46
  • 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). – Petar Donchev Sep 13 at 19:10
  • @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! – jfr3000 Sep 14 at 5:01
  • @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. – jfr3000 Sep 14 at 5:03
  • @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. – Petar Donchev Sep 14 at 7:08
up vote 0 down vote accepted

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.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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