Also aes-1024 sounds like some proprietary thingy, not something people should probably trust anyway...
> It turned out that the key derivation function was PBKDF2 using 1000 iteration of MD5 to derive the encryption key. The salt used to derive the keys is constant and hardcoded in all the solutions and all the vendors. This makes it easier for an attacker to guess the user password of a vault using time/memory tradeoff attack techniques such as rainbow tables and to re-use the tables to retrieve passwords for all users using the software. The implementation itself was incorrect and even with a randomly generated unique salt, it would be effortless to recover the password of a user.
I'd stick with veracrypt for now.
This ends up being a common usability issue whenever a user is asked to provide a passphrase for some sort of symmetrical encryption scheme. The user is almost never given any guidance to allow them to chose a passphrase strong enough for the system in use. So they end up with a dictionary word with a digit on the end and have no way to know that they have not actually protected anything. It ends up being sort of a con in practice. The user is allowed to believe that the system is much more convenient to use than it actually is.
The system under consideration is not really any worse than other things in this.
a dictionary word with common letters substituted with a number, case-sensitive, and one or two punctuation.. that is "not protected anything" ? .. almost any two dictionary words put together, not even case sensitive also "not protected anything" ? the out-of-breath security analysis is bothersome and lead us to mandatory ten characters of garble and other extreme anti-user patterns.. I am looking at a stack of forty accounts with passwords as an ordinary library user.. not convinced of this expert analysis today
Or, we could look at the two-words-separated-by-punctuation case. Same 5,000 word lexicon, maybe 10 different symbols likely to show up between the words. Call that ~250,000,000 possibilities for your password. That'll take up to a day to crack. A day is a long time to spend on one password, but maybe they don't have anything better to do. Maybe they hate you personally. Add another word, suddenly the hackers need years per password, which is obviously uneconomical.
These guidelines don't come out of nowhere, and there isn't really a tower of experts somewhere giggling at the unwashed idiots around them (well, there might be, but I wasn't invited). This is just one of many problems in computing that live around the intersection of math and psychology, where the "natural" thing to do is (unintuitively) quite dangerous.
each word, of say at least four characters.. with a "simple substitution of a letter with a number" .. which number? 10x per substitution..
add one or two special characters.. how many special characters are there? lets say numerals plus at least 16 more (counts key caps).. one or two adds means .. up to (10+16) squared more combinations
two words.. square that again? what am I missing? a brute force attack on that many combinations better include the right set of special characters.. because you will never match if you do not have the right set of characters in your brute force, right?
now, "10,000 hashes per second under these conditions" means you have hashed the guess, and compare to the hashed stored answer.. sure that is fast.. maybe you can do it, but did you say that you have a copy of the database and can run constant, undetected brute force in private for "forever" ? is that common? specific answers welcome
First of all, every single devices shares a common, constant salt. Although that doesn't simplify a single instance of an attack on the key-derivation function, it permits the construction of rainbow tables to trade off storage against time and attack all devices simultaneously.
Secondly, the key-derivation function has a flawed construction. In PBKDF2, if you need more key bits than the hash function outputs, you repeat the process varying a value that's concatenated to the salt as the initial input. This means the cost to generate a key to test scales with the length of the key. In this implementation, the salt + constant is not actually an input in the hash function at all, but instead XOR'd against the result of the hash.
As a result, you get no increase in work factor at all.
There are other problems in the implementation of the actual cipher (AES-CTR is malleable, not authenticated; keys longer than 128 bits are only actually using half of the additional key bits - "AES-1024" only uses 576 bits of the generated key) but the KDF is the real problem.