1

I am considering switching over to Brave and maybe also use it's sync feature for settings, and maybe even passwords if it's good enough. I do use a password generator but out of laziness I happen to sometimes store passwords locally.

In their FAQ they state that they use a seed that's then stretched with scrypt(N = 2^13, r = 8, p = 11). This is the first head scratcher. According to C.Percival, the KDFs creator, in 2017(!) 32k iterations should be made, iirc the recommended parameters back then were (N=32768, r=8 or 16, p=1).

Second, they use AES128-CTR-HMAC, which is not listed by SSL Labs best practices.

The question is, does any of this matter? Why, why not? Would you deem Brave Sync secure enough to use for syncing passwords across devices, given that my devices are properly protected and I only sync passwords to accounts that matter less or that have 2FA if they do matter?

EDIT: As has been pointed out, in the comments, there's nothing wrong with AES128-CTR and the scrypt parameters mentioned above were specified in regard to interactive logins, where (usually weaker) user-passwords are hardened instead of a generated seed.

However it still seems weird to me that a task that often requires multiple executions per second(sending packets via TLS) often employs "stronger" encryption schemes(AES-256 GCM has got to be stronger than the suite used, even if it only comes down to the doubled key-size) than this Brave Sync, even though the latter most likely isn't executed that often; maybe only on demand/after a change. Here waiting for 5 seconds to pack/unpack should be easily tolerable. I just don't see why you wouldn't use rather high parameters when sending user's unhashed(!) passwords around.

6
  • 2
    "Second, they use AES128-CTR-HMAC, which is not listed by SSL Labs best practices." - SSL Labs is about TLS. But AES128-CTR-HMAC is not a TLS cipher and it is also not used for TLS in this use case and thus not covered by TLS best practices. See also What is wrong with AES-CTR-HMAC-SHA256 - or why is it not in TLS?. – Steffen Ullrich Jan 25 at 4:50
  • "According to C.Percival, the KDFs creator, in 2017(!) 32k iterations should be made, iirc the recommended parameters back then were (N=32768, r=8 or 16, p=1)" - This recommendation is specifically about interactive logins, which is clearly not the case here. Instead "... the passphrase to be the BIP39 encoding of the sync seed..." – Steffen Ullrich Jan 25 at 4:56
  • Why does symmetrically encrypting a password safe require "less tough" encryption suits than TLS? I don't quite get what's the benefit of speeding this probably once a day operation up a bit for the cost of harder KDF and stronger encryption? – jaaq Jan 25 at 8:17
  • 1
    @jaaq If you read the Q/A Steffen linked to, you'll see that AES-CTR-HMAC is not "less tough" than TLS encryption suites. As for the scrypt parameters, the reason you can use weaker parameters is that the seed used is a BIP39 encoding of the sync seed (which I imagine has much better entropy than the typical user's password) so using less intense parameters doesn't reduce security. – nobody Jan 25 at 9:23
  • 1
    "Also you didn't quite answer my question" - that's why I did not write an answer but only used comments to add relevant context to your question, i.e. to point out problems with your arguments. – Steffen Ullrich Jan 25 at 15:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.