| |||||||||||||
Howto fix the problem:Howto fix the problem:Posted Oct 14, 2009 21:49 UTC (Wed) by drag (subscriber, #31333)Parent article: Ubuntu to store copies of all users' address books
The way you get around this syncing and lingering re and fear about handing
over personal information to a corporation is through encryption.
That is the data is encrypted on the client prior to being sent up into the
Very simple, very effective and should quell people's fear. AES256 should be
(Log in to post comments)
Howto fix the problem: Posted Oct 14, 2009 23:42 UTC (Wed) by gdt (subscriber, #6284) [Link] Even with encryption, traffic analysis can still reveal information you'd rather keep private.
Howto fix the problem: Posted Oct 15, 2009 0:11 UTC (Thu) by drag (subscriber, #31333) [Link]
Like what? That I use Evolution or not? How much information I feel like
backing up?
I really doubt there is much useful information that anybody could gleam from
Traffic analysis can surprise Posted Oct 15, 2009 2:27 UTC (Thu) by jreiser (subscriber, #11027) [Link]
The date and time of contact with the database are useful to those who might want to track you and those with whom you communicate. A Snoop can learn a lot by correlating that data with all the other data that is available. Many times the result is "only" classification into broad categories, but sometimes a very specific inference can be drawn.
Traffic analysis can surprise Posted Oct 15, 2009 4:15 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
if someone is after you specifically, _anything_ you do can be significant.
however, if someone is not after you specifically, but is just after things that they can sell, it becomes much easier to have reasonable defenses
"I don't have to outrun the bear, I just have to outrun you"
with "you" being enough other users that the bad guys don't get around to bothering with me.
yes, this is security by obscurity, and if someone decides to go after you it doesn't help much, but the reality is that for the vast majority of people this really is good enough.
Howto fix the problem: Posted Oct 15, 2009 1:19 UTC (Thu) by msebast (guest, #57130) [Link]
Yes. Encryption should be part of the marketing message. Make it clear that the only thing Canonical knows is that you stored some data and they can't tell what's in there.
I guess Elilot Murphy's email was intended for people who already know what couchDB is.
I've heard about couchDB a few times but never seen any mention of encryption. So I've always assumed this is something I don't want and didn't investigate further.
Howto fix the problem: Posted Oct 15, 2009 2:18 UTC (Thu) by drag (subscriber, #31333) [Link]
Yeah. I don't think that couchdb does any sort of encryption either.
I am very uninterested in any sort of "cloud" backup scheme that does not
Why? (a person may ask) A few reasons. Whether or not a person should trust
The other thing is that it makes storage side a lot cheaper and a lot
This makes things cheaper; I only have to keep a database of hashes and
As you can imagine that if I was a third party provider of storage that
Howto fix the problem: Posted Oct 15, 2009 4:09 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the only issue with encrypting the data before you send it up to the cloud is where you store your encryption keys.
if you loose those keys you loose your data, so it does no good to store your data in multiple places if your keys only exist on one machine.
for many people who do not have good ways to store the keys, they are actually better of in many ways with the data in the clear so that they can pull it back down to a replacement machine if something happens to the first one.
yes, this is not good from a security point of view, but in this case the security risks need to be balanced against the availability risks. which one is more important will vary from person to person.
Howto fix the problem: Posted Oct 15, 2009 5:33 UTC (Thu) by drag (subscriber, #31333) [Link]
For important things I write down my passwords and put them in my wallet.
Then I also save another copy somewhere else.
The choice is simple really.
Do you want to keep track of a password..
All in all it is a massive undertaking trying to keep data safe and
And it's hugely expensive undertaking, to boot. It is virtually impossible
Meanwhile if your job is to handle already encrypted data then it is much
It is not difficult to print out copies of your keys into ascii armor
(and, frankly, the notion that you should never write down your passwords
If you value your data and want to be able to use Ubuntu's cloud service
Howto fix the problem: Posted Oct 15, 2009 7:22 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
do you want to run the risk of loosing everything if you loose the password? or are you willing to take the risk that someone will break in through the Canonical security, download your data, dig through it to find something interesting, and take action on it?
I would not use their service personally (I would do the client-side encryption and keep track of the key), but I know a lot of users who I would recommend use something like this so that when they trash their system badly enough that they need to reinstall their systems they will still have their data. Many of these users have trouble remembering one password for their system, let alone taking appropriate actions to protect an encryption key.
Howto fix the problem: Posted Oct 15, 2009 8:02 UTC (Thu) by ekj (guest, #1524) [Link]
I have a laptop, it does backups to a fileserver in the basement. It also does encrypted backups to a backup-service on the internet. The latter is there for the case that our house is burglarised, or burn down, or some other disaster destroys BOTH laptop AND fileserver at the same time.
And yes, if that happens AND I've forgotten the password for the encryption, it's acceptable for me to suffer data-loss. We're talking miniscule probabilities here. (I'd have to forget the password I use for logging in every day at the precise same time that something catastrophic happens at home. That's a level of risk that is entirely acceptable to me.)
Sending my entire digital world to some random company on the internet, for them and anyone that aquires, breaks into, subpoenas or otherwise gains access to their servers ? No thank you, not interested.
Howto fix the problem: Posted Oct 15, 2009 17:39 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
you are not the common case (neither am I), we can and do take steps like this so that we do not have a single point of failure.
we also don't need a service like this because we can replicate and protect things ourselves.
this service is intended for people who otherwise are not backing things up, let alone replicating an encryption key for the backup.
Howto fix the problem: Posted Oct 15, 2009 13:19 UTC (Thu) by sourcejedi (guest, #45153) [Link]
Won't help. They still need their launchpad password.
If you can trust someone to hold your launchpad password in escrow, you can surely trust them to do the same with your encryption password.
In practice, I suspect you can just reset your launchpad password by email. So you have to rely on your ISP resetting your email password when you forget _that_. And that they don't go bust or disconnect you for using too much bandwidth making online backups :-)...
Yes, many people are likely to accept this service given the choice. But this is a pretty low bar to pass. We can and should do better.
Howto fix the problem: Posted Oct 15, 2009 16:23 UTC (Thu) by drag (subscriber, #31333) [Link]
> do you want to run the risk of loosing everything if you loose the
password? or are you willing to take the risk that someone will break in through the Canonical security, download your data, dig through it to find something interesting, and take action on it?
It is easy to keep a password or key safe. Print it out into a hard copy
Then it is win on both sides. As long as you make it absolutely known that
I suppose if customers trust Canonical then they can just send them the
Howto fix the problem: Posted Oct 15, 2009 17:37 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
you would be amazed at the number of people so do not protect their important documents like this.
Howto fix the problem: Posted Oct 15, 2009 10:14 UTC (Thu) by nix (subscriber, #2304) [Link]
If the encryption key is relatively 'bare' (i.e. it's not made clear in the keyfile what service's data it's encrypting), just keep the encryption key on a USB key. Even if you drop it on a train, nobody who picks it up will have a clue what it's meant to decrypt.
(Now everyone else can tell me how stupid this idea is.)
Howto fix the problem: Posted Oct 15, 2009 16:33 UTC (Thu) by drag (subscriber, #31333) [Link]
I save my important passwords on a LUKS-encrypted SD card. (it is small and
fits in my wallet and my laptops have SD support)
The LUKS password is relatively simple (plain english phrase), but it
When you plug it into a Linux Gnome desktop automatically prompts you for
I can't recommend this approach to normal folks because it only works if
But what is better (in terms of security) would be to print out keys into
Howto fix the problem: Posted Oct 15, 2009 17:36 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
and a flood or fire would destroy your printout as well as your computer.
Howto fix the problem: Posted Oct 15, 2009 11:06 UTC (Thu) by endecotp (guest, #36428) [Link]
> I am very uninterested in any sort of "cloud" backup
> scheme that does not integrate encryption on the client > side.
Does anyone know how to get rsync-like functionality with the data at the other end stored encrypted?
I currently use rsync over ssh for some of my backups, so the data is encrypted on the wire but unencrypted on the remote disk. When I set this up I tried to find a way of storing the remote copy encrypted without losing rsync's efficient incremental transfers, but I didn't find anything satisfactory. Any ideas?
Check out Tarsnap Posted Oct 15, 2009 12:26 UTC (Thu) by fghorow (subscriber, #5229) [Link]
From Colin Percival, the (Free?)BSD Security officer.
Just a happy user of the service.
(Be aware, it is a *for a fee* service, but the micropayments are truly micro!)
Howto fix the problem: Posted Oct 15, 2009 13:09 UTC (Thu) by sourcejedi (guest, #45153) [Link]
Try encfs + rsync. Encfs will encrypt both file content and names. (It won't hide filesizes, directory topology, permissions, and the approximate _lengths_ of filenames).
http://ubuntuforums.org/showthread.php?t=148600
Howto fix the problem: Posted Oct 15, 2009 16:01 UTC (Thu) by zooko (subscriber, #2589) [Link]
Tarsnap seems like a well-engineered system, from reading the author's blog, but as far as I know
the server-side code is proprietary. The Tahoe-LAFS project (I'm a contributor) has excellent encryption and erasure-coding features and if you like duplicity you can use Tahoe-LAFS as a backend for duplicity. Also Tahoe-LAFS comes with its own integrated backup system which has different trade-offs than the duplicity backend. (Duplicity does deltas for you, but you can't view or download your files without going through duplicity. The Tahoe-LAFS integrated backup doesn't do deltas, but it stores the files in a time-machine-style layout which you can browse and download through the web.)
AES security Posted Oct 15, 2009 8:25 UTC (Thu) by job (guest, #670) [Link]
If you are paranoid you should use AES128 instead of 256 as there are indications that the larger key isn't diffused properly.
AES security Posted Oct 16, 2009 7:40 UTC (Fri) by brouhaha (subscriber, #1698) [Link] I'm sufficiently paranoid that I much prefer 3DES to either AES128 or AES256. AES hasn't been subjected to anywhere near the amount of cryptanalysis as DES. If I didn't think 112 bits of key was enough to withstand brute-force attacks, I'd use two rounds of 3DES with different sets of keys (6DES).
AES security Posted Oct 16, 2009 13:02 UTC (Fri) by pharm (guest, #22305) [Link]
Just using the same encryption algorithm twice with two different keys of size N does not increase
the exhaustive search time from 2^n to 2^2n, thanks to meet-in-the-middle attacks, which reduce the time to 4^n. IOW in return for doubling your key size you've increased the search time by a factor of 2: That doesn't seem a good tradeoff.
Leave designing encryption algorithms to the experts: Personally, I know just enough to know that I
AES security Posted Oct 16, 2009 19:22 UTC (Fri) by brouhaha (subscriber, #1698) [Link]
The meet in the middle attack reduces the time from 2^(2n) to 2^(n+1). This is why 3DES (even with 168 bits of keying) only effectively gives 112 bits of security. That's why I didn't propose 4DES, which wouldn't have any improvement in security over 3DES. However, my proposed 6DES would give 168 bits of security, or 8DES sould give 224, etc. 6DES has the advantage that you can use an existing 3DES implementation twice.
However, that's just the time complexity. The meet in the middle attack also requires storage for 2^n blocks, which is obviously not available for n=112, let alone larger values of n.
AES security Posted Oct 16, 2009 20:08 UTC (Fri) by ABCD (subscriber, #53650) [Link]
> Just using the same encryption algorithm twice with two different keys of
> size N does not increase the exhaustive search time from 2^n to 2^2n, > thanks to meet-in-the-middle attacks, which reduce the time to 4^n.
I think there is a mistake somewhere in there, because 2^(2n) = (2^2)^n = 4^n.
AES security Posted Oct 18, 2009 16:08 UTC (Sun) by pharm (guest, #22305) [Link]
Yes, a thinko on my part.
|
|||||||||||||