Hacker News new | past | comments | ask | show | jobs | submit login

> What we really need is a fork of Firefox.

Step up to the task yourself, then?

> and replacing their secure sync with one that drops it all on their servers presumably unencrypted as it works with a basic username/password.

Firefox Sync is every bit as end-to-end encrypted as it was before. The only difference is that it now comes with a login scheme that is actually usable.




>Step up to the task yourself, then?

Because everyone here is an uberprogrammer, right?

>Firefox Sync is every bit as end-to-end encrypted as it was before. The only difference is that it now comes with a login scheme that is actually usable.

I might have believed that before PRISM. I wouldn't even care about it sitting on Mozilla servers if I could still encrypt it with my own key instead of trusting them. Even if it is encrypted, presumably it is then derived from the user's password. For the average user, that might be 20-30 bits of entropy. Not good. I don't use sync, but if I did, now I essentially need a 2048-bit password to get good encryption on it.


> I might have believed that before PRISM.

What does this have to do with anything? How is the old sync system any different, then?

> Even if it is encrypted, presumably it is then derived from the user's password. For the average user, that might be 20-30 bits of entropy. Not good.

The other alternative here is having a sync system that your average user can't even figure out to use. On the other hand, it doesn't take anything away from you.

> I don't use sync, but if I did, now I essentially need a 2048-bit password to get good encryption on it.

You are confusing key lengths from algorithms like RSA with symmetric algorithms. The keys that are used for encrypting data will be either 128 or 256 bits (haven't checked) and used with some symmetric cipher.

Therefore, if you don't trust key stretching to be sufficient with a strong passphrase, you can grab 16 or 32 bytes of randomness, encode it however you wish and use it as a password.


>What does this have to do with anything? How is the old sync system any different, then?

The old one let you run your own server. It let you encrypt it with your own key, which you could know was generated from a good entropy source, not been shared, and is store securely. As it is, it's possible the new sync has a backdoor, even one many people at Mozilla don't know. There is also no point in deliberately increasing the attack surface for no reason.

>You are confusing key lengths from algorithms like RSA with symmetric algorithms. The keys that are used for encrypting data will be either 128 or 256 bits (haven't checked) and used with some symmetric cipher.

I may be wrong, but I thought the old sync used an RSA key as it's used for authenticating the user as well as actually saving/accessing the data (probably symmetric for the actual storage, with the key encrypted using the RSA key).


> The old one let you run your own server.

This is still possible with the new system, although I'll admit the ease and usability of such a setup needs work (and IIRC there are some changes required before android devices can properly use a third-party server; it may take a few releases before this become as easy as it was with the old system).

> As it is, it's possible the new sync has a backdoor, > even one many people at Mozilla don't know.

Both the client and server are open-source, and you can verify that the client follows the protocol [1] and doesn't leak anything more than a PBKDF2-stretched password derivative to the server. It's about as backdoor-proof as any client/server system is likely to get.

But yes, it is more dependent on the strength of your password than the previous sync system.

[1] https://github.com/mozilla/fxa-auth-server/wiki/onepw-protoc...


> The old one let you run your own server.

https://docs.services.mozilla.com/howtos/run-sync-1.5.html

> It let you encrypt it with your own key

Huh? No, it didn't. The key was generated automatically by the client just like it is now.

> As it is, it's possible the new sync has a backdoor, even one many people at Mozilla don't know.

How do you know the old one didn't? You have to trust Mozilla at some point. What if the client generates bad encryption keys on purpose, or so on?

> I may be wrong, but I thought the old sync used an RSA key as it's used for authenticating the user as well as actually saving/accessing the data (probably symmetric for the actual storage, with the key encrypted using the RSA key).

RSA keys were scrapped from the system a long time ago as they provided no benefit.


>Huh? No, it didn't. The key was generated automatically by the client just like it is now.

>What if the client generates bad encryption keys on purpose, or so on?

Fair enough, I never used it, but I was under the impression the user could generate their own, even if just as an option.

>RSA keys were scrapped from the system a long time ago as they provided no benefit.

Exactly the problem. The benefit is invisible to (most) endusers, so in Mozilla logic, it doesn't exist for the user.


> Exactly the problem. The benefit is invisible to (most) endusers, so in Mozilla logic, it doesn't exist for the user.

What is the benefit in using RSA with the sync protocol? What sort of experience do you have in the design of cryptographic protocols to comment on this? Or are you grasping at whatever random reasons you can find to take a shit on the Firefox developers?

If you're interested in the reasons why asymmetric crypto was dropped, they are here:

https://wiki.mozilla.org/Services/Sync/SimplifiedCryptoPropo...

https://wiki.mozilla.org/Services/Sync/SimplifyCrypto

TL;DR: There simply was no reason to use RSA. A faster and simpler protocol that is just as secure could be built without it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: