-
I’d be 100% down with a peer to peer syncing solution, but considering they’re using azure to store everything centrally it makes me question how they intend to sustain this service and their longevity.
-
bitwarden is currently sponsored by the Microsoft BizSpark program which covers many of our operation costs and allows us to offer services for free to our users. We are working on our monetization strategy which will introduce additional premium features in the future. For now though, everything is free for users.
-
-
I use pass to manage my passwords, and instead of using the integrated Git support for syncing, I know I’ll get lazy and forget to commit and push at times, I use Syncthing to keep everything in sync across all my devices. Syncthing works very well for me, easy to install and configure and adding other devices is trivial to do.
-
-
IPFS is great! I’ve used it to sync large files between my home and remote nodes from time to time.
If all you keep are website + password pairs (no username/login ID), then even if the encryption employed by IPFS is “broken”, the risk profile is still very low as any intermediary node that has a copy of your file will have no way of figuring out which user ID to pair with the password.
-
-
-
This is nice to see, it is a bit sad to see that
bectlmay not launch with support with separate boot pools (affecting users with a boot pool and an encrypted root pool) but I understand Allan’s point about consistency between the snapshots. Although it seems that native encryption in OpenZFS is coming along nicely for FreeBSD-current which should help the situation, just doesn’t seem to play nice if you also use dedup in ZFS.New installations of FreeBSD 12.0-RELEASE (when it comes out) should not need a separate boot pool. But, yeah, systems upgrading to 12 from 11 may have a separate boot pool. I’d argue that with how awesome 12 is shaping out to be, a fresh reinstallation would be a good idea.
The OpenZFS native encryption implementation may suffer from the same types of watermarking vulnerabilities that plague the Oracle ZFS implementation. It would be best to stick with geli until the native crypto receives more cryptanalysis.
For the FreeBSD 12.0-RELEASE: definitely agree once it’s out a reinstall maybe worth considering, it’s just down to how well the encrypted pool support will work (I have not tried FreeBSD 12-ALPHA2 yet so I can’t say).
As for the OpenZFS native encryption, my take on the discussion in the linked mailing list thread is that the watermarking attack stems around how deduplication works in ZFS, so if you don’t need the dedup feature then it shouldn’t be as susceptible to watermarking vulnerabilities. Definitely something that needs heavy testing to be validated. Otherwise yes if you need/want dedup enabled on your encrypted pool, or don’t want to take the risk that it may still in fact be vulnerable, then for now sticking with geli would be wise, I was just saying that progress seems to be coming along nicely on that front.
Yup. There’s also potential attacks when compression is enabled. So, if you enable native encryption, you’ll want to disable both dedup and compression. These kinds of situations are why I prefer to be a bit more cautious in adoption. I think we need multiple cryptographers analysing this from multiple angles.