![]() So let's generate a table for 6 to 8 characters passwords, with a simple Alphanum charset (no symbols, nothing fancy). Now say we want to generate a rainbow table, we know that qTox profile passwords have a minimum length of 6 characters. Since we use scrypt, there are high memory requirements which makes it a major pain to parallelize key-derivation or implement custom hardware for it, but let's assume an attacker with 10,000 times more computing power than my machine, that's a 0.1 Mhash/s hash rate. On my laptop each call to the KDF takes a bit over 100ms, that's 10 -5 Mhash/s. It's not that easy to get numbers for a typical scrypt hashrate nowadays since the custom scrypt parameters make it hard to compare. ![]() Let's do a quick back-of-the-envelope calculation. The key-derivation function that we use internally is libsodium's scrypt with slightly stronger than default parameters. We absolutely could find a way to use a random salt, but first let's see how practical rainbow tables are in this case to check whether there is a security issue. This static salt is used to derive a key for the history database when the qTox profile has a password set, we currently don't use a random salt mainly because the PBKDF that we use is strong enough to make rainbow tables impractical by itself, and second because there's no obvious place to store that random salt (as it can't easily be written in the database file itself without confusing SQLite). Hi, I wrote this code so I'll try to clear things up a little! ![]() Though not explictly stated, it does mention that tox_derive_key_from_pass (which should be used for initial key derivation) uses a random salt. */ bool tox_derive_key_with_salt( const uint8_t *passphrase, size_t pplength, const uint8_t *salt, TOX_PASS_KEY *out_key, ![]() * The salt must be TOX_PASS_SALT_LENGTH bytes in length. * Same as above, except use the given salt for deterministic key derivation. * * returns true on success */ bool tox_derive_key_from_pass( const uint8_t *passphrase, size_t pplength, TOX_PASS_KEY *out_key, * * Note that this function is not deterministic to derive the same key from a * password, you also must know the random salt that was used. * The key should only be used with the other functions in this module, as it * includes a salt. * The password is zeroed after key derivation. * Be sure to not compromise the key! Only keep it in memory, do not write to disk. out_key must be at least * TOX_PASS_KEY_LENGTH bytes long. * Generates a secret symmetric key from the given passphrase. The PRAGMA directive apparently causes sqlite to perform it's own encryption operation using the given key. Such use of the salt guarantees that everyone's db file will have a different salt (and thus lookup/rainbow tables become ineffective).Įdit: The static-salted key is being saved as a PRAGMA within the DB, but doesn't seem to be otherwise used, I'm continuing to investigate. As such, during initial generation, the salt should be randomly generated from a TRNG or a CSPRNG source and then stored with the database file. The concept of a salt, especially in this case is such that it changes the way a hashing function or PBKDF works, preventing a single pre-generated rainbow table from being used against the chat history database. QTox's database key derivation routine uses a static salt, this is incredibly dangerous and detrimental to the security of the chat database file. Not sure if that's meant as a joke or something but since this singular byte array is set during compile time, all users who use pre-compiled binary versions or did not change this salt would have the same salt, effectively negating the password salt.Īn attacker can simply generate a rainbow table with this specific salt, and given access to the database file, attempt a brute-force attack that's amortized by his/her pre-generated table.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |