[Cryptography] Recommendations for short AES passphrases

[ıuoʎ]

On Mon, Sep 19, 2016 at 2:04 AM, Kent Borg <kentborg at borg.org> wrote:
> Looking at hashcat speeds (https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40) on an 8-GPU system (pretty affordable for many values of "medium"), is a lot slower, but dang impressive. The comments say the PBKDF2 numbers are all 1,000-rounds, I don't know which matches your proposal.

So from this benchmark it seems like 26156.2 kH/s of PBKDF2-HMAC-SHA1
at 1000 rounds.
which means it can find a single key in less than 2 months.
and I can only assume a cost of ~ 2000$ per key.
this is probably way more secure than the implementation need to be,
but I can see why it feels a bit weak.

Any way I notified the service owner about the issues with the current keys.
I offered him to have default mode where long keys and urls endpoints
are generated and only
use shorter ones if the user explicitly chooses to.
I offered him to have 12 chars passphrase for the short length mode

As for the PRNG that actually chooses the password.
The current implementation used Math.random() which is not
cryptographically secure.
The best option would probably be to use the browser Crypto API
getRandomValues but that might not be available on all browsers
and I couldn't actually find what the actual implementation so I hope
we can trust the browser vendors on this one.
Since the encryption is using CryptoJS I thought he might be able to
use its PRNG but when I looked at the implementation it seems like
there using `Donald Knuth's linear congruential PRNG` which from what
I could find online is also not cryptographically secure.
I find it a bit weird that a crypto lib PRNG wont be cryptographically
secure so maybe I got it wrong.