131–140 of 203 posts
This is really neat. I really love the idea and the presentation. I would not trust my backups to your service yet , just because of the "this is a prototype" language. My immediate thought is, "this seems great, I'll have to come back and check it out once it's more of a real business". But therein lies the rub, I think: what will drive me back to check it out later? There doesn't seem to be a mailing list to sign u…
Two reasons why I do not want to use the service in its current state (meant as constructive criticism): 1. If I would send my backups to some SASS there is no way I would do that without encryption. 2. I like to backup my filesystem and not just the files in it (to make sure I've got everything and make restoring easy). Currently, I just dd my block devices, but I am sure that could be optimized to not upload a comp…
That's actually not a good idea at all.
It's very fragile, the slightest problem and you may lose the entire backup.
Silent corruption may get backed up for months and you won't notice until it's too late.
Doing a restore means having space for the full file, just to restore a single small file.
If you don't know when your file changed you may have to do that multiple times instead of just being able to check when that single file changed.
In short: don't do that. Copy the full directory structure, sure. But not the disk image.
Calling it Unix friendly but not supporting ssh (and thus sftp/rsync/etc) seems like quite a weird choice, and one that’s lost you a potential customer.
(Alternative product recommendation, please downvote/remove if you feel that isn't appropriate) For Unix/Linux backups, may I suggest Borg Backup? It encrypts and does dedupe astonishingly well. It also works over SSH incredibly fast, and restores are via a mounted FUSE filesystem so they're easy to pick and choose what you need. It prunes really well too, and is a single executable so it's easy to distribute via Ans…
> Trial 1 Month 0.1E > Subscription: 5E per Month > ... > I decided to charge 5$ (0.1$ trial) So which is it? $ or E? And is E supposed to be €? Also, in English the currency marker goes to the left of the number.
I used E because € does not render on xterm, maybe I should switch it to EUR to remove the confusion also fixed the $ to E in the blog, thanks for the heads up
Earlier quoted context omitted.
The encryption in Borg is weak but otherwise it works well if it fits your use case.
Can you give more details on how the encryption is weak?
1. Borg's authenticated encryption is a composition of AES-256 in CTR mode and HMAC-SHA256 (or alternatively, Blake2b256). This consists of two distinct constructions. Most cryptographic vulnerabilities are introduced in the combination of distinct primitives and constructions. While combining AES-CTR and HMAC is a way of doing authenticated encryption, it's not the safest way. As a specific example - in order to avoid introducing a nonce-misuse vulnerability, Borg needs to implement specific logic beyond the construction to ensure that the CTR counter (containing a randomized nonce) is not reused. This kind of overhead is dangerous because it adds a lot of room for a developer to make a fatal mistake.
It would be much better to use a dedicated authenticated encryption scheme, like AES-GCM. AES-GCM is a more complex construction, but it also has very convenient interfaces and language bindings which obviate the need for developers to interact with raw primitives and constructions entirely. You don't need to implement AES-GCM so much as call its seal and unseal operations from your language of choice. There's far less room to footgun yourself here. The even more modern method would be to use something in the ChaPoly family. For example, XSalsa-Poly1305 goes one step further than AES-GCM by using an extended nonce. ChaPoly constructions also have ubiquitous language bindings and easily used interfaces to safe implementations.
2. Borg uses OpenSSL directly. This is not great because libcrypto exposes raw primitives directly to the developer. To its credit, Borg's documentation does provide a few reasons why its use of OpenSSL is trustworthy. But those reasons are more to do with TLS implementations than cryptographic constructions. As with above, working directly with raw primitives provides a lot of room for implementation errors and avoidable security vulnerabilities. It's generally better to abstract away your cryptography implementation to a known-good, trustworthy source which you can just call via a straightforward (and opinionated) interface. For example Borg could use NaCL instead, which would provide XSalsa-Poly1305 encryption out of the box. I hypothesize they'd eliminate a few hundred lines of code with NaCL instead of OpenSSL.
That being said, I don't know if I'd call Borg's encryption "weak." It's not ideal, and I don't personally trust it. But it's not like they're using AES in ECB mode or Mac-Then-Encrypt CBC mode.
I love the UX for this.. why haven't we seen more of going back to UNIX principles? I'm also curious.. why and what ML do you want to add?
i think the problem needs exploration, i have been bitten by bad anomaly detection and setting up alerts post-moretm after losing data one too many times :)
i imagine creating a bunch of features such as:
* file extension
* time of upload
* delta from previous version
* size difference from other files in the directory
* etc..
when a file version is "weird", so we could send notifications such as:
> hey is this file ok?
with some exploration factor, even using UCB will(should) be better than nothing
I plan to use vowpal wabbit's contextual bandits with only 2 actions, "send notification"/"dont send notification" given all the context
this of course will be just extra on top of the manual alert rules, but hopefully it will save some data :)
If the users agree we could also publish anonymized datasets with labeled data (such as: given context alert was sent: was [good]/[bad])
Which will be awesome.
Earlier quoted context omitted.
Can you give more details on how the encryption is weak?
I'm not the person you responded to, but here are my observations: 1. Borg's authenticated encryption is a composition of AES-256 in CTR mode and HMAC-SHA256 (or alternatively, Blake2b256). This consists of two distinct constructions. Most cryptographic vulnerabilities are introduced in the combination of distinct primitives and constructions. While combining AES-CTR and HMAC is a way of doing authenticated encryptio…
> It would be much better to use a dedicated authenticated encryption scheme, like AES-GCM.
Actually, in the scheme Borg uses, which is vulnerable to repeating IVs/nonces, using AES-GCM or Chapoly (or indeed any Wegman-Carter authenticator) would not only delete confidentiality, but also authenticity, i.e. it wouldn't just disclose plaintext to the attacker, but allow an attacker to potentially change your backups [1].
> That being said, I don't know if I'd call Borg's encryption "weak." It's not ideal, and I don't personally trust it. But it's not like they're using AES in ECB mode or Mac-Then-Encrypt CBC mode.
I'm calling it out as weak because it is an insufficient and poor design. If you say encrypted today it should better be up to me throwing my encrypted data up on a random cloud server and be sure that it's actually encrypted. This is not the case with Borg; partial credit for getting some aspects of the construction right (e.g. EtM, separate keys, properly salted master key encryption key derivation) isn't worth much when it fails to provide confidentiality in not-at-all unreasonable, practical usage.
[1] Probably not because by necessity Borg uses a separate HMAC over the plaintext for deduplication, and the manifest has a third layer of HMACing due to protocol issues, so it should be impossible to just change stuff even if you break the ciphertext authentication.
> Trial 1 Month 0.1E > Subscription: 5E per Month > ... > I decided to charge 5$ (0.1$ trial) So which is it? $ or E? And is E supposed to be €? Also, in English the currency marker goes to the left of the number.
I used E because € does not render on xterm, maybe I should switch it to EUR to remove the confusion also fixed the $ to E in the blog, thanks for the heads up